Re: [U-Boot] Mainline u-boot SPL for socfpga
On Thursday 15 May 2014 04:42:58 Pavel Machek wrote: Hi! I am trying to understand the state of the socfpga preloader in mainline u-boot. From what I see, this is broken and perhaps has never worked. That's correct AFAICT. When I build the code in u-boot-socfpga I get a healthy working u-boot-spl.bin of approx 45kbytes. When I build the mainline u-boot code I get a broken u-boot-spl.bin of approx 3kbytes. It seems the mainline u-boot is missing stuff, including the all-critical sdram initialisation without which the SPL is useless. Are you able to build working u-boot proper from recent sources? I know u-boot SPL misses critical parts, but I was told that u-boot proper should have everything. Only... I was not able to get it to work. [I'm attempting to load recent u-boot from patched/old u-boot; I know this is not exactly recommended, but due to spl/proper split, it should work AFAIK... and does for old versions.] I have not tried booting u-boot proper from mainline. It just seemed pointless to me to be working from 2 source trees to make a single product. I will give it a go though. As Chin Liang See has said, there are two issues thwarting this: legal AND source conformance. The code we can fix, the legal can only be fixed by bending Altera - I am going to do that too. Regards Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] mkimage: Refactor mxsimage to use common crc32 code
On Tuesday 13 May 2014 08:26:44 Tom Rini wrote: On Tue, May 06, 2014 at 10:46:46AM +1200, Charles Manning wrote: mxsimage uses the same crc32 function as pblimage. Signed-off-by: Charles Manning cdhmann...@gmail.com Acked-by: Stefano Babic sba...@denx.de This introduces warnings: tools/mxsimage.c: In function ‘sb_build_command_load’: tools/mxsimage.c:979:2: warning: pointer targets in passing argument 2 of ‘pbl_crc32’ differ in signedness [-Wpointer-sign] tools/pbl_crc32.h:11:10: note: expected ‘const char *’ but argument is of type ‘uint8_t *’ u-boot/tools/mxsimage.c: In function ‘sb_verify_command’: tools/mxsimage.c:1815:3: warning: pointer targets in passing argument 2 of ‘pbl_crc32’ differ in signedness [-Wpointer-sign] tools/pbl_crc32.h:11:10: note: expected ‘const char *’ but argument is of type ‘uint8_t *’ Thanks for the feedback. Will it be acceptable to do the following: *Change the called function from uint8_t * to const uint8_t *Cast the const char * pointer to const uint8_t *. Thanks Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] mkimage: Refactor and clean up 32-bit crcs
As a step towards adding an image signer for socfpga, this set of patches breaks out the common crc code that is used in both pblimage and mxsimage. Not that this is NOT the same algorithm as the crc generated by zlib. The new function has been named pbl_crc32. This patch set just changes patch 1/2: casting pointers in mxsimage.c Charles Manning (2): mkimage : Split out and clean pbl_crc32 for use by other image types tools: Refactor mxsimage to use pbl_crc32 tools/Makefile|1 + tools/mxsimage.c | 32 +++--- tools/pbl_crc32.c | 56 + tools/pbl_crc32.h | 13 + tools/pblimage.c | 47 +--- 5 files changed, 78 insertions(+), 71 deletions(-) create mode 100644 tools/pbl_crc32.c create mode 100644 tools/pbl_crc32.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] tools: Refactor mxsimage to use pbl_crc32
Both pblimage and mxsimage use the same crc algorithm, so refactor.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
Changes for V2:
- Cast buffer pointers when calling pbl_crc32().
tools/mxsimage.c | 32 +++-
1 file changed, 7 insertions(+), 25 deletions(-)
diff --git a/tools/mxsimage.c b/tools/mxsimage.c
index 045b35a..81c7f2d 100644
--- a/tools/mxsimage.c
+++ b/tools/mxsimage.c
@@ -19,6 +19,7 @@
#include imagetool.h
#include mxsimage.h
+#include pbl_crc32.h
#include image.h
@@ -231,29 +232,6 @@ static int sb_aes_reinit(struct sb_image_ctx *ictx, int
enc)
}
/*
- * CRC32
- */
-static uint32_t crc32(uint8_t *data, uint32_t len)
-{
- const uint32_t poly = 0x04c11db7;
- uint32_t crc32 = 0x;
- unsigned int byte, bit;
-
- for (byte = 0; byte len; byte++) {
- crc32 ^= data[byte] 24;
-
- for (bit = 8; bit 0; bit--) {
- if (crc32 (1UL 31))
- crc32 = (crc32 1) ^ poly;
- else
- crc32 = (crc32 1);
- }
- }
-
- return crc32;
-}
-
-/*
* Debug
*/
static void soprintf(struct sb_image_ctx *ictx, const char *fmt, ...)
@@ -998,7 +976,9 @@ static int sb_build_command_load(struct sb_image_ctx *ictx,
ccmd-load.address = dest;
ccmd-load.count= cctx-length;
- ccmd-load.crc32= crc32(cctx-data, cctx-length);
+ ccmd-load.crc32= pbl_crc32(0,
+ (const char *)cctx-data,
+ cctx-length);
cctx-size = sizeof(*ccmd) + cctx-length;
@@ -1834,7 +1814,9 @@ static int sb_verify_command(struct sb_image_ctx *ictx,
EVP_DigestUpdate(ictx-md_ctx, cctx-data, asize);
sb_aes_crypt(ictx, cctx-data, cctx-data, asize);
- if (ccmd-load.crc32 != crc32(cctx-data, asize)) {
+ if (ccmd-load.crc32 != pbl_crc32(0,
+ (const char *)cctx-data,
+ asize)) {
fprintf(stderr,
ERR: SB LOAD command payload CRC32
invalid!\n);
return -EINVAL;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] mkimage : Split out and clean pbl_crc32 for use by other image types
The crc32 used by pblimgae is NOT the same as zlib crc32.
The pbl_crc32 is useful for other purposes in mkimage so split it out.
While we are about it, clean up redundant and confusing code.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
Unchanged from V1.
tools/Makefile|1 +
tools/pbl_crc32.c | 56 +
tools/pbl_crc32.h | 13 +
tools/pblimage.c | 47 +---
4 files changed, 71 insertions(+), 46 deletions(-)
create mode 100644 tools/pbl_crc32.c
create mode 100644 tools/pbl_crc32.h
diff --git a/tools/Makefile b/tools/Makefile
index c34df4f..2f30749 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -86,6 +86,7 @@ dumpimage-mkimage-objs := aisimage.o \
omapimage.o \
os_support.o \
pblimage.o \
+ pbl_crc32.o \
sha1.o \
sha256.o \
ublimage.o \
diff --git a/tools/pbl_crc32.c b/tools/pbl_crc32.c
new file mode 100644
index 000..6e6735a
--- /dev/null
+++ b/tools/pbl_crc32.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Cleaned up and refactored by Charles Manning.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include pblimage.h
+
+static uint32_t crc_table[256];
+static int crc_table_valid;
+
+static void make_crc_table(void)
+{
+ uint32_t mask;
+ int i, j;
+ uint32_t poly; /* polynomial exclusive-or pattern */
+
+ if (crc_table_valid)
+ return;
+
+ /*
+* the polynomial used by PBL is 1 + x1 + x2 + x4 + x5 + x7 + x8 + x10
+* + x11 + x12 + x16 + x22 + x23 + x26 + x32.
+*/
+ poly = 0x04c11db7;
+
+ for (i = 0; i 256; i++) {
+ mask = i 24;
+ for (j = 0; j 8; j++) {
+ if (mask 0x8000)
+ mask = (mask 1) ^ poly;
+ else
+ mask = 1;
+ }
+ crc_table[i] = mask;
+ }
+
+ crc_table_valid = 1;
+}
+
+uint32_t pbl_crc32(uint32_t in_crc, const char *buf, uint32_t len)
+{
+ uint32_t crc32_val;
+ int i;
+
+ make_crc_table();
+
+ crc32_val = ~in_crc;
+
+ for (i = 0; i len; i++)
+ crc32_val = (crc32_val 8) ^
+ crc_table[(crc32_val 24) ^ (*buf++ 0xff)];
+
+ return crc32_val;
+}
diff --git a/tools/pbl_crc32.h b/tools/pbl_crc32.h
new file mode 100644
index 000..4ab55ee
--- /dev/null
+++ b/tools/pbl_crc32.h
@@ -0,0 +1,13 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef PBLCRC32_H
+#define PBLCRC32_H
+
+#include stdint.h
+uint32_t pbl_crc32(uint32_t in_crc, const char *buf, uint32_t len);
+
+#endif
diff --git a/tools/pblimage.c b/tools/pblimage.c
index ef3d7f6..6e6e801 100644
--- a/tools/pblimage.c
+++ b/tools/pblimage.c
@@ -6,6 +6,7 @@
#include imagetool.h
#include image.h
#include pblimage.h
+#include pbl_crc32.h
/*
* Initialize to an invalid value.
@@ -137,52 +138,6 @@ static void pbl_parser(char *name)
fclose(fd);
}
-static uint32_t crc_table[256];
-
-static void make_crc_table(void)
-{
- uint32_t mask;
- int i, j;
- uint32_t poly; /* polynomial exclusive-or pattern */
-
- /*
-* the polynomial used by PBL is 1 + x1 + x2 + x4 + x5 + x7 + x8 + x10
-* + x11 + x12 + x16 + x22 + x23 + x26 + x32.
-*/
- poly = 0x04c11db7;
-
- for (i = 0; i 256; i++) {
- mask = i 24;
- for (j = 0; j 8; j++) {
- if (mask 0x8000)
- mask = (mask 1) ^ poly;
- else
- mask = 1;
- }
- crc_table[i] = mask;
- }
-}
-
-unsigned long pbl_crc32(unsigned long crc, const char *buf, uint32_t len)
-{
- uint32_t crc32_val = 0x;
- uint32_t xor = 0x0;
- int i;
-
- make_crc_table();
-
- for (i = 0; i len; i++)
- crc32_val = (crc32_val 8) ^
- crc_table[(crc32_val 24) ^ (*buf++ 0xff)];
-
- crc32_val = crc32_val ^ xor;
- if (crc32_val 0) {
- crc32_val += 0x;
- crc32_val += 1;
- }
- return crc32_val;
-}
-
static uint32_t reverse_byte(uint32_t val)
{
uint32_t temp;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mainline u-boot SPL for socfpga
On Thu, May 8, 2014 at 10:24 PM, Chin Liang See cl...@altera.com wrote: Hi Charles, On Tue, 2014-05-06 at 12:22 +1200, Charles Manning wrote: Hello I am trying to understand the state of the socfpga preloader in mainline u-boot. From what I see, this is broken and perhaps has never worked. When I build the code in u-boot-socfpga I get a healthy working u-boot-spl.bin of approx 45kbytes. When I build the mainline u-boot code I get a broken u-boot-spl.bin of approx 3kbytes. It seems the mainline u-boot is missing stuff, including the all-critical sdram initialisation without which the SPL is useless. As of now, we have most of the drivers already upstreamed to main line. The missing piece here are the SDRAM driver. The SDRAM driver poses a big challenge as its now licensed under BSD-3 clause. I am still working with legal team to look into potential to make it GPL license. So, I have a few related questions: 1. The SDRAM init code, like other SocFPGA hand-off files is generated by the Altera tools. Since it is not hand written, and is not compliant with u-boot coding style. Is it more important to preserve coding style and have a broken SPL than it is to have a working SPL and broken code? The SDRAM handoff files generated by tools is not compliance as the original code developer doesn't familiar with open source world. But if you look into the SDRAM handoff files within rocketboard.org git, the existing code already updated. I enhanced the code to ensure it meet with basic coding standard. But further enhancement is needed and on-going now. What is really needed is that the hand-off files are actually generated as compliant code. Enhancing and hand-editing then checking in machine generated code is a broken work-flow because: 1) It has to be redone every time the code is regenerated. 2) There are so many changes that it is impossible to check for errors and diff for changes. 2. Is there a practical half-way compromise whereby the generated code is run through lindent and we just accept that this is as good as it gets? The on-going plan now is to use the enhanced SDRAM handoff file at rocketboard.org. From there, we want to streamline the driver by removing unused code. Once its ready, we will upstream this file. That might work if it is a once-off exercise that places the sdram code in arch/arm/cpu/armv7/socfpga The only stuff that should really be in a board/xxx directory is board-specific stuff and tuning files. In other words: * sequence.c (a file of over 11000 lines of C code) should be in arch/.../scofpga * sequencer_auto_ac_init.c (300 lines of board-specific register config values) should be in board/.../socfpga 3. Can we get some sort of coding style waiver, considering that this code is off in a board file and does not impact on anyone working on anything other than socfpga (indeed nobody even working on socfpga even reads it). Clearly significant hand editing generated code makes for a very broken workflow, but running it through an automated step like lindent is Ok from a workflow point of view. Unless this can be resolved we end up with a situation where people working on SocFPGA are forced to fork for practical reasons. I believe it would be tough to get the waiver. Nevertheless, we are further enhancing the handoff files to a state which is good for upstreaming. At same time, I am also working with tools team to ensure all these enhancement is putting back to original code. Maybe splitting the code better as I suggest above would make this far simpler. If the board specific part of the hand-offs is reduced to just header files and register config tables, then it is a trivial matter to run them through an extra **automated** step to produce a compliant file. Apart from gaining the mainstreaming, this would also make it far easier to create configs for different boards (eg. sockit board would just become a few hundred lines of register configs and not 13 thousand lines of code - most of that duplicated between platforms). Regards Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] mkimage: Refactor and clean up 32-bit crcs
As a step towards adding an image signer for socfpga, this set of patches breaks out the common crc code that is used in both pblimage and mxsimage. Not that this is NOT the same algorithm as the crc generated by zlib. The new function has been named pbl_crc32. Charles Manning (2): mkimage : Split out and clean pbl_crc32 for use by other image types mkimage: Refactor mxsimage to use common crc32 code tools/Makefile|1 + tools/mxsimage.c | 28 +++ tools/pbl_crc32.c | 56 + tools/pbl_crc32.h | 13 + tools/pblimage.c | 47 +--- 5 files changed, 74 insertions(+), 71 deletions(-) create mode 100644 tools/pbl_crc32.c create mode 100644 tools/pbl_crc32.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mkimage: Refactor mxsimage to use common crc32 code
mxsimage uses the same crc32 function as pblimage.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
tools/mxsimage.c | 28 +++-
1 file changed, 3 insertions(+), 25 deletions(-)
diff --git a/tools/mxsimage.c b/tools/mxsimage.c
index 045b35a..0c4348c 100644
--- a/tools/mxsimage.c
+++ b/tools/mxsimage.c
@@ -19,6 +19,7 @@
#include imagetool.h
#include mxsimage.h
+#include pbl_crc32.h
#include image.h
@@ -231,29 +232,6 @@ static int sb_aes_reinit(struct sb_image_ctx *ictx, int
enc)
}
/*
- * CRC32
- */
-static uint32_t crc32(uint8_t *data, uint32_t len)
-{
- const uint32_t poly = 0x04c11db7;
- uint32_t crc32 = 0x;
- unsigned int byte, bit;
-
- for (byte = 0; byte len; byte++) {
- crc32 ^= data[byte] 24;
-
- for (bit = 8; bit 0; bit--) {
- if (crc32 (1UL 31))
- crc32 = (crc32 1) ^ poly;
- else
- crc32 = (crc32 1);
- }
- }
-
- return crc32;
-}
-
-/*
* Debug
*/
static void soprintf(struct sb_image_ctx *ictx, const char *fmt, ...)
@@ -998,7 +976,7 @@ static int sb_build_command_load(struct sb_image_ctx *ictx,
ccmd-load.address = dest;
ccmd-load.count= cctx-length;
- ccmd-load.crc32= crc32(cctx-data, cctx-length);
+ ccmd-load.crc32= pbl_crc32(0, cctx-data, cctx-length);
cctx-size = sizeof(*ccmd) + cctx-length;
@@ -1834,7 +1812,7 @@ static int sb_verify_command(struct sb_image_ctx *ictx,
EVP_DigestUpdate(ictx-md_ctx, cctx-data, asize);
sb_aes_crypt(ictx, cctx-data, cctx-data, asize);
- if (ccmd-load.crc32 != crc32(cctx-data, asize)) {
+ if (ccmd-load.crc32 != pbl_crc32(0, cctx-data, asize)) {
fprintf(stderr,
ERR: SB LOAD command payload CRC32
invalid!\n);
return -EINVAL;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mkimage : Split out and clean pbl_crc32 for use by other image types
The crc32 used by pblimgae is NOT the same as zlib crc32.
The pbl_crc32 is useful for other purposes in mkimage so split it out.
While we are about it, clean up redundant and confusing code.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
tools/Makefile|1 +
tools/pbl_crc32.c | 56 +
tools/pbl_crc32.h | 13 +
tools/pblimage.c | 47 +---
4 files changed, 71 insertions(+), 46 deletions(-)
create mode 100644 tools/pbl_crc32.c
create mode 100644 tools/pbl_crc32.h
diff --git a/tools/Makefile b/tools/Makefile
index c34df4f..2f30749 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -86,6 +86,7 @@ dumpimage-mkimage-objs := aisimage.o \
omapimage.o \
os_support.o \
pblimage.o \
+ pbl_crc32.o \
sha1.o \
sha256.o \
ublimage.o \
diff --git a/tools/pbl_crc32.c b/tools/pbl_crc32.c
new file mode 100644
index 000..6e6735a
--- /dev/null
+++ b/tools/pbl_crc32.c
@@ -0,0 +1,56 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * Cleaned up and refactored by Charles Manning.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include pblimage.h
+
+static uint32_t crc_table[256];
+static int crc_table_valid;
+
+static void make_crc_table(void)
+{
+ uint32_t mask;
+ int i, j;
+ uint32_t poly; /* polynomial exclusive-or pattern */
+
+ if (crc_table_valid)
+ return;
+
+ /*
+* the polynomial used by PBL is 1 + x1 + x2 + x4 + x5 + x7 + x8 + x10
+* + x11 + x12 + x16 + x22 + x23 + x26 + x32.
+*/
+ poly = 0x04c11db7;
+
+ for (i = 0; i 256; i++) {
+ mask = i 24;
+ for (j = 0; j 8; j++) {
+ if (mask 0x8000)
+ mask = (mask 1) ^ poly;
+ else
+ mask = 1;
+ }
+ crc_table[i] = mask;
+ }
+
+ crc_table_valid = 1;
+}
+
+uint32_t pbl_crc32(uint32_t in_crc, const char *buf, uint32_t len)
+{
+ uint32_t crc32_val;
+ int i;
+
+ make_crc_table();
+
+ crc32_val = ~in_crc;
+
+ for (i = 0; i len; i++)
+ crc32_val = (crc32_val 8) ^
+ crc_table[(crc32_val 24) ^ (*buf++ 0xff)];
+
+ return crc32_val;
+}
diff --git a/tools/pbl_crc32.h b/tools/pbl_crc32.h
new file mode 100644
index 000..4ab55ee
--- /dev/null
+++ b/tools/pbl_crc32.h
@@ -0,0 +1,13 @@
+/*
+ * Copyright 2012 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef PBLCRC32_H
+#define PBLCRC32_H
+
+#include stdint.h
+uint32_t pbl_crc32(uint32_t in_crc, const char *buf, uint32_t len);
+
+#endif
diff --git a/tools/pblimage.c b/tools/pblimage.c
index ef3d7f6..6e6e801 100644
--- a/tools/pblimage.c
+++ b/tools/pblimage.c
@@ -6,6 +6,7 @@
#include imagetool.h
#include image.h
#include pblimage.h
+#include pbl_crc32.h
/*
* Initialize to an invalid value.
@@ -137,52 +138,6 @@ static void pbl_parser(char *name)
fclose(fd);
}
-static uint32_t crc_table[256];
-
-static void make_crc_table(void)
-{
- uint32_t mask;
- int i, j;
- uint32_t poly; /* polynomial exclusive-or pattern */
-
- /*
-* the polynomial used by PBL is 1 + x1 + x2 + x4 + x5 + x7 + x8 + x10
-* + x11 + x12 + x16 + x22 + x23 + x26 + x32.
-*/
- poly = 0x04c11db7;
-
- for (i = 0; i 256; i++) {
- mask = i 24;
- for (j = 0; j 8; j++) {
- if (mask 0x8000)
- mask = (mask 1) ^ poly;
- else
- mask = 1;
- }
- crc_table[i] = mask;
- }
-}
-
-unsigned long pbl_crc32(unsigned long crc, const char *buf, uint32_t len)
-{
- uint32_t crc32_val = 0x;
- uint32_t xor = 0x0;
- int i;
-
- make_crc_table();
-
- for (i = 0; i len; i++)
- crc32_val = (crc32_val 8) ^
- crc_table[(crc32_val 24) ^ (*buf++ 0xff)];
-
- crc32_val = crc32_val ^ xor;
- if (crc32_val 0) {
- crc32_val += 0x;
- crc32_val += 1;
- }
- return crc32_val;
-}
-
static uint32_t reverse_byte(uint32_t val)
{
uint32_t temp;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Mainline u-boot SPL for socfpga
Hello I am trying to understand the state of the socfpga preloader in mainline u-boot. From what I see, this is broken and perhaps has never worked. When I build the code in u-boot-socfpga I get a healthy working u-boot-spl.bin of approx 45kbytes. When I build the mainline u-boot code I get a broken u-boot-spl.bin of approx 3kbytes. It seems the mainline u-boot is missing stuff, including the all-critical sdram initialisation without which the SPL is useless. So, I have a few related questions: 1. The SDRAM init code, like other SocFPGA hand-off files is generated by the Altera tools. Since it is not hand written, and is not compliant with u-boot coding style. Is it more important to preserve coding style and have a broken SPL than it is to have a working SPL and broken code? 2. Is there a practical half-way compromise whereby the generated code is run through lindent and we just accept that this is as good as it gets? 3. Can we get some sort of coding style waiver, considering that this code is off in a board file and does not impact on anyone working on anything other than socfpga (indeed nobody even working on socfpga even reads it). Clearly significant hand editing generated code makes for a very broken workflow, but running it through an automated step like lindent is Ok from a workflow point of view. Unless this can be resolved we end up with a situation where people working on SocFPGA are forced to fork for practical reasons. Regards Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Socfpga preloader signing patch
On Saturday 05 April 2014 09:47:02 Pavel Machek wrote:
Hi!
I'm trying to get custom preloader to work (on EBV Socrates)... I
tried applying old patch from mail archives, but a) applying patch
from mail archives is not fun and b) it did not seem to do the trick.
Just to make sure... right way to use the
socfpga-signed-preloader.bin is
dd if=socfpga-signed-preloader.bin of=/dev/mmcblk0p1 bs=64k seek=0
dd if=u-boot.img of=/dev/mmcblk0p1 bs=64K seek=4
Almost right.
It must be partition 3, which must be of type A2.
dd .of=/dev/mmcblk0p3 ...
I use the following script to set up an sd card with some useful partitions:
#!/bin/bash
# Script to partition an SDCard for the SoCFPGA
# /dev/sdx3 MUST be type A2. It is used for the bootloaders.
#
# We also make /dev/sdx1 - FAT, then the rest is ext2
#
#set -e -x
DEVICE=$1
THIS_DIR=$( cd $( dirname $0 ) pwd )
BASE_DIR=${THIS_DIR}/..
errmsg() {
echo Error: $@ 21
}
errdie() {
errmsg $@
exit 1
}
log() {
echo ''
echo $@
echo ''
}
usage() {
echo Usage: $1 sd/mmc device file
}
if [ $# -ne 1 ]; then
errmsg incorrect usage
usage $0
exit 1
fi
DEVICE=$1
# precondition checks
if [ ! -b ${DEVICE} ]; then
errdie ${DEVICE} is not an accessable block device
fi
# confirm
read -p The ${DEVICE} device will be formatted. Continue? [y/n] answer
if [ $answer != y ]; then
exit 0;
fi
# umount if device partitions are mounted
for partition in `mount | grep ${DEVICE} | cut -d ' ' -f 1`; do
echo Umounting ${partition} ...
umount $partition
if [ $? -ne 0 ]; then
errdie failed to umount ${partition}
fi
done
# go
log 'Repartitioning...'
#
# Set up 3 partitions, then set their type.
# /dev/sdx3 is the bootloader partition and must be type A2
# We add a small FAT partition, as /dev/sdx1 then the rest is
# an ext2 partition.
#
fdisk $DEVICE EOF
o
n
p
3
2048
+8M
n
p
1
+20M
n
p
2
t
1
4
t
2
83
t
3
a2
p
w
EOF
if [ $? -ne 0 ]; then
errdie repartitioning failed
fi
log 'Formatting...'
echo Formatting FAT aprtition...
mkfs.vfat ${DEVICE}1
if [ $? -ne 0 ]; then
errdie formatting failed
fi
echo Formatting Linux partition ...
mkfs.ext2 ${DEVICE}2
if [ $? -ne 0 ]; then
errdie formatting failed
fi
log 'Done'
exit 0
#end of script
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] socfpga: Add socfpga preloader signing to mkimage
On Tuesday 11 March 2014 22:13:26 you wrote: Hello Charles, Gerhard, Is there any (real, technical) reason why the bzip stuff (the CRC-32 calculation that has been made available separately) cannot get built and used as a library, and the tools/ application just gets linked against it as one would expect? From my limited understanding, lib/ is not built for the host. It is only built for the target. That is why we have all these ugly C files: crc32.c, sha1.c,... in tools/. With Kbuild, is the '#include ../otherdir/source.c trick still needed? Would a list of object files with relative path specs work, or can object files in one output directory result from compile units taken out of several source directories? In this case, object files with relative path such as ../lib/foo.o does not work. If we write ../lib/foo.o in tools/Makefile, $(HOSTCC) will compile foo.o into lib/ directory. And lator it will be overwritten with the one compiled with $(CC). I thought this is a simple way to generate two objects from one source file, one is for hostprogs in tools/ and the other for the target in lib/. In the long run, I guess splitting the objects something like how SPL is handled in parallel to main u-boot is the right thing, but I absolutely agree with you that this should be a separate exercise. Mixing adding new features and refactoring in one patch is best avoided. It is a similar issue that makes most of the target side code unavailable for the host tools. For example, anything requiring asm/* will clearly NOT work since the host side processor environment need not be, and indeed seldom is, the same as target. Perhaps a split compile could fix that, but it is beyond the scope of this exercise. BTW, I sometimes see #include for *.c for example, drivers/usb/host/ehci-hcd.c of Linux Kernel, although I admit it is ugly. I agree we need to do something with it, but it's beyond the scope of this patch. diff --git a/spl/Makefile b/spl/Makefile index 346d0aa..4e0f33f 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -182,6 +182,11 @@ MLO MLO.byteswap: $(obj)/u-boot-spl.bin ALL-y += $(obj)/$(SPL_BIN).bin +$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin + $(OBJTREE)/tools/mkimage -T socfpgaimage -d $ $@ + +ALL-$(CONFIG_SOCFPGA) += $(OBJTREE)/socfpga-signed-preloader.bin + ifdef CONFIG_SAMSUNG ALL-y += $(obj)/$(BOARD)-spl.bin endif Could you re-write this part as follows, please? diff --git a/spl/Makefile b/spl/Makefile index bb3d349..9f3893e 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -184,6 +184,12 @@ MLO MLO.byteswap: $(obj)/u-boot-spl.bin ALL-y += $(obj)/$(SPL_BIN).bin +MKIMAGEFLAGS_socfpga-signed-preloader.bin := -T socfpgaimage +socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin + $(call cmd,mkimage) + +ALL-$(CONFIG_SOCFPGA) += socfpga-signed-preloader.bin + ifdef CONFIG_SAMSUNG ALL-y += $(obj)/$(BOARD)-spl.bin endif Thank you. I shall try that. Thank you for that valuable feedback. Regards. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v7] socfpga: Add socfpga preloader signing to mkimage
Dear Gerhard
Thank you for your further comments and clarifications, may I press you for a
few more?
On Tuesday 11 March 2014 08:36:24 Gerhard Sittig wrote:
[ Cc: to Masahiro for the tools/ vs lib/ build support part ]
On Mon, Mar 10, 2014 at 16:04 +1300, Charles Manning wrote:
On Sunday 09 March 2014 05:51:23 Gerhard Sittig wrote:
On Thu, Mar 06, 2014 at 15:40 +1300, Charles Manning wrote:
--- /dev/null
+++ b/lib/bzlib_crc32.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * This provides a CRC-32 using the tables in bzlib_crctable.c
+ */
+
+#include bzlib_crc32.h
+#include bzlib_private.h
+
+uint32_t bzlib_crc32(uint32_t crc, const void *_buf, int length)
+{
+ const uint8_t *buf = _buf;
+
+ crc ^= ~0;
+
+ while (length--) {
+ crc = (crc 8) ^ BZ2_crc32Table[((crc 24) ^ *buf)
0xff];
+ buf++;
+ }
+
+ crc ^= ~0;
+
+ return crc;
+}
Since you already include the private bzlib header for the
BZ2_crc32Table[] declaration, you might as well use the
BZ_INITIALISE_CRC(), BZ_FINALISE_CRC(), and BZ_UPDATE_CRC()
macros declared from there (right next to the table's
declaration), instead of re-inventing how the CRC gets
calculated.
If you think that makes it more clear I shall do that. I don't think
though that it really is any clearer.
Admittedly your wrapper is thin. Yet it duplicates what the
bzlib header already provides. And does so in different phrases
(i.e. textually does not match the original, so probably gets
missed upon searches).
It's more a matter of consistency to re-use the code as well as
the table of the bzip2 implementation, instead of re-inventing
both or using parts of it only.
It does not bug me to use either way. I shall use that.
You probably should determine whether you want to provide one
routine to do the complete calculate over a given byte stream,
without any previous CRC value -- this is what your current use
case is. Or whether you want to provide three primitives to
initialize, update, and finalize a CRC (which is not used yet).
Or whether you want to provide the three primitives plus one
convenience wrapper.
I try to use a single familiar function, like crc32() does.
You can start with 0, then use it with the results.
eg
crc = crc32(0, first_buff,...);
crc = crc32(crc, second_bufer,...);
This only works by coincidence because the final XOR and the
initial value happen to be complimentary and only by chance the
value of zero works. So it's not a general pattern, but a
specific feature of this very implementation.
Given that your current application only determines CRC values
for complete buffers and nothing is done piecemeal, I'd suggest
to provide the one convenience wrapper routine which does not
take a previous partial result.
Should other use cases later require incremental calculation,
they can introduce and use the three primitives to open, iterate
and close the calculation. This better reflects what's
happening. Or am I being overly picky?
Perhaps picky, but I do not mind losing this.
The issue is that these functions are often used on long sequences one buffer
at a time (eg. doing a crc on 100k, but getting the data in 1k blocks).
This implementation does not need the multi-buffer support, but when I
refactor the crcs in mkimage (as I have undertaken to do - even though it is
of no direct utility to me at all), there might be a need to use
multi-buffer.
For now I will just provide a single buffer version, and will widen it up if
need be later.
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -70,6 +70,8 @@ RSA_OBJS-$(CONFIG_FIT_SIGNATURE) := rsa-sign.o
# common objs for dumpimage and mkimage
dumpimage-mkimage-objs := aisimage.o \
$(FIT_SIG_OBJS-y) \
+ bzlib_crc32.o \
+ bzlib_crctable.o \
crc32.o \
default_image.o \
fit_image.o \
@@ -85,6 +87,7 @@ dumpimage-mkimage-objs := aisimage.o \
os_support.o \
pblimage.o \
sha1.o \
+ socfpgaimage.o \
ublimage.o \
$(LIBFDT_OBJS) \
$(RSA_OBJS-y)
diff --git a/tools/bzlib_crc32.c b/tools/bzlib_crc32.c
new file mode 100644
index 000..b7f7aa5
--- /dev/null
+++ b/tools/bzlib_crc32.c
@@ -0,0 +1 @@
+#include ../lib/bzlib_crc32.c
diff --git a/tools/bzlib_crctable.c b/tools/bzlib_crctable.c
new file mode 100644
index 000..53d38ef
--- /dev
Re: [U-Boot] [PATCH v7] socfpga: Add socfpga preloader signing to mkimage
Hello Gerhard
Thank you for that feedback.
On Sunday 09 March 2014 05:51:23 Gerhard Sittig wrote:
On Thu, Mar 06, 2014 at 15:40 +1300, Charles Manning wrote:
[ ... ]
Unfortunately the CRC used in this boot ROM is not the same as the
Adler CRC in lib/crc32.c. Indeed the Adler code is not technically a
CRC but is more correctly described as a checksum.
I don't quite get why you say that the zlib implementation is not
a CRC. IIUC all of the CRC-32 methods follow a common algorithm,
and just happen to differ in their polynomials or initial and
final masks. So they result in different CRC values for the same
data stream, yet all of them are CRCs.
But strictly speaking this remark is not specific to this patch
submission, and might be omitted. The only relevant thing is
that the zlib CRC-32 approach does not result in the value that
the SoC's ROM loader expects.
Ok I will change that comment
Thus, the appropriate CRC generator is added to lib/ as crc32_alt.c.
What does alt stand for, and can you provide an appropriate
description with the commit log (or just use a better name)? As
previous communication suggests, it's certainly not alternative
-- as there just are too many alternatives available to mark one
of them as _the_ alternative. It's neither apple where you
appear to have found the matching polynomial first. If it's
Altera, I'd suggest to use either altr as this is what
elsewhere is used for Altera (the stock ticker), or plain
altera instead of something this short and ambiguous. Or
bzlib since this is the most recent implementation that you are
using.
I agree thank you for pointing out that error in my comment.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
Changes for v3:
- Fix some coding style issues.
- Move from a standalone tool to the mkimgae framework.
Changes for v4:
- Fix more coding style issues.
- Fix typos in Makefile.
- Rebase on master (previous version was not on master, but on a
working socfpga branch).
Changes for v5:
- Fix more coding style issues.
- Add some more comments.
- Remove some unused defines.
- Move the local CRC32 code into lib/crc32_alt.c.
Changes for v6:
- Fix more coding style issues.
- Rejig socfpgaimage_vrec_header() function so that it has one return
path and does stricter size checks.
Changes for v7:
- Use bzlib's crc table instead of adding another one.
- Use existing code and a packed structure for header marshalling.
One of the reasons I got tired of providing feedback is that this
change log is rather terse. Several identical fix coding style
phrases are another way of telling readers that they should
figure out for themselves what might have changed (especially
when newer versions have functional changes that are not
announced as such), and whether feedback was considered or got
ignored. Seeing several iterations which suffer from the same
issues that have been identified multiple versions before isn't
helpful either when asking yourself whether to spend more time
and getting ignored another time.
Ok, I will try to be less terse.
--- /dev/null
+++ b/include/bzlib_crc32.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Note that the CRC is **not** the zlib/Adler crc32 in crc32.c.
+ * It is the CRC-32 used in bzip2, ethernet and elsewhere.
+ */
+
+#ifndef __BZLIB_CRC32_H__
+#define __BZLIB_CRC32_H__
+
+#include stdint.h
+
+uint32_t bzlib_crc32(uint32_t crc, const void *_buf, int length);
+
+#endif
and
--- /dev/null
+++ b/lib/bzlib_crc32.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * This provides a CRC-32 using the tables in bzlib_crctable.c
+ */
+
+#include bzlib_crc32.h
+#include bzlib_private.h
+
+uint32_t bzlib_crc32(uint32_t crc, const void *_buf, int length)
+{
+ const uint8_t *buf = _buf;
+
+ crc ^= ~0;
+
+ while (length--) {
+ crc = (crc 8) ^ BZ2_crc32Table[((crc 24) ^ *buf) 0xff];
+ buf++;
+ }
+
+ crc ^= ~0;
+
+ return crc;
+}
Since you already include the private bzlib header for the
BZ2_crc32Table[] declaration, you might as well use the
BZ_INITIALISE_CRC(), BZ_FINALISE_CRC(), and BZ_UPDATE_CRC()
macros declared from there (right next to the table's
declaration), instead of re-inventing how the CRC gets
calculated.
If you think that makes it more clear I shall do that. I don't think though
that it really is any clearer.
You probably should determine whether you want to provide one
routine to do the complete calculate over a given byte stream,
without any previous CRC value -- this is what your current use
case is. Or whether you want to provide three primitives to
initialize
[U-Boot] [PATCH v7] socfpga: Add socfpga preloader signing to mkimage
Like many platforms, the Altera socfpga platform requires that the
preloader be signed in a certain way or the built-in boot ROM will
not boot the code.
This change automatically creates an appropriately signed preloader
from an SPL image.
The signed image includes a CRC which must, of course, be generated
with a CRC generator that the SoCFPGA boot ROM agrees with otherwise
the boot ROM will reject the image.
Unfortunately the CRC used in this boot ROM is not the same as the
Adler CRC in lib/crc32.c. Indeed the Adler code is not technically a
CRC but is more correctly described as a checksum.
Thus, the appropriate CRC generator is added to lib/ as crc32_alt.c.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
Changes for v3:
- Fix some coding style issues.
- Move from a standalone tool to the mkimgae framework.
Changes for v4:
- Fix more coding style issues.
- Fix typos in Makefile.
- Rebase on master (previous version was not on master, but on a
working socfpga branch).
Changes for v5:
- Fix more coding style issues.
- Add some more comments.
- Remove some unused defines.
- Move the local CRC32 code into lib/crc32_alt.c.
Changes for v6:
- Fix more coding style issues.
- Rejig socfpgaimage_vrec_header() function so that it has one return
path and does stricter size checks.
Changes for v7:
- Use bzlib's crc table instead of adding another one.
- Use existing code and a packed structure for header marshalling.
Note: Building a SOCFPGA preloader will currently not produce a
working image if built in master, but that is due to issues in
building SPL, not in this signer.
common/image.c |1 +
include/bzlib_crc32.h | 17
include/image.h|1 +
lib/bzlib_crc32.c | 26 +
spl/Makefile |5 +
tools/Makefile |3 +
tools/bzlib_crc32.c|1 +
tools/bzlib_crctable.c |1 +
tools/bzlib_private.h |1 +
tools/imagetool.c |2 +
tools/imagetool.h |1 +
tools/socfpgaimage.c | 255
12 files changed, 314 insertions(+)
create mode 100644 include/bzlib_crc32.h
create mode 100644 lib/bzlib_crc32.c
create mode 100644 tools/bzlib_crc32.c
create mode 100644 tools/bzlib_crctable.c
create mode 100644 tools/bzlib_private.h
create mode 100644 tools/socfpgaimage.c
diff --git a/common/image.c b/common/image.c
index 9c6bec5..e7dc8cc 100644
--- a/common/image.c
+++ b/common/image.c
@@ -135,6 +135,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_PBLIMAGE, pblimage, Freescale PBL Boot Image,},
{ IH_TYPE_RAMDISK,ramdisk,RAMDisk Image, },
{ IH_TYPE_SCRIPT, script, Script, },
+ { IH_TYPE_SOCFPGAIMAGE, socfpgaimage, Altera SOCFPGA
preloader,},
{ IH_TYPE_STANDALONE, standalone, Standalone Program, },
{ IH_TYPE_UBLIMAGE, ublimage, Davinci UBL image,},
{ IH_TYPE_MXSIMAGE, mxsimage, Freescale MXS Boot Image,},
diff --git a/include/bzlib_crc32.h b/include/bzlib_crc32.h
new file mode 100644
index 000..96d8124
--- /dev/null
+++ b/include/bzlib_crc32.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Note that the CRC is **not** the zlib/Adler crc32 in crc32.c.
+ * It is the CRC-32 used in bzip2, ethernet and elsewhere.
+ */
+
+#ifndef __BZLIB_CRC32_H__
+#define __BZLIB_CRC32_H__
+
+#include stdint.h
+
+uint32_t bzlib_crc32(uint32_t crc, const void *_buf, int length);
+
+#endif
diff --git a/include/image.h b/include/image.h
index 6afd57b..bde31d9 100644
--- a/include/image.h
+++ b/include/image.h
@@ -215,6 +215,7 @@ struct lmb;
#define IH_TYPE_KERNEL_NOLOAD 14 /* OS Kernel Image, can run from any
load address */
#define IH_TYPE_PBLIMAGE 15 /* Freescale PBL Boot Image */
#define IH_TYPE_MXSIMAGE 16 /* Freescale MXSBoot Image */
+#define IH_TYPE_SOCFPGAIMAGE 17 /* Altera SOCFPGA Preloader */
/*
* Compression Types
diff --git a/lib/bzlib_crc32.c b/lib/bzlib_crc32.c
new file mode 100644
index 000..cc1a8a0
--- /dev/null
+++ b/lib/bzlib_crc32.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * This provides a CRC-32 using the tables in bzlib_crctable.c
+ */
+
+#include bzlib_crc32.h
+#include bzlib_private.h
+
+uint32_t bzlib_crc32(uint32_t crc, const void *_buf, int length)
+{
+ const uint8_t *buf = _buf;
+
+ crc ^= ~0;
+
+ while (length--) {
+ crc = (crc 8) ^ BZ2_crc32Table[((crc 24) ^ *buf) 0xff];
+ buf++;
+ }
+
+ crc ^= ~0;
+
+ return crc;
+}
diff --git a/spl/Makefile b/spl/Makefile
index 346d0aa..4e0f33f 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -182,6 +182,11 @@ MLO MLO.byteswap: $(obj)/u-boot-spl.bin
[U-Boot] Is it OK to use target code from host tools
Hello All I am currently reworking a socfpga signer patch which is part of mkimage. One thing I need to do is to stuff some bytes into a header ensuring the endianism is correct. This is a trivial thing to do in C, but I have been instructed to use the existing functions put_unaligned_le32() etc. These are part of Linux in linux/unaligned/access_ok.h. But this includes asm/* It seems to me that this mixing of host space and target space is potentially problematic. Is this a safe thing to do? Thanks Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] socfpga: Add socfpga preloader signing to mkimage
Hello Wolfgang
Further to my last response
On Friday 28 February 2014 11:43:47 Charles Manning wrote:
On Friday 28 February 2014 10:57:21 Wolfgang Denk wrote:
+static uint32_t get_le32(const uint8_t *buf)
+{
+ uint32_t retval;
+
+ retval = (((uint32_t) buf[0]) 0) |
+ (((uint32_t) buf[1]) 8) |
+ (((uint32_t) buf[2]) 16) |
+ (((uint32_t) buf[3]) 24);
+ return retval;
+}
Why do you not use existing code (like get_unaligned_le16(),
get_unaligned_le32()) ?
From what I see these get_aligned_xxx() functions and friends exist in target
space, not host land.
From my limited understanding of these matters, it is unwise to call
these functions here.
Are you Ok with that explanation? I will be fixing the other issues you raised
one way or another.
Best regards
Charles
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] socfpga: Add socfpga preloader signing to mkimage
I can certainly avoid the ifdef, but there is already another one three lines down for the SAMSUNG case: ifdef CONFIG_SOCFPGA ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin endif ifdef CONFIG_SAMSUNG ALL-y+= $(obj)/$(BOARD)-spl.bin endif It seems odd to me that you would want different conventions in the same Makefile, but if that is what you want then that is what you will get. Existing poor code should not be used as reference for adding new bad code. If possible, it should be imprived -patches are welcome. In any case, please avoid the issues in new code. Thank you for that, though it is not obvious which is poor code and which is good code and sometimes one must follow what exists for guidance. I have cleared this up in the latest version that I posted. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] socfpga: Add socfpga preloader signing to mkimage
On Friday 28 February 2014 10:23:11 Wolfgang Denk wrote: Dear Charles, sorry, I only send part of the message. Here is the rest. In message cae21aqp2gspedrdakio1wpa3vgtwjd-3d1wsqm0whg9r-8b...@mail.gmail.com you wrote: Both Gerhard and me asked before: Why exactly do we need another implementation of CRC32. We already have some - why cannot we use these? ... The actual table values I am using are also found in lib/bzlib_crctable.c So could you use the bzlib implementation for your purposes? This is, however, not exposed but is a private thing within bzlib. The best choice would possibly be to expose this with a new crc function, but that means dragging bzlib (or parts thereof) into mkimage or at least putting hooks into bzlib that were never intended to be there. The alternative is to maybe just add a new alt_crc.c to lib. Code duplication is always bad. Please factor out common code parts. Ok, I will write a small wrapper thing that accesses the bzlib table. That table will now be compiled in if you use either bzlib or the alternative crc32. Does that sound OK? + * Copyright for the CRC code: + * + * COPYRIGHT (C) 1986 Gary S. Brown. You may use this program, or + * code or tables extracted from it, as desired without restriction. I asked before: Please provide _exact_ reference. See ... Exact reference includes some URL plus version id, etc. That stuff is now gone I also commented before: If you really need this copied code (i. e. you canot use one of the already existing implementations of CRC32 - which I seriously doubt), then better move this into a separate file, and assign a separate license ID tag for it. You say already exiting implementations. I see only one: lib/crc32.c. Perhaps I am not looking in the right place? I shall split this code out and call it alt_crc32 and put it in lib with one of those proxy files in tools. alt is a really bad name - you mentioned yourself that ther eis not only one alternative, so please rather use a descriptive name. Is bzlib_crc32 Ok? Thank you for your feedback. -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] socfpga: Add socfpga preloader signing to mkimage
On Friday 28 February 2014 10:57:21 Wolfgang Denk wrote:
Dear Charles,
In message 1393472979-7522-1-git-send-email-cdhmann...@gmail.com you
wrote:
Like many platforms, the Altera socfpga platform requires that the
preloader be signed in a certain way or the built-in boot ROM will
not boot the code.
...
diff --git a/include/crc32_alt.h b/include/crc32_alt.h
new file mode 100644
index 000..813d55d
--- /dev/null
+++ b/include/crc32_alt.h
alt is a bad name as there is more than one alternative. Please use
a descriptive name.
Ok I shall do that.
--- /dev/null
+++ b/lib/crc32_alt.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Note that the CRC is **not** the zlib/Adler crc32 in crc32.c.
+ * It is the CRC-32 used in bzip2, ethernet and elsewhere.
+ */
I understand this was copied from lib/bzlib_crctable.c ? BUt you
claim copyright on this, without any attribution where you got it
form. This is very, vary bad.
You understand incorrectly. I did not copy it from bzlib. I generated it.
I had generated this table before I even knew it was part of
ib/bzlib_crctable.c.
Of course it **must** have the same values in it because that is how the
mathematics works out.
I hope you are as free with your retractions as you are with your accusations!
+static uint32_t crc_table[256] = {
+ 0x, 0x04c11db7, 0x09823b6e, 0x0d4326d9,
...
+ 0xbcb4666d, 0xb8757bda, 0xb5365d03, 0xb1f740b4,
+};
Indeed this looks very much like a duplication of code we have
elsewhere:
- in lib/bzlib_crctable.c (as BZ2_crc32Table[])
- in drivers/mtd/ubi/crc32table.h (as crc32table_be[])
+uint32_t crc32_alt(uint32_t crc, const void *_buf, int length)
+{
+ const uint8_t *buf = _buf;
+
+ crc ^= ~0;
+
+ while (length--) {
+ crc = (crc 8) ^ crc_table[((crc 24) ^ *buf) 0xff];
+ buf++;
+ }
+
+ crc ^= ~0;
+
+ return crc;
+}
In addition to this, we also have
- crc32 in lib/crc32.c
- crc32() in tools/mxsimage.c
- make_crc_table() and pbl_crc32() in tools/pblimage.c
I really think we should factor out the common tables and code here.
I will not accept yet another duplication of this - we already have
way too many of these.
Based on your comments in another thread, I have suggested that I do one of
two things:
1) Either have a new C file in lib that uses the bzlib table or
2) Extend the bzlib in a way that exposes a function called
crc32_bzlib() or bzlib_crc32().
Whichever you like.
It seems to me that refactoring is best kept as a different patch.
May I humbly submit that it would be a good idea to bed this socfpga signer
down. Then, as a separate commit and a separate patch, I will refactor with
pbllimage and mxsimage.
Does that sound OK with you?
--- /dev/null
+++ b/tools/socfpgaimage.c
@@ -0,0 +1,278 @@
...
+ * Endian is LSB.
What does that mean? When talking about endianess, I know
Big-endian and Little-endian - LSB is meaningless in this context
(unless you write something like LSB first or LSB last, but even
this would not be really clear).
Sorry typo. I will fix.
+ * Note that the CRC used here is **not** the zlib/Adler crc32. It is
the + * CRC-32 used in bzip2, ethernet and elsewhere.
Does this have a name?
CRC-32 ... the real one. Adler was really a bit naughty in using the crc32
name for something that:
a) is not the most standard crc
b) is not even really a crc anyway -i t is more correctly a checksum.
+ * The image is padded out to 64k, because that is what is
+ * typically used to write the image to the boot medium.
+ */
typically used - by what or whom? Is there any rechnical reason for
such padding? If not, can we not rather omit this?
The files are often concatenated into blocks of 4 repeats and are also often
written into NAND and aligning them to 64k makes some sense.
+/*
+ * Some byte marshalling functions...
+ * These load or get little endian values to/from the
+ * buffer.
+ */
+static void load_le16(uint8_t *buf, uint16_t v)
+{
+ buf[0] = (v 0) 0xff;
+ buf[1] = (v 8) 0xff;
+}
+
+static void load_le32(uint8_t *buf, uint32_t v)
+{
+ buf[0] = (v 0) 0xff;
+ buf[1] = (v 8) 0xff;
+ buf[2] = (v 16) 0xff;
+ buf[3] = (v 24) 0xff;
+}
These are misnomers. You do not load something, but instead you store
the value of 'v' into the buffer 'buf'.
And why do you invent new functions here instead of using existing
code (like put_unaligned_le16(), put_unaligned_le32()) ?
I was not aware of the existence of these functions.
Thank you.
+static uint16_t get_le16(const uint8_t *buf)
+{
+ uint16_t retval;
+
+ retval = (((uint16_t) buf[0]) 0) |
+(((uint16_t) buf[1]) 8);
+ return retval;
+}
+
+static uint32_t get_le32(const uint8_t *buf
[U-Boot] [PATCH v6] socfpga: Add socfpga preloader signing to mkimage
Like many platforms, the Altera socfpga platform requires that the
preloader be signed in a certain way or the built-in boot ROM will
not boot the code.
This change automatically creates an appropriately signed preloader
from an SPL image.
The signed image includes a CRC which must, of course, be generated
with a CRC generator that the SoCFPGA boot ROM agrees with otherwise
the boot ROM will reject the image.
Unfortunately the CRC used in this boot ROM is not the same as the
Adler CRC in lib/crc32.c. Indeed the Adler code is not technically a
CRC but is more correctly described as a checksum.
Thus, the appropriate CRC generator is added to lib/ as crc32_alt.c.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
Changes for v3:
- Fix some coding style issues.
- Move from a standalone tool to the mkimgae framework.
Changes for v4:
- Fix more coding style issues.
- Fix typos in Makefile.
- Rebase on master (previous version was not on master, but on a
working socfpga branch).
Changes for v5:
- Fix more coding style issues.
- Add some more comments.
- Remove some unused defines.
- Move the local CRC32 code into lib/crc32_alt.c.
Changes for v6:
- Fix more coding style issues.
- Rejig socfpgaimage_vrec_header() function so that it has one return
path and does stricter size checks.
Note: Building a SOCFPGA preloader will currently not produe a working
image if built in master, but that is due to issues in building SPL,
not in this signer.
common/image.c |1 +
include/crc32_alt.h | 17 +++
include/image.h |1 +
lib/Makefile |1 +
lib/crc32_alt.c | 94 +
spl/Makefile |5 +
tools/Makefile |2 +
tools/crc32_alt.c|1 +
tools/imagetool.c|2 +
tools/imagetool.h|1 +
tools/socfpgaimage.c | 278 ++
11 files changed, 403 insertions(+)
create mode 100644 include/crc32_alt.h
create mode 100644 lib/crc32_alt.c
create mode 100644 tools/crc32_alt.c
create mode 100644 tools/socfpgaimage.c
diff --git a/common/image.c b/common/image.c
index 9c6bec5..e7dc8cc 100644
--- a/common/image.c
+++ b/common/image.c
@@ -135,6 +135,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_PBLIMAGE, pblimage, Freescale PBL Boot Image,},
{ IH_TYPE_RAMDISK,ramdisk,RAMDisk Image, },
{ IH_TYPE_SCRIPT, script, Script, },
+ { IH_TYPE_SOCFPGAIMAGE, socfpgaimage, Altera SOCFPGA
preloader,},
{ IH_TYPE_STANDALONE, standalone, Standalone Program, },
{ IH_TYPE_UBLIMAGE, ublimage, Davinci UBL image,},
{ IH_TYPE_MXSIMAGE, mxsimage, Freescale MXS Boot Image,},
diff --git a/include/crc32_alt.h b/include/crc32_alt.h
new file mode 100644
index 000..813d55d
--- /dev/null
+++ b/include/crc32_alt.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Note that the CRC is **not** the zlib/Adler crc32 in crc32.c.
+ * It is the CRC-32 used in bzip2, ethernet and elsewhere.
+ */
+
+#ifndef __CRC32_ALT_H__
+#define __CRC32_ALT_H__
+
+#include stdint.h
+
+uint32_t crc32_alt(uint32_t crc, const void *_buf, int length);
+
+#endif
diff --git a/include/image.h b/include/image.h
index 6afd57b..bde31d9 100644
--- a/include/image.h
+++ b/include/image.h
@@ -215,6 +215,7 @@ struct lmb;
#define IH_TYPE_KERNEL_NOLOAD 14 /* OS Kernel Image, can run from any
load address */
#define IH_TYPE_PBLIMAGE 15 /* Freescale PBL Boot Image */
#define IH_TYPE_MXSIMAGE 16 /* Freescale MXSBoot Image */
+#define IH_TYPE_SOCFPGAIMAGE 17 /* Altera SOCFPGA Preloader */
/*
* Compression Types
diff --git a/lib/Makefile b/lib/Makefile
index 8c483c9..7ee07a5 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -52,6 +52,7 @@ obj-y += errno.o
obj-y += display_options.o
obj-$(CONFIG_BCH) += bch.o
obj-y += crc32.o
+obj-y += crc32_alt.o
obj-y += ctype.o
obj-y += div64.o
obj-y += hang.o
diff --git a/lib/crc32_alt.c b/lib/crc32_alt.c
new file mode 100644
index 000..e0db335
--- /dev/null
+++ b/lib/crc32_alt.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Note that the CRC is **not** the zlib/Adler crc32 in crc32.c.
+ * It is the CRC-32 used in bzip2, ethernet and elsewhere.
+ */
+
+#include crc32_alt.h
+#include stdint.h
+
+static uint32_t crc_table[256] = {
+ 0x, 0x04c11db7, 0x09823b6e, 0x0d4326d9,
+ 0x130476dc, 0x17c56b6b, 0x1a864db2, 0x1e475005,
+ 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6, 0x2b4bcb61,
+ 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd,
+ 0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9,
+ 0x5f15adac, 0x5bd4b01b, 0x569796c2, 0x52568b75,
+ 0x6a1936c8, 0x6ed82b7f, 0x639b0da6, 0x675a1011
[U-Boot] [PATCH v5] socfpga: Add socfpga preloader signing to mkimage
Like many platforms, the Altera socfpga platform requires that the
preloader be signed in a certain way or the built-in boot ROM will
not boot the code.
This change automatically creates an appropriately signed preloader
from an SPL image.
The signed image includes a CRC which must, of course, be generated
with a CRC generator that the SoCFPGA boot ROM agrees with otherwise
the boot ROM will reject the image.
Unfortunately the CRC used in this boot ROM is not the same as the
Adler CRC in lib/crc32.c. Indeed the Adler code is not technically a
CRC but is more correctly described as a checksum.
Thus, the appropriate CRC generator is added to lib/ as crc32_alt.c.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
Changes for v3:
- Fix some coding style issues.
- Move from a standalone tool to the mkimgae framework.
Changes for v4:
- Fix more coding style issues.
- Fix typos in Makefile.
- Rebase on master (previous version was not on master, but on a
working socfpga branch).
Changes for v5:
- Fix more coding style issues.
- Add some more comments.
- Remove some unused defines.
- Move the local CRC32 code into lib/crc32_alt.c.
Note: Building a SOCFPGA preloader will currently not produe a working
image if built in master, but that is due to issues in building SPL,
not in this signer.
common/image.c |1 +
include/crc32_alt.h | 17
include/image.h |1 +
lib/Makefile |1 +
lib/crc32_alt.c | 94 +
spl/Makefile |5 +
tools/Makefile |2 +
tools/crc32_alt.c|1 +
tools/imagetool.c|2 +
tools/imagetool.h|1 +
tools/socfpgaimage.c | 276 ++
11 files changed, 401 insertions(+)
create mode 100644 include/crc32_alt.h
create mode 100644 lib/crc32_alt.c
create mode 100644 tools/crc32_alt.c
create mode 100644 tools/socfpgaimage.c
diff --git a/common/image.c b/common/image.c
index 9c6bec5..e7dc8cc 100644
--- a/common/image.c
+++ b/common/image.c
@@ -135,6 +135,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_PBLIMAGE, pblimage, Freescale PBL Boot Image,},
{ IH_TYPE_RAMDISK,ramdisk,RAMDisk Image, },
{ IH_TYPE_SCRIPT, script, Script, },
+ { IH_TYPE_SOCFPGAIMAGE, socfpgaimage, Altera SOCFPGA
preloader,},
{ IH_TYPE_STANDALONE, standalone, Standalone Program, },
{ IH_TYPE_UBLIMAGE, ublimage, Davinci UBL image,},
{ IH_TYPE_MXSIMAGE, mxsimage, Freescale MXS Boot Image,},
diff --git a/include/crc32_alt.h b/include/crc32_alt.h
new file mode 100644
index 000..813d55d
--- /dev/null
+++ b/include/crc32_alt.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Note that the CRC is **not** the zlib/Adler crc32 in crc32.c.
+ * It is the CRC-32 used in bzip2, ethernet and elsewhere.
+ */
+
+#ifndef __CRC32_ALT_H__
+#define __CRC32_ALT_H__
+
+#include stdint.h
+
+uint32_t crc32_alt(uint32_t crc, const void *_buf, int length);
+
+#endif
diff --git a/include/image.h b/include/image.h
index 6afd57b..bde31d9 100644
--- a/include/image.h
+++ b/include/image.h
@@ -215,6 +215,7 @@ struct lmb;
#define IH_TYPE_KERNEL_NOLOAD 14 /* OS Kernel Image, can run from any
load address */
#define IH_TYPE_PBLIMAGE 15 /* Freescale PBL Boot Image */
#define IH_TYPE_MXSIMAGE 16 /* Freescale MXSBoot Image */
+#define IH_TYPE_SOCFPGAIMAGE 17 /* Altera SOCFPGA Preloader */
/*
* Compression Types
diff --git a/lib/Makefile b/lib/Makefile
index 8c483c9..7ee07a5 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -52,6 +52,7 @@ obj-y += errno.o
obj-y += display_options.o
obj-$(CONFIG_BCH) += bch.o
obj-y += crc32.o
+obj-y += crc32_alt.o
obj-y += ctype.o
obj-y += div64.o
obj-y += hang.o
diff --git a/lib/crc32_alt.c b/lib/crc32_alt.c
new file mode 100644
index 000..e0db335
--- /dev/null
+++ b/lib/crc32_alt.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Note that the CRC is **not** the zlib/Adler crc32 in crc32.c.
+ * It is the CRC-32 used in bzip2, ethernet and elsewhere.
+ */
+
+#include crc32_alt.h
+#include stdint.h
+
+static uint32_t crc_table[256] = {
+ 0x, 0x04c11db7, 0x09823b6e, 0x0d4326d9,
+ 0x130476dc, 0x17c56b6b, 0x1a864db2, 0x1e475005,
+ 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6, 0x2b4bcb61,
+ 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd,
+ 0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9,
+ 0x5f15adac, 0x5bd4b01b, 0x569796c2, 0x52568b75,
+ 0x6a1936c8, 0x6ed82b7f, 0x639b0da6, 0x675a1011,
+ 0x791d4014, 0x7ddc5da3, 0x709f7b7a, 0x745e66cd,
+ 0x9823b6e0, 0x9ce2ab57, 0x91a18d8e, 0x95609039,
+ 0x8b27c03c, 0x8fe6dd8b, 0x82a5fb52
Re: [U-Boot] [PATCH v5] socfpga: Add socfpga preloader signing to mkimage
On Wednesday 26 February 2014 19:16:37 Michal Simek wrote:
On 02/26/2014 02:17 AM, Charles Manning wrote:
Like many platforms, the Altera socfpga platform requires that the
preloader be signed in a certain way or the built-in boot ROM will
not boot the code.
This change automatically creates an appropriately signed preloader
from an SPL image.
The signed image includes a CRC which must, of course, be generated
with a CRC generator that the SoCFPGA boot ROM agrees with otherwise
the boot ROM will reject the image.
Unfortunately the CRC used in this boot ROM is not the same as the
Adler CRC in lib/crc32.c. Indeed the Adler code is not technically a
CRC but is more correctly described as a checksum.
Thus, the appropriate CRC generator is added to lib/ as crc32_alt.c.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
Changes for v3:
- Fix some coding style issues.
- Move from a standalone tool to the mkimgae framework.
Changes for v4:
- Fix more coding style issues.
- Fix typos in Makefile.
- Rebase on master (previous version was not on master, but on a
working socfpga branch).
Changes for v5:
- Fix more coding style issues.
- Add some more comments.
- Remove some unused defines.
- Move the local CRC32 code into lib/crc32_alt.c.
Note: Building a SOCFPGA preloader will currently not produe a working
image if built in master, but that is due to issues in building SPL,
not in this signer.
common/image.c |1 +
include/crc32_alt.h | 17
include/image.h |1 +
lib/Makefile |1 +
lib/crc32_alt.c | 94 +
spl/Makefile |5 +
tools/Makefile |2 +
tools/crc32_alt.c|1 +
tools/imagetool.c|2 +
tools/imagetool.h|1 +
tools/socfpgaimage.c | 276
++ 11 files changed, 401
insertions(+)
create mode 100644 include/crc32_alt.h
create mode 100644 lib/crc32_alt.c
create mode 100644 tools/crc32_alt.c
create mode 100644 tools/socfpgaimage.c
diff --git a/common/image.c b/common/image.c
index 9c6bec5..e7dc8cc 100644
--- a/common/image.c
+++ b/common/image.c
@@ -135,6 +135,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_PBLIMAGE, pblimage, Freescale PBL Boot Image,},
{ IH_TYPE_RAMDISK,ramdisk,RAMDisk Image, },
{ IH_TYPE_SCRIPT, script, Script, },
+ { IH_TYPE_SOCFPGAIMAGE, socfpgaimage, Altera SOCFPGA
preloader,},
{ IH_TYPE_STANDALONE, standalone, Standalone Program, },
{ IH_TYPE_UBLIMAGE, ublimage, Davinci UBL image,},
{ IH_TYPE_MXSIMAGE, mxsimage, Freescale MXS Boot Image,},
diff --git a/include/crc32_alt.h b/include/crc32_alt.h
new file mode 100644
index 000..813d55d
--- /dev/null
+++ b/include/crc32_alt.h
@@ -0,0 +1,17 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Note that the CRC is **not** the zlib/Adler crc32 in crc32.c.
+ * It is the CRC-32 used in bzip2, ethernet and elsewhere.
+ */
+
+#ifndef __CRC32_ALT_H__
+#define __CRC32_ALT_H__
+
+#include stdint.h
+
+uint32_t crc32_alt(uint32_t crc, const void *_buf, int length);
+
+#endif
diff --git a/include/image.h b/include/image.h
index 6afd57b..bde31d9 100644
--- a/include/image.h
+++ b/include/image.h
@@ -215,6 +215,7 @@ struct lmb;
#define IH_TYPE_KERNEL_NOLOAD 14 /* OS Kernel Image, can run
from any
load address */ #define IH_TYPE_PBLIMAGE15 /* Freescale PBL Boot
Image */
#define IH_TYPE_MXSIMAGE 16 /* Freescale MXSBoot Image */
+#define IH_TYPE_SOCFPGAIMAGE 17 /* Altera SOCFPGA Preloader
*/
/*
* Compression Types
diff --git a/lib/Makefile b/lib/Makefile
index 8c483c9..7ee07a5 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -52,6 +52,7 @@ obj-y += errno.o
obj-y += display_options.o
obj-$(CONFIG_BCH) += bch.o
obj-y += crc32.o
+obj-y += crc32_alt.o
obj-y += ctype.o
obj-y += div64.o
obj-y += hang.o
diff --git a/lib/crc32_alt.c b/lib/crc32_alt.c
new file mode 100644
index 000..e0db335
--- /dev/null
+++ b/lib/crc32_alt.c
@@ -0,0 +1,94 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Note that the CRC is **not** the zlib/Adler crc32 in crc32.c.
+ * It is the CRC-32 used in bzip2, ethernet and elsewhere.
+ */
+
+#include crc32_alt.h
+#include stdint.h
+
+static uint32_t crc_table[256] = {
+ 0x, 0x04c11db7, 0x09823b6e, 0x0d4326d9,
+ 0x130476dc, 0x17c56b6b, 0x1a864db2, 0x1e475005,
+ 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6, 0x2b4bcb61,
+ 0x350c9b64, 0x31cd86d3
Re: [U-Boot] [PATCH v4] socfpga: Add socfpga preloader signing to mkimage
Hello Wolfgang On Monday 24 February 2014 19:48:36 Wolfgang Denk wrote: Dear Charles, In message 1393194939-29786-1-git-send-email-cdhmann...@gmail.com you wrote: Like many platforms, the Altera socfpga platform requires that the preloader be signed in a certain way or the built-in boot ROM will not boot the code. This change automatically creates an appropriately signed preloader from an SPL image. Signed-off-by: Charles Manning cdhmann...@gmail.com --- Changes for v3: - Fix some coding style issues. - Move from a standalone tool to the mkimgae framework. Changes for v4: - Fix more coding style issues. - Fix typos in Makefile. - Rebase on master (previous version was not on master, but on a working socfpga branch). There may be perfectly valid reasons why you might decide to ingore a review comments - sch comments may be wrong, too, after all. But in such a case it is always a good idea to provide feedback to the reviewer why you decided not to follow his advice. Otherwise he might think you just missed or ignored the comment. I am sorry, I must have missed some of the comments. I have intended to implement them all, except one by Gerhard. And this is what is happeneing (again) in your patch... diff --git a/spl/Makefile b/spl/Makefile index bf98024..90faaa6 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -181,6 +181,14 @@ $(objtree)/SPL : $(obj)/u-boot-spl.bin ALL-y += $(obj)/$(SPL_BIN).bin +$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin + $(OBJTREE)/tools/mkimage -T socfpgaimage -d $ $@ + + One blank line is sufficient. Ok, a blank line. I can delete that. I asked before: socfpga-signed-preloader.bin is a terribly long name. Can we find a better one? +ifdef CONFIG_SOCFPGA +ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin +endif I asked before: Can we not use ALL-$(CONFIG_SOCFPGA) and avoid the ifdef ? I am sorry, I had developed this code in a different (older) branch where socfpga actually works. It is broken in master. This I shall fix. + * Reference doc http://www.altera.com.cn/literature/hb/cyclone-v/cv_5400A.pdf + * Note this doc is not entirely accurate. I aseked before: Would you care to explain the errors in the document that might cause problems to the reader? Noting that something contains errors without mentioning what these are is really not helpful. Ok, I shall mention the errors pertinent to the code. Other errors I shall ignore. + * This uses the CRC32 calc out of the well known Apple + * crc32.c code. CRC32 algorithms do not produce the same results. + * We need this one. Sorry about the coade bloat. Both Gerhard and me asked before: Why exactly do we need another implementation of CRC32. We already have some - why cannot we use these? Well I would have thought that obvious from the comment I put in the code, but email is an imperfect communications medium, so I shall explain in further detail here. As I am sure you are aware, there are many different crc32 calculations. Indeed Wikipedia lists 5 and there are most likely others. Even when they use the same polynomial, they give differences when you stuff the bits through the shift register lsb-first or msb-first. Now from what I see looking through the u-boot lib/ directory u-boot provides just one crc32 version - Adler (and a bit flipped version thereof for use by jffs2). If there are others I did not see them. Now as I expect you are aware, the purpose of a signer is to massage the code so that it is in a form that the boot ROM accepts. One of those criteria is that the crc in the code matches the crc the boot ROM is expecting. If not, the boot ROM refuses to execute the code. It would be nice to use the Adler code. Indeed this is my favourite crc. However, this is not what the boot ROM wants. The boot ROM does not enter into rational discussions, so we must, unfortunately, bow to its whims. If it wants a different CRC calculation then we must supply it. I did much experimentation to find the crc that worked. I tried the zlib crc - no luck. I tried different many things until I found something that worked. + * Copyright for the CRC code: + * + * COPYRIGHT (C) 1986 Gary S. Brown. You may use this program, or + * code or tables extracted from it, as desired without restriction. I asked before: Please provide _exact_ reference. See http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sig n for instructions how to do this. As it was, I had attributed this incorrectly. This is a file I generated myself, though I had used this as a reference during my research. The values will look the same as some other code floating out there, but that is because that is the way things have to be. I shall fix this wen I make another file. I also commented before: If you really need this copied code (i. e. you canot use one
Re: [U-Boot] [PATCH v4] socfpga: Add socfpga preloader signing to mkimage
Hello Wolfgang I have some further observations to my last email... Your input would be vastly appreciated. Please see below. On Tue, Feb 25, 2014 at 8:18 AM, Charles Manning cdhmann...@gmail.comwrote: Hello Wolfgang On Monday 24 February 2014 19:48:36 Wolfgang Denk wrote: Dear Charles, In message 1393194939-29786-1-git-send-email-cdhmann...@gmail.com you wrote: Like many platforms, the Altera socfpga platform requires that the preloader be signed in a certain way or the built-in boot ROM will not boot the code. This change automatically creates an appropriately signed preloader from an SPL image. Signed-off-by: Charles Manning cdhmann...@gmail.com --- Changes for v3: - Fix some coding style issues. - Move from a standalone tool to the mkimgae framework. Changes for v4: - Fix more coding style issues. - Fix typos in Makefile. - Rebase on master (previous version was not on master, but on a working socfpga branch). There may be perfectly valid reasons why you might decide to ingore a review comments - sch comments may be wrong, too, after all. But in such a case it is always a good idea to provide feedback to the reviewer why you decided not to follow his advice. Otherwise he might think you just missed or ignored the comment. I am sorry, I must have missed some of the comments. I have intended to implement them all, except one by Gerhard. And this is what is happeneing (again) in your patch... diff --git a/spl/Makefile b/spl/Makefile index bf98024..90faaa6 100644 --- a/spl/Makefile +++ b/spl/Makefile @@ -181,6 +181,14 @@ $(objtree)/SPL : $(obj)/u-boot-spl.bin ALL-y += $(obj)/$(SPL_BIN).bin +$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin + $(OBJTREE)/tools/mkimage -T socfpgaimage -d $ $@ + + One blank line is sufficient. Ok, a blank line. I can delete that. I asked before: socfpga-signed-preloader.bin is a terribly long name. Can we find a better one? +ifdef CONFIG_SOCFPGA +ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin +endif I asked before: Can we not use ALL-$(CONFIG_SOCFPGA) and avoid the ifdef ? I am sorry, I had developed this code in a different (older) branch where socfpga actually works. It is broken in master. This I shall fix. I can certainly avoid the ifdef, but there is already another one three lines down for the SAMSUNG case: ifdef CONFIG_SOCFPGA ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin endif ifdef CONFIG_SAMSUNG ALL-y+= $(obj)/$(BOARD)-spl.bin endif It seems odd to me that you would want different conventions in the same Makefile, but if that is what you want then that is what you will get. + * Reference doc http://www.altera.com.cn/literature/hb/cyclone-v/cv_5400A.pdf + * Note this doc is not entirely accurate. I aseked before: Would you care to explain the errors in the document that might cause problems to the reader? Noting that something contains errors without mentioning what these are is really not helpful. Ok, I shall mention the errors pertinent to the code. Other errors I shall ignore. + * This uses the CRC32 calc out of the well known Apple + * crc32.c code. CRC32 algorithms do not produce the same results. + * We need this one. Sorry about the coade bloat. Both Gerhard and me asked before: Why exactly do we need another implementation of CRC32. We already have some - why cannot we use these? Well I would have thought that obvious from the comment I put in the code, but email is an imperfect communications medium, so I shall explain in further detail here. As I am sure you are aware, there are many different crc32 calculations. Indeed Wikipedia lists 5 and there are most likely others. Even when they use the same polynomial, they give differences when you stuff the bits through the shift register lsb-first or msb-first. Now from what I see looking through the u-boot lib/ directory u-boot provides just one crc32 version - Adler (and a bit flipped version thereof for use by jffs2). If there are others I did not see them. Now as I expect you are aware, the purpose of a signer is to massage the code so that it is in a form that the boot ROM accepts. One of those criteria is that the crc in the code matches the crc the boot ROM is expecting. If not, the boot ROM refuses to execute the code. It would be nice to use the Adler code. Indeed this is my favourite crc. However, this is not what the boot ROM wants. The boot ROM does not enter into rational discussions, so we must, unfortunately, bow to its whims. If it wants a different CRC calculation then we must supply it. I did much experimentation to find the crc that worked. I tried the zlib crc - no luck. I tried different many things until I found something that worked. The actual table values I am using are also found in lib
Re: [U-Boot] [PATCH v3] socfpga: Add a signer that is integrated into mkimage
Hello All, but mainly a message to Wolfgang and Gerhard. I would like to apologise for my recent flurry of postings causing some confusion and gnashing of teeth. I only read some of the comments (relating to adding a version number on the patch). I had read that far then assumed the patch had already been NAKed at that point and did not read further. I shall now read all the comments from Wolfgang and Gerhard again and resubmit another version which I hope is closer to the mark. Thank you for my ongoing education. Regards Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] socfpga: Add socfpga preloader signing to mkimage
Like many platforms, the Altera socfpga platform requires that the
preloader be signed in a certain way or the built-in boot ROM will
not boot the code.
This change automatically creates an appropriately signed preloader
from an SPL image.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
Changes for v3:
- Fix some coding style issues.
- Move from a standalone tool to the mkimgae framework.
Changes for v4:
- Fix more coding style issues.
- Fix typos in Makefile.
- Rebase on master (previous version was not on master, but on a
working socfpga branch).
Note: Building a SOCFPGA preloader will currently not produe a working
image, but that is due to issues in building SPL, not in this signer.
common/image.c |1 +
include/image.h |1 +
spl/Makefile |8 ++
tools/Makefile |1 +
tools/imagetool.c|2 +
tools/imagetool.h|1 +
tools/socfpgaimage.c | 365 ++
7 files changed, 379 insertions(+)
create mode 100644 tools/socfpgaimage.c
diff --git a/common/image.c b/common/image.c
index 9c6bec5..e7dc8cc 100644
--- a/common/image.c
+++ b/common/image.c
@@ -135,6 +135,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_PBLIMAGE, pblimage, Freescale PBL Boot Image,},
{ IH_TYPE_RAMDISK,ramdisk,RAMDisk Image, },
{ IH_TYPE_SCRIPT, script, Script, },
+ { IH_TYPE_SOCFPGAIMAGE, socfpgaimage, Altera SOCFPGA
preloader,},
{ IH_TYPE_STANDALONE, standalone, Standalone Program, },
{ IH_TYPE_UBLIMAGE, ublimage, Davinci UBL image,},
{ IH_TYPE_MXSIMAGE, mxsimage, Freescale MXS Boot Image,},
diff --git a/include/image.h b/include/image.h
index 6afd57b..bde31d9 100644
--- a/include/image.h
+++ b/include/image.h
@@ -215,6 +215,7 @@ struct lmb;
#define IH_TYPE_KERNEL_NOLOAD 14 /* OS Kernel Image, can run from any
load address */
#define IH_TYPE_PBLIMAGE 15 /* Freescale PBL Boot Image */
#define IH_TYPE_MXSIMAGE 16 /* Freescale MXSBoot Image */
+#define IH_TYPE_SOCFPGAIMAGE 17 /* Altera SOCFPGA Preloader */
/*
* Compression Types
diff --git a/spl/Makefile b/spl/Makefile
index bf98024..90faaa6 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -181,6 +181,14 @@ $(objtree)/SPL : $(obj)/u-boot-spl.bin
ALL-y += $(obj)/$(SPL_BIN).bin
+$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)/u-boot-spl.bin
+ $(OBJTREE)/tools/mkimage -T socfpgaimage -d $ $@
+
+
+ifdef CONFIG_SOCFPGA
+ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin
+endif
+
ifdef CONFIG_SAMSUNG
ALL-y += $(obj)/$(BOARD)-spl.bin
endif
diff --git a/tools/Makefile b/tools/Makefile
index dcd49f8..59ff8d3 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -85,6 +85,7 @@ dumpimage-mkimage-objs := aisimage.o \
os_support.o \
pblimage.o \
sha1.o \
+ socfpgaimage.o \
ublimage.o \
$(LIBFDT_OBJS) \
$(RSA_OBJS-y)
diff --git a/tools/imagetool.c b/tools/imagetool.c
index 29d2189..1ef20b1 100644
--- a/tools/imagetool.c
+++ b/tools/imagetool.c
@@ -45,6 +45,8 @@ void register_image_tool(imagetool_register_t image_register)
init_ubl_image_type();
/* Init Davinci AIS support */
init_ais_image_type();
+ /* Init Altera SOCFPGA support */
+ init_socfpga_image_type();
}
/*
diff --git a/tools/imagetool.h b/tools/imagetool.h
index c2c9aea..c4833b1 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -167,6 +167,7 @@ void init_mxs_image_type(void);
void init_fit_image_type(void);
void init_ubl_image_type(void);
void init_omap_image_type(void);
+void init_socfpga_image_type(void);
void pbl_load_uboot(int fd, struct image_tool_params *mparams);
diff --git a/tools/socfpgaimage.c b/tools/socfpgaimage.c
new file mode 100644
index 000..ca4369c
--- /dev/null
+++ b/tools/socfpgaimage.c
@@ -0,0 +1,365 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * Use as you see fit.
+ *
+ * Reference doc http://www.altera.com.cn/literature/hb/cyclone-v/cv_5400A.pdf
+ * Note this doc is not entirely accurate.
+ *
+ * Header is a structure of the following format.
+ * this is positioned at 0x40.
+ *
+ * Endian is LSB.
+ *
+ * Offset Length Usage
+ * ---
+ * 0x404 Validation word 0x31305341
+ * 0x441 Version (whatever, zero is fine)
+ * 0x451 Flags (unused, zero is fine)
+ * 0x462 Length (in units of u32, including the end checksum).
+ * 0x482 Zero
+ * 0x0A2 Checksum over the heder. NB Not CRC32
+ *
+ * At the end of the code we have a 32-bit CRC checksum over whole binary
+ * excluding the CRC.
+ *
+ * The image is typically padded out to 64k, because
[U-Boot] [PATCH v3] socfpga: Add a signer that is integrated into mkimage
This adds a signer for the socfpga preloader built from SPL.
Instead of using the arcane Altera signing tool, this automatically
creates a signed version of the SPL in the u-boot root directory.
Changes since previous submissions:
* This version is integrated into mkimage, with image type socfpgaimage.
* This version passes checkpatch too :-)
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
common/image.c |1 +
include/image.h |1 +
spl/Makefile |8 ++
tools/Makefile |2 +
tools/mkimage.c |2 +
tools/mkimage.h |1 +
tools/socfpgaimage.c | 348 ++
7 files changed, 363 insertions(+)
create mode 100644 tools/socfpgaimage.c
diff --git a/common/image.c b/common/image.c
index 95498e6..1a2e107 100644
--- a/common/image.c
+++ b/common/image.c
@@ -144,6 +144,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_INVALID,NULL, Invalid Image, },
{ IH_TYPE_MULTI, multi, Multi-File Image, },
{ IH_TYPE_OMAPIMAGE, omapimage, TI OMAP SPL With GP CH,},
+ { IH_TYPE_SOCFPGAIMAGE, socfpgaimage, Altera SOCFPGA
preloader,},
{ IH_TYPE_PBLIMAGE, pblimage, Freescale PBL Boot Image,},
{ IH_TYPE_RAMDISK,ramdisk,RAMDisk Image, },
{ IH_TYPE_SCRIPT, script, Script, },
diff --git a/include/image.h b/include/image.h
index f5adc50..95a0bf7 100644
--- a/include/image.h
+++ b/include/image.h
@@ -166,6 +166,7 @@
#define IH_TYPE_AISIMAGE 13 /* TI Davinci AIS Image */
#define IH_TYPE_KERNEL_NOLOAD 14 /* OS Kernel Image, can run from any
load address */
#define IH_TYPE_PBLIMAGE 15 /* Freescale PBL Boot Image */
+#define IH_TYPE_SOCFPGAIMAGE 16 /* Altera SOCFPGA Preloader Image
*/
/*
* Compression Types
diff --git a/spl/Makefile b/spl/Makefile
index c0abe3d..8f061b0 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -144,8 +144,12 @@ $(OBJTREE)/MLO:$(obj)u-boot-spl.bin
$(OBJTREE)/MLO.byteswap: $(obj)u-boot-spl.bin
$(OBJTREE)/tools/mkimage -T omapimage -n byteswap \
+
-a $(CONFIG_SPL_TEXT_BASE) -d $ $@
+$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)u-boot-spl.bin
+ $(OBJTREE)/tools/mkimage -T socfpgaimage -d $ $@
+
ifneq ($(CONFIG_IMX_CONFIG),)
$(OBJTREE)/SPL:$(obj)u-boot-spl.bin
$(OBJTREE)/tools/mkimage -n $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T
imximage \
@@ -154,6 +158,10 @@ endif
ALL-y += $(obj)u-boot-spl.bin
+ifdef CONFIG_SOCFPGA
+ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin
+endif
+
ifdef CONFIG_SAMSUNG
ALL-y += $(obj)$(BOARD)-spl.bin
endif
diff --git a/tools/Makefile b/tools/Makefile
index 686840a..52f4bfc 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -95,6 +95,7 @@ NOPED_OBJ_FILES-y += kwbimage.o
NOPED_OBJ_FILES-y += pblimage.o
NOPED_OBJ_FILES-y += imximage.o
NOPED_OBJ_FILES-y += omapimage.o
+NOPED_OBJ_FILES-y += socfpgaimage.o
NOPED_OBJ_FILES-y += mkenvimage.o
NOPED_OBJ_FILES-y += mkimage.o
OBJ_FILES-$(CONFIG_SMDK5250) += mkexynosspl.o
@@ -214,6 +215,7 @@ $(obj)mkimage$(SFX):$(obj)aisimage.o \
$(obj)mkimage.o \
$(obj)os_support.o \
$(obj)omapimage.o \
+ $(obj)socfpgaimage.o \
$(obj)sha1.o \
$(obj)ublimage.o \
$(LIBFDT_OBJS)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index e43b09f..87bacc0 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -167,6 +167,8 @@ main (int argc, char **argv)
init_ubl_image_type();
/* Init Davinci AIS support */
init_ais_image_type();
+ /* Init Altera SOCFPGA image generation/list support */
+ init_socfpga_image_type();
params.cmdname = *argv;
params.addr = params.ep = 0;
diff --git a/tools/mkimage.h b/tools/mkimage.h
index ea45f5c..eda4832 100644
--- a/tools/mkimage.h
+++ b/tools/mkimage.h
@@ -157,5 +157,6 @@ void init_default_image_type (void);
void init_fit_image_type (void);
void init_ubl_image_type(void);
void init_omap_image_type(void);
+void init_socfpga_image_type(void);
#endif /* _MKIIMAGE_H_ */
diff --git a/tools/socfpgaimage.c b/tools/socfpgaimage.c
new file mode 100644
index 000..9944c78
--- /dev/null
+++ b/tools/socfpgaimage.c
@@ -0,0 +1,348 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * Use as you see fit.
+ *
+ * Reference doc http://www.altera.com.cn/literature/hb/cyclone-v/cv_5400A.pdf
+ * Note this doc is not entirely accurate.
+ *
+ * Header is a structure of the following format.
+ * this is positioned at 0x40.
+ *
+ * Endian is LSB.
+ *
+ * Offset Length Usage
+ * ---
+ * 04 Validation word 0x31305341
+ * 41 Version (whatever, zero is fine
[U-Boot] Questions on adding a new type to mkimage
I am in the throes of extending mkimage to add socfpga support. This is my first time in mkimage, so please forgive me being on a learning curve. It seems that the most normal path for mkimage signers is to append some sort of header to the front of the image ie the flow is write header out copy image data with copy_file call set_header The socfpga preloader needs something a bit different. It does not add a header, but instead adds a tail (CRC+padding) and mashes some bytes into a known place in the image. Unfortunately the mkimage framework does not seem to provide an add tail function which is really what is needed here. The only way I can see to extend the size of the image, using the normal mkimage workflow would be to do something like this: *Provide vrec_header which adds a fake header of 64k - input_size. * Allow copy_file to then do the copy step. * I now have a 64k image which is 64k-size 0 bytes, followed by the actual input_data. * When set_header is called, shift the actual input data to where it should be, add the CRC and fix up the padding. This seems needlessly contrived to work with the framework. Or the alternative might be just to treat this as a special case Thoughts/opinions??? Thanks Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] socfpga: Add a signer that is integrated into mkimage
This tool signs a preloader (built from SPL) when CONFIG_SOCFPGA is set.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
common/image.c |1 +
include/image.h |1 +
spl/Makefile |8 ++
tools/Makefile |2 +
tools/mkimage.c |2 +
tools/mkimage.h |1 +
tools/socfpgaimage.c | 343 ++
7 files changed, 358 insertions(+)
create mode 100644 tools/socfpgaimage.c
diff --git a/common/image.c b/common/image.c
index 95498e6..1a2e107 100644
--- a/common/image.c
+++ b/common/image.c
@@ -144,6 +144,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_INVALID,NULL, Invalid Image, },
{ IH_TYPE_MULTI, multi, Multi-File Image, },
{ IH_TYPE_OMAPIMAGE, omapimage, TI OMAP SPL With GP CH,},
+ { IH_TYPE_SOCFPGAIMAGE, socfpgaimage, Altera SOCFPGA
preloader,},
{ IH_TYPE_PBLIMAGE, pblimage, Freescale PBL Boot Image,},
{ IH_TYPE_RAMDISK,ramdisk,RAMDisk Image, },
{ IH_TYPE_SCRIPT, script, Script, },
diff --git a/include/image.h b/include/image.h
index f5adc50..95a0bf7 100644
--- a/include/image.h
+++ b/include/image.h
@@ -166,6 +166,7 @@
#define IH_TYPE_AISIMAGE 13 /* TI Davinci AIS Image */
#define IH_TYPE_KERNEL_NOLOAD 14 /* OS Kernel Image, can run from any
load address */
#define IH_TYPE_PBLIMAGE 15 /* Freescale PBL Boot Image */
+#define IH_TYPE_SOCFPGAIMAGE 16 /* Altera SOCFPGA Preloader Image
*/
/*
* Compression Types
diff --git a/spl/Makefile b/spl/Makefile
index c0abe3d..8f061b0 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -144,8 +144,12 @@ $(OBJTREE)/MLO:$(obj)u-boot-spl.bin
$(OBJTREE)/MLO.byteswap: $(obj)u-boot-spl.bin
$(OBJTREE)/tools/mkimage -T omapimage -n byteswap \
+
-a $(CONFIG_SPL_TEXT_BASE) -d $ $@
+$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)u-boot-spl.bin
+ $(OBJTREE)/tools/mkimage -T socfpgaimage -d $ $@
+
ifneq ($(CONFIG_IMX_CONFIG),)
$(OBJTREE)/SPL:$(obj)u-boot-spl.bin
$(OBJTREE)/tools/mkimage -n $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T
imximage \
@@ -154,6 +158,10 @@ endif
ALL-y += $(obj)u-boot-spl.bin
+ifdef CONFIG_SOCFPGA
+ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin
+endif
+
ifdef CONFIG_SAMSUNG
ALL-y += $(obj)$(BOARD)-spl.bin
endif
diff --git a/tools/Makefile b/tools/Makefile
index 686840a..52f4bfc 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -95,6 +95,7 @@ NOPED_OBJ_FILES-y += kwbimage.o
NOPED_OBJ_FILES-y += pblimage.o
NOPED_OBJ_FILES-y += imximage.o
NOPED_OBJ_FILES-y += omapimage.o
+NOPED_OBJ_FILES-y += socfpgaimage.o
NOPED_OBJ_FILES-y += mkenvimage.o
NOPED_OBJ_FILES-y += mkimage.o
OBJ_FILES-$(CONFIG_SMDK5250) += mkexynosspl.o
@@ -214,6 +215,7 @@ $(obj)mkimage$(SFX):$(obj)aisimage.o \
$(obj)mkimage.o \
$(obj)os_support.o \
$(obj)omapimage.o \
+ $(obj)socfpgaimage.o \
$(obj)sha1.o \
$(obj)ublimage.o \
$(LIBFDT_OBJS)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index e43b09f..87bacc0 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -167,6 +167,8 @@ main (int argc, char **argv)
init_ubl_image_type();
/* Init Davinci AIS support */
init_ais_image_type();
+ /* Init Altera SOCFPGA image generation/list support */
+ init_socfpga_image_type();
params.cmdname = *argv;
params.addr = params.ep = 0;
diff --git a/tools/mkimage.h b/tools/mkimage.h
index ea45f5c..eda4832 100644
--- a/tools/mkimage.h
+++ b/tools/mkimage.h
@@ -157,5 +157,6 @@ void init_default_image_type (void);
void init_fit_image_type (void);
void init_ubl_image_type(void);
void init_omap_image_type(void);
+void init_socfpga_image_type(void);
#endif /* _MKIIMAGE_H_ */
diff --git a/tools/socfpgaimage.c b/tools/socfpgaimage.c
new file mode 100644
index 000..92abd93
--- /dev/null
+++ b/tools/socfpgaimage.c
@@ -0,0 +1,343 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * Use as you see fit.
+ *
+ * Reference doc http://www.altera.com.cn/literature/hb/cyclone-v/cv_5400A.pdf
+ * Note this doc is not entirely accurate.
+ *
+ * Header is a structure of the following format.
+ * this is positioned at 0x40.
+ *
+ * Endian is LSB.
+ *
+ * Offset Length Usage
+ * ---
+ * 04 Validation word 0x31305341
+ * 41 Version (whatever, zero is fine)
+ * 51 Flags (unused, zero is fine)
+ * 62 Length (in units of u32, including the end checksum).
+ * 82 Zero
+ * 0x0A2 Checksum over the heder. NB Not CRC32
+ *
+ * At the end of the code we have a 32-bit CRC checksum
[U-Boot] [PATCH] socfpga: Add a signer that is integrated into mkimage
This one passes checkpatch too :-)
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
common/image.c |1 +
include/image.h |1 +
spl/Makefile |8 ++
tools/Makefile |2 +
tools/mkimage.c |2 +
tools/mkimage.h |1 +
tools/socfpgaimage.c | 348 ++
7 files changed, 363 insertions(+)
create mode 100644 tools/socfpgaimage.c
diff --git a/common/image.c b/common/image.c
index 95498e6..1a2e107 100644
--- a/common/image.c
+++ b/common/image.c
@@ -144,6 +144,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_INVALID,NULL, Invalid Image, },
{ IH_TYPE_MULTI, multi, Multi-File Image, },
{ IH_TYPE_OMAPIMAGE, omapimage, TI OMAP SPL With GP CH,},
+ { IH_TYPE_SOCFPGAIMAGE, socfpgaimage, Altera SOCFPGA
preloader,},
{ IH_TYPE_PBLIMAGE, pblimage, Freescale PBL Boot Image,},
{ IH_TYPE_RAMDISK,ramdisk,RAMDisk Image, },
{ IH_TYPE_SCRIPT, script, Script, },
diff --git a/include/image.h b/include/image.h
index f5adc50..95a0bf7 100644
--- a/include/image.h
+++ b/include/image.h
@@ -166,6 +166,7 @@
#define IH_TYPE_AISIMAGE 13 /* TI Davinci AIS Image */
#define IH_TYPE_KERNEL_NOLOAD 14 /* OS Kernel Image, can run from any
load address */
#define IH_TYPE_PBLIMAGE 15 /* Freescale PBL Boot Image */
+#define IH_TYPE_SOCFPGAIMAGE 16 /* Altera SOCFPGA Preloader Image
*/
/*
* Compression Types
diff --git a/spl/Makefile b/spl/Makefile
index c0abe3d..8f061b0 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -144,8 +144,12 @@ $(OBJTREE)/MLO:$(obj)u-boot-spl.bin
$(OBJTREE)/MLO.byteswap: $(obj)u-boot-spl.bin
$(OBJTREE)/tools/mkimage -T omapimage -n byteswap \
+
-a $(CONFIG_SPL_TEXT_BASE) -d $ $@
+$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)u-boot-spl.bin
+ $(OBJTREE)/tools/mkimage -T socfpgaimage -d $ $@
+
ifneq ($(CONFIG_IMX_CONFIG),)
$(OBJTREE)/SPL:$(obj)u-boot-spl.bin
$(OBJTREE)/tools/mkimage -n $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T
imximage \
@@ -154,6 +158,10 @@ endif
ALL-y += $(obj)u-boot-spl.bin
+ifdef CONFIG_SOCFPGA
+ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin
+endif
+
ifdef CONFIG_SAMSUNG
ALL-y += $(obj)$(BOARD)-spl.bin
endif
diff --git a/tools/Makefile b/tools/Makefile
index 686840a..52f4bfc 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -95,6 +95,7 @@ NOPED_OBJ_FILES-y += kwbimage.o
NOPED_OBJ_FILES-y += pblimage.o
NOPED_OBJ_FILES-y += imximage.o
NOPED_OBJ_FILES-y += omapimage.o
+NOPED_OBJ_FILES-y += socfpgaimage.o
NOPED_OBJ_FILES-y += mkenvimage.o
NOPED_OBJ_FILES-y += mkimage.o
OBJ_FILES-$(CONFIG_SMDK5250) += mkexynosspl.o
@@ -214,6 +215,7 @@ $(obj)mkimage$(SFX):$(obj)aisimage.o \
$(obj)mkimage.o \
$(obj)os_support.o \
$(obj)omapimage.o \
+ $(obj)socfpgaimage.o \
$(obj)sha1.o \
$(obj)ublimage.o \
$(LIBFDT_OBJS)
diff --git a/tools/mkimage.c b/tools/mkimage.c
index e43b09f..87bacc0 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -167,6 +167,8 @@ main (int argc, char **argv)
init_ubl_image_type();
/* Init Davinci AIS support */
init_ais_image_type();
+ /* Init Altera SOCFPGA image generation/list support */
+ init_socfpga_image_type();
params.cmdname = *argv;
params.addr = params.ep = 0;
diff --git a/tools/mkimage.h b/tools/mkimage.h
index ea45f5c..eda4832 100644
--- a/tools/mkimage.h
+++ b/tools/mkimage.h
@@ -157,5 +157,6 @@ void init_default_image_type (void);
void init_fit_image_type (void);
void init_ubl_image_type(void);
void init_omap_image_type(void);
+void init_socfpga_image_type(void);
#endif /* _MKIIMAGE_H_ */
diff --git a/tools/socfpgaimage.c b/tools/socfpgaimage.c
new file mode 100644
index 000..9944c78
--- /dev/null
+++ b/tools/socfpgaimage.c
@@ -0,0 +1,348 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * Use as you see fit.
+ *
+ * Reference doc http://www.altera.com.cn/literature/hb/cyclone-v/cv_5400A.pdf
+ * Note this doc is not entirely accurate.
+ *
+ * Header is a structure of the following format.
+ * this is positioned at 0x40.
+ *
+ * Endian is LSB.
+ *
+ * Offset Length Usage
+ * ---
+ * 04 Validation word 0x31305341
+ * 41 Version (whatever, zero is fine)
+ * 51 Flags (unused, zero is fine)
+ * 62 Length (in units of u32, including the end checksum).
+ * 82 Zero
+ * 0x0A2 Checksum over the heder. NB Not CRC32
+ *
+ * At the end of the code we have a 32-bit CRC checksum over whole binary
+ * excluding
[U-Boot] [PATCH] socfpga: Add a signing tool that automatically signs the preloader.
No need to use the altera tool any more...
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
spl/Makefile |8 ++
tools/Makefile |9 +-
tools/socfpga-signer.c | 294
3 files changed, 310 insertions(+), 1 deletion(-)
create mode 100644 tools/socfpga-signer.c
diff --git a/spl/Makefile b/spl/Makefile
index c0abe3d..086b1e6 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -144,8 +144,12 @@ $(OBJTREE)/MLO:$(obj)u-boot-spl.bin
$(OBJTREE)/MLO.byteswap: $(obj)u-boot-spl.bin
$(OBJTREE)/tools/mkimage -T omapimage -n byteswap \
+
-a $(CONFIG_SPL_TEXT_BASE) -d $ $@
+$(OBJTREE)/socfpga-signed-preloader.bin: $(obj)u-boot-spl.bin
+ $(OBJTREE)/tools/socfpga-signer -i $ -o $@ -p
+
ifneq ($(CONFIG_IMX_CONFIG),)
$(OBJTREE)/SPL:$(obj)u-boot-spl.bin
$(OBJTREE)/tools/mkimage -n $(SRCTREE)/$(CONFIG_IMX_CONFIG) -T
imximage \
@@ -154,6 +158,10 @@ endif
ALL-y += $(obj)u-boot-spl.bin
+ifdef CONFIG_SOCFPGA
+ALL-y += $(OBJTREE)/socfpga-signed-preloader.bin
+endif
+
ifdef CONFIG_SAMSUNG
ALL-y += $(obj)$(BOARD)-spl.bin
endif
diff --git a/tools/Makefile b/tools/Makefile
index 686840a..1ed2281 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -73,7 +73,8 @@ BIN_FILES-$(CONFIG_MX28) += mxsboot$(SFX)
BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX)
BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX)
BIN_FILES-$(CONFIG_KIRKWOOD) += kwboot$(SFX)
-
+BIN_FILES-$(CONFIG_SOCFPGA) += socfpga-signer$(SFX)
+
# Source files which exist outside the tools directory
EXT_OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += common/env_embedded.o
EXT_OBJ_FILES-y += common/image.o
@@ -104,6 +105,7 @@ NOPED_OBJ_FILES-y += os_support.o
OBJ_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1.o
NOPED_OBJ_FILES-y += ublimage.o
OBJ_FILES-$(CONFIG_KIRKWOOD) += kwboot.o
+OBJ_FILES-$(CONFIG_SOCFPGA) += socfpga-signer.o
# Don't build by default
#ifeq ($(ARCH),ppc)
@@ -243,6 +245,11 @@ $(obj)kwboot$(SFX): $(obj)kwboot.o
$(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
$(HOSTSTRIP) $@
+
+$(obj)socfpga-signer$(SFX): $(obj)socfpga-signer.o
+ $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^
+ $(HOSTSTRIP) $@
+
# Some of the tool objects need to be accessed from outside the tools directory
$(obj)%.o: $(SRCTREE)/common/%.c
$(HOSTCC) -g $(HOSTCFLAGS_NOPED) -c -o $@ $
diff --git a/tools/socfpga-signer.c b/tools/socfpga-signer.c
new file mode 100644
index 000..4861066
--- /dev/null
+++ b/tools/socfpga-signer.c
@@ -0,0 +1,294 @@
+
+/* Reference doc http://www.altera.com.cn/literature/hb/cyclone-v/cv_5400A.pdf
+*
+ * Header is a structure of the following format.
+ * this is positioned at 0x40.
+ *
+ * Endian is LSB.
+ *
+ * Offset Length Usage
+ * ---
+ * 04 Validation word 0x31305341
+ * 41 Version (whatever, zero is fine)
+ * 51 Flags (unused, zero is fine)
+ * 62 Length (in units of u32, including the end checksum).
+ * 82 Zero
+ * 0x0A2 Checksum over the heder. NB Not CRC32
+ *
+ * At the end of the code we have a 32-bit CRC checksum over whole binary
+ * excluding the CRC. This uses the CRC32 calc out of the well known Apple
+ * crc32.c code.
+ *
+ */
+
+#include stdio.h
+#include fcntl.h
+#include stdint.h
+#include unistd.h
+#include stdlib.h
+#include string.h
+
+
+#define HEADER_OFFSET 0x40
+#define HEADER_SIZE0x0C
+#define BUFFER_SIZE(0x1)
+#define MAX_IMAGE_SIZE 0xFF00
+#define VALIDATION_WORD0x31305341
+#define FILL_BYTE 0x00
+
+
+static uint16_t hdr_checksum(uint8_t *buf, int len)
+{
+ uint16_t ret = 0;
+ int i;
+
+ for(i = 0; i len; i++) {
+ ret += (((uint16_t) *buf) 0xff);
+ buf++;
+ }
+ return ret;
+}
+
+
+static void le16(uint8_t *buf, uint16_t v)
+{
+ buf[0] = (v 0) 0xff;
+ buf[1] = (v 8) 0xff;
+}
+
+static void le32(uint8_t *buf, uint32_t v)
+{
+ buf[0] = (v 0) 0xff;
+ buf[1] = (v 8) 0xff;
+ buf[2] = (v 16) 0xff;
+ buf[3] = (v 24) 0xff;
+}
+
+static int align4(int v)
+{
+ return ((v + 3) / 4) * 4;
+}
+
+static void build_header(uint8_t *buf,
+ uint8_t version,
+ uint8_t flags,
+ uint16_t length_bytes)
+{
+ memset(buf, 0, HEADER_SIZE);
+
+ le32(buf + 0, VALIDATION_WORD);
+ buf[4] = version;
+ buf[5] = flags;
+ le16(buf + 6, length_bytes/4);
+ le16(buf + 10, hdr_checksum(buf, 10));
+}
+
+static uint32_t crc_table[256] = {
+
+ 0x, 0x04c11db7, 0x09823b6e, 0x0d4326d9,
+ 0x130476dc, 0x17c56b6b, 0x1a864db2, 0x1e475005,
+ 0x2608edb8, 0x22c9f00f, 0x2f8ad6d6, 0x2b4bcb61,
+ 0x350c9b64, 0x31cd86d3, 0x3c8ea00a, 0x384fbdbd,
+ 0x4c11db70, 0x48d0c6c7, 0x4593e01e, 0x4152fda9,
+ 0x5f15adac
Re: [U-Boot] [PATCH] socfpga: Add a signing tool that automatically signs the preloader.
Hi Tom On Thursday 20 February 2014 13:32:37 Tom Rini wrote: On Thu, Feb 20, 2014 at 12:01:40PM +1300, Charles Manning wrote: No need to use the altera tool any more... Signed-off-by: Charles Manning cdhmann...@gmail.com [snip] + //crcval = crc_calc ((uint32_t *)buf, len/4); + printf(crc %x\n, crcval); Debug stuff left in? +static char *out_filename = ; + + + +static void bad_exit(const char *str) Extra spaces. Thanks for the feedback. I will fix those and resubmit. Finally, we can't do this as an extension of mkimage? We do other headers with that already, does it really not fit that model? Thanks! I looked at doing a mkimage integration, but is this really the way to go in all cases? The signed image does not really apply a header as such. It mashes in a header at position 0x40 and then appends a checksum at the end, then pads the file out to 64k. The final file is: * 64 bytes of executable (interrupt vector table) * header * more code *crc32 *padding with 0x00 to 64k. Adding it to mkimage and cooking the binary was not too hard. I could not figure out how to extend the size of the buffer and pad it out to 64k. I'm sure I could figure that out... it's just software.. If it really **must** be part of mkimage, I'll do that. If so, what mkimage operation need to be supported? Changing type makes no sense (apart from signing a binary). There are no uboot-format header/marker or anything. Verification probably makes sense, but that's it. Thoughts?? -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] yaffs2: Remove block number check from summary verification
The summary already has other verification. This one is not needed.
The check caused summaries to be ignored if they were not on the
numbered block. This caused problems when a summary was embedded in an
image and the image is written to a flash with bad blocks.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
fs/yaffs2/yaffs_summary.c |1 -
1 file changed, 1 deletion(-)
diff --git a/fs/yaffs2/yaffs_summary.c b/fs/yaffs2/yaffs_summary.c
index 46e42f6..e9e1b5d 100644
--- a/fs/yaffs2/yaffs_summary.c
+++ b/fs/yaffs2/yaffs_summary.c
@@ -232,7 +232,6 @@ int yaffs_summary_read(struct yaffs_dev *dev,
if (result == YAFFS_OK) {
/* Verify header */
if (hdr.version != YAFFS_SUMMARY_VERSION ||
- hdr.block != blk ||
hdr.seq != bi-seq_number ||
hdr.sum != yaffs_summary_sum(dev))
result = YAFFS_FAIL;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
I have had to deal with this a bit so I'll give my 2c. Under the GPL2, the company only has to provide source, or make an offer to do so, to customers buying the product containing the GPL code. The flip side to this is that the teeth in the GPL come from copyright law and the only person who can force anything is the copyright holder. So that really means: 1) If you buy a product containing GPL code, but the company does not supply the code, then - in general - you cannot force the company to supply you with code. You need to get the collaboration of an infringed copyright holder to force the issue. 2) If you are the copyright holder of some GPL code, you cannot - in general - demand that the company supply you with code. You have to either buy a product or get the collaboration of someone that has bought a product. In the cases I have been involved with (as an infringed copyright holder), the lawyers bought a product on our behalf and made requests for code and then when none was forthcoming they pressed the case. It really isn't as easy as it should be... On Fri, Mar 8, 2013 at 4:28 AM, Wolfgang Denk w...@denx.de wrote: Dear Pavel, In message 20130307091729.GA24807@xo-6d-61-c0.localdomain you wrote: So did you contact the vendor and ask for the source code? And did they answer, and what exactly? Technically... he should have got source code or written offer for it with the device. So they are already breaking GPL. Of course you are correct. But there is a wide ange of possibilies; some vendors just don't know what they are supposed to do, and are appreciative for a friendly hint. Of course there are also those where you need a fully charged blaster - but in my experience these are very few. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The evolution of the human race will not be accomplished in the ten thousand years of tame animals, but in the million years of wild animals, because man is and will always be a wild animal. - Charles Galton Darwin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Possible GPL violation
On Fri, Mar 8, 2013 at 11:23 AM, Wolfgang Denk w...@denx.de wrote: Dear Charles, In message CAE21AQoqC8_sJarKmSAa2f-3=3YDPL9gK7rxL7pXUx3aa=n...@mail.gmail.com you wrote: 1) If you buy a product containing GPL code, but the company does not supply the code, then - in general - you cannot force the company to supply you with code. You need to get the collaboration of an infringed copyright holder to force the issue. Just for the record: I'm always willing to help out as such. One of the problems with pursuing these actions is that it can be somewhat hard to prove that you have contributed materially to claim copyright over some code. There are some places where this is clear (eg. much of Wolfgang's u-boot work) or in my case Yaffs (where I have written all the core yaffs code). In much of open source though, there have been many major contributors and even more minor contributors and it can be hard to claim to be a legitimate copyright holder. In theory, I guess you could claim copyright on a three line patch, but the harsh reality of lawyer land would probably want to see something far more substantial. #disclaimer I'm not a lawyer -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] YAFFS2: Fix compiler errors preventing successful build
On Wednesday 15 August 2012 08:16:22 Marek Vasut wrote: Signed-off-by: Marek Vasut ma...@denx.de Cc: Charles Manning cdhmann...@gmail.com Cc: Wolfgang Denk w...@denx.de While I appreciate this, I would prefer the use the patch I submitted today which also gets rid of the yaffs hweight code too. -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] u-boot yaffs2: Fix compilation warnings
Also remove yaffs_hweight and use the hweight in u-boot.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
fs/yaffs2/Makefile|2 +-
fs/yaffs2/stdio.h |1 -
fs/yaffs2/stdlib.h|1 -
fs/yaffs2/string.h|4 ---
fs/yaffs2/yaffs_hweight.c | 52 -
fs/yaffs2/yaffs_hweight.h | 24
fs/yaffs2/yaffs_mtdif2.c |3 --
fs/yaffs2/yaffsfs.c |2 -
fs/yaffs2/ydirectenv.h| 16 +++--
fs/yaffs2/yportenv.h |1 +
10 files changed, 6 insertions(+), 100 deletions(-)
delete mode 100644 fs/yaffs2/stdio.h
delete mode 100644 fs/yaffs2/stdlib.h
delete mode 100644 fs/yaffs2/string.h
delete mode 100644 fs/yaffs2/yaffs_hweight.c
delete mode 100644 fs/yaffs2/yaffs_hweight.h
diff --git a/fs/yaffs2/Makefile b/fs/yaffs2/Makefile
index 31c12af..9b29d22 100644
--- a/fs/yaffs2/Makefile
+++ b/fs/yaffs2/Makefile
@@ -23,7 +23,7 @@ LIB = $(obj)libyaffs2.o
COBJS-$(CONFIG_YAFFS2) := \
yaffs_allocator.o yaffs_attribs.o yaffs_bitmap.o yaffs_uboot_glue.o\
yaffs_checkptrw.o yaffs_ecc.o yaffs_error.o \
- yaffsfs.o yaffs_guts.o yaffs_hweight.o yaffs_nameval.o yaffs_nand.o\
+ yaffsfs.o yaffs_guts.o yaffs_nameval.o yaffs_nand.o\
yaffs_packedtags1.o yaffs_packedtags2.o yaffs_qsort.o \
yaffs_summary.o yaffs_tagscompat.o yaffs_verify.o yaffs_yaffs1.o \
yaffs_yaffs2.o yaffs_mtdif.o yaffs_mtdif2.o
diff --git a/fs/yaffs2/stdio.h b/fs/yaffs2/stdio.h
deleted file mode 100644
index 9f379d7..000
--- a/fs/yaffs2/stdio.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Dummy header for u-boot */
diff --git a/fs/yaffs2/stdlib.h b/fs/yaffs2/stdlib.h
deleted file mode 100644
index 9f379d7..000
--- a/fs/yaffs2/stdlib.h
+++ /dev/null
@@ -1 +0,0 @@
-/* Dummy header for u-boot */
diff --git a/fs/yaffs2/string.h b/fs/yaffs2/string.h
deleted file mode 100644
index 6501fa7..000
--- a/fs/yaffs2/string.h
+++ /dev/null
@@ -1,4 +0,0 @@
-#include linux/stddef.h
-#include linux/string.h
-#include linux/stat.h
-#include common.h
diff --git a/fs/yaffs2/yaffs_hweight.c b/fs/yaffs2/yaffs_hweight.c
deleted file mode 100644
index d96773e..000
--- a/fs/yaffs2/yaffs_hweight.c
+++ /dev/null
@@ -1,52 +0,0 @@
-/*
- * YAFFS: Yet Another Flash File System. A NAND-flash specific file system.
- *
- * Copyright (C) 2002-2011 Aleph One Ltd.
- * for Toby Churchill Ltd and Brightstar Engineering
- *
- * Created by Charles Manning char...@aleph1.co.uk
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-/* These functions have been renamed to hweightxx to match the
- * equivaqlent functions in the Linux kernel.
- */
-
-#include yaffs_hweight.h
-
-static const char yaffs_count_bits_table[256] = {
- 0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4,
- 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
- 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
- 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
- 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
- 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
- 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
- 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
- 1, 2, 2, 3, 2, 3, 3, 4, 2, 3, 3, 4, 3, 4, 4, 5,
- 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
- 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
- 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
- 2, 3, 3, 4, 3, 4, 4, 5, 3, 4, 4, 5, 4, 5, 5, 6,
- 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
- 3, 4, 4, 5, 4, 5, 5, 6, 4, 5, 5, 6, 5, 6, 6, 7,
- 4, 5, 5, 6, 5, 6, 6, 7, 5, 6, 6, 7, 6, 7, 7, 8
-};
-
-int yaffs_hweight8(u8 x)
-{
- int ret_val;
- ret_val = yaffs_count_bits_table[x];
- return ret_val;
-}
-
-int yaffs_hweight32(u32 x)
-{
- return yaffs_hweight8(x 0xff) +
- yaffs_hweight8((x 8) 0xff) +
- yaffs_hweight8((x 16) 0xff) +
- yaffs_hweight8((x 24) 0xff);
-}
diff --git a/fs/yaffs2/yaffs_hweight.h b/fs/yaffs2/yaffs_hweight.h
deleted file mode 100644
index 3f7c6c3..000
--- a/fs/yaffs2/yaffs_hweight.h
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * YAFFS: Yet another Flash File System . A NAND-flash specific file system.
- *
- * Copyright (C) 2002-2011 Aleph One Ltd.
- * for Toby Churchill Ltd and Brightstar Engineering
- *
- * Created by Charles Manning char...@aleph1.co.uk
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU Lesser General Public License version 2.1 as
- * published by the Free Software Foundation.
- *
- * Note: Only YAFFS headers are LGPL, YAFFS C code is covered by GPL.
- */
-
-#ifndef __YAFFS_HWEIGHT_H__
-#define __YAFFS_HWEIGHT_H__
-
-#include yportenv.h
-
-int yaffs_hweight8(u8 x);
-int yaffs_hweight32(u32 x
[U-Boot] Why no cache flushing in do_go_exec()
Hi All I'm helping to work through an issue where some code is loaded into RAM and go xxx is issued to then launch the code. Sometimes this works and sometimes it does not, which makes me suspect that there might be a cache flushing issue. I looked at do_exec_go() and it does not flush caches before jumping to the entry point. Is there a good reason for this or is it an oversight? Would it help to add a call to cleanup_before_linux() to do_go_exec() to make sure the right thing is happening? Thanks Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AM3703 Overo SPL/u-boot booting woes
Hello All I am trying to use SPL to boot an AM3703-based overo board from NAND. SPL runs and seems to load u-boot correctly but u-boot does not run correctly. When I use the same SPL and u-boot from MMC, everything boots fine. I have modified SPL slightly to add some extra debugging. Any ideas what's wrong? Boot from MMC looks like: board_init_f() spl:board_init_r() boot device - 6 OMAP SD/MMC: 0 reading u-boot.img spl: payload image: U-Boot 2011.12-00475-g92216bd-di load addr: 0x80007fc0 size: 25822 reading u-boot.img Jumping to U-Boot image entry point: 0x80008000 pointers to parameters: 0x8708 First few instructions 80008000:ea14 80008004:e59ff014 80008008:e59ff014 8000800c:e59ff014 80008010:e59ff014 80008014:e59ff014 80008018:e59ff014 8000801c:e59ff014 80008020:80008200 80008024:80008260 U-Boot 2011.12-00475-g92216bd-dirty (May 29 2012 - 11:17:15) etc... all the way to Linux. Boot from NAND looks like: board_init_f() spl:board_init_r() boot device - 2 spl_nand_load_image() Load header: 8,800,80008000 spl: payload image: U-Boot 2011.12-00475-e92216bd-di load addr: 0x80007fc0 size: 25822 Call nand_spl_load_image(8,3f0f4,80007fc0) spl_nand_load_image() returning... Jumping to U-Boot image entry point: 0x80008000 pointers to parameters: 0x8708 First few instructions 80008000:ea14 80008004:e59ff014 80008008:e59ff014 8000800c:e59ff014 80008010:e59ff014 80008014:e59ff014 80008018:e59ff014 8000801c:e59ff014 80008020:80008200 80008024:80008260 and then nothing. Thanks -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] What is the correct way to configure SPL options?
Hi All My understanding of the way SPL is intended to be configured is: (a) You have one config file for both SPL and u-boot. (b) SPL features are selected via SPL-specific options. I have a need to build SPL with MMC/FAT support, but I don't want u-boot to have MMC/FAT support. I do however see that quite a few SPL feature selections don't use SPL config definitions though which would seem to violate (b) above. eg.drivers/mmc/Makefile contains COBJS-$(CONFIG_GENERIC_MMC) += mmc.o It seems to me there are three ways to address this: A) Change all those Makefiles to something like: ifdef CONFIG_SPL_BUILD COBJS-$(CONFIG_SPL_MMC_SUPPORT) += mmc.o else COBJS-$(CONFIG_GENERIC_MMC) += mmc.o endif B) Modifying the config file with something like #ifdef CONFIG_SPL_BUILD #define CONFIG_GENERIC_MMC ... #endif C) Separate config files. One for SPL and the other for u-boot. Which is the best way to do this? Thanks Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] What is the correct way to configure SPL options?
On Friday 18 May 2012 08:58:06 Scott Wood wrote: On 05/17/2012 03:47 PM, Tom Rini wrote: On 05/17/2012 01:22 PM, Scott Wood wrote: We had problems with (B) regarding TEXT_BASE -- the makefile versions of the config symbols will only be generated once. CONFIG_SKIP_LOW_LEVEL_INIT doesn't seem to be used from makefiles. I still think (C) is the way to go. But since we have CONFIG_SYS_SPL_TEXT_BASE now, (B) is how we do it normally, yes? That was more of an instance of OK, I give in, we'll do it the simple but ugly way if it's just this one thing than the normal way. To me it looks like the ugliness comes from an unclear policy resulting in SPL configs being handled in two different ways. IMHO, the policy can be simplified and rationalised in two ways: A) Recognise name each config option that might vary with an SPL and regular variant. That will just lead to hell in the Makefiles. - non inclusive or- C) Each binary has a different config and is built separately. Then there is no need for multiple CONFIGs for the same feature. I have found (C) to work fine for building multiple variants (using a much older version of u-boot). For example, I build two stripped u-boots to run a manufacturing loader process. I thus build at least 3 different u-boots for the same board. Each has a different config and is built separately. I guess common stuff can be rationalised: foo-common.h foo-uboot.h #include foo-common.h ... foo-spl.h #include foo-common.h ... But that really makes for config file proliferation. Still, that would seem more manageable. -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add gc-section support for ARM
On Tuesday 15 May 2012 17:12:05 Mike Frysinger wrote: On Monday 14 May 2012 17:01:30 Charles Manning wrote: On Monday 14 May 2012 17:15:50 Mike Frysinger wrote: On Wednesday 02 May 2012 21:37:51 Charles Manning wrote: Seems odd that this hasn't been done yet. Shaves 5k off an omap overo build. my understanding is that it doesn't work for some It won't work for people that don't set up their lds properly. current u-boot policy is to not introduce changes that knowingly break other platforms. so if you want to update the common arm config.mk, you need to at least compile test all arm boards. Doesn't that makes it an impossible task? Not having all the boards makes it pretty hard to test them all. +PLATFORM_RELFLAGS += -ffunction-sections where's the -fdata-sections ? I tried that once before and could not get that to work with u-boot. I figure doing just the function sections is better than nothing. so even your lds isn't setup properly ? :P Correct. I was aiming to achieve a certain size. Once I achieved that I stopped fiddling. The problem was probably in the relocation stuff. other arches are using both fine, so it isn't a problem of common code. I might be incorrect, but I have noticed what appears to be some differences between different versions of binutils. -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add gc-section support for ARM
On Wednesday 16 May 2012 10:25:26 Wolfgang Denk wrote: Dear Charles, In message 201205161007.59560.mannin...@actrix.gen.nz you wrote: On Tuesday 15 May 2012 17:12:05 Mike Frysinger wrote: ... current u-boot policy is to not introduce changes that knowingly break other platforms. so if you want to update the common arm config.mk, you need to at least compile test all arm boards. - Doesn't that makes it an impossible task? Not having all the boards makes it pretty hard to test them all. A compile test does not require any actual hardware. Does the patch fail I submitted fail any compile tests? AFAIK, it compiles but the resulting binary might just be rubbish on some boards. It worked fine on my overo board without any changes to the overo lds. I have just verified that it builds on overo mx51evk davinci_sonata If there is an expectation to build every possible config is there a script that will do that? other arches are using both fine, so it isn't a problem of common code. I might be incorrect, but I have noticed what appears to be some differences between different versions of binutils. Please be more specific. The same different versions of binutils appear to work fine on other architectures ? That was based on some observations a year or two ago. I don't know if the problem has now gone away and have no way of reproducing it. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add gc-section support for ARM
On Monday 14 May 2012 17:15:50 Mike Frysinger wrote: On Wednesday 02 May 2012 21:37:51 Charles Manning wrote: Seems odd that this hasn't been done yet. Shaves 5k off an omap overo build. my understanding is that it doesn't work for some It won't work for people that don't set up their lds properly. +PLATFORM_RELFLAGS += -ffunction-sections where's the -fdata-sections ? I tried that once before and could not get that to work with u-boot. I figure doing just the function sections is better than nothing. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add gc-section support for ARM
Seems odd that this hasn't been done yet. Shaves 5k off an omap overo build. Signed-off-by: Charles Manning cdhmann...@gmail.com --- arch/arm/config.mk |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 45f9dca..73e0cce 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -55,6 +55,10 @@ PF_CPPFLAGS_ABI := $(call cc-option,\ ) PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARM) $(PF_CPPFLAGS_ABI) +PLATFORM_RELFLAGS += -ffunction-sections + +LDFLAGS_FINAL += --gc-sections + # For EABI, make sure to provide raise() ifneq (,$(findstring -mabi=aapcs-linux,$(PLATFORM_CPPFLAGS))) # This file is parsed many times, so the string may get added multiple -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Replace yaffs2 with new version
On Monday 30 April 2012 16:40:16 Wolfgang Denk wrote: Dear Charles Manning, In message 1335739336-2942-1-git-send-email-cdhmann...@gmail.com you wrote: This patch set replaces fs/yaffs2 with a new version. This new version is faster and also adds the ability to dynamically add yaffs2 mount points which makes configuration far simpler. Sorry, but it doesn't work like this. You cannot remove all code in one patch and re-add it in another, as this will break bisectability. This must be done in a single commit. Also, please run your new code through checkpatch, and clean it up before resubmitting. Current status is: Ok, so one huge patch that passes (or close) checkpatch will be acceptable? I have spent the last couple of days cleaning things up so I hope it will be. I am having problems with the yaffs git server so when that is sorted, I'll make another u-boot patch and send that. -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] Replace yaffs2 with new version
This patch set replaces fs/yaffs2 with a new version. This new version is faster and also adds the ability to dynamically add yaffs2 mount points which makes configuration far simpler. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Integrate latest yaffs2
On Friday 27 April 2012 00:25:55 Wolfgang Denk wrote: Dear Charles Manning, In message 201204261028.44543.mannin...@actrix.gen.nz you wrote: yaffs went through a large reformat a while ago meaning that the current code does not diff well against the old code. Future changes shuld be a lot easier to handle with direct patching. yaffs changes typically don't go through the yaffs list since people with direct git checkin access do 95-99% of the changes. U-Boot has a different policy. Here nothing goes into mainline that has not been posted on the mailing list before. There are several reasons for this: 1) We want to make sure that the code has actually been visible and reviewed. When pulling from a git repo, you just get a drop of software in unknown condition. 2) We want to make sure the review process gets recorded - we use patchwork for this purpose. So if you want to submit your code, then please post patches. There is no way around this step. I understand what you are trying to achieve but the reality is that nobody is going to read the patching of a whole file system. If you supported patches greater than 100k this would be trivial to do, but I have a single file greater than that. Perhaps it is time to accept larger patches more consistent with the lkml and friends. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Yaffs] yaffs2 u-boot patching support
On Tuesday 24 April 2012 03:33:35 Stefano Babic wrote: On 22/04/2012 22:23, Charles Manning wrote: On Friday 20 April 2012 09:40:50 Tom Rini wrote: On Mon, Apr 16, 2012 at 04:32:07PM +1200, Charles Manning wrote: Hello ubooters and yaffsers Hi Charles, I was commissioned to refresh yaffs2 in u-boot and add a mechanism to support dynamic yaffs partition set up (way simpler than screwing around with mtd part) and manual configuration. Rather than do this as a once off, I set this scripting up so that this can be done at any time (painlessly I hope) to bring in the fresh code (as per Linux patching). Just to put this out there, if you're not submitting patches to get the code into git, should the current support in-tree be removed? I think it is worth having yaffs in the main code base, but not the old stuff. The primary reason to have a patch-in script is to allow people to refresh the yaffs they are using in a pretty painless way. Well, why do not push your patches directly to ML ? This increases surely the number of testers, and after ypur patches will be merged thare is not need for external scripts. I have sent a pull request to the list. https://github.com/cdhmanning/u-boot-yaffs2 -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Integrate latest yaffs2
On Tuesday 24 April 2012 08:58:09 you wrote: Dear Charles Manning, In message 201204231346.32195.mannin...@actrix.gen.nz you wrote: I recently sent a message to the list announcing a method for patching in the latest yaffs2. u-boot updated with the latest yaffs2 can be pulled from g...@github.com:cdhmanning/u-boot-yaffs2.git Please read http://www.denx.de/wiki/U-Boot/Patches and post proper patch(es) for review. At least one of the files exceeds the 100k patch limit. I know you'd like patches, but there are two really easy options for someone on the inside to do this: 1) Run the script off the yaffs git -or- 2) Merge from the https://github.com/cdhmanning/u-boot-yaffs2 Regards -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Integrate latest yaffs2
On Thursday 26 April 2012 10:21:37 Tom Rini wrote: On Thu, Apr 26, 2012 at 09:08:42AM +1200, Charles Manning wrote: On Tuesday 24 April 2012 08:58:09 you wrote: Dear Charles Manning, In message 201204231346.32195.mannin...@actrix.gen.nz you wrote: I recently sent a message to the list announcing a method for patching in the latest yaffs2. u-boot updated with the latest yaffs2 can be pulled from g...@github.com:cdhmanning/u-boot-yaffs2.git Please read http://www.denx.de/wiki/U-Boot/Patches and post proper patch(es) for review. At least one of the files exceeds the 100k patch limit. I know you'd like patches, but there are two really easy options for someone on the inside to do this: 1) Run the script off the yaffs git -or- 2) Merge from the https://github.com/cdhmanning/u-boot-yaffs2 So this means things have gotten really far out of sync. Would you be willing to say that in the future you'll be submitting regular well formatted and broken down patches like I assume you do in the yaffs2 tree itself so we can avoid this in the future? yaffs went through a large reformat a while ago meaning that the current code does not diff well against the old code. Future changes shuld be a lot easier to handle with direct patching. yaffs changes typically don't go through the yaffs list since people with direct git checkin access do 95-99% of the changes. -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: Integrate latest yaffs2
On Thursday 26 April 2012 10:40:51 Tom Rini wrote: On 04/25/2012 03:28 PM, Charles Manning wrote: On Thursday 26 April 2012 10:21:37 Tom Rini wrote: On Thu, Apr 26, 2012 at 09:08:42AM +1200, Charles Manning wrote: On Tuesday 24 April 2012 08:58:09 you wrote: Dear Charles Manning, In message201204231346.32195.mannin...@actrix.gen.nz you wrote: I recently sent a message to the list announcing a method for patching in the latest yaffs2. u-boot updated with the latest yaffs2 can be pulled from g...@github.com:cdhmanning/u-boot-yaffs2.git Please read http://www.denx.de/wiki/U-Boot/Patches and post proper patch(es) for review. At least one of the files exceeds the 100k patch limit. I know you'd like patches, but there are two really easy options for someone on the inside to do this: 1) Run the script off the yaffs git -or- 2) Merge from the https://github.com/cdhmanning/u-boot-yaffs2 So this means things have gotten really far out of sync. Would you be willing to say that in the future you'll be submitting regular well formatted and broken down patches like I assume you do in the yaffs2 tree itself so we can avoid this in the future? yaffs went through a large reformat a while ago meaning that the current code does not diff well against the old code. Future changes shuld be a lot easier to handle with direct patching. yaffs changes typically don't go through the yaffs list since people with direct git checkin access do 95-99% of the changes. Right, but a proper set of individual patches could be posted and reviewed in the future, yes? That makes sense to me. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Yaffs] yaffs2 u-boot patching support
On Friday 20 April 2012 09:40:50 Tom Rini wrote: On Mon, Apr 16, 2012 at 04:32:07PM +1200, Charles Manning wrote: Hello ubooters and yaffsers I was commissioned to refresh yaffs2 in u-boot and add a mechanism to support dynamic yaffs partition set up (way simpler than screwing around with mtd part) and manual configuration. Rather than do this as a once off, I set this scripting up so that this can be done at any time (painlessly I hope) to bring in the fresh code (as per Linux patching). Just to put this out there, if you're not submitting patches to get the code into git, should the current support in-tree be removed? I think it is worth having yaffs in the main code base, but not the old stuff. The primary reason to have a patch-in script is to allow people to refresh the yaffs they are using in a pretty painless way. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: Integrate latest yaffs2
Hello all I recently sent a message to the list announcing a method for patching in the latest yaffs2. u-boot updated with the latest yaffs2 can be pulled from g...@github.com:cdhmanning/u-boot-yaffs2.git -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] yaffs2 u-boot patching support
Hello ubooters and yaffsers I was commissioned to refresh yaffs2 in u-boot and add a mechanism to support dynamic yaffs partition set up (way simpler than screwing around with mtd part) and manual configuration. Rather than do this as a once off, I set this scripting up so that this can be done at any time (painlessly I hope) to bring in the fresh code (as per Linux patching). Basically... Get latest from yaffs git. cd yaffs2-dir/direct/u-boot ./patch-u-boot.sh uboot-dir Edit your u-boot config file and add #define CONFIG_YAFFS2 1 Rebuild u-boot (mrproper probably a Good Idea). Job done. OK, so how does the new dynamic partition stuff work? There are 2 new commands: ydevconfig configures a mount point partition and ydevls lists the mount points and their state So for example let us say we want a mount point called foo on NAND device 0 starting at block 55 and ending at block 999. ydevconfig foo 0 55 999 Now you want to mount it. ymount foo Access files and do stuff... yls foo yls -l foo # more info ymkdir foo/dir ... You can have multiple mountpoints in use at the same time though they are not allowed to overlap. inband tags is selected automatically if there is insufficient space in oobavail to store the tags. Have fun. Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
On Monday 19 March 2012 12:09:49 Bud Miljkovic wrote: Charles I looked at where I could set the startBlock and endBlock (btw - start_block and end_block are used in cmd_onenand.c) and I saw that in yaffscfg.c (flashDev-startBlock = 0; for yaffsVersion == 2). Is this the place do change flashDev-endBlock = nBlocks - 1; to flashDev-endBlock = N - 1, where N desired number of blocks? Yes, that's the stuff to modify. It might even make sense to add u-boot commands to set these. Also, do you have or can point me to a comprehensive YAFFS2 commands document? I have never used yaffs in u-boot myself. have a look at the commands for the yaffs code. Bud -Original Message- From: Charles Manning [mailto:mannin...@actrix.gen.nz] Sent: Thursday, 15 March 2012 6:24 a.m. To: Bud Miljkovic Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Enabling nand createbbt command On Wednesday 14 March 2012 17:00:58 Bud Miljkovic wrote: Charles That is interesting. Any clue how to configure the start and end blocks manually? Yes I do since I wrote yaffs :-). Set the statrt_block and end_block (might be startBlock and endBlock) values as needed BEFORE the mount/init happens. In a normal situation with mtd partitioning these are set to 0 and n-blocks-in-partition -1, but they can be set manually too. -- Charles Bud -Original Message- From: Charles Manning [mailto:mannin...@actrix.gen.nz] Sent: Monday, 12 March 2012 8:20 a.m. To: Bud Miljkovic Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Enabling nand createbbt command Bud Yaffs can work without mtdpart. To do that you just need to configure the start and end blocks manually instead of using the partition info to do this. On Friday 09 March 2012 13:58:48 Bud Miljkovic wrote: Thank you Scott and Fabio, You help is much appreciated. I will try to add the nand support for mx53 mainline. However, what I am trying to do is to build a u-boot that supports NAND and have YAFFS2 as well and at moment I use the mx53_ard board since this is very close to what my custom board will be. I was able to build such a version, using Freescale u-boot sources, which included nand subsystem, and yaffs commands. Then I needed to create partitions in the nand and this is where i discovered I needed the support of mtdparts command. So I, guess, I need to configure the u-boot for mtdparts support. This is where I am at. -Bud -Original Message- From: Scott Wood Sent: Friday, 9 March 2012 12:04 p.m. To: Bud Miljkovic Cc: Fabio Estevam; Subject: Re: [U-Boot] Enabling nand createbbt command I do expect mainline is better maintained and supported, except for missing particular features/hardware support that nobody ever bothered to submit to mainline -- which in this case appears to be hardware that you care about, so unless you're prepared to do a fair bit of work to add support to mainline, I'd try again to find a support channel for your Freescale-provided U-Boot. Or maybe we could help you figure out what it is you want to do, instead of scrubbing, if the answer doesn't depend on details of a non-standard U-Boot. Oh, and if you're curious about my freescale.com e-mail address, I work in a different part of the company and don't have i.MX knowledge or contacts. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
On Wednesday 14 March 2012 17:00:58 Bud Miljkovic wrote: Charles That is interesting. Any clue how to configure the start and end blocks manually? Yes I do since I wrote yaffs :-). Set the statrt_block and end_block (might be startBlock and endBlock) values as needed BEFORE the mount/init happens. In a normal situation with mtd partitioning these are set to 0 and n-blocks-in-partition -1, but they can be set manually too. -- Charles Bud -Original Message- From: Charles Manning [mailto:mannin...@actrix.gen.nz] Sent: Monday, 12 March 2012 8:20 a.m. To: Bud Miljkovic Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Enabling nand createbbt command Bud Yaffs can work without mtdpart. To do that you just need to configure the start and end blocks manually instead of using the partition info to do this. On Friday 09 March 2012 13:58:48 Bud Miljkovic wrote: Thank you Scott and Fabio, You help is much appreciated. I will try to add the nand support for mx53 mainline. However, what I am trying to do is to build a u-boot that supports NAND and have YAFFS2 as well and at moment I use the mx53_ard board since this is very close to what my custom board will be. I was able to build such a version, using Freescale u-boot sources, which included nand subsystem, and yaffs commands. Then I needed to create partitions in the nand and this is where i discovered I needed the support of mtdparts command. So I, guess, I need to configure the u-boot for mtdparts support. This is where I am at. -Bud -Original Message- From: Scott Wood Sent: Friday, 9 March 2012 12:04 p.m. To: Bud Miljkovic Cc: Fabio Estevam; Subject: Re: [U-Boot] Enabling nand createbbt command I do expect mainline is better maintained and supported, except for missing particular features/hardware support that nobody ever bothered to submit to mainline -- which in this case appears to be hardware that you care about, so unless you're prepared to do a fair bit of work to add support to mainline, I'd try again to find a support channel for your Freescale-provided U-Boot. Or maybe we could help you figure out what it is you want to do, instead of scrubbing, if the answer doesn't depend on details of a non-standard U-Boot. Oh, and if you're curious about my freescale.com e-mail address, I work in a different part of the company and don't have i.MX knowledge or contacts. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling nand createbbt command
Bud Yaffs can work without mtdpart. To do that you just need to configure the start and end blocks manually instead of using the partition info to do this. On Friday 09 March 2012 13:58:48 Bud Miljkovic wrote: Thank you Scott and Fabio, You help is much appreciated. I will try to add the nand support for mx53 mainline. However, what I am trying to do is to build a u-boot that supports NAND and have YAFFS2 as well and at moment I use the mx53_ard board since this is very close to what my custom board will be. I was able to build such a version, using Freescale u-boot sources, which included nand subsystem, and yaffs commands. Then I needed to create partitions in the nand and this is where i discovered I needed the support of mtdparts command. So I, guess, I need to configure the u-boot for mtdparts support. This is where I am at. -Bud -Original Message- From: Scott Wood Sent: Friday, 9 March 2012 12:04 p.m. To: Bud Miljkovic Cc: Fabio Estevam; Subject: Re: [U-Boot] Enabling nand createbbt command I do expect mainline is better maintained and supported, except for missing particular features/hardware support that nobody ever bothered to submit to mainline -- which in this case appears to be hardware that you care about, so unless you're prepared to do a fair bit of work to add support to mainline, I'd try again to find a support channel for your Freescale-provided U-Boot. Or maybe we could help you figure out what it is you want to do, instead of scrubbing, if the answer doesn't depend on details of a non-standard U-Boot. Oh, and if you're curious about my freescale.com e-mail address, I work in a different part of the company and don't have i.MX knowledge or contacts. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build u-Boot for NAND boot on i.MX53x platform
On Wednesday 08 February 2012 17:16:10 Bud Miljkovic wrote: Can someone clue me in how one goes about a NAND bootable u-Boot? Bud You can't actually run uboot from NAND per se. The rom boot loader reads the image into ram where it runs. Based on my experience with omap - which uses a very similar sequence - you need to configure the uboot to run from the desired location in RAM. The resulting uboot.bin must then be mashed in whatever way is appropriate for loading with the rom boot loader and programmed to flash. -- CHarles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Configuration settings for Freescale i.MX53x demo boards
On Friday 10 February 2012 10:37:44 Bud Miljkovic wrote: Hello Jason Liu, Is there a glossary for the defines used in the /include/configs/board_name.h files? I find it far easier to just grep the code. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting YAFFS2 to U-boot
Bud Last time I looked, the yaffs code in u-boot is pretty old and I would recommend refreshing it. -- Charles On Friday 03 February 2012 10:40:45 Bud Miljkovic wrote: I am newbie in this. Anybody done it? Any lead is appreciated. Cheers, Bud Miljkovic -Original Message- From: Marek Vasut [mailto:marek.va...@gmail.com] Sent: Wednesday, 1 February 2012 11:58 p.m. To: Wolfgang Denk Cc: u-boot@lists.denx.de; Bud Miljkovic Subject: Re: [U-Boot] Can u-Boot Ran from RAM? Dear Marek Vasut, In message 20120201.09465.marek.va...@gmail.com you wrote: On Monday 30 January 2012 23:07:05 Bud Miljkovic wrote: While getting acquainted with possible u-Boot development issues, I read FAQ 14.2.1. Can U-Boot be configured such that it can be started in RAM? and was puzzled to learn that u-Boot cannot run from RAM. you misread it. the question is for people who have loaded u-boot, and then want to load another copy of u-boot into ram and then execute that directly. so the question is can u-boot be *started in ram* and the answer is no. The answer is yes if you know how to do it ;-) The answer is NO. You cannot load the _normal_ U-Boot image to RAM and start it. You must prepare a _special_ image which omits all the initializations that are normally included. You can on PXA ;-) This FAQ addresses the situation where people want to load and run their _normal_ images before burning these to flash. And this CANNOT be done like that. You're certainly right this is true for general case, but there are special cases where you can load u-boot from u-boot without any harm (PXA is the example). Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Can u-Boot Ran from RAM?
On Tuesday 31 January 2012 17:07:05 Bud Miljkovic wrote: Hi there, While getting acquainted with possible u-Boot development issues, I read FAQ 14.2.1. Can U-Boot be configured such that it can be started in RAM? and was puzzled to learn that u-Boot cannot run from RAM. This is clearly not true. The omap devices and davinci devices both use rom boot loaders to load uboot into ram for further execution. In the case of omaps it is often even more complex using a rom boot loader to load x-load (or cut down u-boot) to load the real uboot which then loads Linux. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Does usbtty work on omap3?
Hi All I have usbtty partially working on omap3 (overo board). Unfortunately the byte stream gets corrupted. It looks like some sort of buffer / fifo corruption or similar with old bytes being sent and some bytes being dropped. Does anyone have this actually working reliably? I tried to have a hunt around the code, but the musb user guides are unfortunately under NDA. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Does usbtty work on omap3?
On Wednesday 11 May 2011 11:47:14 Jason Kridner wrote: On Tue, May 10, 2011 at 7:23 PM, Charles Manning mannin...@actrix.gen.nzwrote: Hi All I have usbtty partially working on omap3 (overo board). Unfortunately the byte stream gets corrupted. It looks like some sort of buffer / fifo corruption or similar with old bytes being sent and some bytes being dropped. Does anyone have this actually working reliably? It is also not reliable for me. There was an alternative implementation, I believe originating from a combination of TI and RidgeRun, for which patches were made public, but the current upstream has data corruption in it. I hunted around for a bit but could not find those patches. Can you point me at it? What is somewhat annoying is that the old code (~2008) actually worked well, but that was replaced with broken code from Wind River :-(. I'm looking into getting the issue staffed by TI, but this is a nice-to-have feature currently so it is at a low priority. I would argue that it is more than just nice to have. USB is an excellent way to load up data in a manufacturing jig etc and beats any other way to load up software. Thanks -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] usbtty corruption on omap3
Hi All I recently moved from a really old uboot to git master of a few days back to be able to get the benefit of dcache/icache Unfortunately I'm now seeing data corruption on the serial stream using usbtty. Anyone else seeing this problem? Thanks Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usbtty corruption on omap3
On Thursday 05 May 2011 13:44:01 Charles Manning wrote: Hi All I recently moved from a really old uboot to git master of a few days back to be able to get the benefit of dcache/icache Unfortunately I'm now seeing data corruption on the serial stream using usbtty. Anyone else seeing this problem? The same happens with the top of /gitorious.org/u-boot-omap3 I hacked the overo config to include the usb stuff from evm and I get the /dev/ttyACM0 port working. The stuff that comes out is mangled. It loods like some buffers are not getting cleared properly because old bytes come up. -- Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Strip dead code on omap3 devices
On Wednesday 20 April 2011 15:51:56 Charles Manning wrote: Garbage collect code that isn't used. Saves a good few kbytes. Sorry folks. THis patch is broken. I'll submit another. Charles ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Fix for overlapping sections?
On Tuesday 19 April 2011 11:20:47 Ciummo, Larry (DS-1) wrote:
Designation: Non-SSA/Finmeccanica
A while back there was a fix for the overlapping section link problem
(see below) involving changing some sort of global. Does anyone have a
pointer to the change. I'm using a fairly old uboot for AMCC
Canyonlands/460Ex and can't easily upgrade to a newer uboot build.
Thanks
Larry
eldk/usr/bin/../lib/gcc/powerpc-linux/4.2.2/pic -lgcc -Map u-boot.map -o
u-boot
/opt/eldk/usr/bin/ppc_4xx-ld: section .bootpg [f000 - f303]
overlaps section .data.rel.local [e1d8 - febb]
/opt/eldk/usr/bin/ppc_4xx-ld: u-boot: section .bootpg lma 0xf000
overlaps previous sections
/opt/eldk/usr/bin/ppc_4xx-ld: u-boot: section .u_boot_cmd lma 0xfebc
overlaps previous sections
make: *** [u-boot] Error 1
Overlapping sections are commonly caused by one of two problems:
1) You have set up the memory map in a way that does not give enough space so
the sections do indeed overlap.
2) Your ld script is not handling all the sections being fed to it. This is
likely if you have switched to using -ffunction-sections etc.
In the case of (2) you will need to modify your ld script with something like:
@@ -34,8 +34,8 @@ SECTIONS
. = ALIGN(4);
.text :
{
- arch/arm/cpu/armv7/start.o (.text)
- *(.text)
+ KEEP(arch/arm/cpu/armv7/start.o (.text*))
+ *(.text*)
}
. = ALIGN(4);
@@ -70,7 +70,7 @@ SECTIONS
.bss __rel_dyn_start (OVERLAY) : {
__bss_start = .;
- *(.bss)
+ *(.bss*)
. = ALIGN(4);
__bss_end__ = .;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Strip dead code on omap3 devices
Garbage collect code that isn't used.
Saves a good few kbytes.
Signed-off-by: Charles Manning cdhmann...@gmail.com
---
Makefile |2 +-
arch/arm/config.mk|6 ++
arch/arm/cpu/armv7/u-boot.lds |6 +++---
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 713dba1..1ba3e3a 100644
--- a/Makefile
+++ b/Makefile
@@ -368,7 +368,7 @@ $(obj)u-boot.dis: $(obj)u-boot
GEN_UBOOT = \
UNDEF_SYM=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \
sed -n -e
's/.*\($(SYM_PREFIX)__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
- cd $(LNDIR) $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $$UNDEF_SYM
$(__OBJS) \
+ cd $(LNDIR) $(LD) $(LDFLAGS) $(LDFLAGSFINAL)
$(LDFLAGS_$(@F))
$$UNDEF_SYM $(__OBJS) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot.map -o u-boot
$(obj)u-boot: depend \
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index fcc26a2..02cc9b2 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -67,3 +67,9 @@ LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
ifndef CONFIG_NAND_SPL
LDFLAGS_u-boot += -pie
endif
+
+# Dead code stripping
+CFLAGS += -ffunction-sections
+CFLAGS += -fdata-sections
+LDFLAGS += --cref
+LDFLAGSFINAL += --cref --gc-sections
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index dbae54d..f1267b5 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -34,8 +34,8 @@ SECTIONS
. = ALIGN(4);
.text :
{
- arch/arm/cpu/armv7/start.o (.text)
- *(.text)
+ KEEP(arch/arm/cpu/armv7/start.o (.text*))
+ *(.text*)
}
. = ALIGN(4);
@@ -70,7 +70,7 @@ SECTIONS
.bss __rel_dyn_start (OVERLAY) : {
__bss_start = .;
- *(.bss)
+ *(.bss*)
. = ALIGN(4);
__bss_end__ = .;
}
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Easy reduction to u-boot image size
I've been investigating reducing the size of an omap3 uboot image to less than
64k to facilitate loading via the bootrom. I've been working with the Brian
Silvermans' patch and some modifications to that.
http://www.mail-archive.com/u-boot@lists.denx.de/msg16073.html
With Brians's patch, and some extra fiddling, I got to around 62k but needed
to get lower (need to be under 60k ).
One thing I came across was that u-boot is not using function sections etc and
as a result there's quite a bit of dead code that is included in the image.
Applying the following patch reduced the size by around 7k to approx 55k. That
really helped :-) and lets me add back some functionality and still keep
under 60k.
Note:
1) This only sorts out the overo. Other u-boot.lds files need to be modified
in the same way.
2) This only does dead code stripping and not dead data stripping. I have not
yet figured out why that is not working (hence the commented out line
for -fdata-sections). This will save something, but I expect not very much.
-- Charles
--- a/board/omap3/overo/u-boot.lds
+++ b/board/omap3/overo/u-boot.lds
@@ -34,7 +34,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
- cpu/arm_cortexa8/start.o(.text)
+ KEEP(cpu/arm_cortexa8/start.o (.text))
*(.text)
}
diff --git a/config.mk b/config.mk
index b1254e9..b129761 100644
--- a/config.mk
+++ b/config.mk
@@ -171,6 +171,11 @@ ifneq ($(TEXT_BASE),)
LDFLAGS += -Ttext $(TEXT_BASE)
endif
+# Stuff to strip out dead code
+CFLAGS += -ffunction-sections
+#CFLAGS += -fdata-sections
+LDFLAGS += --cref --gc-sections
+
# Location of a usable BFD library, where we define usable as
# built for ${HOST}, supports ${TARGET}. Sensible values are
# - When cross-compiling: the root of the cross-environment
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
