GSoC'18-Introduction

[Christian Mauderer]

Am 02.03.2018 um 07:43 schrieb 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.

I think that we should be able to use U-Boots Linux format now. I'm not
sure but I would expect that RTEMS format in U-Boot could be deprecated.

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

Yes, right. I would currently return a "false" in the BBB too. But as
soon as libbsd is linked, that should be overwritten with a true so that
an error message is shown. Might get a little tricky to sort out the
correct link order.

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

Yes. But a warning would be nice if an empty blob is used. Otherwise
it's even harder to find out what's wrong then if a exception happens.

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