russ.haley at gmail.com
Fri Mar 2 06:44:50 UTC 2018
On Thu, Mar 1, 2018 at 10:12 PM, Christian Mauderer
<christian.mauderer at embedded-brains.de> 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 <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.
>From the Device Tree Compiler Manual at
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
> 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
>> 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
> Dornierstr. 4
> D-82178 Puchheim
> 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