[U-Boot] [PATCH 1/2] board: tbs2910: Add u-boot.imx size limit check

[U-Boot] [PATCH 1/2] board: tbs2910: Add u-boot.imx size limit check

[Soeren Moch]

Check the size of the generated u-boot.imx file. Report an error
if it would be too big and overwrite the u-boot environment.

Signed-off-by: Soeren Moch <smoch@web.de>
---
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: u-boot at lists.denx.de
---
 include/configs/tbs2910.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/tbs2910.h b/include/configs/tbs2910.h
index a60223c623..2d4b9c9bfe 100644
--- a/include/configs/tbs2910.h
+++ b/include/configs/tbs2910.h
@@ -122,6 +122,8 @@
 #define CONFIG_ENV_OFFSET		(384 * 1024)
 #define CONFIG_ENV_OVERWRITE
 
+#define CONFIG_BOARD_SIZE_LIMIT		392192 /* (CONFIG_ENV_OFFSET - 1024) */
+
 #define CONFIG_EXTRA_ENV_SETTINGS \
 	"bootargs_mmc1=console=ttymxc0,115200 di0_primary console=tty1\0" \
 	"bootargs_mmc2=video=mxcfb0:dev=hdmi,1920x1080M at 60 " \
-- 
2.17.1

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Soeren Moch]

The current defconfig build generates a u-boot.imx file that is too large
for the available space on a eMMC/SD card. Installing this file overwrites
the u-boot environment. So disable the unused FIT support to reduce the
size of the u-boot binary.

Signed-off-by: Soeren Moch <smoch@web.de>
---
Cc: Stefano Babic <sbabic@denx.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: u-boot at lists.denx.de
---
 configs/tbs2910_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig
index 55cd9bd998..fc15dcf013 100644
--- a/configs/tbs2910_defconfig
+++ b/configs/tbs2910_defconfig
@@ -5,7 +5,6 @@ CONFIG_SYS_TEXT_BASE=0x17800000
 CONFIG_TARGET_TBS2910=y
 CONFIG_CMD_HDMIDETECT=y
 CONFIG_NR_DRAM_BANKS=1
-CONFIG_FIT=y
 CONFIG_BOOTDELAY=3
 CONFIG_PRE_CONSOLE_BUFFER=y
 CONFIG_PRE_CON_BUF_ADDR=0x7c000000
-- 
2.17.1

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Soeren Moch]

Stefano,

can you apply this for v2019.01? This is really a important fix to avoid
 environment and u-boot binary overwriting each other.
It is also a small local fix which cannot hurt anybody else.

Thanks,
Soeren

On 05.01.19 09:31, Soeren Moch wrote:
> The current defconfig build generates a u-boot.imx file that is too large
> for the available space on a eMMC/SD card. Installing this file overwrites
> the u-boot environment. So disable the unused FIT support to reduce the
> size of the u-boot binary.
> 
> Signed-off-by: Soeren Moch <smoch@web.de>
> ---
> Cc: Stefano Babic <sbabic@denx.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: u-boot at lists.denx.de
> ---
>  configs/tbs2910_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig
> index 55cd9bd998..fc15dcf013 100644
> --- a/configs/tbs2910_defconfig
> +++ b/configs/tbs2910_defconfig
> @@ -5,7 +5,6 @@ CONFIG_SYS_TEXT_BASE=0x17800000
>  CONFIG_TARGET_TBS2910=y
>  CONFIG_CMD_HDMIDETECT=y
>  CONFIG_NR_DRAM_BANKS=1
> -CONFIG_FIT=y
>  CONFIG_BOOTDELAY=3
>  CONFIG_PRE_CONSOLE_BUFFER=y
>  CONFIG_PRE_CON_BUF_ADDR=0x7c000000
> 

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Stefano Babic]

Hi Soeren,

On 08/01/19 11:14, Soeren Moch wrote:
> Stefano,
> 
> can you apply this for v2019.01? This is really a important fix to avoid
>  environment and u-boot binary overwriting each other.
> It is also a small local fix which cannot hurt anybody else.

I will apply and I send a new PR. This is not the first fix in this
direction, u-boot becomes pretty large, it is becoming a common problem.

Regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Soeren Moch]

Hi Stefano,

On 08.01.19 11:24, Stefano Babic wrote:
> Hi Soeren,
>
> On 08/01/19 11:14, Soeren Moch wrote:
>> Stefano,
>>
>> can you apply this for v2019.01? This is really a important fix to avoid
>>  environment and u-boot binary overwriting each other.
>> It is also a small local fix which cannot hurt anybody else.
> I will apply and I send a new PR. This is not the first fix in this
> direction, u-boot becomes pretty large, it is becoming a common problem.
>
Thank you very much.

Yes, "in the good old days (tm)" there was much effort put into not
increasing the binary size for existing boards when adding new features.
Unfortunately this is not true anymore.
And all the shiny new driver model / OF features only bring
disadvantages for maintainers and users of existing boards.

I totally understand the desire to convert the driver code to "something
better", which is easier to maintain long-term. But apparently new code
is only tested on a single platform, while constantly breaking support
for others without notice. But 'm complaining to the wrong person...

Thanks again,
Soeren

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Stefano Babic]

Hi Soeren,

On 08/01/19 12:03, Soeren Moch wrote:
> Hi Stefano,
> 
> On 08.01.19 11:24, Stefano Babic wrote:
>> Hi Soeren,
>>
>> On 08/01/19 11:14, Soeren Moch wrote:
>>> Stefano,
>>>
>>> can you apply this for v2019.01? This is really a important fix to avoid
>>>  environment and u-boot binary overwriting each other.
>>> It is also a small local fix which cannot hurt anybody else.
>> I will apply and I send a new PR. This is not the first fix in this
>> direction, u-boot becomes pretty large, it is becoming a common problem.
>>
> Thank you very much.
> 
> Yes, "in the good old days (tm)" there was much effort put into not
> increasing the binary size for existing boards when adding new features.

Right, fully agree.

> Unfortunately this is not true anymore.

I get in the same trouble with more as one project. A previous rule of
thumb was to reserve 512KB to the bootloader because it was pretty
unthinkable that bootloader could be larger. Mhmmhh....this remember me
someone else who said that 640Kb is enough for everything.

Anyway, as you noted, this is a big problem in field and it makes
difficult an upgrade without returning back the device to factory, what
nobody wants.

> And all the shiny new driver model / OF features only bring
> disadvantages for maintainers and users of existing boards.
> 
> I totally understand the desire to convert the driver code to "something
> better", which is easier to maintain long-term. But apparently new code
> is only tested on a single platform, while constantly breaking support
> for others without notice. But 'm complaining to the wrong person...

Yes, I am not the right person ;-)

I picked up your patches, I will run build tests and if everything is
fine I will sent PR for 2019.01.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> Hi Soeren,
> 
> On 08/01/19 12:03, Soeren Moch wrote:
> > Hi Stefano,
> > 
> > On 08.01.19 11:24, Stefano Babic wrote:
> >> Hi Soeren,
> >>
> >> On 08/01/19 11:14, Soeren Moch wrote:
> >>> Stefano,
> >>>
> >>> can you apply this for v2019.01? This is really a important fix to avoid
> >>>  environment and u-boot binary overwriting each other.
> >>> It is also a small local fix which cannot hurt anybody else.
> >> I will apply and I send a new PR. This is not the first fix in this
> >> direction, u-boot becomes pretty large, it is becoming a common problem.
> >>
> > Thank you very much.
> > 
> > Yes, "in the good old days (tm)" there was much effort put into not
> > increasing the binary size for existing boards when adding new features.
> 
> Right, fully agree.
> 
> > Unfortunately this is not true anymore.
> 
> I get in the same trouble with more as one project. A previous rule of
> thumb was to reserve 512KB to the bootloader because it was pretty
> unthinkable that bootloader could be larger. Mhmmhh....this remember me
> someone else who said that 640Kb is enough for everything.
> 
> Anyway, as you noted, this is a big problem in field and it makes
> difficult an upgrade without returning back the device to factory, what
> nobody wants.

So, this is more on me, so I should probably explain a little, and point
at the biggest culprit too.  The biggest at times culprit and sometimes
controversial thing is that we default to the EFI subsystem being on by
default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
agrees that defaulting to EFI application support means the widest
choice of out of the box software support.

And I do look at size changes, at least per push to master.  So most of
the time it comes in "drips and drabs".  Right now I'm going to grow
tbs2910 by 60 bytes[1].  Most of that is section re-alignment and 8 of it
is the regression fix to mmc_startup() or non-DM MMC drivers.  But
that's not super interesting, so lets look at v2018.09 to now.  That's
1800 bytes.  That's not too bad and looks like it's maybe half bug
fixes, half working on various frameworks (sure, DM/DT stuff but also
hash algos.  If we jump back to v2018.01, so more or less a year worth
of changes, that's 19KiB.  Without trying to break down _everything_
that's a good bit of EFI and a little bit everywhere else.

> > And all the shiny new driver model / OF features only bring
> > disadvantages for maintainers and users of existing boards.
> > 
> > I totally understand the desire to convert the driver code to "something
> > better", which is easier to maintain long-term. But apparently new code
> > is only tested on a single platform, while constantly breaking support
> > for others without notice. But 'm complaining to the wrong person...
> 
> Yes, I am not the right person ;-)
> 
> I picked up your patches, I will run build tests and if everything is
> fine I will sent PR for 2019.01.

In retrospect, I wish more people knew about enforcing a link time hard
limit on the binary and knew about it a lot longer ago.  Because when
those failures pop up, I don't apply the new PR and I start talking to
the relevant parties to see what we can do.

[1]: buildman --step 0 -SBCdevlk followed by --step 0 -SsBdevlk to see
how much and where, and yes, that's a few more flags than I _need_ for
that, and since it's in a script I never go and optimize it down.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190109/e9613163/attachment.sig>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Soeren Moch]

On 09.01.19 23:39, Tom Rini wrote:
> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
>> Hi Soeren,
>>
>> On 08/01/19 12:03, Soeren Moch wrote:
>>> Hi Stefano,
>>>
>>> On 08.01.19 11:24, Stefano Babic wrote:
>>>> Hi Soeren,
>>>>
>>>> On 08/01/19 11:14, Soeren Moch wrote:
>>>>> Stefano,
>>>>>
>>>>> can you apply this for v2019.01? This is really a important fix to avoid
>>>>>  environment and u-boot binary overwriting each other.
>>>>> It is also a small local fix which cannot hurt anybody else.
>>>> I will apply and I send a new PR. This is not the first fix in this
>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
>>>>
>>> Thank you very much.
>>>
>>> Yes, "in the good old days (tm)" there was much effort put into not
>>> increasing the binary size for existing boards when adding new features.
>> Right, fully agree.
>>
>>> Unfortunately this is not true anymore.
>> I get in the same trouble with more as one project. A previous rule of
>> thumb was to reserve 512KB to the bootloader because it was pretty
>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
>> someone else who said that 640Kb is enough for everything.
>>
>> Anyway, as you noted, this is a big problem in field and it makes
>> difficult an upgrade without returning back the device to factory, what
>> nobody wants.
> So, this is more on me, so I should probably explain a little, and point
> at the biggest culprit too.  The biggest at times culprit and sometimes
> controversial thing is that we default to the EFI subsystem being on by
> default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
> agrees that defaulting to EFI application support means the widest
> choice of out of the box software support.
>
Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64
boards. The usual way for firmware updates was to load a special
UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or
more convenient these days to support EFI, maybe a good idea to
default=y, but why this is not disabled in old board's defconfigs then?
Either "automatically" like in the Kconfig conversions, or via a short
notice to the relevant board maintainers?
I also noticed this EFI support as big, but disabling it is more
complicated than disabling FIT, and we are at -rc3. Maybe I will send a
corresponding patch for the next merge window.
> And I do look at size changes, at least per push to master.  So most of
> the time it comes in "drips and drabs".  Right now I'm going to grow
> tbs2910 by 60 bytes[1].  Most of that is section re-alignment and 8 of it
> is the regression fix to mmc_startup() or non-DM MMC drivers.  But
> that's not super interesting, so lets look at v2018.09 to now.  That's
> 1800 bytes.  That's not too bad and looks like it's maybe half bug
> fixes, half working on various frameworks (sure, DM/DT stuff but also
> hash algos.  If we jump back to v2018.01, so more or less a year worth
> of changes, that's 19KiB.  Without trying to break down _everything_
> that's a good bit of EFI and a little bit everywhere else.
I fully understand that this is not a easy job for you. And usually a
few kiB are not a big deal. But the one kiB that overwrites the
environment on eMMC (and therefore often bricks the board) is very very
inconvenient for users.
>>> And all the shiny new driver model / OF features only bring
>>> disadvantages for maintainers and users of existing boards.
>>>
>>> I totally understand the desire to convert the driver code to "something
>>> better", which is easier to maintain long-term. But apparently new code
>>> is only tested on a single platform, while constantly breaking support
>>> for others without notice. But 'm complaining to the wrong person...
>> Yes, I am not the right person ;-)
>>
>> I picked up your patches, I will run build tests and if everything is
>> fine I will sent PR for 2019.01.
> In retrospect, I wish more people knew about enforcing a link time hard
> limit on the binary and knew about it a lot longer ago.  Because when
> those failures pop up, I don't apply the new PR and I start talking to
> the relevant parties to see what we can do.
Unfortunately I learned about the availability of this check only
recently. As hobbyist maintainer I usually rely on the reference board
settings.


But for v2019.01 all the problems (MMC partitions and u-boot size) have
been solved (when the relevant patches are applied), so I think we are
in good shape for now.

The bigger challenge are the BLK and DM conversions for the next u-boot
version. I absolutely cannot understand how somebody can insist on these
changes, while letting the board maintainers completely alone with
required driver adaptations. Board maintainers are not familiar with
driver code, a lot of board maintainers would need to work in parallel
on this (when no person is designated for this work, all maintainers are
equally responsible), while the author of the BLK/DM core code is very
familiar with the required changes. The necessary API adaptations in
drivers would be a no-brainer for him, since nothing of the actual
hardware access code needs to be adapted. At least that is my understanding.
But someone (who actually?) decided to simply offload the second
conversion step (drivers) to somebody else, with no help offered for
this, but with short deadlines. I never heard that this can work in
community projects.
If the driver adaptations are done for a single board from each family,
then the third step (adapting board configurations) is a job for board
maintainers. But we're not at his point.

I can offer to help with testing for adapted mmc, usb, and sata drivers
for the imx6qdl family. But I will not do the driver conversions myself.

Regards,
Soeren

