BBB hello does not run...

Wed Jun 23 09:33:35 UTC 2021

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 the problem:
>>>
>>> https://git.rtems.org/rtems/commit/?id=56074644a733ecc984722da2a1b61736275270c0
>>>
>>> Hmmmmm.... 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 (0x00000016)
>>>> 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 at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/