Re: BBB hello does not run...

2021-06-23 Thread Christian MAUDERER

Hello Chris,

Am 23.06.21 um 10:41 schrieb Chris Johns:

Hi Christian,

Thanks for the reply.

My uboot SD card does not have any FDT blobs so this is the reason for the
failure. We seem to now have a dependency on an FDT. I have played a bit and
found the cause of the error:

https://git.rtems.org/rtems/tree/bsps/shared/ofw/ofw.c#n86

I have no problem with the FDT being used in RTEMS but I do have some concerns
about how we handle things. A hard error here is a bit abrupt and maybe just not
having the drivers installed and available would be a better solution. An app
will fail when the driver does not exist. On the other hand a hard error is fine
if we packaged the FDT blob in the executable, something we currently do not do.


The big advantage of the FDT is that we can support multiple Beagle 
variants without problems. Big disadvantage is that we need the FDT.


With the current direction, sooner or later (or maybe already 
implemented) the BSP will also get the information for the serial 
interface from the FDT. As soon as that happens, it won't be really 
possible to start a useful application without the FDT.


What would be alternative approaches? We could continue to add special 
cases in the code for variants. Or we could basically write a similar 
source of information like the FDT. In that case most likely it would be 
the better idea to write a minimal FDT that is linked into the BSP.




I think we should consider the single executable approach to handling FDT blobs,
that is embedding the blob into RTEMS. This is not something we can reach in a
simple single step plus we have the licensing issue but I feel we can make it
happen.


It's really quite easy to embedd a DTB into the executables. Difficult 
part is compiling the FDT to a DTB. After that it's only using 
rtems_bin2c to convert it into a c file and return a pointer to that 
array in bsp_fdt_get().


Disadvantage (beneath licensing) of a FDT blob in the binary is that the 
binary then is fixed for one beagle variant. If the FDT is separate, the 
same binary works for pocketbeagle or BBB. But that's only a small 
disadvantage. It only means that we need more variants.




The first step I am looking at is the building of the FDT source with includes.
A command in the rtems-tool that is installed would be a good first step. The
FreeBSD script is a good base but it is all a bit awkward to get to and use.


I agree that this would be a great improvement. We could use that kind 
of tool regardless what solution we find.


I think the big problem with FDTs is that they can have difficult 
licenses. GPL is the most prominent example and it's the case for a lot 
of FDTs based on the Linux sources. But it could also be a blob with 
some odd vendor license generated by some toolchain (for example for 
FPGA / CPU combo chips like Zynq).


Possible approaches are:

1) Do something similar like FreeBSD: Add a "GPL" or maybe rather a 
"other licenses" subdirectory to RTEMS and collect FDTs there. We could 
put a defined FreeBSD FDT export, special blobs or similar into that 
directory. A BSP can then generate (for example with your planned tool) 
the matching blob from these sources and provide it as a separate file 
in the default case. Alternatively a BSP option with a clear name (like 
"BSP_I_WANT_TO_INTEGRATE_GPL_LICENSED_FDT_BLOB_INTO_THE_BINARY") could 
link it directly into the binary.


2) Keep the FDTs with odd licenses in a separate repo or on an FTP. That 
won't allow to link them into the binaries but it would keep the tree 
clean of other licenses.


From my point of view, the first one would be an OK solution - at least 
if no one finds a better one. It would need a good structure and a good 
idea how to make it absolutely clear that the code is not RTEMS 
licensed. Beneath that it would need clear rules that it is _only_ for 
FDT so that we avoid getting other non-RTEMS-licensed code there too. 
But it should be somehow possible and it would simplify the handling for 
the user.


Best regards

Christian



Chris

On 23/6/21 5:10 pm, Christian Mauderer wrote:

Hello Chris,

there is no new requirement that I know of. The driver should parse the same FDT
fields that have been parsed by libbsd earlier. It only want's to avoid the
double initialization that had been done by RTEMS and libbsd.

But there is a simple method how we can find out whether it's FDT related:
Please try the dtb that I normally use:

     https://nc.c-mauderer.de/index.php/s/JntMtLrE2GpH2Xf

