[U-Boot] [PATCH 21/51] common: Extend board-specific DT fixup

[Mario Six]

Hi Simon,

On Wed, Jul 19, 2017 at 11:05 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Mario,
>
> On 14 July 2017 at 05:55, Mario Six <mario.six at gdsys.cc> wrote:
>> Commit 2a79275 ("dm: Add callback to modify the device tree")
>> implemented a board-specific callback that can modify U-Boot's device
>> tree before relocation to accomodate a range of hardware variations of
>> certain boards.
>>
>> However, this approach only turns out to be useful when the copy of the
>> device tree before relocation is actually writeable. If e.g. a device
>> boots out of a NOR flash, this scheme does not work, since the
>> modification of the flash's contents is not possible, and the unmodified
>> device tree is relocated and used by U-Boot.
>>
>> To circumvent this problem, we split the modification process into two
>> phases.
>>
>> In phase one we only collect information about the board by querying the
>> hardware (reading GPIO values, probing I2C chips, etc.), and store the
>> obtained information in a special, board-specific structure that is part
>> of the global data structure. This phase runs prior to relocation, and
>> utilizes the pre-relocation DM to query hardware information.
>>
>> In phase two, we read the information back from the structure, and do
>> the actual manipulation of the device tree. This phase occurs *after*
>> the relocation of the U-Boot image, but before the driver model is
>> initialized from the device tree. Since the device tree lives in RAM
>> alongside the U-Boot image after relocation, the tree is definitely
>> writeable at this point.
>>
>> Each phase is implemented by a board-specific callback function: phase
>> one by board_fix_fdt_get_info, which takes no arguments, and phase two
>> by board_fix_fdt_change, which takes the writeable device tree blob as
>> its sole argument. Since the structure where the gathered hardware
>> information is stored is necessarily board-dependent, we create a
>> include file where the boards utilizing the functionality can define
>> their individually needed structures.
>>
>> This commit also adapts the controlcenterdc board's fixup function to
>> the new schem
>
> Thanks for the clear explanation.
>
> I have two ideas:
>
> - Can we move the call to the existing function to after reloc_fdt(),
> when the DT is in RAM?
>

That might work, but I'm not sure if it was one of the scenarios which didn't
work for some reason that I tried out before. I'll have to test it.

> - Or can we move this board to use a livetree and adjust the DT using
> livetree functions instead? That might be more efficient.
>

That was actually plan A, but even after applying some of your recent livetree
patches (for ns16550 and such), the boot got stuck very early on, so I didn't
follow this option more than that. It would, of course, be the cleanest
solution, but considering the amount of drivers that would need conversion, and
the absence of actual DT manipulation functions (include/dm/write.h doesn't
exist yet), it's a pretty daunting task.

But I'll look into it.

> Regards,
> Simon
>

Best regards,

Mario