> [1]: buildman --step 0 -SBCdevlk followed by --step 0 -SsBdevlk to see
> how much and where, and yes, that's a few more flags than I _need_ for
> that, and since it's in a script I never go and optimize it down.
>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote:
> 
> 
> On 09.01.19 23:39, Tom Rini wrote:
> > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >> Hi Soeren,
> >>
> >> On 08/01/19 12:03, Soeren Moch wrote:
> >>> Hi Stefano,
> >>>
> >>> On 08.01.19 11:24, Stefano Babic wrote:
> >>>> Hi Soeren,
> >>>>
> >>>> On 08/01/19 11:14, Soeren Moch wrote:
> >>>>> Stefano,
> >>>>>
> >>>>> can you apply this for v2019.01? This is really a important fix to avoid
> >>>>>  environment and u-boot binary overwriting each other.
> >>>>> It is also a small local fix which cannot hurt anybody else.
> >>>> I will apply and I send a new PR. This is not the first fix in this
> >>>> direction, u-boot becomes pretty large, it is becoming a common problem.
> >>>>
> >>> Thank you very much.
> >>>
> >>> Yes, "in the good old days (tm)" there was much effort put into not
> >>> increasing the binary size for existing boards when adding new features.
> >> Right, fully agree.
> >>
> >>> Unfortunately this is not true anymore.
> >> I get in the same trouble with more as one project. A previous rule of
> >> thumb was to reserve 512KB to the bootloader because it was pretty
> >> unthinkable that bootloader could be larger. Mhmmhh....this remember me
> >> someone else who said that 640Kb is enough for everything.
> >>
> >> Anyway, as you noted, this is a big problem in field and it makes
> >> difficult an upgrade without returning back the device to factory, what
> >> nobody wants.
> > So, this is more on me, so I should probably explain a little, and point
> > at the biggest culprit too.  The biggest at times culprit and sometimes
> > controversial thing is that we default to the EFI subsystem being on by
> > default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
> > agrees that defaulting to EFI application support means the widest
> > choice of out of the box software support.
> >
> Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64
> boards. The usual way for firmware updates was to load a special

Yes, there's some amount of chicken-and-egg but it's there and growing.

> UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or
> more convenient these days to support EFI, maybe a good idea to
> default=y, but why this is not disabled in old board's defconfigs then?

While it's default y and means we're even enabling it on pre-v7
processors, the general answer is that defaults matter especially when
things get forked off for a custom project or for a new reference
platform, and it's something that can always be turned off.  i.MX is in
fact where a number of platforms have gone for opt-out.

> Either "automatically" like in the Kconfig conversions, or via a short
> notice to the relevant board maintainers?

I've been bad about communicating stuff to board maintainers, so that's
on me.  I have been, more of late at least, mentioning them in the
release emails, and now that we have build-time warnings (which are long
over-due, sorry!) I hope it will be more visible.  But I haven't come up
with a good way to not too painfully email the 300 or so people listed
as a maintainer for something under boards/.  I need to 'tho.

> I also noticed this EFI support as big, but disabling it is more
> complicated than disabling FIT, and we are at -rc3. Maybe I will send a
> corresponding patch for the next merge window.

It shouldn't be more than just disabling CONFIG_EFI_LOADER.

> > And I do look at size changes, at least per push to master.  So most of
> > the time it comes in "drips and drabs".  Right now I'm going to grow
> > tbs2910 by 60 bytes[1].  Most of that is section re-alignment and 8 of it
> > is the regression fix to mmc_startup() or non-DM MMC drivers.  But
> > that's not super interesting, so lets look at v2018.09 to now.  That's
> > 1800 bytes.  That's not too bad and looks like it's maybe half bug
> > fixes, half working on various frameworks (sure, DM/DT stuff but also
> > hash algos.  If we jump back to v2018.01, so more or less a year worth
> > of changes, that's 19KiB.  Without trying to break down _everything_
> > that's a good bit of EFI and a little bit everywhere else.
> I fully understand that this is not a easy job for you. And usually a
> few kiB are not a big deal. But the one kiB that overwrites the
> environment on eMMC (and therefore often bricks the board) is very very
> inconvenient for users.

Right, it's bad, I agree.  Which is part of my further lament about the
build-time size check.

> >>> And all the shiny new driver model / OF features only bring
> >>> disadvantages for maintainers and users of existing boards.
> >>>
> >>> I totally understand the desire to convert the driver code to "something
> >>> better", which is easier to maintain long-term. But apparently new code
> >>> is only tested on a single platform, while constantly breaking support
> >>> for others without notice. But 'm complaining to the wrong person...
> >> Yes, I am not the right person ;-)
> >>
> >> I picked up your patches, I will run build tests and if everything is
> >> fine I will sent PR for 2019.01.
> > In retrospect, I wish more people knew about enforcing a link time hard
> > limit on the binary and knew about it a lot longer ago.  Because when
> > those failures pop up, I don't apply the new PR and I start talking to
> > the relevant parties to see what we can do.
> Unfortunately I learned about the availability of this check only
> recently. As hobbyist maintainer I usually rely on the reference board
> settings.

Right.

> But for v2019.01 all the problems (MMC partitions and u-boot size) have
> been solved (when the relevant patches are applied), so I think we are
> in good shape for now.

OK, good.

> The bigger challenge are the BLK and DM conversions for the next u-boot
> version. I absolutely cannot understand how somebody can insist on these
> changes, while letting the board maintainers completely alone with
> required driver adaptations. Board maintainers are not familiar with
> driver code, a lot of board maintainers would need to work in parallel
> on this (when no person is designated for this work, all maintainers are
> equally responsible), while the author of the BLK/DM core code is very
> familiar with the required changes. The necessary API adaptations in
> drivers would be a no-brainer for him, since nothing of the actual
> hardware access code needs to be adapted. At least that is my understanding.
> But someone (who actually?) decided to simply offload the second
> conversion step (drivers) to somebody else, with no help offered for
> this, but with short deadlines. I never heard that this can work in
> community projects.
> If the driver adaptations are done for a single board from each family,
> then the third step (adapting board configurations) is a job for board
> maintainers. But we're not at his point.

Keep in mind that for the next release, v2019.04, it's just MMC and SPI.
Everything else is v2019.07.  And in all of these cases, the subsystems
are converted and there's other SoC drivers to look at for conversion.
But yes, i.MX is in a bad spot here.  As a board maintainer, what you
should focus on first is enabling CONFIG_OF_CONTROL and setting (and
grabbing from Linux the file for) CONFIG_DEFAULT_DEVICE_TREE and in
those cases, there's lots of i.MX examples to look at.

> I can offer to help with testing for adapted mmc, usb, and sata drivers
> for the imx6qdl family. But I will not do the driver conversions myself.

That's fine and great, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190109/481fea4f/attachment.sig>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Soeren Moch]

On 10.01.19 03:30, Tom Rini wrote:
> On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote:
>>
>> On 09.01.19 23:39, Tom Rini wrote:
>>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
>>>> Hi Soeren,
>>>>
>>>> On 08/01/19 12:03, Soeren Moch wrote:
>>>>> Hi Stefano,
>>>>>
>>>>> On 08.01.19 11:24, Stefano Babic wrote:
>>>>>> Hi Soeren,
>>>>>>
>>>>>> On 08/01/19 11:14, Soeren Moch wrote:
>>>>>>> Stefano,
>>>>>>>
>>>>>>> can you apply this for v2019.01? This is really a important fix to avoid
>>>>>>>  environment and u-boot binary overwriting each other.
>>>>>>> It is also a small local fix which cannot hurt anybody else.
>>>>>> I will apply and I send a new PR. This is not the first fix in this
>>>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
>>>>>>
>>>>> Thank you very much.
>>>>>
>>>>> Yes, "in the good old days (tm)" there was much effort put into not
>>>>> increasing the binary size for existing boards when adding new features.
>>>> Right, fully agree.
>>>>
>>>>> Unfortunately this is not true anymore.
>>>> I get in the same trouble with more as one project. A previous rule of
>>>> thumb was to reserve 512KB to the bootloader because it was pretty
>>>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
>>>> someone else who said that 640Kb is enough for everything.
>>>>
>>>> Anyway, as you noted, this is a big problem in field and it makes
>>>> difficult an upgrade without returning back the device to factory, what
>>>> nobody wants.
>>> So, this is more on me, so I should probably explain a little, and point
>>> at the biggest culprit too.  The biggest at times culprit and sometimes
>>> controversial thing is that we default to the EFI subsystem being on by
>>> default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
>>> agrees that defaulting to EFI application support means the widest
>>> choice of out of the box software support.
>>>
>> Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64
>> boards. The usual way for firmware updates was to load a special
> Yes, there's some amount of chicken-and-egg but it's there and growing.
>
>> UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or
>> more convenient these days to support EFI, maybe a good idea to
>> default=y, but why this is not disabled in old board's defconfigs then?
> While it's default y and means we're even enabling it on pre-v7
> processors, the general answer is that defaults matter especially when
> things get forked off for a custom project or for a new reference
> platform, and it's something that can always be turned off.  i.MX is in
> fact where a number of platforms have gone for opt-out.
So default y might be OK if this feature is desired for new platforms.
But I would prefer that the same patch series that introduces the
default y also inserts all the "# CONFIG_WHATEVER is not set" in old
board's defconfigs.
>> Either "automatically" like in the Kconfig conversions, or via a short
>> notice to the relevant board maintainers?
> I've been bad about communicating stuff to board maintainers, so that's
> on me.  I have been, more of late at least, mentioning them in the
> release emails, and now that we have build-time warnings (which are long
> over-due, sorry!) I hope it will be more visible.  But I haven't come up
> with a good way to not too painfully email the 300 or so people listed
> as a maintainer for something under boards/.  I need to 'tho.
>
>> I also noticed this EFI support as big, but disabling it is more
>> complicated than disabling FIT, and we are at -rc3. Maybe I will send a
>> corresponding patch for the next merge window.
> It shouldn't be more than just disabling CONFIG_EFI_LOADER.
This works, thanks. I must have done something when I tried this 2 weeks
ago.
>
>>> And I do look at size changes, at least per push to master.  So most of
>>> the time it comes in "drips and drabs".  Right now I'm going to grow
>>> tbs2910 by 60 bytes[1].  Most of that is section re-alignment and 8 of it
>>> is the regression fix to mmc_startup() or non-DM MMC drivers.  But
>>> that's not super interesting, so lets look at v2018.09 to now.  That's
>>> 1800 bytes.  That's not too bad and looks like it's maybe half bug
>>> fixes, half working on various frameworks (sure, DM/DT stuff but also
>>> hash algos.  If we jump back to v2018.01, so more or less a year worth
>>> of changes, that's 19KiB.  Without trying to break down _everything_
>>> that's a good bit of EFI and a little bit everywhere else.
>> I fully understand that this is not a easy job for you. And usually a
>> few kiB are not a big deal. But the one kiB that overwrites the
>> environment on eMMC (and therefore often bricks the board) is very very
>> inconvenient for users.
> Right, it's bad, I agree.  Which is part of my further lament about the
> build-time size check.
>
>>>>> And all the shiny new driver model / OF features only bring
>>>>> disadvantages for maintainers and users of existing boards.
>>>>>
>>>>> I totally understand the desire to convert the driver code to "something
>>>>> better", which is easier to maintain long-term. But apparently new code
>>>>> is only tested on a single platform, while constantly breaking support
>>>>> for others without notice. But 'm complaining to the wrong person...
>>>> Yes, I am not the right person ;-)
>>>>
>>>> I picked up your patches, I will run build tests and if everything is
>>>> fine I will sent PR for 2019.01.
>>> In retrospect, I wish more people knew about enforcing a link time hard
>>> limit on the binary and knew about it a lot longer ago.  Because when
>>> those failures pop up, I don't apply the new PR and I start talking to
>>> the relevant parties to see what we can do.
>> Unfortunately I learned about the availability of this check only
>> recently. As hobbyist maintainer I usually rely on the reference board
>> settings.
> Right.
>
>> But for v2019.01 all the problems (MMC partitions and u-boot size) have
>> been solved (when the relevant patches are applied), so I think we are
>> in good shape for now.
> OK, good.
>
>> The bigger challenge are the BLK and DM conversions for the next u-boot
>> version. I absolutely cannot understand how somebody can insist on these
>> changes, while letting the board maintainers completely alone with
>> required driver adaptations. Board maintainers are not familiar with
>> driver code, a lot of board maintainers would need to work in parallel
>> on this (when no person is designated for this work, all maintainers are
>> equally responsible), while the author of the BLK/DM core code is very
>> familiar with the required changes. The necessary API adaptations in
>> drivers would be a no-brainer for him, since nothing of the actual
>> hardware access code needs to be adapted. At least that is my understanding.
>> But someone (who actually?) decided to simply offload the second
>> conversion step (drivers) to somebody else, with no help offered for
>> this, but with short deadlines. I never heard that this can work in
>> community projects.
>> If the driver adaptations are done for a single board from each family,
>> then the third step (adapting board configurations) is a job for board
>> maintainers. But we're not at his point.
> Keep in mind that for the next release, v2019.04, it's just MMC and SPI.
> Everything else is v2019.07.  And in all of these cases, the subsystems
> are converted and there's other SoC drivers to look at for conversion.
> But yes, i.MX is in a bad spot here.  As a board maintainer, what you
> should focus on first is enabling CONFIG_OF_CONTROL and setting (and
> grabbing from Linux the file for) CONFIG_DEFAULT_DEVICE_TREE
Setting CONFIG_OF_CONTROL and CONFIG_DEFAULT_DEVICE_TREE is the easy
part (I also wrote the dts for this board in linux). But this only gives
me a u-boot-dtb.imx, which is too large for the available flash space.
And the newly introduced size check does not catch this, because the
final image name changed.

But OK, when I disable CONFIG_EFI_LOADER, the size fits. I can boot this
image and it works, other users probably are not aware of the new image
name and boot the wrong one.

But OK, let's go ahead. When I enable DM_MMC as mandatory for v2019.04,
the build fails in the dwc_ahsata driver. So I have to disable sata for
this board, what I really not like to do, especially as sata conversion
is due for v2019.07.

But OK, let's try without sata. The build runs through now, I can start
this image, but it immediately hangs at Loading Environment from MMC...

So there is much more to do than the simple board config conversion. The
DM core and drivers are not ready for the requested board conversions,
at least it looks like this for me. And I have no idea how this
conversion can be done transparently for users due to the new boot image
name.

>  and in those cases, there's lots of i.MX examples to look at.
i.MX is a whole universe full of different cpu and soc architectures.
This board belongs to the original Freescale i.MX6 family (Q/D/DL/S),
all already converted boards (sl/sx/ul/ull) belong to the new NXP i.MX6
family with different peripheral hardware IP. So this does not really help.

