On 02/03/2018 17:12, Christian Mauderer wrote: > Am 02.03.2018 um 00:53 schrieb Chris Johns: >>> >>> I think it would be a good idea to take a look at the boot process >>> first: We have two situations: >>> >>> 1. U-Boot does loads a FDT at a specified address and provides that >>> address to the RTEMS application. The application checks the FDT at this >>> address and uses it. This should be the good case. >>> >>> 2. U-Boot does not provide a FDT. That is the error case that you hit. >>> I'm not sure whether the pointer to the FDT that normally would be >>> provided by U-Boot has a defined value or whether it's just undefined. >>> If it is undefined, a memory access violation might occur (if the >>> pointer points to some non-existing or protected memory) but it doesn't >>> have to (if the pointer points to some random but existing memory). >>> >>> So from my point of view, the first step would be to analyze what is >>> provided as FDT pointer if you boot in U-Boot without a FDT like in your >>> original boot line. >>> >>> I'm quite sure that there had been a discussion on the mailing list >>> about that somewhere during last year. Most likely when Sichen added the >>> FDT support to BBB. But I currently can't find it. >> >> My initial thought was to have a BSP level API via the BSP headers and a BSP >> indication there is a valid FDT. A BSP can also publish a flag that says >> "networking" requires an FDT so libbsd when first called from RTEMS can check >> for both conditions and abort if an FDT is needed and it is not present. >> >> I seem to remember there is a header in the FDT blob we can probe for but I >> could be wrong. > > That's right. There is a magic number in the header of a FDT that can be > checked. I'm quite sure that the libbsd should check it and don't use > the FDT blob if the header is wrong.
I think FreeBSD assumes the boot stages have all this sorted. I seem to remember when looking into the early boot stages of FreeBSD for the RPi this was the case. It searches the address space for a u-boot API signature. > I would expect that the exception > happens because the pointer to the blob is pointing somewhere invalid > (for example to NULL). So we should somehow detect whether U-Boot (or > some other boot loader) passed a valid pointer. Hmm this can become complicated, for example using U-boot's RTEMS format does not work on the RPi which is misleading. Better integration with u-boot would be a nice thing to have. > Depending on that the > FDT could just point to an empty FDT blob which should be enough to stop > any crashes. Sure that works. > BSPs that normally would expect a FDT could print an error message > during boot. The need for an FDT can be propagated in the way that you > suggested. > > I think the hard thing is to find out whether we received a valid pointer. > > Please note that not only the libbsd does use the FDT. There are at > least three BSPs that use the FDT for their drivers too. I use an FDT on a Zynq to manage the AXI register space to the PL. > So a name like > "rtems_bsp_networking_needs_an_fdt" would be quite misleading. I would > suggest a "rtems_bsp_needs_an_fdt" instead. I am running code on a BBB now without an FDT and I an happy and currently have no interest in sorting the FDT out so the 'rtems_bsp_needs_an_fdt' is also misleading and what I wanted to avoid. :) I really like the idea of an empty blob for a BSP that may need an FDT like the BBB if one is not detected. Chris _______________________________________________ users mailing list [email protected] http://lists.rtems.org/mailman/listinfo/users
