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 >> >> 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