Regards,
Soeren
>
>> I can offer to help with testing for adapted mmc, usb, and sata drivers
>> for the imx6qdl family. But I will not do the driver conversions myself.
> That's fine and great, thanks!
>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 03:03:27PM +0100, Soeren Moch wrote:
> 
> 
> On 10.01.19 03:30, Tom Rini wrote:
> > On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote:
> >>
> >> On 09.01.19 23:39, Tom Rini wrote:
> >>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >>>> Hi Soeren,
> >>>>
> >>>> On 08/01/19 12:03, Soeren Moch wrote:
> >>>>> Hi Stefano,
> >>>>>
> >>>>> On 08.01.19 11:24, Stefano Babic wrote:
> >>>>>> Hi Soeren,
> >>>>>>
> >>>>>> On 08/01/19 11:14, Soeren Moch wrote:
> >>>>>>> Stefano,
> >>>>>>>
> >>>>>>> can you apply this for v2019.01? This is really a important fix to avoid
> >>>>>>>  environment and u-boot binary overwriting each other.
> >>>>>>> It is also a small local fix which cannot hurt anybody else.
> >>>>>> I will apply and I send a new PR. This is not the first fix in this
> >>>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
> >>>>>>
> >>>>> Thank you very much.
> >>>>>
> >>>>> Yes, "in the good old days (tm)" there was much effort put into not
> >>>>> increasing the binary size for existing boards when adding new features.
> >>>> Right, fully agree.
> >>>>
> >>>>> Unfortunately this is not true anymore.
> >>>> I get in the same trouble with more as one project. A previous rule of
> >>>> thumb was to reserve 512KB to the bootloader because it was pretty
> >>>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
> >>>> someone else who said that 640Kb is enough for everything.
> >>>>
> >>>> Anyway, as you noted, this is a big problem in field and it makes
> >>>> difficult an upgrade without returning back the device to factory, what
> >>>> nobody wants.
> >>> So, this is more on me, so I should probably explain a little, and point
> >>> at the biggest culprit too.  The biggest at times culprit and sometimes
> >>> controversial thing is that we default to the EFI subsystem being on by
> >>> default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
> >>> agrees that defaulting to EFI application support means the widest
> >>> choice of out of the box software support.
> >>>
> >> Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64
> >> boards. The usual way for firmware updates was to load a special
> > Yes, there's some amount of chicken-and-egg but it's there and growing.
> >
> >> UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or
> >> more convenient these days to support EFI, maybe a good idea to
> >> default=y, but why this is not disabled in old board's defconfigs then?
> > While it's default y and means we're even enabling it on pre-v7
> > processors, the general answer is that defaults matter especially when
> > things get forked off for a custom project or for a new reference
> > platform, and it's something that can always be turned off.  i.MX is in
> > fact where a number of platforms have gone for opt-out.
> So default y might be OK if this feature is desired for new platforms.
> But I would prefer that the same patch series that introduces the
> default y also inserts all the "# CONFIG_WHATEVER is not set" in old
> board's defconfigs.

But that's close to the opposite of why you make something default y,
which I really do try and not do so often, but maybe I'm also not doing
a great job there.

But, digging into specifics for just a moment,
https://www.tbsdtv.com/launch/tbs-2910-matrix-arm-mini-pc.html is what
we're talking about here and that you can install $whatever on it as
$whatever expects to be able to have its EFI-application installer just
run (and be passed a device tree for the kernel) is part of why
EFI_LOADER is default enabled.

That's not saying you shouldn't still disable it if you need the space.

[snip]
> >> The bigger challenge are the BLK and DM conversions for the next u-boot
> >> version. I absolutely cannot understand how somebody can insist on these
> >> changes, while letting the board maintainers completely alone with
> >> required driver adaptations. Board maintainers are not familiar with
> >> driver code, a lot of board maintainers would need to work in parallel
> >> on this (when no person is designated for this work, all maintainers are
> >> equally responsible), while the author of the BLK/DM core code is very
> >> familiar with the required changes. The necessary API adaptations in
> >> drivers would be a no-brainer for him, since nothing of the actual
> >> hardware access code needs to be adapted. At least that is my understanding.
> >> But someone (who actually?) decided to simply offload the second
> >> conversion step (drivers) to somebody else, with no help offered for
> >> this, but with short deadlines. I never heard that this can work in
> >> community projects.
> >> If the driver adaptations are done for a single board from each family,
> >> then the third step (adapting board configurations) is a job for board
> >> maintainers. But we're not at his point.
> > Keep in mind that for the next release, v2019.04, it's just MMC and SPI.
> > Everything else is v2019.07.  And in all of these cases, the subsystems
> > are converted and there's other SoC drivers to look at for conversion.
> > But yes, i.MX is in a bad spot here.  As a board maintainer, what you
> > should focus on first is enabling CONFIG_OF_CONTROL and setting (and
> > grabbing from Linux the file for) CONFIG_DEFAULT_DEVICE_TREE
> Setting CONFIG_OF_CONTROL and CONFIG_DEFAULT_DEVICE_TREE is the easy
> part (I also wrote the dts for this board in linux). But this only gives
> me a u-boot-dtb.imx, which is too large for the available flash space.
> And the newly introduced size check does not catch this, because the
> final image name changed.

Sounds like a bug that u-boot-dtb.imx isn't getting the size check done,
and we should fix that.

> But OK, when I disable CONFIG_EFI_LOADER, the size fits. I can boot this
> image and it works, other users probably are not aware of the new image
> name and boot the wrong one.

I think we've got a place where once again, sadly, iMX is a bit behind
the curve.  On other SoCs when we make the switch broadly, we go from
"u-boot-dtb.foo and u-boot.foo" to "u-boot-nodtb.foo and u-boot.foo".

> But OK, let's go ahead. When I enable DM_MMC as mandatory for v2019.04,
> the build fails in the dwc_ahsata driver. So I have to disable sata for
> this board, what I really not like to do, especially as sata conversion
> is due for v2019.07.

Yes, sadly you might need to turn off SATA support for a release.

> But OK, let's try without sata. The build runs through now, I can start
> this image, but it immediately hangs at Loading Environment from MMC...
> 
> So there is much more to do than the simple board config conversion. The
> DM core and drivers are not ready for the requested board conversions,
> at least it looks like this for me. And I have no idea how this
> conversion can be done transparently for users due to the new boot image
> name.

You might need to look at some of the other i.MX boards which do enable
DM_MMC and see what you're possibly missing.
configs/imx6qdl_icore_mipi_defconfig is another i.MX6Q/DL platform with
DM_MMC and ENV_IS_IN_MMC.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190110/342a4d63/attachment.sig>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Soeren Moch]

On 10.01.19 16:06, Tom Rini wrote:
> On Thu, Jan 10, 2019 at 03:03:27PM +0100, Soeren Moch wrote:
>>
>> On 10.01.19 03:30, Tom Rini wrote:
>>> On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote:
>>>> On 09.01.19 23:39, Tom Rini wrote:
>>>>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
>>>>>> Hi Soeren,
>>>>>>
>>>>>> On 08/01/19 12:03, Soeren Moch wrote:
>>>>>>> Hi Stefano,
>>>>>>>
>>>>>>> On 08.01.19 11:24, Stefano Babic wrote:
>>>>>>>> Hi Soeren,
>>>>>>>>
>>>>>>>> On 08/01/19 11:14, Soeren Moch wrote:
>>>>>>>>> Stefano,
>>>>>>>>>
>>>>>>>>> can you apply this for v2019.01? This is really a important fix to avoid
>>>>>>>>>  environment and u-boot binary overwriting each other.
>>>>>>>>> It is also a small local fix which cannot hurt anybody else.
>>>>>>>> I will apply and I send a new PR. This is not the first fix in this
>>>>>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
>>>>>>>>
>>>>>>> Thank you very much.
>>>>>>>
>>>>>>> Yes, "in the good old days (tm)" there was much effort put into not
>>>>>>> increasing the binary size for existing boards when adding new features.
>>>>>> Right, fully agree.
>>>>>>
>>>>>>> Unfortunately this is not true anymore.
>>>>>> I get in the same trouble with more as one project. A previous rule of
>>>>>> thumb was to reserve 512KB to the bootloader because it was pretty
>>>>>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
>>>>>> someone else who said that 640Kb is enough for everything.
>>>>>>
>>>>>> Anyway, as you noted, this is a big problem in field and it makes
>>>>>> difficult an upgrade without returning back the device to factory, what
>>>>>> nobody wants.
>>>>> So, this is more on me, so I should probably explain a little, and point
>>>>> at the biggest culprit too.  The biggest at times culprit and sometimes
>>>>> controversial thing is that we default to the EFI subsystem being on by
>>>>> default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
>>>>> agrees that defaulting to EFI application support means the widest
>>>>> choice of out of the box software support.
>>>>>
>>>> Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64
>>>> boards. The usual way for firmware updates was to load a special
>>> Yes, there's some amount of chicken-and-egg but it's there and growing.
>>>
>>>> UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or
>>>> more convenient these days to support EFI, maybe a good idea to
>>>> default=y, but why this is not disabled in old board's defconfigs then?
>>> While it's default y and means we're even enabling it on pre-v7
>>> processors, the general answer is that defaults matter especially when
>>> things get forked off for a custom project or for a new reference
>>> platform, and it's something that can always be turned off.  i.MX is in
>>> fact where a number of platforms have gone for opt-out.
>> So default y might be OK if this feature is desired for new platforms.
>> But I would prefer that the same patch series that introduces the
>> default y also inserts all the "# CONFIG_WHATEVER is not set" in old
>> board's defconfigs.
> But that's close to the opposite of why you make something default y,
> which I really do try and not do so often, but maybe I'm also not doing
> a great job there.
>
> But, digging into specifics for just a moment,
> https://www.tbsdtv.com/launch/tbs-2910-matrix-arm-mini-pc.html is what
> we're talking about here and that you can install $whatever on it as
> $whatever expects to be able to have its EFI-application installer just
> run (and be passed a device tree for the kernel) is part of why
> EFI_LOADER is default enabled.
>
> That's not saying you shouldn't still disable it if you need the space.
>
> [snip]
>>>> The bigger challenge are the BLK and DM conversions for the next u-boot
>>>> version. I absolutely cannot understand how somebody can insist on these
>>>> changes, while letting the board maintainers completely alone with
>>>> required driver adaptations. Board maintainers are not familiar with
>>>> driver code, a lot of board maintainers would need to work in parallel
>>>> on this (when no person is designated for this work, all maintainers are
>>>> equally responsible), while the author of the BLK/DM core code is very
>>>> familiar with the required changes. The necessary API adaptations in
>>>> drivers would be a no-brainer for him, since nothing of the actual
>>>> hardware access code needs to be adapted. At least that is my understanding.
>>>> But someone (who actually?) decided to simply offload the second
>>>> conversion step (drivers) to somebody else, with no help offered for
>>>> this, but with short deadlines. I never heard that this can work in
>>>> community projects.
>>>> If the driver adaptations are done for a single board from each family,
>>>> then the third step (adapting board configurations) is a job for board
>>>> maintainers. But we're not at his point.
>>> Keep in mind that for the next release, v2019.04, it's just MMC and SPI.
>>> Everything else is v2019.07.  And in all of these cases, the subsystems
>>> are converted and there's other SoC drivers to look at for conversion.
>>> But yes, i.MX is in a bad spot here.  As a board maintainer, what you
>>> should focus on first is enabling CONFIG_OF_CONTROL and setting (and
>>> grabbing from Linux the file for) CONFIG_DEFAULT_DEVICE_TREE
>> Setting CONFIG_OF_CONTROL and CONFIG_DEFAULT_DEVICE_TREE is the easy
>> part (I also wrote the dts for this board in linux). But this only gives
>> me a u-boot-dtb.imx, which is too large for the available flash space.
>> And the newly introduced size check does not catch this, because the
>> final image name changed.
> Sounds like a bug that u-boot-dtb.imx isn't getting the size check done,
> and we should fix that.
>
>> But OK, when I disable CONFIG_EFI_LOADER, the size fits. I can boot this
>> image and it works, other users probably are not aware of the new image
>> name and boot the wrong one.
> I think we've got a place where once again, sadly, iMX is a bit behind
> the curve.  On other SoCs when we make the switch broadly, we go from
> "u-boot-dtb.foo and u-boot.foo" to "u-boot-nodtb.foo and u-boot.foo".
>
>> But OK, let's go ahead. When I enable DM_MMC as mandatory for v2019.04,
>> the build fails in the dwc_ahsata driver. So I have to disable sata for
>> this board, what I really not like to do, especially as sata conversion
>> is due for v2019.07.
> Yes, sadly you might need to turn off SATA support for a release.
You say we should intentionally break user systems which are configured
to boot over SATA? And the only reason for this is your arbitrary
deadline for enforcing DM_MMC without DM_SCSI ? Really?
>> But OK, let's try without sata. The build runs through now, I can start
>> this image, but it immediately hangs at Loading Environment from MMC...
>>
>> So there is much more to do than the simple board config conversion. The
>> DM core and drivers are not ready for the requested board conversions,
>> at least it looks like this for me. And I have no idea how this
>> conversion can be done transparently for users due to the new boot image
>> name.
> You might need to look at some of the other i.MX boards which do enable
> DM_MMC and see what you're possibly missing.
> configs/imx6qdl_icore_mipi_defconfig is another i.MX6Q/DL platform with
> DM_MMC and ENV_IS_IN_MMC.
>
Will look at this if I find time to do so.

