Hi Simon, On Sat, Nov 3, 2018 at 2:08 PM Simon Glass <s...@chromium.org> wrote: > > Hi Bin, > > On 1 November 2018 at 20:25, Bin Meng <bmeng...@gmail.com> wrote: > > On Sun, Oct 28, 2018 at 9:31 PM Adam Ford <aford...@gmail.com> wrote: > >> > >> On Wed, Oct 24, 2018 at 8:32 AM Bin Meng <bmeng...@gmail.com> wrote: > >> > > >> > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > >> > bound before relocation. However due to a bug in the DM core, > >> > the flag only takes effect when devices are statically declared > >> > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > >> > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > >> > lists_bind_fdt()", but with the fix, it has a side effect that > >> > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > >> > be bound before relocation now. This may expose potential boot > >> > failure on some boards due to insufficient memory during the > >> > pre-relocation stage. > >> > > >> > To mitigate this potential impact, the following changes are > >> > implemented: > >> > > >> > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > >> > only supports configuration from device tree (OF_CONTROL) > >> > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > >> > is statically declared via U_BOOT_DEVICE() > >> > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > >> > drivers that support both statically declared devices and > >> > configuration from device tree > >> > > >> > This series should be applied on top of u-boot-dm/master, for > >> > v2018.11 release. > >> > > >> > > >> > Bin Meng (13): > >> > arm: stm32mp: Remove DM_FLAG_PRE_RELOC flag > >> > clk: Remove DM_FLAG_PRE_RELOC flag in various drivers > >> > gpio: Remove DM_FLAG_PRE_RELOC flag in various drivers > >> > i2c: omap24xx: Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check > >> > mmc: omap: Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check > >> > pinctrl: Remove DM_FLAG_PRE_RELOC flag in various drivers > >> > ram: bmips: Remove DM_FLAG_PRE_RELOC flag > >> > timer: Remove DM_FLAG_PRE_RELOC flag in various drivers > >> > serial: Remove DM_FLAG_PRE_RELOC flag in various drivers > >> > sysreset: Remove DM_FLAG_PRE_RELOC flag in various drivers > >> > video: simplefb: Remove DM_FLAG_PRE_RELOC flag > >> > watchdog: Remove DM_FLAG_PRE_RELOC flag in various drivers > >> > dm: doc: Update description of pre-relocation support > >> > > >> > >> This works just fine for me on the am3517_evm and the omap3_logic boards. > >> > >> Tested-by Adam Ford <aford173@gmailcom> > >> > > > > Thanks Adam and Stephen's testing. > > > > Simon, > > > > Looks we don't have too much time before release, would you please > > test and send the PR? > > > > Another series > > (http://patchwork.ozlabs.org/project/uboot/list/?series=70686) > > needs to be pulled in to unblock x86 too. > > I had assumed we could wait to the next release. > > Could you please explain what you are wanting me to do here?
Short version: As I mentioned in this series' cover letter, "This series should be applied on top of u-boot-dm/master, for v2018.11 release.". The other x86 series should be applied for this release too. The long story: In [1] I said: "It looks that I have to send out a fix to correct Tegra in this release now, and leave other clean ups in next release.", was because I think the clean up changes are massive and only Stephen reported the Tegra was broken by previous series [2] which was applied in *u-boot-dm/master* so initially I only wanted to send out the Tegra fixes. However later Stefan reported in [3] that some x86 boards just don't boot with *u-boot/mater*. Then I had a look and suggested adding DM_FLAG_PRE_RELOC flag to x86 CPU drivers, which was the x86 fixes series [4] I mentioned above. However the issue is that without my fix in series [2], the x86 fix just doesn't work. Then I mentioned that in [5] I said "I spent some time to clean up all driver usage about DM_FLAG_PRE_RELOC flag" and it should fix Tegra (reported) as well as other potential (un-reported) broken. [1] https://lists.denx.de/pipermail/u-boot/2018-October/345085.html [2] http://patchwork.ozlabs.org/project/uboot/list/?series=70150&state=*&q=&archive=both [3] https://lists.denx.de/pipermail/u-boot/2018-October/344266.html [4] http://patchwork.ozlabs.org/project/uboot/list/?series=70686 [5] https://lists.denx.de/pipermail/u-boot/2018-October/345479.html Note both my previous series [2] and x86 fix series [4] are attempting to fix the side effect brought up by c0434407b595 ("board_f: Use static print_cpuinfo if CONFIG_CPU is active") which was part of the MPC83xx CPU uclass driver support. So the root cause is the MPC83xx changes. But I am not sure if we can revert that patch easily now, as I suspect many later commits are dependent on that one, and we may break some more stuff if we revert that. Up to now, I see some 'Tested-by' tags were provided for this series, I think we are good to go. Does this make sense? Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
