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