Regards,
Soeren

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Fri, Jan 11, 2019 at 02:11:38PM +0100, Soeren Moch wrote:
> 
> 
> On 10.01.19 16:06, Tom Rini wrote:
> > On Thu, Jan 10, 2019 at 03:03:27PM +0100, Soeren Moch wrote:
> >>
> >> On 10.01.19 03:30, Tom Rini wrote:
> >>> On Thu, Jan 10, 2019 at 02:28:23AM +0100, Soeren Moch wrote:
> >>>> On 09.01.19 23:39, Tom Rini wrote:
> >>>>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >>>>>> Hi Soeren,
> >>>>>>
> >>>>>> On 08/01/19 12:03, Soeren Moch wrote:
> >>>>>>> Hi Stefano,
> >>>>>>>
> >>>>>>> On 08.01.19 11:24, Stefano Babic wrote:
> >>>>>>>> Hi Soeren,
> >>>>>>>>
> >>>>>>>> On 08/01/19 11:14, Soeren Moch wrote:
> >>>>>>>>> Stefano,
> >>>>>>>>>
> >>>>>>>>> can you apply this for v2019.01? This is really a important fix to avoid
> >>>>>>>>>  environment and u-boot binary overwriting each other.
> >>>>>>>>> It is also a small local fix which cannot hurt anybody else.
> >>>>>>>> I will apply and I send a new PR. This is not the first fix in this
> >>>>>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
> >>>>>>>>
> >>>>>>> Thank you very much.
> >>>>>>>
> >>>>>>> Yes, "in the good old days (tm)" there was much effort put into not
> >>>>>>> increasing the binary size for existing boards when adding new features.
> >>>>>> Right, fully agree.
> >>>>>>
> >>>>>>> Unfortunately this is not true anymore.
> >>>>>> I get in the same trouble with more as one project. A previous rule of
> >>>>>> thumb was to reserve 512KB to the bootloader because it was pretty
> >>>>>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
> >>>>>> someone else who said that 640Kb is enough for everything.
> >>>>>>
> >>>>>> Anyway, as you noted, this is a big problem in field and it makes
> >>>>>> difficult an upgrade without returning back the device to factory, what
> >>>>>> nobody wants.
> >>>>> So, this is more on me, so I should probably explain a little, and point
> >>>>> at the biggest culprit too.  The biggest at times culprit and sometimes
> >>>>> controversial thing is that we default to the EFI subsystem being on by
> >>>>> default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
> >>>>> agrees that defaulting to EFI application support means the widest
> >>>>> choice of out of the box software support.
> >>>>>
> >>>> Hm, AFAIK EFI support is very uncommon for arm32, at least for pre-arm64
> >>>> boards. The usual way for firmware updates was to load a special
> >>> Yes, there's some amount of chicken-and-egg but it's there and growing.
> >>>
> >>>> UEnv.txt or boot.scr with commands. But OK, maybe it is more modern or
> >>>> more convenient these days to support EFI, maybe a good idea to
> >>>> default=y, but why this is not disabled in old board's defconfigs then?
> >>> While it's default y and means we're even enabling it on pre-v7
> >>> processors, the general answer is that defaults matter especially when
> >>> things get forked off for a custom project or for a new reference
> >>> platform, and it's something that can always be turned off.  i.MX is in
> >>> fact where a number of platforms have gone for opt-out.
> >> So default y might be OK if this feature is desired for new platforms.
> >> But I would prefer that the same patch series that introduces the
> >> default y also inserts all the "# CONFIG_WHATEVER is not set" in old
> >> board's defconfigs.
> > But that's close to the opposite of why you make something default y,
> > which I really do try and not do so often, but maybe I'm also not doing
> > a great job there.
> >
> > But, digging into specifics for just a moment,
> > https://www.tbsdtv.com/launch/tbs-2910-matrix-arm-mini-pc.html is what
> > we're talking about here and that you can install $whatever on it as
> > $whatever expects to be able to have its EFI-application installer just
> > run (and be passed a device tree for the kernel) is part of why
> > EFI_LOADER is default enabled.
> >
> > That's not saying you shouldn't still disable it if you need the space.
> >
> > [snip]
> >>>> The bigger challenge are the BLK and DM conversions for the next u-boot
> >>>> version. I absolutely cannot understand how somebody can insist on these
> >>>> changes, while letting the board maintainers completely alone with
> >>>> required driver adaptations. Board maintainers are not familiar with
> >>>> driver code, a lot of board maintainers would need to work in parallel
> >>>> on this (when no person is designated for this work, all maintainers are
> >>>> equally responsible), while the author of the BLK/DM core code is very
> >>>> familiar with the required changes. The necessary API adaptations in
> >>>> drivers would be a no-brainer for him, since nothing of the actual
> >>>> hardware access code needs to be adapted. At least that is my understanding.
> >>>> But someone (who actually?) decided to simply offload the second
> >>>> conversion step (drivers) to somebody else, with no help offered for
> >>>> this, but with short deadlines. I never heard that this can work in
> >>>> community projects.
> >>>> If the driver adaptations are done for a single board from each family,
> >>>> then the third step (adapting board configurations) is a job for board
> >>>> maintainers. But we're not at his point.
> >>> Keep in mind that for the next release, v2019.04, it's just MMC and SPI.
> >>> Everything else is v2019.07.  And in all of these cases, the subsystems
> >>> are converted and there's other SoC drivers to look at for conversion.
> >>> But yes, i.MX is in a bad spot here.  As a board maintainer, what you
> >>> should focus on first is enabling CONFIG_OF_CONTROL and setting (and
> >>> grabbing from Linux the file for) CONFIG_DEFAULT_DEVICE_TREE
> >> Setting CONFIG_OF_CONTROL and CONFIG_DEFAULT_DEVICE_TREE is the easy
> >> part (I also wrote the dts for this board in linux). But this only gives
> >> me a u-boot-dtb.imx, which is too large for the available flash space.
> >> And the newly introduced size check does not catch this, because the
> >> final image name changed.
> > Sounds like a bug that u-boot-dtb.imx isn't getting the size check done,
> > and we should fix that.
> >
> >> But OK, when I disable CONFIG_EFI_LOADER, the size fits. I can boot this
> >> image and it works, other users probably are not aware of the new image
> >> name and boot the wrong one.
> > I think we've got a place where once again, sadly, iMX is a bit behind
> > the curve.  On other SoCs when we make the switch broadly, we go from
> > "u-boot-dtb.foo and u-boot.foo" to "u-boot-nodtb.foo and u-boot.foo".
> >
> >> But OK, let's go ahead. When I enable DM_MMC as mandatory for v2019.04,
> >> the build fails in the dwc_ahsata driver. So I have to disable sata for
> >> this board, what I really not like to do, especially as sata conversion
> >> is due for v2019.07.
> > Yes, sadly you might need to turn off SATA support for a release.
> You say we should intentionally break user systems which are configured
> to boot over SATA? And the only reason for this is your arbitrary
> deadline for enforcing DM_MMC without DM_SCSI ? Really?

After the number of years we're at with lack of action here, yes.
Because it's not unlikely that the driver will be removed in the
following release due to lack of maintainer.

> >> But OK, let's try without sata. The build runs through now, I can start
> >> this image, but it immediately hangs at Loading Environment from MMC...
> >>
> >> So there is much more to do than the simple board config conversion. The
> >> DM core and drivers are not ready for the requested board conversions,
> >> at least it looks like this for me. And I have no idea how this
> >> conversion can be done transparently for users due to the new boot image
> >> name.
> > You might need to look at some of the other i.MX boards which do enable
> > DM_MMC and see what you're possibly missing.
> > configs/imx6qdl_icore_mipi_defconfig is another i.MX6Q/DL platform with
> > DM_MMC and ENV_IS_IN_MMC.
> >
> Will look at this if I find time to do so.

Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190111/fdbb3ee7/attachment.sig>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Stefano Babic]

Hi Tom, Soeren,

On 09/01/19 23:39, Tom Rini wrote:
> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
>> Hi Soeren,
>>
>> On 08/01/19 12:03, Soeren Moch wrote:
>>> Hi Stefano,
>>>
>>> On 08.01.19 11:24, Stefano Babic wrote:
>>>> Hi Soeren,
>>>>
>>>> On 08/01/19 11:14, Soeren Moch wrote:
>>>>> Stefano,
>>>>>
>>>>> can you apply this for v2019.01? This is really a important fix to avoid
>>>>>  environment and u-boot binary overwriting each other.
>>>>> It is also a small local fix which cannot hurt anybody else.
>>>> I will apply and I send a new PR. This is not the first fix in this
>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
>>>>
>>> Thank you very much.
>>>
>>> Yes, "in the good old days (tm)" there was much effort put into not
>>> increasing the binary size for existing boards when adding new features.
>>
>> Right, fully agree.
>>
>>> Unfortunately this is not true anymore.
>>
>> I get in the same trouble with more as one project. A previous rule of
>> thumb was to reserve 512KB to the bootloader because it was pretty
>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
>> someone else who said that 640Kb is enough for everything.
>>
>> Anyway, as you noted, this is a big problem in field and it makes
>> difficult an upgrade without returning back the device to factory, what
>> nobody wants.
> 
> So, this is more on me, so I should probably explain a little, and point
> at the biggest culprit too.  The biggest at times culprit and sometimes
> controversial thing is that we default to the EFI subsystem being on by
> default.  This is 50KiB on tbs2910.

I am not sure if we should point to EFI as responsible for the increased
footprint or it is due to the sum of several components / factors. I
just report my experience in last month : I had to port U-Boot for a
customer from a not very old release (2017.01) to the current. 2017.01
had already (apart of FIT support) all features the customer needed, but
there are issues(NAND, UBI) and I kew that they were solved later.
Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
a lot in board code, but of course I had to reconfigure a lot. At the
end, everything worked but I was quite astonished about footprint. I had:

2017.01	u-boot.bin 443452
2018.11 u-boot.bin 654684

 But the new footprint overwrote the space for the env, and I had to
change the layout.It was not something that I could not manage and in
this specific case, customer could handle it. I cannot say I did
something pretty wrong to bloat the bootloader, so my feeling was that
there is not a specific part responsible for the increased size, but
each component is slightly bigger and they sizes sum at the end.


>  Why default?  Well, "everyone"
> agrees that defaulting to EFI application support means the widest
> choice of out of the box software support.

I am unsure about this - just my two cents.

I agree with you if we are talking about evaluation boards and / or
boards supposed to run different distros (or in any case, more flavour
of software).

But there are a lot of "custom" boards (maintained in U-Boot) that runs
for a specific project and won't run any other kind of software. If a
device is a navigation system, a network controller, or whatever, it
will just do this job until its EOL.

Specially for older boards, a new feature should not be activated as
default. At the beginning, police in U-Boot was to set just what should
be required in the bootloader, without setting what is not needed as
default. So default was off instead of on.

> 
> And I do look at size changes, at least per push to master.  So most of
> the time it comes in "drips and drabs".  Right now I'm going to grow
> tbs2910 by 60 bytes[1].  Most of that is section re-alignment and 8 of it
> is the regression fix to mmc_startup() or non-DM MMC drivers.  But
> that's not super interesting, so lets look at v2018.09 to now.  That's
> 1800 bytes.  That's not too bad and looks like it's maybe half bug
> fixes, half working on various frameworks (sure, DM/DT stuff but also
> hash algos.  If we jump back to v2018.01, so more or less a year worth
> of changes, that's 19KiB.  Without trying to break down _everything_
> that's a good bit of EFI and a little bit everywhere else.
> 
>>> And all the shiny new driver model / OF features only bring
>>> disadvantages for maintainers and users of existing boards.
>>>
>>> I totally understand the desire to convert the driver code to "something
>>> better", which is easier to maintain long-term. But apparently new code
>>> is only tested on a single platform, while constantly breaking support
>>> for others without notice. But 'm complaining to the wrong person...
>>
>> Yes, I am not the right person ;-)
>>
>> I picked up your patches, I will run build tests and if everything is
>> fine I will sent PR for 2019.01.
> 
> In retrospect, I wish more people knew about enforcing a link time hard
> limit on the binary and knew about it a lot longer ago.
>  Because when
> those failures pop up, I don't apply the new PR and I start talking to
> the relevant parties to see what we can do.

You're right - the check is mot a "nice to have", it is something that
should be introduced and used. Also if we see in Soeren's case, because
the first "saveenv" on his board had damaged the bootloader resulting in
a bricked board.

> 
> [1]: buildman --step 0 -SBCdevlk followed by --step 0 -SsBdevlk to see
> how much and where, and yes, that's a few more flags than I _need_ for
> that, and since it's in a script I never go and optimize it down.
> 

Regards,
Stefano


-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Simon Goldschmidt]

On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic <sbabic@denx.de> wrote:
>
> Hi Tom, Soeren,
>
> On 09/01/19 23:39, Tom Rini wrote:
> > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >> Hi Soeren,
> >>
> >> On 08/01/19 12:03, Soeren Moch wrote:
> >>> Hi Stefano,
> >>>
> >>> On 08.01.19 11:24, Stefano Babic wrote:
> >>>> Hi Soeren,
> >>>>
> >>>> On 08/01/19 11:14, Soeren Moch wrote:
> >>>>> Stefano,
> >>>>>
> >>>>> can you apply this for v2019.01? This is really a important fix to avoid
> >>>>>  environment and u-boot binary overwriting each other.
> >>>>> It is also a small local fix which cannot hurt anybody else.
> >>>> I will apply and I send a new PR. This is not the first fix in this
> >>>> direction, u-boot becomes pretty large, it is becoming a common problem.
> >>>>
> >>> Thank you very much.
> >>>
> >>> Yes, "in the good old days (tm)" there was much effort put into not
> >>> increasing the binary size for existing boards when adding new features.
> >>
> >> Right, fully agree.
> >>
> >>> Unfortunately this is not true anymore.
> >>
> >> I get in the same trouble with more as one project. A previous rule of
> >> thumb was to reserve 512KB to the bootloader because it was pretty
> >> unthinkable that bootloader could be larger. Mhmmhh....this remember me
> >> someone else who said that 640Kb is enough for everything.
> >>
> >> Anyway, as you noted, this is a big problem in field and it makes
> >> difficult an upgrade without returning back the device to factory, what
> >> nobody wants.
> >
> > So, this is more on me, so I should probably explain a little, and point
> > at the biggest culprit too.  The biggest at times culprit and sometimes
> > controversial thing is that we default to the EFI subsystem being on by
> > default.  This is 50KiB on tbs2910.
>
> I am not sure if we should point to EFI as responsible for the increased
> footprint or it is due to the sum of several components / factors. I
> just report my experience in last month : I had to port U-Boot for a
> customer from a not very old release (2017.01) to the current. 2017.01
> had already (apart of FIT support) all features the customer needed, but
> there are issues(NAND, UBI) and I kew that they were solved later.
> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> a lot in board code, but of course I had to reconfigure a lot. At the
> end, everything worked but I was quite astonished about footprint. I had:
>
> 2017.01 u-boot.bin 443452
> 2018.11 u-boot.bin 654684
>
>  But the new footprint overwrote the space for the env, and I had to
> change the layout.It was not something that I could not manage and in
> this specific case, customer could handle it. I cannot say I did
> something pretty wrong to bloat the bootloader, so my feeling was that
> there is not a specific part responsible for the increased size, but
> each component is slightly bigger and they sizes sum at the end.
>
>
> >  Why default?  Well, "everyone"
> > agrees that defaulting to EFI application support means the widest
> > choice of out of the box software support.
>
> I am unsure about this - just my two cents.
>
> I agree with you if we are talking about evaluation boards and / or
> boards supposed to run different distros (or in any case, more flavour
> of software).
>
> But there are a lot of "custom" boards (maintained in U-Boot) that runs
> for a specific project and won't run any other kind of software. If a
> device is a navigation system, a network controller, or whatever, it
> will just do this job until its EOL.
>
> Specially for older boards, a new feature should not be activated as
> default. At the beginning, police in U-Boot was to set just what should
> be required in the bootloader, without setting what is not needed as
> default. So default was off instead of on.

I aslo think that would suit U-Boot better. For example, I have one
configuration where I need to squeeze U-Boot into 204 KiB. For me this
currently means I have to re-check the defconfig for every update to
disable new features that are now on by default. I think having those
default to off and enabling them via defconfig if required would be better.

Regards,
Simon

