GSoC'18-Introduction

[Russell Haley]

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:
>>>>> 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: 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.