On Thu, Mar 1, 2018 at 10:12 PM, Christian Mauderer <[email protected]> wrote: > 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.
From the Device Tree Compiler Manual at https://github.com/dgibson/dtc/blob/master/Documentation/manual.txt#L316 - magic This is a magic value that "marks" the beginning of the device-tree block header. It contains the value 0xd00dfeed and is defined by the constant OF_DT_HEADER 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
