[U-Boot] [PATCH] OpenRD: relocate environment to 640kB
U-Boot has become slightly larger than where the environment sector was previously located. Saving the environment would brick the device.
Relocate the environment to where it is with the stock (i.e. Marvell USP) U-Boot version. That should give plenty of room for U-Boot to grow, including local customisations.
This obviously breaks compatibility with previous mainline versions of U-Boot. Users will need to back up the environment before an update and restore it afterwards, or manually copy it to the new address before the update.
Signed-off-by: Sascha Silbe t-uboot@infra-silbe.de --- include/configs/openrd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/openrd.h b/include/configs/openrd.h index 53bafe1..ea7f9aa 100644 --- a/include/configs/openrd.h +++ b/include/configs/openrd.h @@ -90,8 +90,8 @@ * it has to be rounded to sector size */ #define CONFIG_ENV_SIZE 0x20000 /* 128k */ -#define CONFIG_ENV_ADDR 0x60000 -#define CONFIG_ENV_OFFSET 0x60000 /* env starts here */ +#define CONFIG_ENV_ADDR 0xa0000 +#define CONFIG_ENV_OFFSET 0xa0000 /* env starts here */
/* * Default environment variables
Hi Sascha,
On Mon, 27 May 2013 11:42:26 +0200, Sascha Silbe t-uboot@infra-silbe.de wrote:
U-Boot has become slightly larger than where the environment sector was previously located. Saving the environment would brick the device.
Relocate the environment to where it is with the stock (i.e. Marvell USP) U-Boot version. That should give plenty of room for U-Boot to grow, including local customisations.
This obviously breaks compatibility with previous mainline versions of U-Boot. Users will need to back up the environment before an update and restore it afterwards, or manually copy it to the new address before the update.
Signed-off-by: Sascha Silbe t-uboot@infra-silbe.de
include/configs/openrd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/openrd.h b/include/configs/openrd.h index 53bafe1..ea7f9aa 100644 --- a/include/configs/openrd.h +++ b/include/configs/openrd.h @@ -90,8 +90,8 @@
- it has to be rounded to sector size
*/ #define CONFIG_ENV_SIZE 0x20000 /* 128k */ -#define CONFIG_ENV_ADDR 0x60000 -#define CONFIG_ENV_OFFSET 0x60000 /* env starts here */ +#define CONFIG_ENV_ADDR 0xa0000 +#define CONFIG_ENV_OFFSET 0xa0000 /* env starts here */
/*
- Default environment variables
CC:ing Tom.
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
Amicalement,
On Tue, 11 Jun 2013 12:00:19 +0200, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Sascha,
On Mon, 27 May 2013 11:42:26 +0200, Sascha Silbe t-uboot@infra-silbe.de wrote:
U-Boot has become slightly larger than where the environment sector was previously located. Saving the environment would brick the device.
Relocate the environment to where it is with the stock (i.e. Marvell USP) U-Boot version. That should give plenty of room for U-Boot to grow, including local customisations.
This obviously breaks compatibility with previous mainline versions of U-Boot. Users will need to back up the environment before an update and restore it afterwards, or manually copy it to the new address before the update.
Signed-off-by: Sascha Silbe t-uboot@infra-silbe.de
include/configs/openrd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/openrd.h b/include/configs/openrd.h index 53bafe1..ea7f9aa 100644 --- a/include/configs/openrd.h +++ b/include/configs/openrd.h @@ -90,8 +90,8 @@
- it has to be rounded to sector size
*/ #define CONFIG_ENV_SIZE 0x20000 /* 128k */ -#define CONFIG_ENV_ADDR 0x60000 -#define CONFIG_ENV_OFFSET 0x60000 /* env starts here */ +#define CONFIG_ENV_ADDR 0xa0000 +#define CONFIG_ENV_OFFSET 0xa0000 /* env starts here */
/*
- Default environment variables
CC:ing Tom.
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
Amicalement,
Ping.
Amicalement,
On Sat, Jun 22, 2013 at 11:29:59AM +0200, Albert ARIBAUD wrote:
On Tue, 11 Jun 2013 12:00:19 +0200, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hi Sascha,
On Mon, 27 May 2013 11:42:26 +0200, Sascha Silbe t-uboot@infra-silbe.de wrote:
U-Boot has become slightly larger than where the environment sector was previously located. Saving the environment would brick the device.
Relocate the environment to where it is with the stock (i.e. Marvell USP) U-Boot version. That should give plenty of room for U-Boot to grow, including local customisations.
This obviously breaks compatibility with previous mainline versions of U-Boot. Users will need to back up the environment before an update and restore it afterwards, or manually copy it to the new address before the update.
Signed-off-by: Sascha Silbe t-uboot@infra-silbe.de
include/configs/openrd.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/openrd.h b/include/configs/openrd.h index 53bafe1..ea7f9aa 100644 --- a/include/configs/openrd.h +++ b/include/configs/openrd.h @@ -90,8 +90,8 @@
- it has to be rounded to sector size
*/ #define CONFIG_ENV_SIZE 0x20000 /* 128k */ -#define CONFIG_ENV_ADDR 0x60000 -#define CONFIG_ENV_OFFSET 0x60000 /* env starts here */ +#define CONFIG_ENV_ADDR 0xa0000 +#define CONFIG_ENV_OFFSET 0xa0000 /* env starts here */
/*
- Default environment variables
CC:ing Tom.
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
Amicalement,
Ping.
Oh right, agree your idea here.
Hello Albert, hello Tom,
Albert ARIBAUD albert.u.boot@aribaud.net writes:
[Move environment to account for increase in U-Boot size]
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
Where are the U-Boot Release Notes located? Who is responsible for editing them?
Sascha
Hi Sascha,
On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe t-uboot@infra-silbe.de wrote:
Hello Albert, hello Tom,
Albert ARIBAUD albert.u.boot@aribaud.net writes:
[Move environment to account for increase in U-Boot size]
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
Where are the U-Boot Release Notes located? Who is responsible for editing them?
Sascha
Amicalement,
On Thu, Jun 27, 2013 at 11:41:59AM +0200, Albert ARIBAUD wrote:
Hi Sascha,
On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe t-uboot@infra-silbe.de wrote:
Hello Albert, hello Tom,
Albert ARIBAUD albert.u.boot@aribaud.net writes:
[Move environment to account for increase in U-Boot size]
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I imagine that adding -ffunction-sections/-fdata-sections/--gc-sections is what brought the size back down again. We've been adding a lot of kinda optional code, and to avoid having to ifdef the hell out of everything, we've been relying on growth not being a big problem or just ignoring it.
Hi Tom,
On Thu, 11 Jul 2013 12:15:50 -0400, Tom Rini trini@ti.com wrote:
On Thu, Jun 27, 2013 at 11:41:59AM +0200, Albert ARIBAUD wrote:
Hi Sascha,
On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe t-uboot@infra-silbe.de wrote:
Hello Albert, hello Tom,
Albert ARIBAUD albert.u.boot@aribaud.net writes:
[Move environment to account for increase in U-Boot size]
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I imagine that adding -ffunction-sections/-fdata-sections/--gc-sections is what brought the size back down again. We've been adding a lot of kinda optional code, and to avoid having to ifdef the hell out of everything, we've been relying on growth not being a big problem or just ignoring it.
... Which in the end can bite back, see anonymous string issue. Are we heading back to carefully selecting which files we build rather than building then dropping?
Amicalement,
On Thu, Jul 11, 2013 at 07:40:28PM +0200, Albert ARIBAUD wrote:
Hi Tom,
On Thu, 11 Jul 2013 12:15:50 -0400, Tom Rini trini@ti.com wrote:
On Thu, Jun 27, 2013 at 11:41:59AM +0200, Albert ARIBAUD wrote:
Hi Sascha,
On Tue, 25 Jun 2013 11:42:53 +0200, Sascha Silbe t-uboot@infra-silbe.de wrote:
Hello Albert, hello Tom,
Albert ARIBAUD albert.u.boot@aribaud.net writes:
[Move environment to account for increase in U-Boot size]
This patch is for 2013.10, not 2013.07, but I prefer raising the issue as early as possible.
If there is no way to make things smoother, then I think the 2013.10 release notes should contain a red, blinking, paragraph about this. I would *hate* it if people were not warned and given a method to port their current environment setting over.
Possibly even, the 2013.07 could have a warning about the change to come, so that people have a better chance yet to prepare for the change.
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I imagine that adding -ffunction-sections/-fdata-sections/--gc-sections is what brought the size back down again. We've been adding a lot of kinda optional code, and to avoid having to ifdef the hell out of everything, we've been relying on growth not being a big problem or just ignoring it.
... Which in the end can bite back, see anonymous string issue. Are we heading back to carefully selecting which files we build rather than building then dropping?
It depends on what we can get from the tools we have, cleanly. I've seen, for example, patches to kill all output from SPL, as that was required to get the required big features into a size constrained SPL. But I don't think it was clean enough for mainline. On the other hand, we've got some large files, and if splitting them up for logical uses also gets us working around string issues, good for us.
Albert ARIBAUD albert.u.boot@aribaud.net writes:
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I had the same questions and tried a few buildman runs, but didn't get a clear picture. The size was going up and down for various slices of commits.
With v2013.07-rc3, we are now at 376344B (≈ 96% of 384KiB) for openrd_ultimate when built on Debian Wheezy using gcc-4.7-arm-linux-gnueabi from Emdebian.
Is there an equivalent to CONFIG_SPL_MAX_SIZE for the "regular" U-Boot? Detecting the overlap at build time would prevent bricking the device using saveenv at run time. As an additional benefit, commits that push the size beyond the limit would also show up in buildman reports as build failures.
Sascha
Hi Sascha,
On Mon, 15 Jul 2013 11:23:54 +0200, Sascha Silbe t-uboot@infra-silbe.de wrote:
Albert ARIBAUD albert.u.boot@aribaud.net writes:
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I had the same questions and tried a few buildman runs, but didn't get a clear picture. The size was going up and down for various slices of commits.
With v2013.07-rc3, we are now at 376344B (≈ 96% of 384KiB) for openrd_ultimate when built on Debian Wheezy using gcc-4.7-arm-linux-gnueabi from Emdebian.
Thanks for the info.
Is there an equivalent to CONFIG_SPL_MAX_SIZE for the "regular" U-Boot? Detecting the overlap at build time would prevent bricking the device using saveenv at run time. As an additional benefit, commits that push the size beyond the limit would also show up in buildman reports as build failures.
I don't know of a feature like CONFIG_SPL_MAX_SIZE for regular U-Boot. You could 'port it over' as something like CONFIG_MAX_IMAGE_SIZE for U-Boot.
Somehow I gather that an approach like the one I sketched out in http://article.gmane.org/gmane.comp.boot-loaders.u-boot/165510 could bring benefits like making CONFIG_SPL_MAX_SIZE a feature of a "constraints" component which could be built as well in U-Boot as in SPL; but that's at the very early RFC stage anyway -- actually, it drew no reaction at all so far, leading me to think it's not that useful.
Sascha
Amicalement,
On Mon, Jul 15, 2013 at 11:23:54AM +0200, Sascha Silbe wrote:
Albert ARIBAUD albert.u.boot@aribaud.net writes:
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I had the same questions and tried a few buildman runs, but didn't get a clear picture. The size was going up and down for various slices of commits.
With v2013.07-rc3, we are now at 376344B (??? 96% of 384KiB) for openrd_ultimate when built on Debian Wheezy using gcc-4.7-arm-linux-gnueabi from Emdebian.
Is there an equivalent to CONFIG_SPL_MAX_SIZE for the "regular" U-Boot? Detecting the overlap at build time would prevent bricking the device using saveenv at run time. As an additional benefit, commits that push the size beyond the limit would also show up in buildman reports as build failures.
Yes, you can try using CONFIG_BOARD_SIZE_LIMIT, which is missing from the README, but does have a few examples (git grep around). A patch to document it, and then a patch to enable for openrd would be much appreciated. Thanks!
Sascha
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi Sascha,
On Mon, 15 Jul 2013 08:19:57 -0400, Tom Rini trini@ti.com wrote:
On Mon, Jul 15, 2013 at 11:23:54AM +0200, Sascha Silbe wrote:
Albert ARIBAUD albert.u.boot@aribaud.net writes:
The situation has gotten better recently and U-Boot fits into the previous partition size of 384KiB again. So it isn't broken on OpenRD anymore and the above would seem like a good approach.
How well does it fit again, and do you have any idea what caused the increase in size, and what caused the decrease?
I had the same questions and tried a few buildman runs, but didn't get a clear picture. The size was going up and down for various slices of commits.
With v2013.07-rc3, we are now at 376344B (??? 96% of 384KiB) for openrd_ultimate when built on Debian Wheezy using gcc-4.7-arm-linux-gnueabi from Emdebian.
Is there an equivalent to CONFIG_SPL_MAX_SIZE for the "regular" U-Boot? Detecting the overlap at build time would prevent bricking the device using saveenv at run time. As an additional benefit, commits that push the size beyond the limit would also show up in buildman reports as build failures.
Yes, you can try using CONFIG_BOARD_SIZE_LIMIT, which is missing from the README, but does have a few examples (git grep around). A patch to document it, and then a patch to enable for openrd would be much appreciated. Thanks!
Sascha, does this mean the env relocate patch here is dropped in favor of a CONFIG_BOARD_SIZE_LIMIT check at build time?
Amicalement,
Hi Albert,
Albert ARIBAUD albert.u.boot@aribaud.net writes:
On Mon, 15 Jul 2013 08:19:57 -0400, Tom Rini trini@ti.com wrote:
On Mon, Jul 15, 2013 at 11:23:54AM +0200, Sascha Silbe wrote:
With v2013.07-rc3, we are now at 376344B (~ 96% of 384KiB) for openrd_ultimate when built on Debian Wheezy using gcc-4.7-arm-linux-gnueabi from Emdebian.
[...]
Yes, you can try using CONFIG_BOARD_SIZE_LIMIT, which is missing from the README, but does have a few examples (git grep around). A patch to document it, and then a patch to enable for openrd would be much appreciated. Thanks!
Sascha, does this mean the env relocate patch here is dropped in favor of a CONFIG_BOARD_SIZE_LIMIT check at build time?
Given that we're already very close to the limit, we'll likely need the environment relocation patch sooner or later anyway. I'd prefer it to go in now as part of the regular release cycle, rather than as a hot-fix whenever it finally spills over. That also reduces the risk of builds failing only with particular toolchain versions.
Sascha
Tom Rini trini@ti.com writes:
Yes, you can try using CONFIG_BOARD_SIZE_LIMIT, which is missing from the README, but does have a few examples (git grep around). A patch to document it, and then a patch to enable for openrd would be much appreciated. Thanks!
Thanks for the pointer. Here we go.
Sascha Silbe (3): README: document CONFIG_BOARD_SIZE_LIMIT Makefile: check native boot image sizes against CONFIG_BOARD_SIZE_LIMIT openrd: fail build if U-Boot would overlap with environment in flash
Makefile | 3 +++ README | 5 +++++ include/configs/openrd.h | 5 +++++ 3 files changed, 13 insertions(+)
CONFIG_BOARD_SIZE_LIMIT was introduced by f3a14d37 [Makefile: allow boards to check file size limits] and is in use by several boards, but never got documented.
Signed-off-by: Sascha Silbe t-uboot@infra-silbe.de --- README | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/README b/README index a5c3e8d..760c417 100644 --- a/README +++ b/README @@ -3843,6 +3843,11 @@ use the "saveenv" command to store a valid environment. later, once stdio is running and output goes to the LCD, if present.
+- CONFIG_BOARD_SIZE_LIMIT: + Maximum size of the U-Boot image. When defined, the + build system checks that the actual size does not + exceed it. + Low Level (hardware related) configuration options: ---------------------------------------------------
On Sun, 11 Aug 2013 16:40:43 +0200 Sascha Silbe t-uboot@infra-silbe.de wrote:
CONFIG_BOARD_SIZE_LIMIT was introduced by f3a14d37 [Makefile: allow boards to check file size limits] and is in use by several boards, but never got documented.
Signed-off-by: Sascha Silbe t-uboot@infra-silbe.de
README | 5 +++++ 1 file changed, 5 insertions(+)
applied to u-boot-staging/agust@denx.de. thanks!
Anatolij
The purpose of CONFIG_BOARD_SIZE_LIMIT is to make sure that U-Boot fits into the space reserved for it in some permanent storage. This includes any overhead incurred by native boot image formats, so check the final image against the size limit, too.
Signed-off-by: Sascha Silbe t-uboot@infra-silbe.de --- Makefile | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/Makefile b/Makefile index d545d30..3e05f9a 100644 --- a/Makefile +++ b/Makefile @@ -459,15 +459,18 @@ $(obj)u-boot.img: $(obj)u-boot.bin
$(obj)u-boot.imx: $(obj)u-boot.bin depend $(MAKE) -C $(SRCTREE)/arch/arm/imx-common $(OBJTREE)/u-boot.imx + $(BOARD_SIZE_CHECK)
$(obj)u-boot.kwb: $(obj)u-boot.bin $(obj)tools/mkimage -n $(CONFIG_SYS_KWD_CONFIG) -T kwbimage \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) -d $< $@ + $(BOARD_SIZE_CHECK)
$(obj)u-boot.pbl: $(obj)u-boot.bin $(obj)tools/mkimage -n $(CONFIG_PBLRCW_CONFIG) \ -R $(CONFIG_PBLPBI_CONFIG) -T pblimage \ -d $< $@ + $(BOARD_SIZE_CHECK)
$(obj)u-boot.sha1: $(obj)u-boot.bin $(obj)tools/ubsha1 $(obj)u-boot.bin
On Sun, 11 Aug 2013 16:40:44 +0200 Sascha Silbe t-uboot@infra-silbe.de wrote:
The purpose of CONFIG_BOARD_SIZE_LIMIT is to make sure that U-Boot fits into the space reserved for it in some permanent storage. This includes any overhead incurred by native boot image formats, so check the final image against the size limit, too.
Signed-off-by: Sascha Silbe t-uboot@infra-silbe.de
Makefile | 3 +++ 1 file changed, 3 insertions(+)
this patch doesn't apply any more.
Anatolij
Set CONFIG_BOARD_SIZE_LIMIT so we'll notice at build time if U-Boot has grown so large that it would overlap with the environment area in flash, rather than bricking the device at run-time on first saveenv.
Signed-off-by: Sascha Silbe t-uboot@infra-silbe.de --- include/configs/openrd.h | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/include/configs/openrd.h b/include/configs/openrd.h index 8fab6e6..b7526f8 100644 --- a/include/configs/openrd.h +++ b/include/configs/openrd.h @@ -76,6 +76,11 @@ #define CONFIG_ENV_SIZE 0x20000 /* 128k */ #define CONFIG_ENV_ADDR 0x60000 #define CONFIG_ENV_OFFSET 0x60000 /* env starts here */ +/* + * Environment is right behind U-Boot in flash. Make sure U-Boot + * doesn't grow into the environment area. + */ +#define CONFIG_BOARD_SIZE_LIMIT CONFIG_ENV_OFFSET
/* * Default environment variables
On Sun, 11 Aug 2013 16:40:45 +0200 Sascha Silbe t-uboot@infra-silbe.de wrote:
Set CONFIG_BOARD_SIZE_LIMIT so we'll notice at build time if U-Boot has grown so large that it would overlap with the environment area in flash, rather than bricking the device at run-time on first saveenv.
Signed-off-by: Sascha Silbe t-uboot@infra-silbe.de
include/configs/openrd.h | 5 +++++ 1 file changed, 5 insertions(+)
applied to u-boot-staging/agust@denx.de. thanks!
Anatolij
participants (4)
-
Albert ARIBAUD -
Anatolij Gustschin -
Sascha Silbe -
Tom Rini