>
> >
> > And I do look at size changes, at least per push to master.  So most of
> > the time it comes in "drips and drabs".  Right now I'm going to grow
> > tbs2910 by 60 bytes[1].  Most of that is section re-alignment and 8 of it
> > is the regression fix to mmc_startup() or non-DM MMC drivers.  But
> > that's not super interesting, so lets look at v2018.09 to now.  That's
> > 1800 bytes.  That's not too bad and looks like it's maybe half bug
> > fixes, half working on various frameworks (sure, DM/DT stuff but also
> > hash algos.  If we jump back to v2018.01, so more or less a year worth
> > of changes, that's 19KiB.  Without trying to break down _everything_
> > that's a good bit of EFI and a little bit everywhere else.
> >
> >>> And all the shiny new driver model / OF features only bring
> >>> disadvantages for maintainers and users of existing boards.
> >>>
> >>> I totally understand the desire to convert the driver code to "something
> >>> better", which is easier to maintain long-term. But apparently new code
> >>> is only tested on a single platform, while constantly breaking support
> >>> for others without notice. But 'm complaining to the wrong person...
> >>
> >> Yes, I am not the right person ;-)
> >>
> >> I picked up your patches, I will run build tests and if everything is
> >> fine I will sent PR for 2019.01.
> >
> > In retrospect, I wish more people knew about enforcing a link time hard
> > limit on the binary and knew about it a lot longer ago.
> >  Because when
> > those failures pop up, I don't apply the new PR and I start talking to
> > the relevant parties to see what we can do.
>
> You're right - the check is mot a "nice to have", it is something that
> should be introduced and used. Also if we see in Soeren's case, because
> the first "saveenv" on his board had damaged the bootloader resulting in
> a bricked board.
>
> >
> > [1]: buildman --step 0 -SBCdevlk followed by --step 0 -SsBdevlk to see
> > how much and where, and yes, that's a few more flags than I _need_ for
> > that, and since it's in a script I never go and optimize it down.
> >
>
> Regards,
> Stefano
>
>
> --
> =====================================================================
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
> =====================================================================
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
> On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic <sbabic@denx.de> wrote:
> >
> > Hi Tom, Soeren,
> >
> > On 09/01/19 23:39, Tom Rini wrote:
> > > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> > >> Hi Soeren,
> > >>
> > >> On 08/01/19 12:03, Soeren Moch wrote:
> > >>> Hi Stefano,
> > >>>
> > >>> On 08.01.19 11:24, Stefano Babic wrote:
> > >>>> Hi Soeren,
> > >>>>
> > >>>> On 08/01/19 11:14, Soeren Moch wrote:
> > >>>>> Stefano,
> > >>>>>
> > >>>>> can you apply this for v2019.01? This is really a important fix to avoid
> > >>>>>  environment and u-boot binary overwriting each other.
> > >>>>> It is also a small local fix which cannot hurt anybody else.
> > >>>> I will apply and I send a new PR. This is not the first fix in this
> > >>>> direction, u-boot becomes pretty large, it is becoming a common problem.
> > >>>>
> > >>> Thank you very much.
> > >>>
> > >>> Yes, "in the good old days (tm)" there was much effort put into not
> > >>> increasing the binary size for existing boards when adding new features.
> > >>
> > >> Right, fully agree.
> > >>
> > >>> Unfortunately this is not true anymore.
> > >>
> > >> I get in the same trouble with more as one project. A previous rule of
> > >> thumb was to reserve 512KB to the bootloader because it was pretty
> > >> unthinkable that bootloader could be larger. Mhmmhh....this remember me
> > >> someone else who said that 640Kb is enough for everything.
> > >>
> > >> Anyway, as you noted, this is a big problem in field and it makes
> > >> difficult an upgrade without returning back the device to factory, what
> > >> nobody wants.
> > >
> > > So, this is more on me, so I should probably explain a little, and point
> > > at the biggest culprit too.  The biggest at times culprit and sometimes
> > > controversial thing is that we default to the EFI subsystem being on by
> > > default.  This is 50KiB on tbs2910.
> >
> > I am not sure if we should point to EFI as responsible for the increased
> > footprint or it is due to the sum of several components / factors. I
> > just report my experience in last month : I had to port U-Boot for a
> > customer from a not very old release (2017.01) to the current. 2017.01
> > had already (apart of FIT support) all features the customer needed, but
> > there are issues(NAND, UBI) and I kew that they were solved later.
> > Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> > a lot in board code, but of course I had to reconfigure a lot. At the
> > end, everything worked but I was quite astonished about footprint. I had:
> >
> > 2017.01 u-boot.bin 443452
> > 2018.11 u-boot.bin 654684
> >
> >  But the new footprint overwrote the space for the env, and I had to
> > change the layout.It was not something that I could not manage and in
> > this specific case, customer could handle it. I cannot say I did
> > something pretty wrong to bloat the bootloader, so my feeling was that
> > there is not a specific part responsible for the increased size, but
> > each component is slightly bigger and they sizes sum at the end.
> >
> >
> > >  Why default?  Well, "everyone"
> > > agrees that defaulting to EFI application support means the widest
> > > choice of out of the box software support.
> >
> > I am unsure about this - just my two cents.
> >
> > I agree with you if we are talking about evaluation boards and / or
> > boards supposed to run different distros (or in any case, more flavour
> > of software).
> >
> > But there are a lot of "custom" boards (maintained in U-Boot) that runs
> > for a specific project and won't run any other kind of software. If a
> > device is a navigation system, a network controller, or whatever, it
> > will just do this job until its EOL.
> >
> > Specially for older boards, a new feature should not be activated as
> > default. At the beginning, police in U-Boot was to set just what should
> > be required in the bootloader, without setting what is not needed as
> > default. So default was off instead of on.
> 
> I aslo think that would suit U-Boot better. For example, I have one
> configuration where I need to squeeze U-Boot into 204 KiB. For me this
> currently means I have to re-check the defconfig for every update to
> disable new features that are now on by default. I think having those
> default to off and enabling them via defconfig if required would be better.

Can SoCFPGA not set the option to make a link failure if you grow beyond
204KiB?  As part of this thread, the only new default y thing since
v2018.01 at least is CRC16-CCITT support in "hash".

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190110/1eb49d35/attachment.sig>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Simon Goldschmidt]

Am 10.01.2019 um 16:56 schrieb Tom Rini:
> On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
>> On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic <sbabic@denx.de> wrote:
>>>
>>> Hi Tom, Soeren,
>>>
>>> On 09/01/19 23:39, Tom Rini wrote:
>>>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
>>>>> Hi Soeren,
>>>>>
>>>>> On 08/01/19 12:03, Soeren Moch wrote:
>>>>>> Hi Stefano,
>>>>>>
>>>>>> On 08.01.19 11:24, Stefano Babic wrote:
>>>>>>> Hi Soeren,
>>>>>>>
>>>>>>> On 08/01/19 11:14, Soeren Moch wrote:
>>>>>>>> Stefano,
>>>>>>>>
>>>>>>>> can you apply this for v2019.01? This is really a important fix to avoid
>>>>>>>>   environment and u-boot binary overwriting each other.
>>>>>>>> It is also a small local fix which cannot hurt anybody else.
>>>>>>> I will apply and I send a new PR. This is not the first fix in this
>>>>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
>>>>>>>
>>>>>> Thank you very much.
>>>>>>
>>>>>> Yes, "in the good old days (tm)" there was much effort put into not
>>>>>> increasing the binary size for existing boards when adding new features.
>>>>>
>>>>> Right, fully agree.
>>>>>
>>>>>> Unfortunately this is not true anymore.
>>>>>
>>>>> I get in the same trouble with more as one project. A previous rule of
>>>>> thumb was to reserve 512KB to the bootloader because it was pretty
>>>>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
>>>>> someone else who said that 640Kb is enough for everything.
>>>>>
>>>>> Anyway, as you noted, this is a big problem in field and it makes
>>>>> difficult an upgrade without returning back the device to factory, what
>>>>> nobody wants.
>>>>
>>>> So, this is more on me, so I should probably explain a little, and point
>>>> at the biggest culprit too.  The biggest at times culprit and sometimes
>>>> controversial thing is that we default to the EFI subsystem being on by
>>>> default.  This is 50KiB on tbs2910.
>>>
>>> I am not sure if we should point to EFI as responsible for the increased
>>> footprint or it is due to the sum of several components / factors. I
>>> just report my experience in last month : I had to port U-Boot for a
>>> customer from a not very old release (2017.01) to the current. 2017.01
>>> had already (apart of FIT support) all features the customer needed, but
>>> there are issues(NAND, UBI) and I kew that they were solved later.
>>> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
>>> a lot in board code, but of course I had to reconfigure a lot. At the
>>> end, everything worked but I was quite astonished about footprint. I had:
>>>
>>> 2017.01 u-boot.bin 443452
>>> 2018.11 u-boot.bin 654684
>>>
>>>   But the new footprint overwrote the space for the env, and I had to
>>> change the layout.It was not something that I could not manage and in
>>> this specific case, customer could handle it. I cannot say I did
>>> something pretty wrong to bloat the bootloader, so my feeling was that
>>> there is not a specific part responsible for the increased size, but
>>> each component is slightly bigger and they sizes sum at the end.
>>>
>>>
>>>>   Why default?  Well, "everyone"
>>>> agrees that defaulting to EFI application support means the widest
>>>> choice of out of the box software support.
>>>
>>> I am unsure about this - just my two cents.
>>>
>>> I agree with you if we are talking about evaluation boards and / or
>>> boards supposed to run different distros (or in any case, more flavour
>>> of software).
>>>
>>> But there are a lot of "custom" boards (maintained in U-Boot) that runs
>>> for a specific project and won't run any other kind of software. If a
>>> device is a navigation system, a network controller, or whatever, it
>>> will just do this job until its EOL.
>>>
>>> Specially for older boards, a new feature should not be activated as
>>> default. At the beginning, police in U-Boot was to set just what should
>>> be required in the bootloader, without setting what is not needed as
>>> default. So default was off instead of on.
>>
>> I aslo think that would suit U-Boot better. For example, I have one
>> configuration where I need to squeeze U-Boot into 204 KiB. For me this
>> currently means I have to re-check the defconfig for every update to
>> disable new features that are now on by default. I think having those
>> default to off and enabling them via defconfig if required would be better.
> 
> Can SoCFPGA not set the option to make a link failure if you grow beyond
> 204KiB?  As part of this thread, the only new default y thing since
> v2018.01 at least is CRC16-CCITT support in "hash".

Well, this is a non-mainline config. Plus I keep having problems with 
the size check in that it does not account for the DTB. Wait, that was 
for SPL, how do you enable a size check for U-Boot?

