GSoC'18-Introduction

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