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.y...@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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot