On Tue, Jan 30, 2018 at 02:29:27PM +0530, Jagan Teki wrote:
On Tue, Jan 30, 2018 at 1:54 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
On Mon, Jan 29, 2018 at 01:49:14PM +0530, Jagan Teki wrote:
On Mon, Jan 29, 2018 at 1:32 PM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
On Sun, Jan 28, 2018 at 09:49:38PM +0530, Jagan Teki wrote:
U-Boot size is crossing MMC environment offset due to adding new features on arm64 boards. So update the ENV_OFFSET to 0x100000 so the u-boot size limit increased to 0xf6000
MMC layout(updated):
part: sector: size unused: 0: 8KiB SPL: 16: 32KiB U-Boot: 80: 984KiB uENV: 2048: 128KiB
Signed-off-by: Jagan Teki jagan@amarulasolutions.com
env/Kconfig | 3 ++- include/configs/sunxi-common.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/env/Kconfig b/env/Kconfig index 692f863..e2b32c2 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -441,7 +441,8 @@ config ENV_OFFSET hex "Environment Offset" depends on !ENV_IS_IN_UBI depends on !ENV_IS_NOWHERE
default 0x88000 if ARCH_SUNXI
default 0x88000 if ARCH_SUNXI && !ARM64default 0x100000 if ARCH_SUNXI && ARM64This breaks all existing platforms. NAK.
Can you elaborate, what it breaks. 32 bit sunxi start with 0x88000 and 64-sun start with 0x100000 this is what I expecting here.
If you have an environment already flashed, flashing the new u-boot will overwrite it, and might break any partition layout you have set.
True, but we can't control this adding new stuff ultimately increasing size. either we can stop working new features or increasing partition size, do you have any other suggestions?
https://lists.denx.de/pipermail/u-boot/2017-December/314940.html
Why do you think we went into so great troubles recently?
Certainly yes, MUSB_GADGET increasing u-boot.itb 548K
u-boot.itb exceeds file size limit: limit: 516096 bytes actual: 560088 bytes excess: 43992 bytes make: *** [u-boot.itb] Error 1 make: *** Waiting for unfinished jobs..
That's not my question. Why do you think we had some many discussions, debates and patches if we could have done so from the beginning?
Sorry, can't understand please explain it little bit.
We've had: https://patchwork.ozlabs.org/cover/828100/ https://patchwork.ozlabs.org/cover/851904/ https://patchwork.ozlabs.org/cover/864994/
That were doing everything we could to *not* move the location of the environment in order to address the issue. Why do you think we did that?
Maxime