GSoC'18-Introduction

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

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