Am 02.03.2018 um 00:53 schrieb Chris Johns: > On 01/03/2018 18:42, Christian Mauderer wrote: >> Am 01.03.2018 um 08:07 schrieb Russell Haley: >>> On Wed, Feb 28, 2018 at 3:24 AM, Udit agarwal <[email protected]> wrote: >>>> Hi, >>>> Sorry for late reply, i am having my mid term examinations ongoing. >>>> >>>> So as of now, I'm having following two short term tasks: >>>> *Adding a check on targets that needs FDT , and then raising an >>>> error/warning rather then a crash if missing FDT >>>> *Implementation of getentropy() on BBB >>>> >> >> These would be two tasks that you can try out as first steps. Please >> note that this have only been suggestions. If you would like to do >> something else, you can have a look at that too. >> >> The getentropy() implementation should be a quite small and >> straightforward patch that you can implement and send to the mailing list. >> >> The FDT might need some discussion before you implement it. In the best >> case, that one would work for all boards and not only the BBB. Note that >> the devel mailing list could be the better place to discuss it. >> >>>> For the first task, i did debug a bit and found that in case of missing >>>> FDT, >>>> during kernel memory initialization i.e during mi_startup()(here), after >>>> few >>>> iterations the call function (On line 306) raises a >>>> RTEMS_FATAL_SOURCE_EXCEPTION error which as described here occurs during >>>> memory access violation. So, wrapping it with a different an exception >>>> handler, might allow us raise a more specific error regarding missing FDT >>>> blob. Do let me know if i'm on a right track! Here are the update logs. I >>>> have wrapped the the mi_startup with multiple printfs for debugging, that >>>> makes it a bit clumsy but i guess i need to stick to it before getting my >>>> Jlink segger EDU, probably in few days :0. >> >> First of all: Great that you already found out where the FATAL occurs. >> It's not that easy to go through all the layers in libbsd. Especially >> without a debugger. >> >> But I'm not sure whether catching the memory access violation would be >> the right method here. > > Agreed. > >> >> 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 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. Depending on that the FDT could just point to an empty FDT blob which should be enough to stop any crashes. 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. So a name like "rtems_bsp_networking_needs_an_fdt" would be quite misleading. I would suggest a "rtems_bsp_needs_an_fdt" instead. The BSPs that have a call to bsp_fdt_get() are: - Altera Cyclone V - IMX - qoriq Christian > > For example add bsps/include/bsp/rtems-fdt.h with: > > bool rtem_bsp_has_fdt(void); > bool rtem_bsp_networking_needs_an_ftd(void); > > /* > * Called by a BSP. > */ > void rtems_bsp_set_has_fdt(); > void rtems_bsp_set_networking_needs_an_fdt(); > > The defaults are false and false. > > 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
