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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