Anyway, if new default y things aren't the problem, it's probably an 
increasement here and there, like Stefano said... :-(

Thanks,
Simon

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote:
> Am 10.01.2019 um 16:56 schrieb Tom Rini:
> >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
> >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic <sbabic@denx.de> wrote:
> >>>
> >>>Hi Tom, Soeren,
> >>>
> >>>On 09/01/19 23:39, Tom Rini wrote:
> >>>>On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >>>>>Hi Soeren,
> >>>>>
> >>>>>On 08/01/19 12:03, Soeren Moch wrote:
> >>>>>>Hi Stefano,
> >>>>>>
> >>>>>>On 08.01.19 11:24, Stefano Babic wrote:
> >>>>>>>Hi Soeren,
> >>>>>>>
> >>>>>>>On 08/01/19 11:14, Soeren Moch wrote:
> >>>>>>>>Stefano,
> >>>>>>>>
> >>>>>>>>can you apply this for v2019.01? This is really a important fix to avoid
> >>>>>>>>  environment and u-boot binary overwriting each other.
> >>>>>>>>It is also a small local fix which cannot hurt anybody else.
> >>>>>>>I will apply and I send a new PR. This is not the first fix in this
> >>>>>>>direction, u-boot becomes pretty large, it is becoming a common problem.
> >>>>>>>
> >>>>>>Thank you very much.
> >>>>>>
> >>>>>>Yes, "in the good old days (tm)" there was much effort put into not
> >>>>>>increasing the binary size for existing boards when adding new features.
> >>>>>
> >>>>>Right, fully agree.
> >>>>>
> >>>>>>Unfortunately this is not true anymore.
> >>>>>
> >>>>>I get in the same trouble with more as one project. A previous rule of
> >>>>>thumb was to reserve 512KB to the bootloader because it was pretty
> >>>>>unthinkable that bootloader could be larger. Mhmmhh....this remember me
> >>>>>someone else who said that 640Kb is enough for everything.
> >>>>>
> >>>>>Anyway, as you noted, this is a big problem in field and it makes
> >>>>>difficult an upgrade without returning back the device to factory, what
> >>>>>nobody wants.
> >>>>
> >>>>So, this is more on me, so I should probably explain a little, and point
> >>>>at the biggest culprit too.  The biggest at times culprit and sometimes
> >>>>controversial thing is that we default to the EFI subsystem being on by
> >>>>default.  This is 50KiB on tbs2910.
> >>>
> >>>I am not sure if we should point to EFI as responsible for the increased
> >>>footprint or it is due to the sum of several components / factors. I
> >>>just report my experience in last month : I had to port U-Boot for a
> >>>customer from a not very old release (2017.01) to the current. 2017.01
> >>>had already (apart of FIT support) all features the customer needed, but
> >>>there are issues(NAND, UBI) and I kew that they were solved later.
> >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> >>>a lot in board code, but of course I had to reconfigure a lot. At the
> >>>end, everything worked but I was quite astonished about footprint. I had:
> >>>
> >>>2017.01 u-boot.bin 443452
> >>>2018.11 u-boot.bin 654684
> >>>
> >>>  But the new footprint overwrote the space for the env, and I had to
> >>>change the layout.It was not something that I could not manage and in
> >>>this specific case, customer could handle it. I cannot say I did
> >>>something pretty wrong to bloat the bootloader, so my feeling was that
> >>>there is not a specific part responsible for the increased size, but
> >>>each component is slightly bigger and they sizes sum at the end.
> >>>
> >>>
> >>>>  Why default?  Well, "everyone"
> >>>>agrees that defaulting to EFI application support means the widest
> >>>>choice of out of the box software support.
> >>>
> >>>I am unsure about this - just my two cents.
> >>>
> >>>I agree with you if we are talking about evaluation boards and / or
> >>>boards supposed to run different distros (or in any case, more flavour
> >>>of software).
> >>>
> >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs
> >>>for a specific project and won't run any other kind of software. If a
> >>>device is a navigation system, a network controller, or whatever, it
> >>>will just do this job until its EOL.
> >>>
> >>>Specially for older boards, a new feature should not be activated as
> >>>default. At the beginning, police in U-Boot was to set just what should
> >>>be required in the bootloader, without setting what is not needed as
> >>>default. So default was off instead of on.
> >>
> >>I aslo think that would suit U-Boot better. For example, I have one
> >>configuration where I need to squeeze U-Boot into 204 KiB. For me this
> >>currently means I have to re-check the defconfig for every update to
> >>disable new features that are now on by default. I think having those
> >>default to off and enabling them via defconfig if required would be better.
> >
> >Can SoCFPGA not set the option to make a link failure if you grow beyond
> >204KiB?  As part of this thread, the only new default y thing since
> >v2018.01 at least is CRC16-CCITT support in "hash".
> 
> Well, this is a non-mainline config. Plus I keep having problems with the
> size check in that it does not account for the DTB. Wait, that was for SPL,
> how do you enable a size check for U-Boot?

We have CONFIG_BOARD_SIZE_LIMIT, which I would be unsurprised to learn
also needs to be used in just a few more targets in the top-level
Makefile.

> Anyway, if new default y things aren't the problem, it's probably an
> increasement here and there, like Stefano said... :-(

Well, which part?  There's the huge jump that I want to see what's going
on with on Stefano's PowerPC board.  Looking at SoCFPGA for that
time-frame, wow, there's a lot of growth due to how we've fixed things
in FAT write support.  Then it's EFI fixes and UBI fixes.  A lot of that
growth could be returned by dropping LOGLEVEL.  In fact, a quick test of
going down to CONFIG_LOGLEVEL=2 shows a net reduction of 6KiB instead of
40KiB growth.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190110/b41146b0/attachment.sig>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Simon Goldschmidt]

On Thu, Jan 10, 2019 at 5:54 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote:
> > Am 10.01.2019 um 16:56 schrieb Tom Rini:
> > >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
> > >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic <sbabic@denx.de> wrote:
> > >>>
> > >>>Hi Tom, Soeren,
> > >>>
> > >>>On 09/01/19 23:39, Tom Rini wrote:
> > >>>>On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> > >>>>>Hi Soeren,
> > >>>>>
> > >>>>>On 08/01/19 12:03, Soeren Moch wrote:
> > >>>>>>Hi Stefano,
> > >>>>>>
> > >>>>>>On 08.01.19 11:24, Stefano Babic wrote:
> > >>>>>>>Hi Soeren,
> > >>>>>>>
> > >>>>>>>On 08/01/19 11:14, Soeren Moch wrote:
> > >>>>>>>>Stefano,
> > >>>>>>>>
> > >>>>>>>>can you apply this for v2019.01? This is really a important fix to avoid
> > >>>>>>>>  environment and u-boot binary overwriting each other.
> > >>>>>>>>It is also a small local fix which cannot hurt anybody else.
> > >>>>>>>I will apply and I send a new PR. This is not the first fix in this
> > >>>>>>>direction, u-boot becomes pretty large, it is becoming a common problem.
> > >>>>>>>
> > >>>>>>Thank you very much.
> > >>>>>>
> > >>>>>>Yes, "in the good old days (tm)" there was much effort put into not
> > >>>>>>increasing the binary size for existing boards when adding new features.
> > >>>>>
> > >>>>>Right, fully agree.
> > >>>>>
> > >>>>>>Unfortunately this is not true anymore.
> > >>>>>
> > >>>>>I get in the same trouble with more as one project. A previous rule of
> > >>>>>thumb was to reserve 512KB to the bootloader because it was pretty
> > >>>>>unthinkable that bootloader could be larger. Mhmmhh....this remember me
> > >>>>>someone else who said that 640Kb is enough for everything.
> > >>>>>
> > >>>>>Anyway, as you noted, this is a big problem in field and it makes
> > >>>>>difficult an upgrade without returning back the device to factory, what
> > >>>>>nobody wants.
> > >>>>
> > >>>>So, this is more on me, so I should probably explain a little, and point
> > >>>>at the biggest culprit too.  The biggest at times culprit and sometimes
> > >>>>controversial thing is that we default to the EFI subsystem being on by
> > >>>>default.  This is 50KiB on tbs2910.
> > >>>
> > >>>I am not sure if we should point to EFI as responsible for the increased
> > >>>footprint or it is due to the sum of several components / factors. I
> > >>>just report my experience in last month : I had to port U-Boot for a
> > >>>customer from a not very old release (2017.01) to the current. 2017.01
> > >>>had already (apart of FIT support) all features the customer needed, but
> > >>>there are issues(NAND, UBI) and I kew that they were solved later.
> > >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> > >>>a lot in board code, but of course I had to reconfigure a lot. At the
> > >>>end, everything worked but I was quite astonished about footprint. I had:
> > >>>
> > >>>2017.01 u-boot.bin 443452
> > >>>2018.11 u-boot.bin 654684
> > >>>
> > >>>  But the new footprint overwrote the space for the env, and I had to
> > >>>change the layout.It was not something that I could not manage and in
> > >>>this specific case, customer could handle it. I cannot say I did
> > >>>something pretty wrong to bloat the bootloader, so my feeling was that
> > >>>there is not a specific part responsible for the increased size, but
> > >>>each component is slightly bigger and they sizes sum at the end.
> > >>>
> > >>>
> > >>>>  Why default?  Well, "everyone"
> > >>>>agrees that defaulting to EFI application support means the widest
> > >>>>choice of out of the box software support.
> > >>>
> > >>>I am unsure about this - just my two cents.
> > >>>
> > >>>I agree with you if we are talking about evaluation boards and / or
> > >>>boards supposed to run different distros (or in any case, more flavour
> > >>>of software).
> > >>>
> > >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs
> > >>>for a specific project and won't run any other kind of software. If a
> > >>>device is a navigation system, a network controller, or whatever, it
> > >>>will just do this job until its EOL.
> > >>>
> > >>>Specially for older boards, a new feature should not be activated as
> > >>>default. At the beginning, police in U-Boot was to set just what should
> > >>>be required in the bootloader, without setting what is not needed as
> > >>>default. So default was off instead of on.
> > >>
> > >>I aslo think that would suit U-Boot better. For example, I have one
> > >>configuration where I need to squeeze U-Boot into 204 KiB. For me this
> > >>currently means I have to re-check the defconfig for every update to
> > >>disable new features that are now on by default. I think having those
> > >>default to off and enabling them via defconfig if required would be better.
> > >
> > >Can SoCFPGA not set the option to make a link failure if you grow beyond
> > >204KiB?  As part of this thread, the only new default y thing since
> > >v2018.01 at least is CRC16-CCITT support in "hash".
> >
> > Well, this is a non-mainline config. Plus I keep having problems with the
> > size check in that it does not account for the DTB. Wait, that was for SPL,
> > how do you enable a size check for U-Boot?
>
> We have CONFIG_BOARD_SIZE_LIMIT, which I would be unsurprised to learn
> also needs to be used in just a few more targets in the top-level
> Makefile.
>
> > Anyway, if new default y things aren't the problem, it's probably an
> > increasement here and there, like Stefano said... :-(
>
> Well, which part?  There's the huge jump that I want to see what's going
> on with on Stefano's PowerPC board.  Looking at SoCFPGA for that
> time-frame, wow, there's a lot of growth due to how we've fixed things
> in FAT write support.  Then it's EFI fixes and UBI fixes.  A lot of that
> growth could be returned by dropping LOGLEVEL.  In fact, a quick test of
> going down to CONFIG_LOGLEVEL=2 shows a net reduction of 6KiB instead of
> 40KiB growth.

Luckily, I'm not having a huge jump like Stefano. Also, in my 200 KiB config, I
don't have FAT support enabled. EFI and UBI are disabled, logging is disabled
as well, so I don't expect that changing CONFIG_LOGLEVEL would change
anything.

Seems like there's no easy way out and I have to keep monitoring the size.
I'll try to add the automatic size check at least.

Thanks,
Simon

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Simon Goldschmidt]

On Thu, Jan 10, 2019 at 5:54 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote:
> > Am 10.01.2019 um 16:56 schrieb Tom Rini:
> > >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
> > >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic <sbabic@denx.de> wrote:
> > >>>
> > >>>Hi Tom, Soeren,
> > >>>
> > >>>On 09/01/19 23:39, Tom Rini wrote:
> > >>>>On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> > >>>>>Hi Soeren,
> > >>>>>
> > >>>>>On 08/01/19 12:03, Soeren Moch wrote:
> > >>>>>>Hi Stefano,
> > >>>>>>
> > >>>>>>On 08.01.19 11:24, Stefano Babic wrote:
> > >>>>>>>Hi Soeren,
> > >>>>>>>
> > >>>>>>>On 08/01/19 11:14, Soeren Moch wrote:
> > >>>>>>>>Stefano,
> > >>>>>>>>
> > >>>>>>>>can you apply this for v2019.01? This is really a important fix to avoid
> > >>>>>>>>  environment and u-boot binary overwriting each other.
> > >>>>>>>>It is also a small local fix which cannot hurt anybody else.
> > >>>>>>>I will apply and I send a new PR. This is not the first fix in this
> > >>>>>>>direction, u-boot becomes pretty large, it is becoming a common problem.
> > >>>>>>>
> > >>>>>>Thank you very much.
> > >>>>>>
> > >>>>>>Yes, "in the good old days (tm)" there was much effort put into not
> > >>>>>>increasing the binary size for existing boards when adding new features.
> > >>>>>
> > >>>>>Right, fully agree.
> > >>>>>
> > >>>>>>Unfortunately this is not true anymore.
> > >>>>>
> > >>>>>I get in the same trouble with more as one project. A previous rule of
> > >>>>>thumb was to reserve 512KB to the bootloader because it was pretty
> > >>>>>unthinkable that bootloader could be larger. Mhmmhh....this remember me
> > >>>>>someone else who said that 640Kb is enough for everything.
> > >>>>>
> > >>>>>Anyway, as you noted, this is a big problem in field and it makes
> > >>>>>difficult an upgrade without returning back the device to factory, what
> > >>>>>nobody wants.
> > >>>>
> > >>>>So, this is more on me, so I should probably explain a little, and point
> > >>>>at the biggest culprit too.  The biggest at times culprit and sometimes
> > >>>>controversial thing is that we default to the EFI subsystem being on by
> > >>>>default.  This is 50KiB on tbs2910.
> > >>>
> > >>>I am not sure if we should point to EFI as responsible for the increased
> > >>>footprint or it is due to the sum of several components / factors. I
> > >>>just report my experience in last month : I had to port U-Boot for a
> > >>>customer from a not very old release (2017.01) to the current. 2017.01
> > >>>had already (apart of FIT support) all features the customer needed, but
> > >>>there are issues(NAND, UBI) and I kew that they were solved later.
> > >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> > >>>a lot in board code, but of course I had to reconfigure a lot. At the
> > >>>end, everything worked but I was quite astonished about footprint. I had:
> > >>>
> > >>>2017.01 u-boot.bin 443452
> > >>>2018.11 u-boot.bin 654684
> > >>>
> > >>>  But the new footprint overwrote the space for the env, and I had to
> > >>>change the layout.It was not something that I could not manage and in
> > >>>this specific case, customer could handle it. I cannot say I did
> > >>>something pretty wrong to bloat the bootloader, so my feeling was that
> > >>>there is not a specific part responsible for the increased size, but
> > >>>each component is slightly bigger and they sizes sum at the end.
> > >>>
> > >>>
> > >>>>  Why default?  Well, "everyone"
> > >>>>agrees that defaulting to EFI application support means the widest
> > >>>>choice of out of the box software support.
> > >>>
> > >>>I am unsure about this - just my two cents.
> > >>>
> > >>>I agree with you if we are talking about evaluation boards and / or
> > >>>boards supposed to run different distros (or in any case, more flavour
> > >>>of software).
> > >>>
> > >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs
> > >>>for a specific project and won't run any other kind of software. If a
> > >>>device is a navigation system, a network controller, or whatever, it
> > >>>will just do this job until its EOL.
> > >>>
> > >>>Specially for older boards, a new feature should not be activated as
> > >>>default. At the beginning, police in U-Boot was to set just what should
> > >>>be required in the bootloader, without setting what is not needed as
> > >>>default. So default was off instead of on.
> > >>
> > >>I aslo think that would suit U-Boot better. For example, I have one
> > >>configuration where I need to squeeze U-Boot into 204 KiB. For me this
> > >>currently means I have to re-check the defconfig for every update to
> > >>disable new features that are now on by default. I think having those
> > >>default to off and enabling them via defconfig if required would be better.
> > >
> > >Can SoCFPGA not set the option to make a link failure if you grow beyond
> > >204KiB?  As part of this thread, the only new default y thing since
> > >v2018.01 at least is CRC16-CCITT support in "hash".
> >
> > Well, this is a non-mainline config. Plus I keep having problems with the
> > size check in that it does not account for the DTB. Wait, that was for SPL,
> > how do you enable a size check for U-Boot?
>
> We have CONFIG_BOARD_SIZE_LIMIT, which I would be unsurprised to learn
> also needs to be used in just a few more targets in the top-level
> Makefile.

So I just tried that and it doesn't really work as the size checked is without
DTB and without image header. These two add up to nearly 20 KiB on my board,
so a size check without them is not really worth anything.

I'll send a patch to check the size of u-boot.img

Regards,
Simon

>
> > Anyway, if new default y things aren't the problem, it's probably an
> > increasement here and there, like Stefano said... :-(
>
> Well, which part?  There's the huge jump that I want to see what's going
> on with on Stefano's PowerPC board.  Looking at SoCFPGA for that
> time-frame, wow, there's a lot of growth due to how we've fixed things
> in FAT write support.  Then it's EFI fixes and UBI fixes.  A lot of that
> growth could be returned by dropping LOGLEVEL.  In fact, a quick test of
> going down to CONFIG_LOGLEVEL=2 shows a net reduction of 6KiB instead of
> 40KiB growth.
>
> --
> Tom

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Fri, Jan 11, 2019 at 08:22:45AM +0100, Simon Goldschmidt wrote:
> On Thu, Jan 10, 2019 at 5:54 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Jan 10, 2019 at 05:36:11PM +0100, Simon Goldschmidt wrote:
> > > Am 10.01.2019 um 16:56 schrieb Tom Rini:
> > > >On Thu, Jan 10, 2019 at 09:11:53AM +0100, Simon Goldschmidt wrote:
> > > >>On Thu, Jan 10, 2019 at 9:00 AM Stefano Babic <sbabic@denx.de> wrote:
> > > >>>
> > > >>>Hi Tom, Soeren,
> > > >>>
> > > >>>On 09/01/19 23:39, Tom Rini wrote:
> > > >>>>On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> > > >>>>>Hi Soeren,
> > > >>>>>
> > > >>>>>On 08/01/19 12:03, Soeren Moch wrote:
> > > >>>>>>Hi Stefano,
> > > >>>>>>
> > > >>>>>>On 08.01.19 11:24, Stefano Babic wrote:
> > > >>>>>>>Hi Soeren,
> > > >>>>>>>
> > > >>>>>>>On 08/01/19 11:14, Soeren Moch wrote:
> > > >>>>>>>>Stefano,
> > > >>>>>>>>
> > > >>>>>>>>can you apply this for v2019.01? This is really a important fix to avoid
> > > >>>>>>>>  environment and u-boot binary overwriting each other.
> > > >>>>>>>>It is also a small local fix which cannot hurt anybody else.
> > > >>>>>>>I will apply and I send a new PR. This is not the first fix in this
> > > >>>>>>>direction, u-boot becomes pretty large, it is becoming a common problem.
> > > >>>>>>>
> > > >>>>>>Thank you very much.
> > > >>>>>>
> > > >>>>>>Yes, "in the good old days (tm)" there was much effort put into not
> > > >>>>>>increasing the binary size for existing boards when adding new features.
> > > >>>>>
> > > >>>>>Right, fully agree.
> > > >>>>>
> > > >>>>>>Unfortunately this is not true anymore.
> > > >>>>>
> > > >>>>>I get in the same trouble with more as one project. A previous rule of
> > > >>>>>thumb was to reserve 512KB to the bootloader because it was pretty
> > > >>>>>unthinkable that bootloader could be larger. Mhmmhh....this remember me
> > > >>>>>someone else who said that 640Kb is enough for everything.
> > > >>>>>
> > > >>>>>Anyway, as you noted, this is a big problem in field and it makes
> > > >>>>>difficult an upgrade without returning back the device to factory, what
> > > >>>>>nobody wants.
> > > >>>>
> > > >>>>So, this is more on me, so I should probably explain a little, and point
> > > >>>>at the biggest culprit too.  The biggest at times culprit and sometimes
> > > >>>>controversial thing is that we default to the EFI subsystem being on by
> > > >>>>default.  This is 50KiB on tbs2910.
> > > >>>
> > > >>>I am not sure if we should point to EFI as responsible for the increased
> > > >>>footprint or it is due to the sum of several components / factors. I
> > > >>>just report my experience in last month : I had to port U-Boot for a
> > > >>>customer from a not very old release (2017.01) to the current. 2017.01
> > > >>>had already (apart of FIT support) all features the customer needed, but
> > > >>>there are issues(NAND, UBI) and I kew that they were solved later.
> > > >>>Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> > > >>>a lot in board code, but of course I had to reconfigure a lot. At the
> > > >>>end, everything worked but I was quite astonished about footprint. I had:
> > > >>>
> > > >>>2017.01 u-boot.bin 443452
> > > >>>2018.11 u-boot.bin 654684
> > > >>>
> > > >>>  But the new footprint overwrote the space for the env, and I had to
> > > >>>change the layout.It was not something that I could not manage and in
> > > >>>this specific case, customer could handle it. I cannot say I did
> > > >>>something pretty wrong to bloat the bootloader, so my feeling was that
> > > >>>there is not a specific part responsible for the increased size, but
> > > >>>each component is slightly bigger and they sizes sum at the end.
> > > >>>
> > > >>>
> > > >>>>  Why default?  Well, "everyone"
> > > >>>>agrees that defaulting to EFI application support means the widest
> > > >>>>choice of out of the box software support.
> > > >>>
> > > >>>I am unsure about this - just my two cents.
> > > >>>
> > > >>>I agree with you if we are talking about evaluation boards and / or
> > > >>>boards supposed to run different distros (or in any case, more flavour
> > > >>>of software).
> > > >>>
> > > >>>But there are a lot of "custom" boards (maintained in U-Boot) that runs
> > > >>>for a specific project and won't run any other kind of software. If a
> > > >>>device is a navigation system, a network controller, or whatever, it
> > > >>>will just do this job until its EOL.
> > > >>>
> > > >>>Specially for older boards, a new feature should not be activated as
> > > >>>default. At the beginning, police in U-Boot was to set just what should
> > > >>>be required in the bootloader, without setting what is not needed as
> > > >>>default. So default was off instead of on.
> > > >>
> > > >>I aslo think that would suit U-Boot better. For example, I have one
> > > >>configuration where I need to squeeze U-Boot into 204 KiB. For me this
> > > >>currently means I have to re-check the defconfig for every update to
> > > >>disable new features that are now on by default. I think having those
> > > >>default to off and enabling them via defconfig if required would be better.
> > > >
> > > >Can SoCFPGA not set the option to make a link failure if you grow beyond
> > > >204KiB?  As part of this thread, the only new default y thing since
> > > >v2018.01 at least is CRC16-CCITT support in "hash".
> > >
> > > Well, this is a non-mainline config. Plus I keep having problems with the
> > > size check in that it does not account for the DTB. Wait, that was for SPL,
> > > how do you enable a size check for U-Boot?
> >
> > We have CONFIG_BOARD_SIZE_LIMIT, which I would be unsurprised to learn
> > also needs to be used in just a few more targets in the top-level
> > Makefile.
> 
> So I just tried that and it doesn't really work as the size checked is without
> DTB and without image header. These two add up to nearly 20 KiB on my board,
> so a size check without them is not really worth anything.
> 
> I'll send a patch to check the size of u-boot.img

Thanks.  This is another one of those great features that's not used /
plumbed in widely enough.  It's a bug that it's not in use in the areas
where we have DTB + image header.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190111/5a4acc85/attachment.sig>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
> Hi Tom, Soeren,
> 
> On 09/01/19 23:39, Tom Rini wrote:
> > On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >> Hi Soeren,
> >>
> >> On 08/01/19 12:03, Soeren Moch wrote:
> >>> Hi Stefano,
> >>>
> >>> On 08.01.19 11:24, Stefano Babic wrote:
> >>>> Hi Soeren,
> >>>>
> >>>> On 08/01/19 11:14, Soeren Moch wrote:
> >>>>> Stefano,
> >>>>>
> >>>>> can you apply this for v2019.01? This is really a important fix to avoid
> >>>>>  environment and u-boot binary overwriting each other.
> >>>>> It is also a small local fix which cannot hurt anybody else.
> >>>> I will apply and I send a new PR. This is not the first fix in this
> >>>> direction, u-boot becomes pretty large, it is becoming a common problem.
> >>>>
> >>> Thank you very much.
> >>>
> >>> Yes, "in the good old days (tm)" there was much effort put into not
> >>> increasing the binary size for existing boards when adding new features.
> >>
> >> Right, fully agree.
> >>
> >>> Unfortunately this is not true anymore.
> >>
> >> I get in the same trouble with more as one project. A previous rule of
> >> thumb was to reserve 512KB to the bootloader because it was pretty
> >> unthinkable that bootloader could be larger. Mhmmhh....this remember me
> >> someone else who said that 640Kb is enough for everything.
> >>
> >> Anyway, as you noted, this is a big problem in field and it makes
> >> difficult an upgrade without returning back the device to factory, what
> >> nobody wants.
> > 
> > So, this is more on me, so I should probably explain a little, and point
> > at the biggest culprit too.  The biggest at times culprit and sometimes
> > controversial thing is that we default to the EFI subsystem being on by
> > default.  This is 50KiB on tbs2910.
> 
> I am not sure if we should point to EFI as responsible for the increased
> footprint or it is due to the sum of several components / factors. I
> just report my experience in last month : I had to port U-Boot for a
> customer from a not very old release (2017.01) to the current. 2017.01
> had already (apart of FIT support) all features the customer needed, but
> there are issues(NAND, UBI) and I kew that they were solved later.
> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> a lot in board code, but of course I had to reconfigure a lot. At the
> end, everything worked but I was quite astonished about footprint. I had:
> 
> 2017.01	u-boot.bin 443452
> 2018.11 u-boot.bin 654684

I'm splitting my reply here into two emails.  This here concerns the
heck out of me.  But I don't see it on MPC8308RDB.  There I see:
   powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text +6847.0
            MPC8308RDB     : all -124241 bss -131040 data -48 text +6847
               u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 (-125646)

And in terms of .bins:
-rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin
-rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin

I am doing all of mpc83xx now to see if something else trips such a
large growth.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190110/33f0911e/attachment.sig>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Stefano Babic]

Hi Tom,

On 10/01/19 15:44, Tom Rini wrote:
> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
>> Hi Tom, Soeren,
>>
>> On 09/01/19 23:39, Tom Rini wrote:
>>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
>>>> Hi Soeren,
>>>>
>>>> On 08/01/19 12:03, Soeren Moch wrote:
>>>>> Hi Stefano,
>>>>>
>>>>> On 08.01.19 11:24, Stefano Babic wrote:
>>>>>> Hi Soeren,
>>>>>>
>>>>>> On 08/01/19 11:14, Soeren Moch wrote:
>>>>>>> Stefano,
>>>>>>>
>>>>>>> can you apply this for v2019.01? This is really a important fix to avoid
>>>>>>>  environment and u-boot binary overwriting each other.
>>>>>>> It is also a small local fix which cannot hurt anybody else.
>>>>>> I will apply and I send a new PR. This is not the first fix in this
>>>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
>>>>>>
>>>>> Thank you very much.
>>>>>
>>>>> Yes, "in the good old days (tm)" there was much effort put into not
>>>>> increasing the binary size for existing boards when adding new features.
>>>>
>>>> Right, fully agree.
>>>>
>>>>> Unfortunately this is not true anymore.
>>>>
>>>> I get in the same trouble with more as one project. A previous rule of
>>>> thumb was to reserve 512KB to the bootloader because it was pretty
>>>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
>>>> someone else who said that 640Kb is enough for everything.
>>>>
>>>> Anyway, as you noted, this is a big problem in field and it makes
>>>> difficult an upgrade without returning back the device to factory, what
>>>> nobody wants.
>>>
>>> So, this is more on me, so I should probably explain a little, and point
>>> at the biggest culprit too.  The biggest at times culprit and sometimes
>>> controversial thing is that we default to the EFI subsystem being on by
>>> default.  This is 50KiB on tbs2910.
>>
>> I am not sure if we should point to EFI as responsible for the increased
>> footprint or it is due to the sum of several components / factors. I
>> just report my experience in last month : I had to port U-Boot for a
>> customer from a not very old release (2017.01) to the current. 2017.01
>> had already (apart of FIT support) all features the customer needed, but
>> there are issues(NAND, UBI) and I kew that they were solved later.
>> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
>> a lot in board code, but of course I had to reconfigure a lot. At the
>> end, everything worked but I was quite astonished about footprint. I had:
>>
>> 2017.01	u-boot.bin 443452
>> 2018.11 u-boot.bin 654684
>> I'm splitting my reply here into two emails.  This here concerns the
> heck out of me.  But I don't see it on MPC8308RDB.  There I see:
>    powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text +6847.0
>             MPC8308RDB     : all -124241 bss -131040 data -48 text +6847
>                u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 (-125646)

Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but
it is not MPC8308RDB. But nevertheless, I could not understand the
difference is sitze.

> 
> And in terms of .bins:
> -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin
> -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin
> 
> I am doing all of mpc83xx now to see if something else trips such a
> large growth.
> 

I will do the same here on this board and try to understand where the
difference is coming from. I will report to you, then.


Regards,
Stefano


-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 03:51:51PM +0100, Stefano Babic wrote:
> Hi Tom,
> 
> On 10/01/19 15:44, Tom Rini wrote:
> > On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
> >> Hi Tom, Soeren,
> >>
> >> On 09/01/19 23:39, Tom Rini wrote:
> >>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >>>> Hi Soeren,
> >>>>
> >>>> On 08/01/19 12:03, Soeren Moch wrote:
> >>>>> Hi Stefano,
> >>>>>
> >>>>> On 08.01.19 11:24, Stefano Babic wrote:
> >>>>>> Hi Soeren,
> >>>>>>
> >>>>>> On 08/01/19 11:14, Soeren Moch wrote:
> >>>>>>> Stefano,
> >>>>>>>
> >>>>>>> can you apply this for v2019.01? This is really a important fix to avoid
> >>>>>>>  environment and u-boot binary overwriting each other.
> >>>>>>> It is also a small local fix which cannot hurt anybody else.
> >>>>>> I will apply and I send a new PR. This is not the first fix in this
> >>>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
> >>>>>>
> >>>>> Thank you very much.
> >>>>>
> >>>>> Yes, "in the good old days (tm)" there was much effort put into not
> >>>>> increasing the binary size for existing boards when adding new features.
> >>>>
> >>>> Right, fully agree.
> >>>>
> >>>>> Unfortunately this is not true anymore.
> >>>>
> >>>> I get in the same trouble with more as one project. A previous rule of
> >>>> thumb was to reserve 512KB to the bootloader because it was pretty
> >>>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
> >>>> someone else who said that 640Kb is enough for everything.
> >>>>
> >>>> Anyway, as you noted, this is a big problem in field and it makes
> >>>> difficult an upgrade without returning back the device to factory, what
> >>>> nobody wants.
> >>>
> >>> So, this is more on me, so I should probably explain a little, and point
> >>> at the biggest culprit too.  The biggest at times culprit and sometimes
> >>> controversial thing is that we default to the EFI subsystem being on by
> >>> default.  This is 50KiB on tbs2910.
> >>
> >> I am not sure if we should point to EFI as responsible for the increased
> >> footprint or it is due to the sum of several components / factors. I
> >> just report my experience in last month : I had to port U-Boot for a
> >> customer from a not very old release (2017.01) to the current. 2017.01
> >> had already (apart of FIT support) all features the customer needed, but
> >> there are issues(NAND, UBI) and I kew that they were solved later.
> >> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> >> a lot in board code, but of course I had to reconfigure a lot. At the
> >> end, everything worked but I was quite astonished about footprint. I had:
> >>
> >> 2017.01	u-boot.bin 443452
> >> 2018.11 u-boot.bin 654684
> >> I'm splitting my reply here into two emails.  This here concerns the
> > heck out of me.  But I don't see it on MPC8308RDB.  There I see:
> >    powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text +6847.0
> >             MPC8308RDB     : all -124241 bss -131040 data -48 text +6847
> >                u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 (-125646)
> 
> Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but
> it is not MPC8308RDB. But nevertheless, I could not understand the
> difference is sitze.

Right, I understand, that's just the first MPC83xx board I spotted, and
I wanted to see if all platforms had such unreasonable growth.  You're
showing your custom platform went up by _200_ kilobytes.

> > And in terms of .bins:
> > -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin
> > -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin
> > 
> > I am doing all of mpc83xx now to see if something else trips such a
> > large growth.
> > 
> 
> I will do the same here on this board and try to understand where the
> difference is coming from. I will report to you, then.

Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190110/b9654a0d/attachment.sig>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Stefano Babic]

