GSoC'18-Introduction

[Chris Johns]

On 02/03/2018 17:12, Christian Mauderer wrote:
> Am 02.03.2018 um 00:53 schrieb Chris Johns:
>>>
>>> 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 think FreeBSD assumes the boot stages have all this sorted. I seem to remember
when looking into the early boot stages of FreeBSD for the RPi this was the
case. It searches the address space for a u-boot API signature.

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

Hmm this can become complicated, for example using U-boot's RTEMS format does
not work on the RPi which is misleading.

Better integration with u-boot would be a nice thing to have.

> Depending on that the
> FDT could just point to an empty FDT blob which should be enough to stop
> any crashes.

Sure that works.

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

I use an FDT on a Zynq to manage the AXI register space to the PL.

> So a name like
> "rtems_bsp_networking_needs_an_fdt" would be quite misleading. I would
> suggest a "rtems_bsp_needs_an_fdt" instead.

I am running code on a BBB now without an FDT and I an happy and currently have
no interest in sorting the FDT out so the 'rtems_bsp_needs_an_fdt' is also
misleading and what I wanted to avoid. :)

I really like the idea of an empty blob for a BSP that may need an FDT like the
BBB if one is not detected.

Chris