| Message ID | 20171019082649.27819-1-maxime.ripard@free-electrons.com |
|---|---|
| Headers | show |
| Series | sunxi: Fix boot of Cubietruk and al. | expand |
On 10/19/2017 10:26 AM, Maxime Ripard wrote: > Hi, > > Most featureful boards, such as the Cubietruck, have been broken since > the release 2017.09. > > This is due to a size increase of the binary that will trip us across > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > We would have two ways to work around it. The first one would be to > just increase the offset of the environment. However, since it would > break all the environments of our users and possibly the custom > partition scheme that they would have created, it doesn't really seem > like a smart move. > > Another one would be to start trimming down a bit our enabled options > in order to reduce the size and to gain some extra space for users > customisations. I've taken care some of the low hanging fruits, and we > should probably take another go at it in the future (and add a size > check in the image build somehow?) How about we add the size check first before crippling the feature set of sunxi boards? Then maybe rather disable lesser used features than efi_loader? Alex
On Thu, Oct 19, 2017 at 11:26 AM, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > Hi, > > Most featureful boards, such as the Cubietruck, have been broken since > the release 2017.09. > > This is due to a size increase of the binary that will trip us across > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > We would have two ways to work around it. The first one would be to > just increase the offset of the environment. However, since it would > break all the environments of our users and possibly the custom > partition scheme that they would have created, it doesn't really seem > like a smart move. > > Another one would be to start trimming down a bit our enabled options > in order to reduce the size and to gain some extra space for users > customisations. I've taken care some of the low hanging fruits, and we > should probably take another go at it in the future (and add a size > check in the image build somehow?) > > Maxime > > Maxime Ripard (3): > ARM: sunxi: Disable USB host options by default > ARM: sunxi: Disable FAT write by default > efi_loader: Do not enable it by default for sunxi > > arch/arm/Kconfig | 4 ---- > lib/efi_loader/Kconfig | 2 +- > 2 files changed, 1 insertion(+), 5 deletions(-) We can first enable Thumb2 build by default for 32-bit sunxi boards and this should fix Cubietruck problems. $ cat .config | grep THUMB CONFIG_HAS_THUMB2=y # CONFIG_SYS_THUMB_BUILD is not set CONFIG_SPL_SYS_THUMB_BUILD=y As a test, enabling CONFIG_SYS_THUMB_BUILD=y in Cubietruck_defconfig reduces the size of the resulting U-Boot binary. == Before: == $ arm-linux-gnueabihf-size u-boot text data bss dec hex filename 489398 26492 249240 765130 bacca u-boot.orig == After: == $ arm-linux-gnueabihf-size u-boot text data bss dec hex filename 366314 26492 249232 642038 9cbf6 u-boot
On Thu, Oct 19, 2017 at 10:44:54AM +0200, Alexander Graf wrote: > On 10/19/2017 10:26 AM, Maxime Ripard wrote: > > Hi, > > > > Most featureful boards, such as the Cubietruck, have been broken since > > the release 2017.09. > > > > This is due to a size increase of the binary that will trip us across > > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > > > We would have two ways to work around it. The first one would be to > > just increase the offset of the environment. However, since it would > > break all the environments of our users and possibly the custom > > partition scheme that they would have created, it doesn't really seem > > like a smart move. > > > > Another one would be to start trimming down a bit our enabled options > > in order to reduce the size and to gain some extra space for users > > customisations. I've taken care some of the low hanging fruits, and we > > should probably take another go at it in the future (and add a size > > check in the image build somehow?) > > How about we add the size check first before crippling the feature > set of sunxi boards? Then maybe rather disable lesser used features > than efi_loader? All the features have some users. All the kind of arguments that have been sent so far are that "but I use this feature". Yes. You probably do. But you can have the same kind of argument for any of the features enabled. Let's look at the features enabled by a Cubietruck defconfig: - GMAC: I'm pretty sure there's some people using network out there, and you don't want to break those. - AHCI: I'm pretty sure there's some people using their SATA disk out there, and you don't want to break those. - PSCI: I'm pretty sure there's some people using multiple CPUs out there, and you don't want to break those. - Fastboot: I'm pretty sure there's some people reflashing their systems out there, and you don't want to break those. - DFU: I'm pretty sure there's some people reflashing their systems out there and that don't like fastboot, and you don't want to break those. - MMC: I'm pretty sure there's some people using their MMC card out there, and you don't want to break those. - USB: I'm pretty sure there's some people using their USB devices out there, and you don't want to break those. tl; dr: using that kind of argument, nothing is removed, and we keep building non-functional (as in, non-booting) binaries. Is that *really* what you're suggesting? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
On 10/19/2017 11:11 AM, Maxime Ripard wrote: > On Thu, Oct 19, 2017 at 10:44:54AM +0200, Alexander Graf wrote: >> On 10/19/2017 10:26 AM, Maxime Ripard wrote: >>> Hi, >>> >>> Most featureful boards, such as the Cubietruck, have been broken since >>> the release 2017.09. >>> >>> This is due to a size increase of the binary that will trip us across >>> the size we've been using in the u-boot-sunxi-with-spl.bin file. >>> >>> We would have two ways to work around it. The first one would be to >>> just increase the offset of the environment. However, since it would >>> break all the environments of our users and possibly the custom >>> partition scheme that they would have created, it doesn't really seem >>> like a smart move. >>> >>> Another one would be to start trimming down a bit our enabled options >>> in order to reduce the size and to gain some extra space for users >>> customisations. I've taken care some of the low hanging fruits, and we >>> should probably take another go at it in the future (and add a size >>> check in the image build somehow?) >> How about we add the size check first before crippling the feature >> set of sunxi boards? Then maybe rather disable lesser used features >> than efi_loader? > All the features have some users. All the kind of arguments that have > been sent so far are that "but I use this feature". Yes. You probably > do. But you can have the same kind of argument for any of the features > enabled. I agree, but my first statement still holds: Please make sure we don't overrun our size restrictions first so that these issue get caught early during the development cycle, not when U-Boot is already released. That said, how about we just imply SYS_THUMB_BUILD in ARCH_SUNXI? That way we save even more (going from 537K to 417K with gcc7.1) without losing any feature set on 32bit systems. Alex
Hi, On 19/10/17 09:26, Maxime Ripard wrote: > Hi, > > Most featureful boards, such as the Cubietruck, have been broken since > the release 2017.09. > > This is due to a size increase of the binary that will trip us across > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > We would have two ways to work around it. The first one would be to > just increase the offset of the environment. However, since it would > break all the environments of our users and possibly the custom > partition scheme that they would have created, it doesn't really seem > like a smart move. Is that really such a problem? How many people rely on having their custom environment preserved over an update? (That's an honest question) I see that the environment is hardcoded to 0x88000 in env/Kconfig. Where does this value come from? Why is it this rather arbitrary value? I believe the real limit should be 1MB - ENV_SIZE. Most sane partitioning tools put the first partition at 1MB, so this leaves the space below that to the bootloader/firmware. This would put the actual limit at 856 KB for now - that should be enough for everybody ;-) We could even push this further by reducing ENV_SIZE to say 64KB. At least that would buy us some time to address this issue in a more sustainable way. Cheers, Andre. > Another one would be to start trimming down a bit our enabled options > in order to reduce the size and to gain some extra space for users > customisations. I've taken care some of the low hanging fruits, and we > should probably take another go at it in the future (and add a size > check in the image build somehow?) > > Maxime > > Maxime Ripard (3): > ARM: sunxi: Disable USB host options by default > ARM: sunxi: Disable FAT write by default > efi_loader: Do not enable it by default for sunxi > > arch/arm/Kconfig | 4 ---- > lib/efi_loader/Kconfig | 2 +- > 2 files changed, 1 insertion(+), 5 deletions(-) >
On Thu, Oct 19, 2017 at 12:10:44PM +0300, Siarhei Siamashka wrote: > On Thu, Oct 19, 2017 at 11:26 AM, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > Hi, > > > > Most featureful boards, such as the Cubietruck, have been broken since > > the release 2017.09. > > > > This is due to a size increase of the binary that will trip us across > > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > > > We would have two ways to work around it. The first one would be to > > just increase the offset of the environment. However, since it would > > break all the environments of our users and possibly the custom > > partition scheme that they would have created, it doesn't really seem > > like a smart move. > > > > Another one would be to start trimming down a bit our enabled options > > in order to reduce the size and to gain some extra space for users > > customisations. I've taken care some of the low hanging fruits, and we > > should probably take another go at it in the future (and add a size > > check in the image build somehow?) > > > > Maxime > > > > Maxime Ripard (3): > > ARM: sunxi: Disable USB host options by default > > ARM: sunxi: Disable FAT write by default > > efi_loader: Do not enable it by default for sunxi > > > > arch/arm/Kconfig | 4 ---- > > lib/efi_loader/Kconfig | 2 +- > > 2 files changed, 1 insertion(+), 5 deletions(-) > > We can first enable Thumb2 build by default for 32-bit sunxi boards > and this should fix Cubietruck problems. > > $ cat .config | grep THUMB > CONFIG_HAS_THUMB2=y > # CONFIG_SYS_THUMB_BUILD is not set > CONFIG_SPL_SYS_THUMB_BUILD=y > > As a test, enabling CONFIG_SYS_THUMB_BUILD=y in Cubietruck_defconfig > reduces the size of the resulting U-Boot binary. > > == Before: == > > $ arm-linux-gnueabihf-size u-boot > text data bss dec hex filename > 489398 26492 249240 765130 bacca u-boot.orig > > == After: == > > $ arm-linux-gnueabihf-size u-boot > text data bss dec hex filename > 366314 26492 249232 642038 9cbf6 u-boot Yes, I would strongly encourage enabling Thumb2 support instead of removing various features. I would also encourage looking at moving environment either "up", or switching to env in filesystem in the future as a "Yes, we broke your existing setup, but we gave you a real useful feature". -- Tom
On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote: > Hi, > > On 19/10/17 09:26, Maxime Ripard wrote: > > Hi, > > > > Most featureful boards, such as the Cubietruck, have been broken since > > the release 2017.09. > > > > This is due to a size increase of the binary that will trip us across > > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > > > We would have two ways to work around it. The first one would be to > > just increase the offset of the environment. However, since it would > > break all the environments of our users and possibly the custom > > partition scheme that they would have created, it doesn't really seem > > like a smart move. > > Is that really such a problem? How many people rely on having their > custom environment preserved over an update? (That's an honest question) All of them, I guess. In your U-boot upgrade script, do you do a 'env default -a; saveenv' all the time ? I know I don't. And I guess the question should be turned the other way around. Should you expect your environment to be erased / ignored by any upgrade? There's never been any documentation on this as far as I know, so there's probably people that will expect it to be fixed, and things keep on booting. > I see that the environment is hardcoded to 0x88000 in env/Kconfig. > Where does this value come from? Why is it this rather arbitrary value? It predates my involvement in U-Boot, so I don't really know, but I guess some arbitrary value needed to be picked and someone did (maybe Hans or Enrick) because it seemed reasonable at the time. > I believe the real limit should be 1MB - ENV_SIZE. > Most sane partitioning tools put the first partition at 1MB, so this > leaves the space below that to the bootloader/firmware. Is that 1MB after the partition table or 1MB since the beginning of the device? > This would put the actual limit at 856 KB for now - that should be > enough for everybody ;-) > We could even push this further by reducing ENV_SIZE to say 64KB. > > At least that would buy us some time to address this issue in a more > sustainable way. Yeah, but even if we could address the issues mentionned above, we'd still need to take care of the partitions for let's say the environment that would need to be moved as well. This is just not practical. I guess we could introduce a new image with more room for the u-boot binary, and advertise it as such. But we would still have to build the old one for quite some time. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Hi Siarhei, On Thu, Oct 19, 2017 at 12:10:44PM +0300, Siarhei Siamashka wrote: > On Thu, Oct 19, 2017 at 11:26 AM, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > Hi, > > > > Most featureful boards, such as the Cubietruck, have been broken since > > the release 2017.09. > > > > This is due to a size increase of the binary that will trip us across > > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > > > We would have two ways to work around it. The first one would be to > > just increase the offset of the environment. However, since it would > > break all the environments of our users and possibly the custom > > partition scheme that they would have created, it doesn't really seem > > like a smart move. > > > > Another one would be to start trimming down a bit our enabled options > > in order to reduce the size and to gain some extra space for users > > customisations. I've taken care some of the low hanging fruits, and we > > should probably take another go at it in the future (and add a size > > check in the image build somehow?) > > > > Maxime > > > > Maxime Ripard (3): > > ARM: sunxi: Disable USB host options by default > > ARM: sunxi: Disable FAT write by default > > efi_loader: Do not enable it by default for sunxi > > > > arch/arm/Kconfig | 4 ---- > > lib/efi_loader/Kconfig | 2 +- > > 2 files changed, 1 insertion(+), 5 deletions(-) > > We can first enable Thumb2 build by default for 32-bit sunxi boards > and this should fix Cubietruck problems. > > $ cat .config | grep THUMB > CONFIG_HAS_THUMB2=y > # CONFIG_SYS_THUMB_BUILD is not set > CONFIG_SPL_SYS_THUMB_BUILD=y > > As a test, enabling CONFIG_SYS_THUMB_BUILD=y in Cubietruck_defconfig > reduces the size of the resulting U-Boot binary. > > == Before: == > > $ arm-linux-gnueabihf-size u-boot > text data bss dec hex filename > 489398 26492 249240 765130 bacca u-boot.orig > > == After: == > > $ arm-linux-gnueabihf-size u-boot > text data bss dec hex filename > 366314 26492 249232 642038 9cbf6 u-boot I just gave it a try, and indeed it solves the issue for all the boards. Thanks for the suggestion! I'll send the patches. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
On Thu, Oct 19, 2017 at 10:26:46AM +0200, Maxime Ripard wrote: > Hi, > > Most featureful boards, such as the Cubietruck, have been broken since > the release 2017.09. > > This is due to a size increase of the binary that will trip us across > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > We would have two ways to work around it. The first one would be to > just increase the offset of the environment. However, since it would > break all the environments of our users and possibly the custom > partition scheme that they would have created, it doesn't really seem > like a smart move. > > Another one would be to start trimming down a bit our enabled options > in order to reduce the size and to gain some extra space for users > customisations. I've taken care some of the low hanging fruits, and we > should probably take another go at it in the future (and add a size > check in the image build somehow?) So, where is the over-run exactly? We have CONFIG_SPL_MAX_SIZE to ensure that we have SPL fitting within constraints. For U-Boot itself we don't have a generic check but it's usually done with a custom linker script (which could in turn just #include the regular one I think). -- Tom
On Thu, Oct 19, 2017 at 03:24:57PM +0200, Maxime Ripard wrote: > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote: > > Hi, > > > > On 19/10/17 09:26, Maxime Ripard wrote: > > > Hi, > > > > > > Most featureful boards, such as the Cubietruck, have been broken since > > > the release 2017.09. > > > > > > This is due to a size increase of the binary that will trip us across > > > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > > > > > We would have two ways to work around it. The first one would be to > > > just increase the offset of the environment. However, since it would > > > break all the environments of our users and possibly the custom > > > partition scheme that they would have created, it doesn't really seem > > > like a smart move. > > > > Is that really such a problem? How many people rely on having their > > custom environment preserved over an update? (That's an honest question) > > All of them, I guess. In your U-boot upgrade script, do you do a 'env > default -a; saveenv' all the time ? > > I know I don't. > > And I guess the question should be turned the other way around. Should > you expect your environment to be erased / ignored by any upgrade? > > There's never been any documentation on this as far as I know, so > there's probably people that will expect it to be fixed, and things > keep on booting. There is a strong expectation that environment is preserved. In deployment cases, it's a must, and when it's not able to happen, people have to work their upgrade such that it knows and the flag-day type action happens. It's certainly not unprecedented to change the env location / size / type (we've done it on am335x_evm/related a few times) but it usually requires a good reason and communication outward too. > > I see that the environment is hardcoded to 0x88000 in env/Kconfig. > > Where does this value come from? Why is it this rather arbitrary value? > > It predates my involvement in U-Boot, so I don't really know, but I > guess some arbitrary value needed to be picked and someone did (maybe > Hans or Enrick) because it seemed reasonable at the time. Yes, it's likely a reasonable at the time choice. This is also, FWIW, I try and encourage new SoCs to pick env in filesystem options instead as it's generally more friendly for reference / general purpose type builds, and custom designs can still easily figure out where they want to store env and do so. -- Tom
On Thu, Oct 19, 2017 at 09:28:03AM -0400, Tom Rini wrote: > On Thu, Oct 19, 2017 at 10:26:46AM +0200, Maxime Ripard wrote: > > Hi, > > > > Most featureful boards, such as the Cubietruck, have been broken since > > the release 2017.09. > > > > This is due to a size increase of the binary that will trip us across > > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > > > We would have two ways to work around it. The first one would be to > > just increase the offset of the environment. However, since it would > > break all the environments of our users and possibly the custom > > partition scheme that they would have created, it doesn't really seem > > like a smart move. > > > > Another one would be to start trimming down a bit our enabled options > > in order to reduce the size and to gain some extra space for users > > customisations. I've taken care some of the low hanging fruits, and we > > should probably take another go at it in the future (and add a size > > check in the image build somehow?) > > So, where is the over-run exactly? We have CONFIG_SPL_MAX_SIZE to > ensure that we have SPL fitting within constraints. For U-Boot itself > we don't have a generic check but it's usually done with a custom linker > script (which could in turn just #include the regular one I think). The overlap is between the end of the U-Boot binary (so SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR in this case + U-Boot size) and ENV_OFFSET. I've been able to add a check in the u-boot-sunxi-with-spl.bin for the size, but I guess we could have something generic as well. This seems to not be very trivial to do though, since some offsets (ENV_OFFSET) are in bytes, and some other in storage units (SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR in blocks, SYS_SPI_U_BOOT_OFFS and SYS_NAND_U_BOOT_OFFS in bytes), and then some other are just booting from a partition and we can't really do anything there. I'll send the patches, let's start the discussion from there. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Hi, On 19/10/17 14:24, Maxime Ripard wrote: > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote: >> Hi, >> >> On 19/10/17 09:26, Maxime Ripard wrote: >>> Hi, >>> >>> Most featureful boards, such as the Cubietruck, have been broken since >>> the release 2017.09. >>> >>> This is due to a size increase of the binary that will trip us across >>> the size we've been using in the u-boot-sunxi-with-spl.bin file. >>> >>> We would have two ways to work around it. The first one would be to >>> just increase the offset of the environment. However, since it would >>> break all the environments of our users and possibly the custom >>> partition scheme that they would have created, it doesn't really seem >>> like a smart move. >> >> Is that really such a problem? How many people rely on having their >> custom environment preserved over an update? (That's an honest question) > > All of them, I guess. In your U-boot upgrade script, do you do a 'env > default -a; saveenv' all the time ? > > I know I don't. Well, I never use the saved environment and always expected some user or board specific environment to come from some file (boot.scr or something loaded via TFTP). But that's just my personal use, hence I was asking. And I was wondering if it hasn't been broken in the past for arm64 sunxi boards already, because aarch64 code is usually bigger (I remember seeing like +20% for u-boot.bin in the past). > And I guess the question should be turned the other way around. Should > you expect your environment to be erased / ignored by any upgrade? I think this is usually the case for a BIOS upgrade on a PC. > There's never been any documentation on this as far as I know, so > there's probably people that will expect it to be fixed, and things > keep on booting. That's probably right and we should be nice ;-) >> I see that the environment is hardcoded to 0x88000 in env/Kconfig. >> Where does this value come from? Why is it this rather arbitrary value? > > It predates my involvement in U-Boot, so I don't really know, but I > guess some arbitrary value needed to be picked and someone did (maybe > Hans or Enrick) because it seemed reasonable at the time. I chased it down to: commit e24ea55c04a8ee9c273dd879edda23bbde3d807a Author: Ian Campbell <ijc@hellion.org.uk> Date: Mon May 5 14:42:31 2014 +0100 sunxi: mmc support So yeah, dawn of time (for upstream sunxi support). >> I believe the real limit should be 1MB - ENV_SIZE. >> Most sane partitioning tools put the first partition at 1MB, so this >> leaves the space below that to the bootloader/firmware. > > Is that 1MB after the partition table or 1MB since the beginning of > the device? The beginning of the device. I would expect a (legacy) layout to be: @0: MBR (1 sector) @8K: SPL (up to 32KB) @40K: U-Boot image (@544K: environment) @1MB: first primary partition Not sure if there is anything else in there. I wonder if we could insert some code in U-Boot to move the environment in preparation for a hard change? Like: - Before looking at 544K, check for a valid environment at 896K. - If an env is found @544K: move it to 896K, invalidate the 544K copy. If we have this algorithm live for some time, we might be able to catch and migrate many users, without making life miserable for *everyone*. Not perfect, I know, but better than a hard cut. Meanwhile we switch to Thumb2 to buy us some time and add a build time check to be alerted when future builds exceed the current limit. >> This would put the actual limit at 856 KB for now - that should be >> enough for everybody ;-) >> We could even push this further by reducing ENV_SIZE to say 64KB. >> >> At least that would buy us some time to address this issue in a more >> sustainable way. > > Yeah, but even if we could address the issues mentionned above, we'd > still need to take care of the partitions for let's say the > environment that would need to be moved as well. This is just not > practical. I don't understand. What partitions? Android? Do they start between 544K and 1MB? > I guess we could introduce a new image with more room for the u-boot > binary, and advertise it as such. But we would still have to build the > old one for quite some time. Who would be "we", exactly? Distributions? I guess this is the only case where we want to preserve the ENV location? Could they mitigate this by using the transitional schema as described above? For new (whole) images this would certainly not be a problem, would it? Cheers, Andre.
On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > Hi, > > On 19/10/17 14:24, Maxime Ripard wrote: > > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote: > >> Hi, > >> > >> On 19/10/17 09:26, Maxime Ripard wrote: > >>> Hi, > >>> > >>> Most featureful boards, such as the Cubietruck, have been broken since > >>> the release 2017.09. > >>> > >>> This is due to a size increase of the binary that will trip us across > >>> the size we've been using in the u-boot-sunxi-with-spl.bin file. > >>> > >>> We would have two ways to work around it. The first one would be to > >>> just increase the offset of the environment. However, since it would > >>> break all the environments of our users and possibly the custom > >>> partition scheme that they would have created, it doesn't really seem > >>> like a smart move. > >> > >> Is that really such a problem? How many people rely on having their > >> custom environment preserved over an update? (That's an honest question) > > > > All of them, I guess. In your U-boot upgrade script, do you do a 'env > > default -a; saveenv' all the time ? > > > > I know I don't. > > Well, I never use the saved environment and always expected some user or > board specific environment to come from some file (boot.scr or something > loaded via TFTP). But that's just my personal use, hence I was asking. Well, even if you want to boot to tftp, you'll need to have some setup to do, even just to use a different server IP, and that will be in the environment. > And I was wondering if it hasn't been broken in the past for arm64 sunxi > boards already, because aarch64 code is usually bigger (I remember > seeing like +20% for u-boot.bin in the past). > > > And I guess the question should be turned the other way around. Should > > you expect your environment to be erased / ignored by any upgrade? > > I think this is usually the case for a BIOS upgrade on a PC. Yeah, so definitely not the U-Boot habits :) > >> I believe the real limit should be 1MB - ENV_SIZE. > >> Most sane partitioning tools put the first partition at 1MB, so this > >> leaves the space below that to the bootloader/firmware. > > > > Is that 1MB after the partition table or 1MB since the beginning of > > the device? > > The beginning of the device. I would expect a (legacy) layout to be: > @0: MBR (1 sector) > @8K: SPL (up to 32KB) > @40K: U-Boot image > (@544K: environment) > @1MB: first primary partition > Not sure if there is anything else in there. > > I wonder if we could insert some code in U-Boot to move the environment > in preparation for a hard change? Like: > - Before looking at 544K, check for a valid environment at 896K. > - If an env is found @544K: move it to 896K, invalidate the 544K copy. > > If we have this algorithm live for some time, we might be able to catch > and migrate many users, without making life miserable for *everyone*. > Not perfect, I know, but better than a hard cut. I guess if we were to do this, we'd better store it in a filesystem file directly like Tom suggested, and just skip the increase of the size. > >> This would put the actual limit at 856 KB for now - that should be > >> enough for everybody ;-) > >> We could even push this further by reducing ENV_SIZE to say 64KB. > >> > >> At least that would buy us some time to address this issue in a more > >> sustainable way. > > > > Yeah, but even if we could address the issues mentionned above, we'd > > still need to take care of the partitions for let's say the > > environment that would need to be moved as well. This is just not > > practical. > > I don't understand. What partitions? Android? Do they start between 544K > and 1MB? I've seen (and built) setups where you would have a partition dedicated to the U-Boot environment and binaries so that you can upgrade / switch them easily. fastboot (and I suspect dfu) makes that really convenient. > > I guess we could introduce a new image with more room for the u-boot > > binary, and advertise it as such. But we would still have to build the > > old one for quite some time. > > Who would be "we", exactly? Distributions? U-Boot upstream > I guess this is the only case where we want to preserve the ENV > location? Could they mitigate this by using the transitional schema as > described above? > For new (whole) images this would certainly not be a problem, would it? Even in the transition scheme, let's say you have a user that would use a 'legacy' offset for its environment, you will not want to overwrite it, so you'll need the size check for as long as the transition period last. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
El jue, 19-10-2017 a las 15:24 +0200, Maxime Ripard escribió: > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote: > > Hi, > > > > On 19/10/17 09:26, Maxime Ripard wrote: > > > Hi, > > > > > > Most featureful boards, such as the Cubietruck, have been broken > > > since > > > the release 2017.09. > > > > > > This is due to a size increase of the binary that will trip us > > > across > > > the size we've been using in the u-boot-sunxi-with-spl.bin file. > > > > > > We would have two ways to work around it. The first one would be > > > to > > > just increase the offset of the environment. However, since it > > > would > > > break all the environments of our users and possibly the custom > > > partition scheme that they would have created, it doesn't really > > > seem > > > like a smart move. > > > > Is that really such a problem? How many people rely on having their > > custom environment preserved over an update? (That's an honest > > question) > > All of them, I guess. In your U-boot upgrade script, do you do a 'env > default -a; saveenv' all the time ? > > I know I don't. I personally do not do anything to the environment ever if I can help it. I rely on u-boot having the smarts to just do the right thing and boot my system for me. if the environment moves, as I use the defaults it will just continue to work. Dennis
El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió: > On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > > Hi, > > > > On 19/10/17 14:24, Maxime Ripard wrote: > > > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote: > > > > Hi, > > > > > > > > On 19/10/17 09:26, Maxime Ripard wrote: > > > > > Hi, > > > > > > > > > > Most featureful boards, such as the Cubietruck, have been > > > > > broken since > > > > > the release 2017.09. > > > > > > > > > > This is due to a size increase of the binary that will trip > > > > > us across > > > > > the size we've been using in the u-boot-sunxi-with-spl.bin > > > > > file. > > > > > > > > > > We would have two ways to work around it. The first one would > > > > > be to > > > > > just increase the offset of the environment. However, since > > > > > it would > > > > > break all the environments of our users and possibly the > > > > > custom > > > > > partition scheme that they would have created, it doesn't > > > > > really seem > > > > > like a smart move. > > > > > > > > Is that really such a problem? How many people rely on having > > > > their > > > > custom environment preserved over an update? (That's an honest > > > > question) > > > > > > All of them, I guess. In your U-boot upgrade script, do you do a > > > 'env > > > default -a; saveenv' all the time ? > > > > > > I know I don't. > > > > Well, I never use the saved environment and always expected some > > user or > > board specific environment to come from some file (boot.scr or > > something > > loaded via TFTP). But that's just my personal use, hence I was > > asking. > > Well, even if you want to boot to tftp, you'll need to have some > setup > to do, even just to use a different server IP, and that will be in > the > environment. I personally just use pxe boot dhcp pxe get pxe boot and pick the right option. nothing needed on the client side. Dennis
On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote: > El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió: > > On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > > > Hi, > > > > > > On 19/10/17 14:24, Maxime Ripard wrote: > > > > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara wrote: > > > > > Hi, > > > > > > > > > > On 19/10/17 09:26, Maxime Ripard wrote: > > > > > > Hi, > > > > > > > > > > > > Most featureful boards, such as the Cubietruck, have been > > > > > > broken since > > > > > > the release 2017.09. > > > > > > > > > > > > This is due to a size increase of the binary that will trip > > > > > > us across > > > > > > the size we've been using in the u-boot-sunxi-with-spl.bin > > > > > > file. > > > > > > > > > > > > We would have two ways to work around it. The first one would > > > > > > be to > > > > > > just increase the offset of the environment. However, since > > > > > > it would > > > > > > break all the environments of our users and possibly the > > > > > > custom > > > > > > partition scheme that they would have created, it doesn't > > > > > > really seem > > > > > > like a smart move. > > > > > > > > > > Is that really such a problem? How many people rely on having > > > > > their > > > > > custom environment preserved over an update? (That's an honest > > > > > question) > > > > > > > > All of them, I guess. In your U-boot upgrade script, do you do a > > > > 'env > > > > default -a; saveenv' all the time ? > > > > > > > > I know I don't. > > > > > > Well, I never use the saved environment and always expected some > > > user or > > > board specific environment to come from some file (boot.scr or > > > something > > > loaded via TFTP). But that's just my personal use, hence I was > > > asking. > > > > Well, even if you want to boot to tftp, you'll need to have some > > setup > > to do, even just to use a different server IP, and that will be in > > the > > environment. > > I personally just use pxe boot It's not really about what personally you use, but what any user can use. > dhcp > pxe get > pxe boot > and pick the right option. nothing needed on the client side. It has the assumption that the DHCP server is setup properly, which might or might not be the case, especially when it comes to the server option being there and valid. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió: > On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote: > > El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió: > > > On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > > > > Hi, > > > > > > > > On 19/10/17 14:24, Maxime Ripard wrote: > > > > > On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > On 19/10/17 09:26, Maxime Ripard wrote: > > > > > > > Hi, > > > > > > > > > > > > > > Most featureful boards, such as the Cubietruck, have been > > > > > > > broken since > > > > > > > the release 2017.09. > > > > > > > > > > > > > > This is due to a size increase of the binary that will > > > > > > > trip > > > > > > > us across > > > > > > > the size we've been using in the u-boot-sunxi-with- > > > > > > > spl.bin > > > > > > > file. > > > > > > > > > > > > > > We would have two ways to work around it. The first one > > > > > > > would > > > > > > > be to > > > > > > > just increase the offset of the environment. However, > > > > > > > since > > > > > > > it would > > > > > > > break all the environments of our users and possibly the > > > > > > > custom > > > > > > > partition scheme that they would have created, it doesn't > > > > > > > really seem > > > > > > > like a smart move. > > > > > > > > > > > > Is that really such a problem? How many people rely on > > > > > > having > > > > > > their > > > > > > custom environment preserved over an update? (That's an > > > > > > honest > > > > > > question) > > > > > > > > > > All of them, I guess. In your U-boot upgrade script, do you > > > > > do a > > > > > 'env > > > > > default -a; saveenv' all the time ? > > > > > > > > > > I know I don't. > > > > > > > > Well, I never use the saved environment and always expected > > > > some > > > > user or > > > > board specific environment to come from some file (boot.scr or > > > > something > > > > loaded via TFTP). But that's just my personal use, hence I was > > > > asking. > > > > > > Well, even if you want to boot to tftp, you'll need to have some > > > setup > > > to do, even just to use a different server IP, and that will be > > > in > > > the > > > environment. > > > > I personally just use pxe boot > > It's not really about what personally you use, but what any user can > use. Not saying that it is. but how I use it is really simple for the user to use without needing to have a ton of specific knowledge about how u- boot works > > dhcp > > pxe get > > pxe boot > > and pick the right option. nothing needed on the client side. > > It has the assumption that the DHCP server is setup properly, which > might or might not be the case, especially when it comes to the > server > option being there and valid. > > Maxime Anyone doing something like this on X86 has to have the same setup. its not that hard of a ask to assume that a pxe environment is available. you can skip the dhcp part and set the serrver ip and system ip manually, its just simpler to use dhcp Dennis
Hi, On 24/10/17 18:05, Dennis Gilmore wrote: > El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió: >> On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote: >>> El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió: >>>> On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: >>>>> Hi, >>>>> >>>>> On 19/10/17 14:24, Maxime Ripard wrote: >>>>>> On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara >>>>>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 19/10/17 09:26, Maxime Ripard wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Most featureful boards, such as the Cubietruck, have been >>>>>>>> broken since >>>>>>>> the release 2017.09. >>>>>>>> >>>>>>>> This is due to a size increase of the binary that will >>>>>>>> trip >>>>>>>> us across >>>>>>>> the size we've been using in the u-boot-sunxi-with- >>>>>>>> spl.bin >>>>>>>> file. >>>>>>>> >>>>>>>> We would have two ways to work around it. The first one >>>>>>>> would >>>>>>>> be to >>>>>>>> just increase the offset of the environment. However, >>>>>>>> since >>>>>>>> it would >>>>>>>> break all the environments of our users and possibly the >>>>>>>> custom >>>>>>>> partition scheme that they would have created, it doesn't >>>>>>>> really seem >>>>>>>> like a smart move. >>>>>>> >>>>>>> Is that really such a problem? How many people rely on >>>>>>> having >>>>>>> their >>>>>>> custom environment preserved over an update? (That's an >>>>>>> honest >>>>>>> question) >>>>>> >>>>>> All of them, I guess. In your U-boot upgrade script, do you >>>>>> do a >>>>>> 'env >>>>>> default -a; saveenv' all the time ? >>>>>> >>>>>> I know I don't. >>>>> >>>>> Well, I never use the saved environment and always expected >>>>> some >>>>> user or >>>>> board specific environment to come from some file (boot.scr or >>>>> something >>>>> loaded via TFTP). But that's just my personal use, hence I was >>>>> asking. >>>> >>>> Well, even if you want to boot to tftp, you'll need to have some >>>> setup >>>> to do, even just to use a different server IP, and that will be >>>> in >>>> the >>>> environment. >>> >>> I personally just use pxe boot >> >> It's not really about what personally you use, but what any user can >> use. > Not saying that it is. but how I use it is really simple for the user > to use without needing to have a ton of specific knowledge about how u- > boot works > >>> dhcp >>> pxe get >>> pxe boot >>> and pick the right option. nothing needed on the client side. >> >> It has the assumption that the DHCP server is setup properly, which >> might or might not be the case, especially when it comes to the >> server >> option being there and valid. >> >> Maxime > Anyone doing something like this on X86 has to have the same setup. its > not that hard of a ask to assume that a pxe environment is available. > you can skip the dhcp part and set the serrver ip and system ip > manually, its just simpler to use dhcp I agree to both of you ;-) As Maxime already pointed out, it's a bit of a pointless discussion, as x U-Boot users have possibly x different usage scenarios. Some very actively do work on the U-Boot prompt and rely on a customized and preserved environment, while others merely rely on some standardized boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI. That being said I have prepared a patch to switch sunxi ARM64 boards over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there and have no Thumb2 to get off lightly. And I believe that the arm64 boards mostly use a standardized way of booting, also are much less wide spread, so the number of affected users is probably less there. I am just thinking of whether it's worthwhile to have some transition code, which tries multiple environment locations (first FAT, then MMC, for instance), or even contains code to migrate from one to another. Cheers, Andre.
On Tue, Oct 24, 2017 at 06:21:43PM +0100, Andre Przywara wrote: > That being said I have prepared a patch to switch sunxi ARM64 boards > over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there > and have no Thumb2 to get off lightly. And I believe that the arm64 > boards mostly use a standardized way of booting, also are much less wide > spread, so the number of affected users is probably less there. > > I am just thinking of whether it's worthwhile to have some transition > code, which tries multiple environment locations (first FAT, then MMC, > for instance), or even contains code to migrate from one to another. I started to look into the latter as well, because that's really what I'd like to see (for some time at least). I guess having a custom environment handling method would be the best, and it doesn't seem that hard. The behaviour I had in mind would be, when reading: - Look for an environment in a FAT partition - If not: - Load the raw environment - Print a warning When writing: - Try to write the environment to a FAT partition - If it fails: - Write to the raw environment - Print a warning That way, we can slowly migrate users in a transparent manner as soon as they would use saveenv, and we also provide a warning that things might (and actually will) break in the future if the setup isn't changed. We could even just rely on the existing methods from both standards environment code, we just need to make the functions !static. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
I'm personally feel trimming un(non)used bits(which might use in future or not) is not a good idea.why can't we have TPL because even adding Falcon might also increase the size. On 25-Oct-2017 11:43 AM, "Maxime Ripard" <maxime.ripard@free-electrons.com> wrote: On Tue, Oct 24, 2017 at 06:21:43PM +0100, Andre Przywara wrote: > That being said I have prepared a patch to switch sunxi ARM64 boards > over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there > and have no Thumb2 to get off lightly. And I believe that the arm64 > boards mostly use a standardized way of booting, also are much less wide > spread, so the number of affected users is probably less there. > > I am just thinking of whether it's worthwhile to have some transition > code, which tries multiple environment locations (first FAT, then MMC, > for instance), or even contains code to migrate from one to another. I started to look into the latter as well, because that's really what I'd like to see (for some time at least). I guess having a custom environment handling method would be the best, and it doesn't seem that hard. The behaviour I had in mind would be, when reading: - Look for an environment in a FAT partition - If not: - Load the raw environment - Print a warning When writing: - Try to write the environment to a FAT partition - If it fails: - Write to the raw environment - Print a warning That way, we can slowly migrate users in a transparent manner as soon as they would use saveenv, and we also provide a warning that things might (and actually will) break in the future if the setup isn't changed. We could even just rely on the existing methods from both standards environment code, we just need to make the functions !static. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Hi, On 25/10/17 10:42, Maxime Ripard wrote: > On Tue, Oct 24, 2017 at 06:21:43PM +0100, Andre Przywara wrote: >> That being said I have prepared a patch to switch sunxi ARM64 boards >> over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there >> and have no Thumb2 to get off lightly. And I believe that the arm64 >> boards mostly use a standardized way of booting, also are much less wide >> spread, so the number of affected users is probably less there. >> >> I am just thinking of whether it's worthwhile to have some transition >> code, which tries multiple environment locations (first FAT, then MMC, >> for instance), or even contains code to migrate from one to another. > > I started to look into the latter as well, because that's really what > I'd like to see (for some time at least). > > I guess having a custom environment handling method would be the best, > and it doesn't seem that hard. > > The behaviour I had in mind would be, when reading: > - Look for an environment in a FAT partition > - If not: > - Load the raw environment > - Print a warning > > When writing: > - Try to write the environment to a FAT partition > - If it fails: > - Write to the raw environment > - Print a warning > > That way, we can slowly migrate users in a transparent manner as soon > as they would use saveenv, and we also provide a warning that things > might (and actually will) break in the future if the setup isn't > changed. That was exactly what I had in mind as well! Do you have some spare cycles to implement this? If not, I can give it a try. > We could even just rely on the existing methods from both standards > environment code, we just need to make the functions !static. There is even a Delphic comment in env/Kconfig: "At *present* the environment can be stored in only one place." ;-) Cheers, Andre. P.S. I will arrive tonight in Prague, for the DT workshop tomorrow.
On Tue, 24 Oct 2017 18:21:43 +0100 Andre Przywara <andre.przywara@arm.com> wrote: > Hi, > > On 24/10/17 18:05, Dennis Gilmore wrote: > > El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió: > >> On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote: > >>> El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió: > >>>> On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > >>>>> Hi, > >>>>> > >>>>> On 19/10/17 14:24, Maxime Ripard wrote: > >>>>>> On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara > >>>>>> wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> On 19/10/17 09:26, Maxime Ripard wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Most featureful boards, such as the Cubietruck, have been > >>>>>>>> broken since > >>>>>>>> the release 2017.09. > >>>>>>>> > >>>>>>>> This is due to a size increase of the binary that will > >>>>>>>> trip > >>>>>>>> us across > >>>>>>>> the size we've been using in the u-boot-sunxi-with- > >>>>>>>> spl.bin > >>>>>>>> file. > >>>>>>>> > >>>>>>>> We would have two ways to work around it. The first one > >>>>>>>> would > >>>>>>>> be to > >>>>>>>> just increase the offset of the environment. However, > >>>>>>>> since > >>>>>>>> it would > >>>>>>>> break all the environments of our users and possibly the > >>>>>>>> custom > >>>>>>>> partition scheme that they would have created, it doesn't > >>>>>>>> really seem > >>>>>>>> like a smart move. > >>>>>>> > >>>>>>> Is that really such a problem? How many people rely on > >>>>>>> having > >>>>>>> their > >>>>>>> custom environment preserved over an update? (That's an > >>>>>>> honest > >>>>>>> question) > >>>>>> > >>>>>> All of them, I guess. In your U-boot upgrade script, do you > >>>>>> do a > >>>>>> 'env > >>>>>> default -a; saveenv' all the time ? > >>>>>> > >>>>>> I know I don't. > >>>>> > >>>>> Well, I never use the saved environment and always expected > >>>>> some > >>>>> user or > >>>>> board specific environment to come from some file (boot.scr or > >>>>> something > >>>>> loaded via TFTP). But that's just my personal use, hence I was > >>>>> asking. > >>>> > >>>> Well, even if you want to boot to tftp, you'll need to have some > >>>> setup > >>>> to do, even just to use a different server IP, and that will be > >>>> in > >>>> the > >>>> environment. > >>> > >>> I personally just use pxe boot > >> > >> It's not really about what personally you use, but what any user can > >> use. > > Not saying that it is. but how I use it is really simple for the user > > to use without needing to have a ton of specific knowledge about how u- > > boot works > > > >>> dhcp > >>> pxe get > >>> pxe boot > >>> and pick the right option. nothing needed on the client side. > >> > >> It has the assumption that the DHCP server is setup properly, which > >> might or might not be the case, especially when it comes to the > >> server > >> option being there and valid. > >> > >> Maxime > > Anyone doing something like this on X86 has to have the same setup. its > > not that hard of a ask to assume that a pxe environment is available. > > you can skip the dhcp part and set the serrver ip and system ip > > manually, its just simpler to use dhcp > > I agree to both of you ;-) > As Maxime already pointed out, it's a bit of a pointless discussion, as > x U-Boot users have possibly x different usage scenarios. > Some very actively do work on the U-Boot prompt and rely on a customized > and preserved environment, while others merely rely on some standardized > boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI. > > That being said I have prepared a patch to switch sunxi ARM64 boards > over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there > and have no Thumb2 to get off lightly. Even without Thumb2 we still can reduce footprint by taking advantage of compression for the main U-Boot binary. For this purpose we can use at least LZO because the decompressor code is really small (was it 200-300 bytes?) and still can fit in SPL. A more sophisticated approach can involve attaching the decompressor code to the main U-Boot binary itself. To be honest, I actually expected the size overflow problem to eventually happen for the SPL, resulting in a proposal of a similar radical feature chopping "solution". And when shit actually hits the fan, I will submit an LZO/UCL runtime decompression patch for the SPL, which can save the day :-) I have already mentioned this a few times in the past and it is our strategic reserve. The size overflow for the main U-Boot binary was a bit of surprise to me, but we still have it under control. Also as already discussed in this thread, we can just move the location of the environment to reserve more space for the main U-Boot binary (yes, handling the smooth environment location move during U-Boot upgrade will be a bit tricky, but still doable if anyone is really up to it). > And I believe that the arm64 boards mostly use a standardized way of > booting, also are much less wide spread, so the number of affected > users is probably less there. I don't think that we have any significant number of U-Boot env users on 32-bit sunxi hardware either. For example, we can do a search in the linux-sunxi wiki to compare the usage of environment vs. boot.scr and uEnv.txt: https://linux-sunxi.org/index.php?search=saveenv https://linux-sunxi.org/index.php?search=boot.scr https://linux-sunxi.org/index.php?search=uenv.txt Using saveenv is justified only in very rare exceptional cases. They do exist, otherwise Maxime would not have encountered the problem in the first place. But I think that we should encourage Maxime to migrate away from it. I would really like to know a bit more about his use case. The Linux distributions don't seem to rely on the U-Boot environment (if I understood their feedback correctly). Our tutorials at the linux-sunxi wiki encourage the use of boot.scr since a very long time ago. Anyone is free to deviate from good practices, but they should really know what they are doing and understand that they are expected to take care of their problems themselves. > I am just thinking of whether it's worthwhile to have some transition > code, which tries multiple environment locations (first FAT, then MMC, > for instance), or even contains code to migrate from one to another. Ugh. I think that this is a very bad idea. It makes the U-Boot environment handling even more convoluted and dangerous than it is now. I would prefer to keep the U-Boot environment (when its use is justified) tightly coupled with the bootloader itself and always stored on the same boot media. We do have the boot media id passed to us from the boot ROM, so this is pretty much straightforward. Allowing to move the environment to a different media is a recipe for disaster. Currently boot.scr or uEnv.txt is loaded from FAT or other partitions as part of distro boot. Is this really not enough?
Hi Jagan, On Wed, Oct 25, 2017 at 03:25:59PM +0530, Jagan Teki wrote: > I'm personally feel trimming un(non)used bits(which might use in > future or not) is not a good idea.why can't we have TPL because even > adding Falcon might also increase the size. As far as I understand it, the TPL is just an extra step between the SPL and the main U-Boot binary. I'm not exactly sure how that would allow us to increase the size of the main U-Boot binary. Can you elaborate? Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Hi, On 25/10/17 12:58, Siarhei Siamashka wrote: > On Tue, 24 Oct 2017 18:21:43 +0100 > Andre Przywara <andre.przywara@arm.com> wrote: > ..... >> >> That being said I have prepared a patch to switch sunxi ARM64 boards >> over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there >> and have no Thumb2 to get off lightly. > > Even without Thumb2 we still can reduce footprint by taking advantage > of compression for the main U-Boot binary. For this purpose we can use > at least LZO because the decompressor code is really small (was it > 200-300 bytes?) and still can fit in SPL. A more sophisticated approach > can involve attaching the decompressor code to the main U-Boot binary > itself. While it's good to know that we have this option for the future, I don't think it's needed right now to solve this particular issue. Because actually it's not a hard architectural limit, just some arbitrary hardcoded limit, which turns out to be too small. And it's actually only a problem when we consider the saved environment to be a crucial feature. > To be honest, I actually expected the size overflow problem to > eventually happen for the SPL, resulting in a proposal of a similar > radical feature chopping "solution". And when shit actually hits the > fan, I will submit an LZO/UCL runtime decompression patch for the SPL, > which can save the day :-) Looking forward to that ;-) > I have already mentioned this a few times in > the past and it is our strategic reserve. The size overflow for the > main U-Boot binary was a bit of surprise to me, but we still have it > under control. > > Also as already discussed in this thread, we can just move the location > of the environment to reserve more space for the main U-Boot binary > (yes, handling the smooth environment location move during U-Boot > upgrade will be a bit tricky, but still doable if anyone is really > up to it). So do you propose to migrate the environment during an upgrade process? I like that idea, but don't think we have anything like a standardized "upgrade process" at the moment. And don't have the time to introduce this. >> And I believe that the arm64 boards mostly use a standardized way of >> booting, also are much less wide spread, so the number of affected >> users is probably less there. > > I don't think that we have any significant number of U-Boot env users > on 32-bit sunxi hardware either. For example, we can do a search in > the linux-sunxi wiki to compare the usage of environment vs. boot.scr > and uEnv.txt: > > https://linux-sunxi.org/index.php?search=saveenv > https://linux-sunxi.org/index.php?search=boot.scr > https://linux-sunxi.org/index.php?search=uenv.txt > > Using saveenv is justified only in very rare exceptional cases. They do > exist, otherwise Maxime would not have encountered the problem in the > first place. But I think that we should encourage Maxime to migrate > away from it. I would really like to know a bit more about his use case. As mentioned above, I don't care so much about a saved environment, but I am merely a "user" of U-Boot, so it's not really my call. As long as there is a non-negligible amount of users, we should consider preserving the saved environment. > The Linux distributions don't seem to rely on the U-Boot environment > (if I understood their feedback correctly). That would be an interesting data point to know for sure. > Our tutorials at the > linux-sunxi wiki encourage the use of boot.scr since a very long > time ago. Anyone is free to deviate from good practices, but they > should really know what they are doing and understand that they are > expected to take care of their problems themselves. > >> I am just thinking of whether it's worthwhile to have some transition >> code, which tries multiple environment locations (first FAT, then MMC, >> for instance), or even contains code to migrate from one to another. > > Ugh. I think that this is a very bad idea. It makes the U-Boot > environment handling even more convoluted and dangerous than it is > now. I would prefer to keep the U-Boot environment (when its use is > justified) tightly coupled with the bootloader itself and always > stored on the same boot media. We do have the boot media id passed > to us from the boot ROM, so this is pretty much straightforward. But this is not how it works at the moment for sunxi (or U-Boot in general), is it? I think we have ENV_IS_IN_MMC defined for sunxi, so we don't access the environment in SPI flash, should we boot from there, for instance (not talking about the missing SPI driver here for now). And how I understand the code this environment location is hardcoded at compile time, so does not take the actual boot source into account? Or does this somehow work with NAND, for instance? Or eMMC vs. SD card? > Allowing to move the environment to a different media is a recipe > for disaster. Why so? I see that it's not very pretty, but I consider this a user friendly solution to some technical problem we need to solve. Maybe we can actually clean up the U-Boot environment code on the way? > Currently boot.scr or uEnv.txt is loaded from FAT or other > partitions as part of distro boot. Is this really not enough? From my point of view: yes. But Maxime strongly hinted that other people might disagree. Cheers, Andre.
On Wed, Oct 25, 2017 at 02:58:44PM +0300, Siarhei Siamashka wrote: > On Tue, 24 Oct 2017 18:21:43 +0100 > Andre Przywara <andre.przywara@arm.com> wrote: > > > Hi, > > > > On 24/10/17 18:05, Dennis Gilmore wrote: > > > El lun, 23-10-2017 a las 09:35 +0200, Maxime Ripard escribió: > > >> On Fri, Oct 20, 2017 at 04:33:57PM -0500, Dennis Gilmore wrote: > > >>> El jue, 19-10-2017 a las 16:58 +0200, Maxime Ripard escribió: > > >>>> On Thu, Oct 19, 2017 at 03:42:11PM +0100, Andre Przywara wrote: > > >>>>> Hi, > > >>>>> > > >>>>> On 19/10/17 14:24, Maxime Ripard wrote: > > >>>>>> On Thu, Oct 19, 2017 at 02:03:55PM +0100, Andre Przywara > > >>>>>> wrote: > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> On 19/10/17 09:26, Maxime Ripard wrote: > > >>>>>>>> Hi, > > >>>>>>>> > > >>>>>>>> Most featureful boards, such as the Cubietruck, have been > > >>>>>>>> broken since > > >>>>>>>> the release 2017.09. > > >>>>>>>> > > >>>>>>>> This is due to a size increase of the binary that will > > >>>>>>>> trip > > >>>>>>>> us across > > >>>>>>>> the size we've been using in the u-boot-sunxi-with- > > >>>>>>>> spl.bin > > >>>>>>>> file. > > >>>>>>>> > > >>>>>>>> We would have two ways to work around it. The first one > > >>>>>>>> would > > >>>>>>>> be to > > >>>>>>>> just increase the offset of the environment. However, > > >>>>>>>> since > > >>>>>>>> it would > > >>>>>>>> break all the environments of our users and possibly the > > >>>>>>>> custom > > >>>>>>>> partition scheme that they would have created, it doesn't > > >>>>>>>> really seem > > >>>>>>>> like a smart move. > > >>>>>>> > > >>>>>>> Is that really such a problem? How many people rely on > > >>>>>>> having > > >>>>>>> their > > >>>>>>> custom environment preserved over an update? (That's an > > >>>>>>> honest > > >>>>>>> question) > > >>>>>> > > >>>>>> All of them, I guess. In your U-boot upgrade script, do you > > >>>>>> do a > > >>>>>> 'env > > >>>>>> default -a; saveenv' all the time ? > > >>>>>> > > >>>>>> I know I don't. > > >>>>> > > >>>>> Well, I never use the saved environment and always expected > > >>>>> some > > >>>>> user or > > >>>>> board specific environment to come from some file (boot.scr or > > >>>>> something > > >>>>> loaded via TFTP). But that's just my personal use, hence I was > > >>>>> asking. > > >>>> > > >>>> Well, even if you want to boot to tftp, you'll need to have some > > >>>> setup > > >>>> to do, even just to use a different server IP, and that will be > > >>>> in > > >>>> the > > >>>> environment. > > >>> > > >>> I personally just use pxe boot > > >> > > >> It's not really about what personally you use, but what any user can > > >> use. > > > Not saying that it is. but how I use it is really simple for the user > > > to use without needing to have a ton of specific knowledge about how u- > > > boot works > > > > > >>> dhcp > > >>> pxe get > > >>> pxe boot > > >>> and pick the right option. nothing needed on the client side. > > >> > > >> It has the assumption that the DHCP server is setup properly, which > > >> might or might not be the case, especially when it comes to the > > >> server > > >> option being there and valid. > > >> > > >> Maxime > > > Anyone doing something like this on X86 has to have the same setup. its > > > not that hard of a ask to assume that a pxe environment is available. > > > you can skip the dhcp part and set the serrver ip and system ip > > > manually, its just simpler to use dhcp > > > > I agree to both of you ;-) > > As Maxime already pointed out, it's a bit of a pointless discussion, as > > x U-Boot users have possibly x different usage scenarios. > > Some very actively do work on the U-Boot prompt and rely on a customized > > and preserved environment, while others merely rely on some standardized > > boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI. > > > > That being said I have prepared a patch to switch sunxi ARM64 boards > > over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there > > and have no Thumb2 to get off lightly. > > Even without Thumb2 we still can reduce footprint by taking advantage > of compression for the main U-Boot binary. For this purpose we can use > at least LZO because the decompressor code is really small (was it > 200-300 bytes?) and still can fit in SPL. A more sophisticated approach > can involve attaching the decompressor code to the main U-Boot binary > itself. > > To be honest, I actually expected the size overflow problem to > eventually happen for the SPL, resulting in a proposal of a similar > radical feature chopping "solution". And when shit actually hits the > fan, I will submit an LZO/UCL runtime decompression patch for the SPL, > which can save the day :-) I have already mentioned this a few times in > the past and it is our strategic reserve. The size overflow for the > main U-Boot binary was a bit of surprise to me, but we still have it > under control. Would you mind posting the runtime decompression part? We have other platforms that are already stuck due to small size limits and something like this might finally un-block them. Thanks! -- Tom
Hi Siarhei, On Wed, Oct 25, 2017 at 02:58:44PM +0300, Siarhei Siamashka wrote: > > > Anyone doing something like this on X86 has to have the same setup. its > > > not that hard of a ask to assume that a pxe environment is available. > > > you can skip the dhcp part and set the serrver ip and system ip > > > manually, its just simpler to use dhcp > > > > I agree to both of you ;-) > > As Maxime already pointed out, it's a bit of a pointless discussion, as > > x U-Boot users have possibly x different usage scenarios. > > Some very actively do work on the U-Boot prompt and rely on a customized > > and preserved environment, while others merely rely on some standardized > > boot paths, using config_distro_bootcmd.h and PXE, DHCP and/or EFI. > > > > That being said I have prepared a patch to switch sunxi ARM64 boards > > over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there > > and have no Thumb2 to get off lightly. > > Even without Thumb2 we still can reduce footprint by taking advantage > of compression for the main U-Boot binary. For this purpose we can use > at least LZO because the decompressor code is really small (was it > 200-300 bytes?) and still can fit in SPL. A more sophisticated approach > can involve attaching the decompressor code to the main U-Boot binary > itself. > > To be honest, I actually expected the size overflow problem to > eventually happen for the SPL, resulting in a proposal of a similar > radical feature chopping "solution". And when shit actually hits the > fan, I will submit an LZO/UCL runtime decompression patch for the > SPL, which can save the day :-) I have already mentioned this a few > times in the past and it is our strategic reserve. The size overflow > for the main U-Boot binary was a bit of surprise to me, but we still > have it under control. I guess one of the reason is that we pretty much have a fixed set of features in the SPL, and there's nothing really missing either, so the size isn't changing that much. The U-Boot binary however gains new features on a regular basis, each of them increasing slightly the binary size. But yeah, that's definitely one of the things we can do :) > Also as already discussed in this thread, we can just move the location > of the environment to reserve more space for the main U-Boot binary > (yes, handling the smooth environment location move during U-Boot > upgrade will be a bit tricky, but still doable if anyone is really > up to it). I've sent a (rather dumb) attempt earlier today as an RFC. > > And I believe that the arm64 boards mostly use a standardized way of > > booting, also are much less wide spread, so the number of affected > > users is probably less there. > > I don't think that we have any significant number of U-Boot env users > on 32-bit sunxi hardware either. For example, we can do a search in > the linux-sunxi wiki to compare the usage of environment vs. boot.scr > and uEnv.txt: > > https://linux-sunxi.org/index.php?search=saveenv > https://linux-sunxi.org/index.php?search=boot.scr > https://linux-sunxi.org/index.php?search=uenv.txt > > Using saveenv is justified only in very rare exceptional cases. They do > exist, otherwise Maxime would not have encountered the problem in the > first place. But I think that we should encourage Maxime to migrate > away from it. I would really like to know a bit more about his use case. There's several of them actually. For example, if fast boot (as in booting fast, not the Android stuff) is something you need, the distro bootcmd is not an option. Only the preboot command that initialize USB will take more time than needed to boot your whole system. The other one is for upgrade mechanism such as Mender.io that will need some changes (and access) to the U-Boot environment to do A-B style upgrades. > The Linux distributions don't seem to rely on the U-Boot environment > (if I understood their feedback correctly). Our tutorials at the > linux-sunxi wiki encourage the use of boot.scr since a very long > time ago. Anyone is free to deviate from good practices, but they > should really know what they are doing and understand that they are > expected to take care of their problems themselves. > > > I am just thinking of whether it's worthwhile to have some transition > > code, which tries multiple environment locations (first FAT, then MMC, > > for instance), or even contains code to migrate from one to another. > > Ugh. I think that this is a very bad idea. It makes the U-Boot > environment handling even more convoluted and dangerous than it is > now. I would prefer to keep the U-Boot environment (when its use is > justified) tightly coupled with the bootloader itself and always > stored on the same boot media. We do have the boot media id passed > to us from the boot ROM, so this is pretty much straightforward. > Allowing to move the environment to a different media is a recipe > for disaster. I think Andre's point was only about storing the environment at different locations, but on the same media. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[CCing Vagrant Cascadian, the Debian U-Boot maintainer] On Wed, Oct 25, 2017 at 02:42:50PM +0100, Andre Przywara wrote: > On 25/10/17 12:58, Siarhei Siamashka wrote: > > On Tue, 24 Oct 2017 18:21:43 +0100 > > Andre Przywara <andre.przywara@arm.com> wrote: > >> That being said I have prepared a patch to switch sunxi ARM64 boards > >> over to ENV_IS_IN_FAT, because I guess we will hit the wall soon there > >> and have no Thumb2 to get off lightly. [...] > > I don't think that we have any significant number of U-Boot env users > > on 32-bit sunxi hardware either. For example, we can do a search in > > the linux-sunxi wiki to compare the usage of environment vs. boot.scr > > and uEnv.txt: > > > > https://linux-sunxi.org/index.php?search=saveenv > > https://linux-sunxi.org/index.php?search=boot.scr > > https://linux-sunxi.org/index.php?search=uenv.txt > > > > Using saveenv is justified only in very rare exceptional cases. They do > > exist, otherwise Maxime would not have encountered the problem in the > > first place. But I think that we should encourage Maxime to migrate > > away from it. I would really like to know a bit more about his use case. Hello, I cannot speak for Maxime, but from a distro point of view there are at least two common usecases: a) Changing the default boot order At least among Debian users it is not uncommon to run the installer from an SD-card (Debian provides SD-card images with u-boot and the Debian installer) and install the distro to a harddisk (especially on the A20 where native SATA is available). The default boot order is MMC before SATA and USB, i.e. after installing to SATA or USB, the user must change the boot order by setting the boot_targets variable accordingly and saving it into the persistent environment, because otherwise the system would reboot into the installer on the SD card all the time instead of booting the installed system. Removing the SD card isn't an option because then there wouldn't be any (mainline) u-boot anymore. This isn't a problem when installing to the SD-card from which the installer was loaded as the SD-card gets repartitioned and the installer is overwritten in that case. b) Changing the default console device The Debian boot.scr passes the contents of the u-boot console variable to the kernel as the system console device. All sunxi-based systems default to serial console, but there are quite a number of users that don't have a serial console cable but instead run their console on HDMI. They change their system console by setting the u-boot "console" variable accordingly and running saveenv. This works as u-boot runs its own console both on serial and simplefb in parallel, while the Linux kernel can only have one system console device at a time. > As mentioned above, I don't care so much about a saved environment, but > I am merely a "user" of U-Boot, so it's not really my call. > As long as there is a non-negligible amount of users, we should consider > preserving the saved environment. > > > The Linux distributions don't seem to rely on the U-Boot environment > > (if I understood their feedback correctly). > > That would be an interesting data point to know for sure. Please see above :-). > > Currently boot.scr or uEnv.txt is loaded from FAT or other > > partitions as part of distro boot. Is this really not enough? In Debian's case it is "other partitions". Debian doesn't create any FAT partitions on non-UEFI systems. The /boot partition is ext2 and for the other partitions ext4 is the default filesystem. Therefore forcing the environment onto a FAT partition would surely cause problems when upgrading an existing system to a newer u-boot version. uEnv.txt is AFAICS not used by mainline u-boot at all, at least on sunxi-based systems. Regards, Karsten
El mié, 25-10-2017 a las 20:41 +0200, Karsten Merker escribió: > [CCing Vagrant Cascadian, the Debian U-Boot maintainer] > > On Wed, Oct 25, 2017 at 02:42:50PM +0100, Andre Przywara wrote: > > On 25/10/17 12:58, Siarhei Siamashka wrote: > > > On Tue, 24 Oct 2017 18:21:43 +0100 > > > Andre Przywara <andre.przywara@arm.com> wrote: > > > > That being said I have prepared a patch to switch sunxi ARM64 > > > > boards > > > > over to ENV_IS_IN_FAT, because I guess we will hit the wall > > > > soon there > > > > and have no Thumb2 to get off lightly. > > [...] > > > I don't think that we have any significant number of U-Boot env > > > users > > > on 32-bit sunxi hardware either. For example, we can do a search > > > in > > > the linux-sunxi wiki to compare the usage of environment vs. > > > boot.scr > > > and uEnv.txt: > > > > > > https://linux-sunxi.org/index.php?search=saveenv > > > https://linux-sunxi.org/index.php?search=boot.scr > > > https://linux-sunxi.org/index.php?search=uenv.txt > > > > > > Using saveenv is justified only in very rare exceptional cases. > > > They do > > > exist, otherwise Maxime would not have encountered the problem in > > > the > > > first place. But I think that we should encourage Maxime to > > > migrate > > > away from it. I would really like to know a bit more about his > > > use case. > > Hello, > > I cannot speak for Maxime, but from a distro point of view there are > at > least two common usecases: > > a) Changing the default boot order > > At least among Debian users it is not uncommon to run the > installer from an SD-card (Debian provides SD-card images with > u-boot and the Debian installer) and install the distro to a > harddisk (especially on the A20 where native SATA is > available). The default boot order is MMC before SATA and > USB, i.e. after installing to SATA or USB, the user must > change the boot order by setting the boot_targets variable > accordingly and saving it into the persistent environment, > because otherwise the system would reboot into the installer > on the SD card all the time instead of booting the installed > system. Removing the SD card isn't an option because then > there wouldn't be any (mainline) u-boot anymore. > > This isn't a problem when installing to the SD-card from which > the installer was loaded as the SD-card gets repartitioned and > the installer is overwritten in that case. This is a bit unfortunate, if only we had spi or some other flash for stroing u-boot on all the hardware so that vendors could ship something that just works. wiping out the installer would b an option, but that is pretty ugly. > b) Changing the default console device > > The Debian boot.scr passes the contents of the u-boot console > variable to the kernel as the system console device. All > sunxi-based systems default to serial console, but there are > quite a number of users that don't have a serial console cable > but instead run their console on HDMI. They change their > system console by setting the u-boot "console" variable > accordingly and running saveenv. This works as u-boot runs > its own console both on serial and simplefb in parallel, while > the Linux kernel can only have one system console device at > a time. u-boot and the linux kernel actually default to displaying to both the serial console and the HDMI console. the user can intereact with both at the same time. At least it is true on the sunxi machines I have tested it on, with zero need to setup any console lines or do anything special. I suspect that you no longer need to have a boot.scr at all. > > As mentioned above, I don't care so much about a saved environment, > > but > > I am merely a "user" of U-Boot, so it's not really my call. > > As long as there is a non-negligible amount of users, we should > > consider > > preserving the saved environment. > > > > > The Linux distributions don't seem to rely on the U-Boot > > > environment > > > (if I understood their feedback correctly). > > > > That would be an interesting data point to know for sure. > > Please see above :-). > > > > Currently boot.scr or uEnv.txt is loaded from FAT or other > > > partitions as part of distro boot. Is this really not enough? > In Debian's case it is "other partitions". Debian doesn't create > any FAT partitions on non-UEFI systems. The /boot partition is > ext2 and for the other partitions ext4 is the default filesystem. > Therefore forcing the environment onto a FAT partition would > surely cause problems when upgrading an existing system to a > newer u-boot version. > > uEnv.txt is AFAICS not used by mainline u-boot at all, at least > on sunxi-based systems. Fedora does not use or support uEnv.txt or boot.scr our disk images ship with a fat partition at the start so that we can ship the firmware needed to boot on a raspberry pi, however any 32 bit system installed using anaconda will not have a fat partition at all. /boot is ext4 and depeding on if you use server or a different installer you will by default get xfs or ext4 on lvm, there is the ability to choose different options. Older disk images before we supported raspberry pi did not have fat partition at all. so there is likely a lot of machines without access to afat partition that would break if if it became required. Dennis