christian.mauderer at embedded-brains.de
Fri Mar 2 06:12:30 UTC 2018
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 <dev.madaari at gmail.com> wrote:
>>>> 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.
>> 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
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
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
> 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.
embedded brains GmbH
Herr Christian Mauderer
email: christian.mauderer at embedded-brains.de
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.
More information about the users