Hi Tom,

On 10/01/19 16:12, Tom Rini wrote:
> On Thu, Jan 10, 2019 at 03:51:51PM +0100, Stefano Babic wrote:
>> Hi Tom,
>>
>> On 10/01/19 15:44, Tom Rini wrote:
>>> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
>>>> Hi Tom, Soeren,
>>>>
>>>> On 09/01/19 23:39, Tom Rini wrote:
>>>>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
>>>>>> Hi Soeren,
>>>>>>
>>>>>> On 08/01/19 12:03, Soeren Moch wrote:
>>>>>>> Hi Stefano,
>>>>>>>
>>>>>>> On 08.01.19 11:24, Stefano Babic wrote:
>>>>>>>> Hi Soeren,
>>>>>>>>
>>>>>>>> On 08/01/19 11:14, Soeren Moch wrote:
>>>>>>>>> Stefano,
>>>>>>>>>
>>>>>>>>> can you apply this for v2019.01? This is really a important fix to avoid
>>>>>>>>>  environment and u-boot binary overwriting each other.
>>>>>>>>> It is also a small local fix which cannot hurt anybody else.
>>>>>>>> I will apply and I send a new PR. This is not the first fix in this
>>>>>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
>>>>>>>>
>>>>>>> Thank you very much.
>>>>>>>
>>>>>>> Yes, "in the good old days (tm)" there was much effort put into not
>>>>>>> increasing the binary size for existing boards when adding new features.
>>>>>>
>>>>>> Right, fully agree.
>>>>>>
>>>>>>> Unfortunately this is not true anymore.
>>>>>>
>>>>>> I get in the same trouble with more as one project. A previous rule of
>>>>>> thumb was to reserve 512KB to the bootloader because it was pretty
>>>>>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
>>>>>> someone else who said that 640Kb is enough for everything.
>>>>>>
>>>>>> Anyway, as you noted, this is a big problem in field and it makes
>>>>>> difficult an upgrade without returning back the device to factory, what
>>>>>> nobody wants.
>>>>>
>>>>> So, this is more on me, so I should probably explain a little, and point
>>>>> at the biggest culprit too.  The biggest at times culprit and sometimes
>>>>> controversial thing is that we default to the EFI subsystem being on by
>>>>> default.  This is 50KiB on tbs2910.
>>>>
>>>> I am not sure if we should point to EFI as responsible for the increased
>>>> footprint or it is due to the sum of several components / factors. I
>>>> just report my experience in last month : I had to port U-Boot for a
>>>> customer from a not very old release (2017.01) to the current. 2017.01
>>>> had already (apart of FIT support) all features the customer needed, but
>>>> there are issues(NAND, UBI) and I kew that they were solved later.
>>>> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
>>>> a lot in board code, but of course I had to reconfigure a lot. At the
>>>> end, everything worked but I was quite astonished about footprint. I had:
>>>>
>>>> 2017.01	u-boot.bin 443452
>>>> 2018.11 u-boot.bin 654684
>>>> I'm splitting my reply here into two emails.  This here concerns the
>>> heck out of me.  But I don't see it on MPC8308RDB.  There I see:
>>>    powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text +6847.0
>>>             MPC8308RDB     : all -124241 bss -131040 data -48 text +6847
>>>                u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 (-125646)
>>
>> Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but
>> it is not MPC8308RDB. But nevertheless, I could not understand the
>> difference is sitze.
> 
> Right, I understand, that's just the first MPC83xx board I spotted, and
> I wanted to see if all platforms had such unreasonable growth.  You're
> showing your custom platform went up by _200_ kilobytes.

