[U-Boot] [PATCH] tools/envcrc: add --binary option to export embedded env
The --binary option to envcrc can be used to export the embedded env as a binary blob so that it can be manipulated/examined/whatever externally.
Signed-off-by: Mike Frysinger vapier@gentoo.org --- tools/envcrc.c | 45 +++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/tools/envcrc.c b/tools/envcrc.c index 4334cdf..ac24967 100644 --- a/tools/envcrc.c +++ b/tools/envcrc.c @@ -24,6 +24,7 @@ #include <stdio.h> #include <stdint.h> #include <stdlib.h> +#include <string.h> #include <unistd.h>
#ifndef __ASSEMBLY__ @@ -77,19 +78,55 @@ extern unsigned char environment; int main (int argc, char **argv) { #ifdef ENV_IS_EMBEDDED + unsigned char pad = 0x00; uint32_t crc; unsigned char *envptr = &environment, *dataptr = envptr + ENV_HEADER_SIZE; unsigned int datasize = ENV_SIZE; + unsigned int eoe; + + if (argv[1] && !strncmp(argv[1], "--binary=", 9)) { + int ipad; + sscanf(argv[1] + 9, "%i", &ipad); + pad = ipad; + } + + if (pad) { + /* find the end of env */ + for (eoe = 0; eoe < datasize - 1; ++eoe) + if (!dataptr[eoe] && !dataptr[eoe+1]) { + eoe += 2; + break; + } + if (eoe < datasize - 1) + memset(dataptr + eoe, pad, datasize - eoe); + }
crc = crc32 (0, dataptr, datasize);
/* Check if verbose mode is activated passing a parameter to the program */ if (argc > 1) { - printf ("CRC32 from offset %08X to %08X of environment = %08X\n", - (unsigned int) (dataptr - envptr), - (unsigned int) (dataptr - envptr) + datasize, - crc); + if (!strncmp(argv[1], "--binary", 8)) { + int le = (argc > 2 ? !strcmp(argv[2], "le") : 1); + size_t i, start, end, step; + if (le) { + start = 0; + end = ENV_HEADER_SIZE; + step = 1; + } else { + start = ENV_HEADER_SIZE - 1; + end = -1; + step = -1; + } + for (i = start; i != end; i += step) + printf("%c", (crc & (0xFF << (i * 8))) >> (i * 8)); + fwrite(dataptr, 1, datasize, stdout); + } else { + printf("CRC32 from offset %08X to %08X of environment = %08X\n", + (unsigned int) (dataptr - envptr), + (unsigned int) (dataptr - envptr) + datasize, + crc); + } } else { printf ("0x%08X\n", crc); }
Dear Mike Frysinger,
In message 1239015670-28314-1-git-send-email-vapier@gentoo.org you wrote:
The --binary option to envcrc can be used to export the embedded env as a binary blob so that it can be manipulated/examined/whatever externally.
Signed-off-by: Mike Frysinger vapier@gentoo.org
tools/envcrc.c | 45 +++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/tools/envcrc.c b/tools/envcrc.c index 4334cdf..ac24967 100644 --- a/tools/envcrc.c +++ b/tools/envcrc.c @@ -24,6 +24,7 @@ #include <stdio.h> #include <stdint.h> #include <stdlib.h> +#include <string.h> #include <unistd.h>
#ifndef __ASSEMBLY__ @@ -77,19 +78,55 @@ extern unsigned char environment; int main (int argc, char **argv) { #ifdef ENV_IS_EMBEDDED
- unsigned char pad = 0x00;
Should we not rather use 0xFF for padding - given that the envrionment is frequently stored in NOR flash?
Best regards,
Wolfgang Denk
On Monday 27 April 2009 18:15:58 Wolfgang Denk wrote:
In message Mike Frysinger wrote:
The --binary option to envcrc can be used to export the embedded env as a binary blob so that it can be manipulated/examined/whatever externally.
@@ -77,19 +78,55 @@ extern unsigned char environment; int main (int argc, char **argv) { #ifdef ENV_IS_EMBEDDED
- unsigned char pad = 0x00;
Should we not rather use 0xFF for padding - given that the envrionment is frequently stored in NOR flash?
i would love to (and with the Blackfin stuff, i do just that), but the problem is that there is no way of forcing the embedded environment to 0xff pad that i know of ...
so, to keep the most common behavior from changing (the char[] env is embedded in the .data section padded with 0x00), the padding defaults to 0x00. this way `envcrc` outputs the right value (see common/Makefile).
for people (like me) who are using --binary to extract the env blob, we can do --binary=0xff and get what you're talking about.
i could extend the behavior so that using plain "--binary" is the same thing as "--binary=0xff" ... -mike
Dear Mike Frysinger,
In message 200904271955.08919.vapier@gentoo.org you wrote:
Should we not rather use 0xFF for padding - given that the envrionment is frequently stored in NOR flash?
i would love to (and with the Blackfin stuff, i do just that), but the problem is that there is no way of forcing the embedded environment to 0xff pad that i know of ...
You mean in the code? Well, if you're using a separate section for it (like the ppcenv section) this should be straightforward using the `=FILLEXP' output section attribute for the linker.
so, to keep the most common behavior from changing (the char[] env is embedded in the .data section padded with 0x00), the padding defaults to 0x00. this way `envcrc` outputs the right value (see common/Makefile).
for people (like me) who are using --binary to extract the env blob, we can do --binary=0xff and get what you're talking about.
i could extend the behavior so that using plain "--binary" is the same thing as "--binary=0xff" ...
OK.
I guess you want to suggest that I accept this patch as is, and we address the gap filling with 0xFF in a separate patch? ;-)
Best regards,
Wolfgang Denk
On Tuesday 28 April 2009 03:13:05 Wolfgang Denk wrote:
In message Mike Frysinger wrote:
Should we not rather use 0xFF for padding - given that the envrionment is frequently stored in NOR flash?
i would love to (and with the Blackfin stuff, i do just that), but the problem is that there is no way of forcing the embedded environment to 0xff pad that i know of ...
You mean in the code? Well, if you're using a separate section for it (like the ppcenv section) this should be straightforward using the `=FILLEXP' output section attribute for the linker.
hmm, a quick grep shows that almost no one has a dedicated section. the majority of people (Blackfin boards included) insert it into the middle of their .text section. this is the use case i was thinking of when i said "no way" because i hadnt seen anyone using a dedicated section before.
so, to keep the most common behavior from changing (the char[] env is embedded in the .data section padded with 0x00), the padding defaults to 0x00. this way `envcrc` outputs the right value (see common/Makefile).
for people (like me) who are using --binary to extract the env blob, we can do --binary=0xff and get what you're talking about.
i could extend the behavior so that using plain "--binary" is the same thing as "--binary=0xff" ...
OK.
I guess you want to suggest that I accept this patch as is, and we address the gap filling with 0xFF in a separate patch? ;-)
if you want the "--binary" thing, i can post a new patch. otherwise yes, i dont see any changes to be made for now. -mike
Dear Mike Frysinger,
In message 200904280854.53669.vapier@gentoo.org you wrote:
You mean in the code? Well, if you're using a separate section for it (like the ppcenv section) this should be straightforward using the `=FILLEXP' output section attribute for the linker.
hmm, a quick grep shows that almost no one has a dedicated section. the
Everybody who uses CONFIG_SYS_USE_PPCENV or CONFIG_NAND_U_BOOT has:
-> find * -name 'u-boot*.lds' | xargs fgrep -l .ppcenv | wc -l 50
majority of people (Blackfin boards included) insert it into the middle of their .text section. this is the use case i was thinking of when i said "no way" because i hadnt seen anyone using a dedicated section before.
But that would be easy to change - see how it's done on ppc.
if you want the "--binary" thing, i can post a new patch. otherwise yes, i dont see any changes to be made for now.
OK.
Best regards,
Wolfgang Denk
On Tuesday 28 April 2009 09:45:38 Wolfgang Denk wrote:
Dear Mike Frysinger,
In message 200904280854.53669.vapier@gentoo.org you wrote:
You mean in the code? Well, if you're using a separate section for it (like the ppcenv section) this should be straightforward using the `=FILLEXP' output section attribute for the linker.
hmm, a quick grep shows that almost no one has a dedicated section. the
Everybody who uses CONFIG_SYS_USE_PPCENV or CONFIG_NAND_U_BOOT has:
-> find * -name 'u-boot*.lds' | xargs fgrep -l .ppcenv | wc -l 50
not really ... look at the linker scripts and you'll see most do: .text { ... common/env_embedded.o (.ppcenv) ...
that's why i didnt use the CONFIG_SYS_USE_PPCENV to figure out how many people had a dedicated section
majority of people (Blackfin boards included) insert it into the middle of their .text section. this is the use case i was thinking of when i said "no way" because i hadnt seen anyone using a dedicated section before.
But that would be easy to change - see how it's done on ppc.
can you name a board ? the ones i saw placed the env sector after things, they didnt split the .text section. otherwise we'd have to do like: .text.pre.env { ... custom filler ... } .ppcenv { common/env_embedded.o (.ppcenv) } .text { ... glob remaining .text } -mike
The --binary option to envcrc can be used to export the embedded env as a binary blob so that it can be manipulated/examined/whatever externally.
Signed-off-by: Mike Frysinger vapier@gentoo.org --- v2 - accept just --binary and have it default to 0xff padding
tools/envcrc.c | 46 ++++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/tools/envcrc.c b/tools/envcrc.c index 4334cdf..5b0f7cd 100644 --- a/tools/envcrc.c +++ b/tools/envcrc.c @@ -24,6 +24,7 @@ #include <stdio.h> #include <stdint.h> #include <stdlib.h> +#include <string.h> #include <unistd.h>
#ifndef __ASSEMBLY__ @@ -77,19 +78,56 @@ extern unsigned char environment; int main (int argc, char **argv) { #ifdef ENV_IS_EMBEDDED + unsigned char pad = 0x00; uint32_t crc; unsigned char *envptr = &environment, *dataptr = envptr + ENV_HEADER_SIZE; unsigned int datasize = ENV_SIZE; + unsigned int eoe; + + if (argv[1] && !strncmp(argv[1], "--binary", 8)) { + int ipad = 0xff; + if (argv[1][8] == '=') + sscanf(argv[1] + 9, "%i", &ipad); + pad = ipad; + } + + if (pad) { + /* find the end of env */ + for (eoe = 0; eoe < datasize - 1; ++eoe) + if (!dataptr[eoe] && !dataptr[eoe+1]) { + eoe += 2; + break; + } + if (eoe < datasize - 1) + memset(dataptr + eoe, pad, datasize - eoe); + }
crc = crc32 (0, dataptr, datasize);
/* Check if verbose mode is activated passing a parameter to the program */ if (argc > 1) { - printf ("CRC32 from offset %08X to %08X of environment = %08X\n", - (unsigned int) (dataptr - envptr), - (unsigned int) (dataptr - envptr) + datasize, - crc); + if (!strncmp(argv[1], "--binary", 8)) { + int le = (argc > 2 ? !strcmp(argv[2], "le") : 1); + size_t i, start, end, step; + if (le) { + start = 0; + end = ENV_HEADER_SIZE; + step = 1; + } else { + start = ENV_HEADER_SIZE - 1; + end = -1; + step = -1; + } + for (i = start; i != end; i += step) + printf("%c", (crc & (0xFF << (i * 8))) >> (i * 8)); + fwrite(dataptr, 1, datasize, stdout); + } else { + printf("CRC32 from offset %08X to %08X of environment = %08X\n", + (unsigned int) (dataptr - envptr), + (unsigned int) (dataptr - envptr) + datasize, + crc); + } } else { printf ("0x%08X\n", crc); }
Dear Mike Frysinger,
In message 1241613705-8622-1-git-send-email-vapier@gentoo.org you wrote:
The --binary option to envcrc can be used to export the embedded env as a binary blob so that it can be manipulated/examined/whatever externally.
Signed-off-by: Mike Frysinger vapier@gentoo.org
v2
- accept just --binary and have it default to 0xff padding
tools/envcrc.c | 46 ++++++++++++++++++++++++++++++++++++++++++---- 1 files changed, 42 insertions(+), 4 deletions(-)
Applied to "next" branch. Thanks.
Best regards,
Wolfgang Denk
participants (2)
-
Mike Frysinger -
Wolfgang Denk