Am 02.03.2018 um 07:43 schrieb Chris Johns: > 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.
I think that we should be able to use U-Boots Linux format now. I'm not sure but I would expect that RTEMS format in U-Boot could be deprecated. > >> 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. :) Yes, right. I would currently return a "false" in the BBB too. But as soon as libbsd is linked, that should be overwritten with a true so that an error message is shown. Might get a little tricky to sort out the correct link order. > > 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. Yes. But a warning would be nice if an empty blob is used. Otherwise it's even harder to find out what's wrong then if a exception happens. > > Chris > -- -------------------------------------------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: [email protected] Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ users mailing list [email protected] http://lists.rtems.org/mailman/listinfo/users