I have found that one of the major reason is the different toolchain.
2018.11 was built with the toolchain requested by customer, it was gcc
6.4. I built 2017.01 with buildman and fetching the toolchain, that
means 7.3. The same U-Boot versione produces very different footprint,
much better with the newer toolchain. At least 50-60KB are due to the
toolchain. LibFDT + FIT image (new features I added) produces ~70Kb more
code. But then, yes, I want to have them. So at the end, one big
responsible is the toolchain. So partially I am responsible for new
footprint (new features), the rest is done by toolchain.


> 
>>> And in terms of .bins:
>>> -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin
>>> -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin
>>>
>>> I am doing all of mpc83xx now to see if something else trips such a
>>> large growth.
>>>
>>
>> I will do the same here on this board and try to understand where the
>> difference is coming from. I will report to you, then.
> 
> Thanks!
> 

Regards,
Stefano

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Simon Goldschmidt]

On Thu, Jan 10, 2019 at 11:47 PM Stefano Babic <sbabic@denx.de> wrote:
>
> Hi Tom,
>
> On 10/01/19 16:12, Tom Rini wrote:
> > On Thu, Jan 10, 2019 at 03:51:51PM +0100, Stefano Babic wrote:
> >> Hi Tom,
> >>
> >> On 10/01/19 15:44, Tom Rini wrote:
> >>> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
> >>>> Hi Tom, Soeren,
> >>>>
> >>>> On 09/01/19 23:39, Tom Rini wrote:
> >>>>> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> >>>>>> Hi Soeren,
> >>>>>>
> >>>>>> On 08/01/19 12:03, Soeren Moch wrote:
> >>>>>>> Hi Stefano,
> >>>>>>>
> >>>>>>> On 08.01.19 11:24, Stefano Babic wrote:
> >>>>>>>> Hi Soeren,
> >>>>>>>>
> >>>>>>>> On 08/01/19 11:14, Soeren Moch wrote:
> >>>>>>>>> Stefano,
> >>>>>>>>>
> >>>>>>>>> can you apply this for v2019.01? This is really a important fix to avoid
> >>>>>>>>>  environment and u-boot binary overwriting each other.
> >>>>>>>>> It is also a small local fix which cannot hurt anybody else.
> >>>>>>>> I will apply and I send a new PR. This is not the first fix in this
> >>>>>>>> direction, u-boot becomes pretty large, it is becoming a common problem.
> >>>>>>>>
> >>>>>>> Thank you very much.
> >>>>>>>
> >>>>>>> Yes, "in the good old days (tm)" there was much effort put into not
> >>>>>>> increasing the binary size for existing boards when adding new features.
> >>>>>>
> >>>>>> Right, fully agree.
> >>>>>>
> >>>>>>> Unfortunately this is not true anymore.
> >>>>>>
> >>>>>> I get in the same trouble with more as one project. A previous rule of
> >>>>>> thumb was to reserve 512KB to the bootloader because it was pretty
> >>>>>> unthinkable that bootloader could be larger. Mhmmhh....this remember me
> >>>>>> someone else who said that 640Kb is enough for everything.
> >>>>>>
> >>>>>> Anyway, as you noted, this is a big problem in field and it makes
> >>>>>> difficult an upgrade without returning back the device to factory, what
> >>>>>> nobody wants.
> >>>>>
> >>>>> So, this is more on me, so I should probably explain a little, and point
> >>>>> at the biggest culprit too.  The biggest at times culprit and sometimes
> >>>>> controversial thing is that we default to the EFI subsystem being on by
> >>>>> default.  This is 50KiB on tbs2910.
> >>>>
> >>>> I am not sure if we should point to EFI as responsible for the increased
> >>>> footprint or it is due to the sum of several components / factors. I
> >>>> just report my experience in last month : I had to port U-Boot for a
> >>>> customer from a not very old release (2017.01) to the current. 2017.01
> >>>> had already (apart of FIT support) all features the customer needed, but
> >>>> there are issues(NAND, UBI) and I kew that they were solved later.
> >>>> Processor was an old PowerPC 8308, a quite dead SOC. I have not changed
> >>>> a lot in board code, but of course I had to reconfigure a lot. At the
> >>>> end, everything worked but I was quite astonished about footprint. I had:
> >>>>
> >>>> 2017.01    u-boot.bin 443452
> >>>> 2018.11 u-boot.bin 654684
> >>>> I'm splitting my reply here into two emails.  This here concerns the
> >>> heck out of me.  But I don't see it on MPC8308RDB.  There I see:
> >>>    powerpc: (for 1/1 boards) all -124241.0 bss -131040.0 data -48.0 text +6847.0
> >>>             MPC8308RDB     : all -124241 bss -131040 data -48 text +6847
> >>>                u-boot: add: 108/-85, grow: 121/-49 bytes: 22672/-148318 (-125646)
> >>
> >> Maybe I confuse you - this is a custom board, similar to MPC8308RDB, but
> >> it is not MPC8308RDB. But nevertheless, I could not understand the
> >> difference is sitze.
> >
> > Right, I understand, that's just the first MPC83xx board I spotted, and
> > I wanted to see if all platforms had such unreasonable growth.  You're
> > showing your custom platform went up by _200_ kilobytes.
>
> I have found that one of the major reason is the different toolchain.
> 2018.11 was built with the toolchain requested by customer, it was gcc
> 6.4. I built 2017.01 with buildman and fetching the toolchain, that
> means 7.3. The same U-Boot versione produces very different footprint,
> much better with the newer toolchain. At least 50-60KB are due to the
> toolchain. LibFDT + FIT image (new features I added) produces ~70Kb more
> code. But then, yes, I want to have them. So at the end, one big
> responsible is the toolchain. So partially I am responsible for new
> footprint (new features), the rest is done by toolchain.

That looked promising, so I gave it a try as well: I'm normally using gcc 6.3
from Debian 9. Comparing the sizes of this and buildman-provided 7.3, I
got a reduction of 100-200 Bytes only (both for SPL and U-Boot) with 7.3.

So your 50 KiB reduction must have been a corner case I guess...

Regards,
Simon

>
>
> >
> >>> And in terms of .bins:
> >>> -rwxrwxr-x 1 trini trini 337400 Jan 10 09:37 /tmp/MPC8308RDB/new/01_of_11922_g80d261881f93ee474d1c9188b5c2b5b42b0c4e6f_powerpc--T2080QDS--R/MPC8308RDB/u-boot.bin
> >>> -rwxrwxr-x 1 trini trini 345804 Jan 10 09:37 /tmp/MPC8308RDB/new/11922_of_11922_g0157013f4a4945bbdb70bb4d98d680e0845fd784_Prepare-v2018.11/MPC8308RDB/u-boot.bin
> >>>
> >>> I am doing all of mpc83xx now to see if something else trips such a
> >>> large growth.
> >>>
> >>
> >> I will do the same here on this board and try to understand where the
> >> difference is coming from. I will report to you, then.
> >
> > Thanks!
> >
>
> Regards,
> Stefano

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Tom Rini]

On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
> Hi Tom, Soeren,
> 
> On 09/01/19 23:39, Tom Rini wrote:
[snip]
> >  Why default?  Well, "everyone"
> > agrees that defaulting to EFI application support means the widest
> > choice of out of the box software support.
> 
> I am unsure about this - just my two cents.
> 
> I agree with you if we are talking about evaluation boards and / or
> boards supposed to run different distros (or in any case, more flavour
> of software).
> 
> But there are a lot of "custom" boards (maintained in U-Boot) that runs
> for a specific project and won't run any other kind of software. If a
> device is a navigation system, a network controller, or whatever, it
> will just do this job until its EOL.
> 
> Specially for older boards, a new feature should not be activated as
> default. At the beginning, police in U-Boot was to set just what should
> be required in the bootloader, without setting what is not needed as
> default. So default was off instead of on.

So, part of what I'm taking away from all of this is that I really do
need to see how many people I can bcc at once before gmail gets really
mad at me,  Yes, there's a number of end-user devices we have support
for in mainline that are intended to be re-used as the manufacturer
intended.  Part of the Kconfig migration means that they can more easily
remove stuff they don't want/need than before.  But there's also the
repurposed boards, and lots of not really clear cut cases, such as the
tbs2910 where while it's not my call, does fall into the "enable EFI
loader support for your end users maybe?" category.  And in the end, I
should have emailed off everyone with a gentle reminder to inspect and
trim their configs.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190110/f6c01076/attachment.sig>

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Sören Moch]

On 10.01.19 16:53, Tom Rini wrote:
> On Thu, Jan 10, 2019 at 09:00:13AM +0100, Stefano Babic wrote:
>> Hi Tom, Soeren,
>>
>> On 09/01/19 23:39, Tom Rini wrote:
> [snip]
>>>  Why default?  Well, "everyone"
>>> agrees that defaulting to EFI application support means the widest
>>> choice of out of the box software support.
>> I am unsure about this - just my two cents.
>>
>> I agree with you if we are talking about evaluation boards and / or
>> boards supposed to run different distros (or in any case, more flavour
>> of software).
>>
>> But there are a lot of "custom" boards (maintained in U-Boot) that runs
>> for a specific project and won't run any other kind of software. If a
>> device is a navigation system, a network controller, or whatever, it
>> will just do this job until its EOL.
>>
>> Specially for older boards, a new feature should not be activated as
>> default. At the beginning, police in U-Boot was to set just what should
>> be required in the bootloader, without setting what is not needed as
>> default. So default was off instead of on.
> So, part of what I'm taking away from all of this is that I really do
> need to see how many people I can bcc at once before gmail gets really
> mad at me,  Yes, there's a number of end-user devices we have support
> for in mainline that are intended to be re-used as the manufacturer
> intended.  Part of the Kconfig migration means that they can more easily
> remove stuff they don't want/need than before.  But there's also the
> repurposed boards, and lots of not really clear cut cases, such as the
> tbs2910 where while it's not my call, does fall into the "enable EFI
> loader support for your end users maybe?" category.  And in the end, I
> should have emailed off everyone with a gentle reminder to inspect and
> trim their configs.
>
My view on this:

The overwhelming majority of users use u-boot as _bootloader_, not as
their favorite toy to play around with every two month. Users want
stable software with bugfixes, not fancy new untested features. For a
lot of users it is a real pain if linux does not boot anymore. Often
u-boot updates are done from a running linux system. Often users don't
have access to serial adapters to re-animate bricked boards (e.g. they
are sold separately for tbs2910).

So I really prefer new features disabled on old boards. 'default y' may
be good to include modern features for new platforms. But for old boards
then include "# CONFIG_WHATEVER is not set" in defconfigs.

Let board maintainers do their job in testing new features and activate
them when properly tested on their platform and found useful. Recently a
lot of code is committed to u-boot by the original author without any
reviewed-by or tested-by tags. We should not force the testing effort on
ordinary users by activation of new features by default. Otherwise for
me the risk is too high to rendering user systems un-bootable just by
updating "stable" u-boot releases.

For me the real advantage of Kconfig is that interested users can
_enable_ new features easily, test this and maybe propose as new
defconfig to board maintainers. So there is no disadvantage for
experienced users, and no harm for users that only follow available
howtos and are not able to handle sudden changes in behavior.

Regards,
Soeren

[U-Boot] [PATCH 2/2] board: tbs2910: Remove FIT support in defconfig to reduce u-boot size

[Joakim Tjernlund]

On Wed, 2019-01-09 at 17:39 -0500, Tom Rini wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> On Wed, Jan 09, 2019 at 05:01:37PM +0100, Stefano Babic wrote:
> > Hi Soeren,
> > 
> > On 08/01/19 12:03, Soeren Moch wrote:
> > > Hi Stefano,
> > > 
> > > On 08.01.19 11:24, Stefano Babic wrote:
> > > > Hi Soeren,
> > > > 
> > > > On 08/01/19 11:14, Soeren Moch wrote:
> > > > > Stefano,
> > > > > 
> > > > > can you apply this for v2019.01? This is really a important fix to avoid
> > > > >  environment and u-boot binary overwriting each other.
> > > > > It is also a small local fix which cannot hurt anybody else.
> > > > I will apply and I send a new PR. This is not the first fix in this
> > > > direction, u-boot becomes pretty large, it is becoming a common problem.
> > > > 
> > > Thank you very much.
> > > 
> > > Yes, "in the good old days (tm)" there was much effort put into not
> > > increasing the binary size for existing boards when adding new features.
> > 
> > Right, fully agree.
> > 
> > > Unfortunately this is not true anymore.
> > 
> > I get in the same trouble with more as one project. A previous rule of
> > thumb was to reserve 512KB to the bootloader because it was pretty
> > unthinkable that bootloader could be larger. Mhmmhh....this remember me
> > someone else who said that 640Kb is enough for everything.
> > 
> > Anyway, as you noted, this is a big problem in field and it makes
> > difficult an upgrade without returning back the device to factory, what
> > nobody wants.
> 
> So, this is more on me, so I should probably explain a little, and point
> at the biggest culprit too.  The biggest at times culprit and sometimes
> controversial thing is that we default to the EFI subsystem being on by
> default.  This is 50KiB on tbs2910.  Why default?  Well, "everyone"
> agrees that defaulting to EFI application support means the widest
> choice of out of the box software support.
> 
> And I do look at size changes, at least per push to master.  So most of
> the time it comes in "drips and drabs".  Right now I'm going to grow
> tbs2910 by 60 bytes[1].  Most of that is section re-alignment and 8 of it
> is the regression fix to mmc_startup() or non-DM MMC drivers.  But
> that's not super interesting, so lets look at v2018.09 to now.  That's
> 1800 bytes.  That's not too bad and looks like it's maybe half bug
> fixes, half working on various frameworks (sure, DM/DT stuff but also
> hash algos.  If we jump back to v2018.01, so more or less a year worth
> of changes, that's 19KiB.  Without trying to break down _everything_
> that's a good bit of EFI and a little bit everywhere else.

If you looking to save a few more bytes you could take a look at my old patch
for handling the env. without a lot of static variables:
  https://patchwork.ozlabs.org/patch/746419/