[U-Boot] [PATCH 11/11] sunxi: Add limit with the MMC environment

[Jagan Teki]

On Fri, Dec 22, 2017 at 2:18 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> On Thu, Dec 21, 2017 at 10:52:04PM +0000, André Przywara wrote:
>> Hi,
>>
>> On 21/12/17 12:40, Maxime Ripard wrote:
>> > The MMC environment offset is getting very close to the end of the U-Boot
>> > binary now. Since we want to make sure this will not overflow, add a size
>> > limit in the board for arm64. arm32 has already that limit enforced in our
>> > custom image generation.
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard at free-electrons.com>
>> > ---
>> >  include/configs/sunxi-common.h | 10 ++++++++++
>> >  1 file changed, 10 insertions(+)
>> >
>> > diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
>> > index 3855c564f914..6236e129a89d 100644
>> > --- a/include/configs/sunxi-common.h
>> > +++ b/include/configs/sunxi-common.h
>> > @@ -147,6 +147,16 @@
>> >  #endif
>> >
>> >  #if defined(CONFIG_ENV_IS_IN_MMC)
>> > +
>> > +#ifdef CONFIG_ARM64
>>
>> Why is that? Isn't the limit applicable to all sunxi boards using MMC
>> env? Maybe that's actually the better check (thanks for digging this up,
>> btw)? I guess this would avoid to break compatibility with older
>> sunxi-fel versions (those provided by distros not carrying your fix),
>> also avoids blowing up u-boot-sunxi-with-spl.bin to 504K always?
>>
>> Or does this break anything on 32-bit boards?
>
> So there's a couple of arguments there, which are probably all a bit
> weak, but the sum of them made me do it that way:
>   - I tried to keep the changes as minimal as possible since it's
>     going to be fixes, in one of the late -rc's. We know that the
>     arm32 part works, so I didn't really want to disrupt that.
>   - It's not really optimal, as the expression is used directly in the
>     Makefile and therefore any arithmetic operations can't really be
>     done. The arm32 part can, and is therefore correct in all
>     cases. Here we just bet that the user will never have changed one
>     of the values.

Based on the previous conversion, 2018.05 or future version will
increase the u-boot partition size. Do we really need this in between
which will anyway removed.