[U-Boot] [PATCH 1/2] board: tbs2910: Add u-boot.imx size limit check
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@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@60 " \
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@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
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@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
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
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
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
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.
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.
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!
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!
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.
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
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!
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
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@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
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".
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
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.
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
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
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.
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.
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
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!
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
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
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.
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
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/
participants (6)
-
Joakim Tjernlund -
Simon Goldschmidt -
Soeren Moch -
Stefano Babic -
Sören Moch
-
Tom Rini