That FDT is build from the FreeBSD sources from that revision:


https://github.com/freebsd/freebsd-src/tree/19a6ceb89dbacf74697d493e48c388767126d418


Note: I don't think that using that FDT is a solution. It's just to find out
whether it's the problem. A solution would be to find a method how we can
distribute matching FDTs with various licenses.

Best regards

Christian

On 23/06/2021 07:24, Chris Johns wrote:

I have bisect'ed the failure and this is the commit that is 

Re: BBB hello does not run...

2021-06-23 Thread Chris Johns
Hi Christian,

Thanks for the reply.

My uboot SD card does not have any FDT blobs so this is the reason for the
failure. We seem to now have a dependency on an FDT. I have played a bit and
found the cause of the error:

https://git.rtems.org/rtems/tree/bsps/shared/ofw/ofw.c#n86

I have no problem with the FDT being used in RTEMS but I do have some concerns
about how we handle things. A hard error here is a bit abrupt and maybe just not
having the drivers installed and available would be a better solution. An app
will fail when the driver does not exist. On the other hand a hard error is fine
if we packaged the FDT blob in the executable, something we currently do not do.

I think we should consider the single executable approach to handling FDT blobs,
that is embedding the blob into RTEMS. This is not something we can reach in a
simple single step plus we have the licensing issue but I feel we can make it
happen.

The first step I am looking at is the building of the FDT source with includes.
A command in the rtems-tool that is installed would be a good first step. The
FreeBSD script is a good base but it is all a bit awkward to get to and use.

Chris

On 23/6/21 5:10 pm, Christian Mauderer wrote:
> Hello Chris,
> 
> there is no new requirement that I know of. The driver should parse the same 
> FDT
> fields that have been parsed by libbsd earlier. It only want's to avoid the
> double initialization that had been done by RTEMS and libbsd.
> 
> But there is a simple method how we can find out whether it's FDT related:
> Please try the dtb that I normally use:
> 
>     https://nc.c-mauderer.de/index.php/s/JntMtLrE2GpH2Xf
> 
> That FDT is build from the FreeBSD sources from that revision:
> 
> 
> https://github.com/freebsd/freebsd-src/tree/19a6ceb89dbacf74697d493e48c388767126d418
> 
> 
> Note: I don't think that using that FDT is a solution. It's just to find out
> whether it's the problem. A solution would be to find a method how we can
> distribute matching FDTs with various licenses.
> 
> Best regards
> 
> Christian
> 
> On 23/06/2021 07:24, Chris Johns wrote:
>> I have bisect'ed the failure and this is the commit that is the problem:
>>
>> https://git.rtems.org/rtems/commit/?id=56074644a733ecc984722da2a1b61736275270c0
>>
>> Hm Is there a new requirement on the needed FDT for a 
>> beagleboneblack.
>>
>> Chris
>>
>>
>> On 23/6/21 2:52 pm, Chris Johns wrote:
>>> Hi,
>>>
>>> hello.exe is not running. Any hints?
>>>
>>> master at ...
>>>
>>> https://git.rtems.org/rtems/commit/?id=b47dbbc5f7c8518634c7c5fccd57d78c65444f2d
>>>
>>> config.ini:
>>> [DEFAULT]
>>> BUILD_TESTS = False
>>> RTEMS_DEBUG = True
>>> RTEMS_POSIX_API = True
>>>
>>> [arm/beagleboneblack]
>>> BUILD_TESTS = True
>>>
>>> output:
>>>
>>> RTEMS Beagleboard: am335x-based
>>>  ARM Debug: 0x4b141000
>>>
>>> *** FATAL ***
>>> fatal source: 1 (INTERNAL_ERROR_RTEMS_API)
>>> fatal code: 22 (0x0016)
>>> RTEMS version: 6.0.0.4977dc74c60e75b90fe8dd72e4dedafd55d70c73
>>> RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
>>> 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
>>> executing thread ID: 0x089010001
>>> executing thread name: IDLE
>>>
>>> Chris
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: BBB hello does not run...

2021-06-23 Thread Christian Mauderer

Hello Chris,

