Handling of modular boards

[Igor Grinberg]

On 05/10/12 19:15, Stephen Warren wrote:
> On 05/10/2012 06:40 AM, Igor Grinberg wrote:
>> On 05/05/12 01:09, Mark Brown wrote:
>>> On Fri, May 04, 2012 at 10:33:57PM +0200, Wolfgang Denk wrote:
>>
>>>> On the other hand, some of the issues we're trying to solve
>>>> here for the kernel are also present in the boot loader, so
>>>> this needs to do this anyway - whether by inserting new or
>>>> modifying (enabling or disabling) existing properties in the DT
>>>> is not really relevant here.
>>
>>> FWIW if the bootloader can usefully handle this stuff I think
>>> that's a good approach but there is substantial variation in
>>> quality of implementation between bootloaders and even when the
>>> bootloader is a good one it's not always practical to update it
>>> or the data it relies on.
>>
>> I agree on this (and also with Ben), all our boards/extensions/base
>> boards/etc can be discovered in the boot loader and we will use the
>> DT to pass the relevant information on the attached extensions and
>> used base board.
>>
>> Also, most (if not all) of our boards/extensions have I2C EEPROM
>> which describes the devices on that board/extension which is useful
>> for building/extending the DT in the bootloader.
> 
> I believe that's true for all/many NVIDIA boards too.
> 
> But, duplicating all this in every bootloader might not make sense.

Yeah, I agree on this, especially when you have multiple bootloaders
for the same board...

On the other hand, that is a common problem of the open source
software - anyone can create a bootloader, publish and use it...

> Sure there are some cases where the bootloader needs this information
> (e.g. to load the kernel from an SD card that's on 1 of N plugin
> boards), but there may be much information the bootloader doesn't care
> about.
> 
> Would it make sense to write a DT-identifying-and-merging shim that
> can be executed by the bootloader, create the final DT, and then jump
> to the kernel?
> 
> Hmmm. That's probably a bad idea, since then it means needing e.g. I2C
> drivers to read the ID EEPROMs, pinmux drivers, ... in the shim.
> 
> Perhaps the common shim idea makes sense, but we need a standardized
> API it can use that all bootloaders provide for it to operate.

Let's see where we're heading:
We created/extended the DT to abstract all the SoC/board specific
(probably also undetectable) stuff away from the kernel and now we will
create a special shi(t)m that will interface the bootloader and create the DT?

I don't think it is a good idea, especially because you still need to change
the bootloader(s) and if you place the I2C/pinmux/gpio drivers inside that
shi(t)m, you duplicate the bootloader, no?

I think we should let the bootloader(s) create/extend the DT and if for some
reason a bootloader wants to separate the DT code into a shim, let it be so.

> 
> This is beginning to sound a lot like a UEFI byte code module (I
> assume; I know little about them)

That's another curse... probably we will not get away from it...

 

-- 
Regards,
Igor.