On Thu, Apr 12, 2018 at 05:21:27PM +0200, Sjoerd Simons wrote:
On Wed, 2018-04-11 at 16:58 -0400, Tom Rini wrote:
On Wed, Apr 11, 2018 at 09:26:40PM +0200, Sjoerd Simons wrote:
Since commit 8e14ba7bd524 ("gpio: omap_gpio: Add DM_FLAG_PRE_RELOC flag") omap GPIO gets bound before relocation. Unfortunately due to this, on at least the beaglebone black, the pre-relocation memory pool gets exhausted before probing the serial port. This then causes u- boot to panic as CONFIG_REQUIRE_SERIAL_CONSOLE is set...
Ah, so, you're using am335x_boneblack_defconfig and not am335x_evm_defconfig which is why I didn't see this problem myself.
Resolve this by doubling the default size of the pre-relocation malloc pool on mach-omap2.
Signed-off-by: Sjoerd Simons sjoerd.simons@collabora.co.uk
arch/arm/mach-omap2/Kconfig | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach- omap2/Kconfig index 3bb1ecb58d..02c5a4c0b8 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -186,4 +186,7 @@ source "board/compulab/cm_t43/Kconfig" config SPL_LDSCRIPT default "arch/arm/mach-omap2/u-boot-spl.lds"
+config SYS_MALLOC_F_LEN
- default 0x0800
This isn't the first bad example, ugh, but we shouldn't go this route. Ideally we should modify the top-level Kconfig, as that declares SYS_MALLOC_F_LEN, to be default 0x800 if ARCH_OMAP2PLUS.
Fwiw I proposed it that way around as various machs (tegra, zync, bmips, meson, integrator, etc) and the x86 arch seems to doing it like that.
Right. Those are bad examples I should migrate :(
That said, most of the am335x platforms set SYS_MALLOC_F_LEN to either 0x1000 or 0x2000. At this point, I would recommend tweaking configs/am335x_evm* and configs/am335x_boneblack* to be consistent and use 0x1000 as I don't know if the HS variants can safely be pushed up to 0x2000 (adding in Andrew). Thanks!
Happy to prepare a patch for that; but the one thing that worries me is that there are probably more defconfigs broken due to this then just those. So changing the default via kconfig is probably more robust.
I'm a little worried too, frankly. We could do default 0x1000 if AM33XX in the top-level Kconfig file for now, and see about bumping it up to 0x2000 for ARCH_OMAP2PLUS for the next release.