[U-Boot] re-use dm data for pre-relocate and post-relocate[Please note, mail behalf by sjg at google.com]

[Kever Yang]

Simon,

    Thanks for you reply to this mail, and it's surprised that it's a
mail which is more than one years ago at Nov 2017 :)

    I have implement re-use kernel dtb in my local branch in 2018, you
can see how I do it here[0] with USING_KERNEL_DTB macro if you have
interest for it.

    I'm not sure if I can get all this upstream, looks like people on
U-Boot prefer to use one dts per board according to comments in my
another mail thread about remove mmc node 'vmmc-supply' for rk3288.

    I think it works pretty well for Rockchip and it's convenient for
most of our costumers.


Thanks,

- Kever

[0] https://github.com/rockchip-linux/u-boot

On 12/29/2018 05:12 AM, Simon Glass wrote:
> Hi Kever,
>
> On Tue, 21 Nov 2017 at 03:24, Kever Yang <kever.yang at rock-chips.com> wrote:
>> Hi Simon,
>>
> There are a lot of points in here, so I will spread my comments
> throughout your email.
>
>>      In order to make people easier to maintain a U-Boot for product,
>>
>> we want to re-use the dtb from kernel. Some peripheral like power/pmic
>>
>> and display panel, key, charger which need work in U-Boot and may different
>>
>> in different product, we want to make people only maintain kernel dts,
>> but not
>>
>> one more U-Boot project for all these devices.
> That sounds like a good idea. The U-Boot and kernel .dts should be the
> same. But in some cases we may need changes made to the kernel version
> to support U-Boot. Unfortunately this has proven quite tricky and I'm
> not aware of any U-Boot change that has been accepted. Admittedly I
> have not tried for a number of years, so perhaps the reviewers are
> more amenable now.
>
>> I want to do this just around the
>>
>> relocate, need to read dtb from storage like emmc/nand/spi, and then use
>>
>> a new dtb for initr_dm after relocate.
> This seems OK, but why? Do you mean that U-Boot should read the
> kernel's DTB and use that after relocation? The problem is that it
> needs to be loaded from somewhere, and you need the DT for U-Boot to
> work. So you add a pre-reloc DT with just enough drivers for loading
> the post-reloc DT. But why bother? You may as well just load the full
> thing.
>
>>      Here are issues I have met:
>>
>> - The kernel dts may not have a stdout in chosen, we may use earlycon,
>> earlyprintk instead;
> I suppose U-Boot could support this, but IMO it would be better to
> upstream the change for stdout.
>
>>      this lead to U-Boot can not find a serial driver after relocate;
>>
>> - no alias for mmc device which is need by  U-Boot but not used in kernel;
> Again, we could upstream a change.
>
>> - not able to init mmc driver twice with current driver;
>>
>>      mmc driver not able to work before relocate, no bss for (static int
>> initialized), and hang even
> Well you cannot access BSS before relocation. If you use DM then it
> should not need to access BSS. You should be able to use the
> uclass-private data instead.
>
>>      if I skip this;
>>
>>      mmc driver can init and read dtb before initr_dm, but not able to
>> init again after initr_dm.
> Why not? That seems like a bug.
>
>>
>> In fact, I don't think we have to re-init serial driver and mmc driver,
>> and most other driver which
>>
>> need pre-relocate like clock, the only driver I have seem have different
>> use in pre-relocate and post-relocate
> Yes that's true, but the idea has never been implemented.
>
>> is video driver(no idea why it have to be pre-relocate, we always have
>> display very late),
> The video driver is only inited before relocation to find out the
> amount of memory it needs to be allocated. It does not actually probe
> it fully.
>
>> can we add a tag for re-use the dm driver data for those with pre-relocate ?
> Yes I think it could work like this:
>
> - initr_dm() remembers the old dm_root pointer
> - post-reloc drivers can request access to the priv/platdata/uc_priv
> from before relocation, e.g. using:
>
> int dm_get_pre_reloc_dev(struct udevice *dev, struct udevice *pre_reloc_devp);
>
> this returns the pre-reloc device associated with the post-reloc
> device 'dev', if available.
>
> Regards,
> Simon
>