there is no new requirement that I know of. The driver should parse the 
same FDT fields that have been parsed by libbsd earlier. It only want's 
to avoid the double initialization that had been done by RTEMS and libbsd.


But there is a simple method how we can find out whether it's FDT 
related: Please try the dtb that I normally use:


https://nc.c-mauderer.de/index.php/s/JntMtLrE2GpH2Xf

That FDT is build from the FreeBSD sources from that revision:


https://github.com/freebsd/freebsd-src/tree/19a6ceb89dbacf74697d493e48c388767126d418

Note: I don't think that using that FDT is a solution. It's just to find 
out whether it's the problem. A solution would be to find a method how 
we can distribute matching FDTs with various licenses.


Best regards

Christian

On 23/06/2021 07:24, Chris Johns wrote:

I have bisect'ed the failure and this is the commit that is the problem:

https://git.rtems.org/rtems/commit/?id=56074644a733ecc984722da2a1b61736275270c0

Hm Is there a new requirement on the needed FDT for a beagleboneblack.

Chris


On 23/6/21 2:52 pm, Chris Johns wrote:

Hi,

hello.exe is not running. Any hints?

master at ...

https://git.rtems.org/rtems/commit/?id=b47dbbc5f7c8518634c7c5fccd57d78c65444f2d

config.ini:
[DEFAULT]
BUILD_TESTS = False
RTEMS_DEBUG = True
RTEMS_POSIX_API = True

[arm/beagleboneblack]
BUILD_TESTS = True

output:

RTEMS Beagleboard: am335x-based
 ARM Debug: 0x4b141000

*** FATAL ***
fatal source: 1 (INTERNAL_ERROR_RTEMS_API)
fatal code: 22 (0x0016)
RTEMS version: 6.0.0.4977dc74c60e75b90fe8dd72e4dedafd55d70c73
RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
executing thread ID: 0x089010001
executing thread name: IDLE

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel




___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: BBB hello does not run...

2021-06-22 Thread Chris Johns
I have bisect'ed the failure and this is the commit that is the problem:

https://git.rtems.org/rtems/commit/?id=56074644a733ecc984722da2a1b61736275270c0

Hm Is there a new requirement on the needed FDT for a beagleboneblack.

Chris


On 23/6/21 2:52 pm, Chris Johns wrote:
> Hi,
> 
> hello.exe is not running. Any hints?
> 
> master at ...
> 
> https://git.rtems.org/rtems/commit/?id=b47dbbc5f7c8518634c7c5fccd57d78c65444f2d
> 
> config.ini:
> [DEFAULT]
> BUILD_TESTS = False
> RTEMS_DEBUG = True
> RTEMS_POSIX_API = True
> 
> [arm/beagleboneblack]
> BUILD_TESTS = True
> 
> output:
> 
> RTEMS Beagleboard: am335x-based
> ARM Debug: 0x4b141000
> 
> *** FATAL ***
> fatal source: 1 (INTERNAL_ERROR_RTEMS_API)
> fatal code: 22 (0x0016)
> RTEMS version: 6.0.0.4977dc74c60e75b90fe8dd72e4dedafd55d70c73
> RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
> 4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
> executing thread ID: 0x089010001
> executing thread name: IDLE
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


BBB hello does not run...

2021-06-22 Thread Chris Johns
Hi,

hello.exe is not running. Any hints?

master at ...

https://git.rtems.org/rtems/commit/?id=b47dbbc5f7c8518634c7c5fccd57d78c65444f2d

config.ini:
[DEFAULT]
BUILD_TESTS = False
RTEMS_DEBUG = True
RTEMS_POSIX_API = True

[arm/beagleboneblack]
BUILD_TESTS = True

output:

RTEMS Beagleboard: am335x-based
ARM Debug: 0x4b141000

*** FATAL ***
fatal source: 1 (INTERNAL_ERROR_RTEMS_API)
fatal code: 22 (0x0016)
RTEMS version: 6.0.0.4977dc74c60e75b90fe8dd72e4dedafd55d70c73
RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
4e6dc6431435821a534da6307e72ecbd7e42b82a, Newlib 0c0f3df)
executing thread ID: 0x089010001
executing thread name: IDLE

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel