Hi Bin,
On 3 November 2018 at 03:48, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Sat, Nov 3, 2018 at 2:08 PM Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 1 November 2018 at 20:25, Bin Meng bmeng.cn@gmail.com wrote:
On Sun, Oct 28, 2018 at 9:31 PM Adam Ford aford173@gmail.com wrote:
On Wed, Oct 24, 2018 at 8:32 AM Bin Meng bmeng.cn@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=*&... [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?
OK yes I get it. I've pulled these into dm/testing and will do a pull request tomorrow for Tom.
Regards, Simon