Re: [U-Boot] cross compiling fw_printenv on big endian
Joakim Tjernlund wrote: Wolfgang Denk w...@denx.de wrote on 2010/03/17 12:57:31: Dear Joakim Tjernlund, In message OFF4AB0804.BE309218-ONC12576E9.003A69DF-C12576E9. 003b4...@transmode.se you wrote: hmm, I recently discovered that normal user space headers always define both __LITTLE_ENDIAN and __BIG_ENDIAN so therefore a # ifdef __LITTLE_ENDIAN # define DO_CRC(x) crc = tab[(crc ^ (x)) 255] ^ (crc 8) # else # define DO_CRC(x) crc = tab[((crc 24) ^ (x)) 255] ^ (crc 8) # endif Wont work. One have to use #if __BYTE_ORDER == __LITTLE_ENDIAN instead. Wenn... Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se Looks as if this were your very own commit. Do you have a fix in the works? I know, but I don't have anything ATM. I am too busy debugging serious customer problems. Jocke This appears to work for me on my big endian PowerPC target. Perhaps somebody with a little endian target can verify it does not break their env tools. diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c index 468b397..27335a3 100644 --- a/lib_generic/crc32.c +++ b/lib_generic/crc32.c @@ -163,7 +163,7 @@ const uint32_t * ZEXPORT get_crc_table() #endif /* = */ -# ifdef __LITTLE_ENDIAN +# if __BYTE_ORDER == __LITTLE_ENDIAN # define DO_CRC(x) crc = tab[(crc ^ (x)) 255] ^ (crc 8) # else # define DO_CRC(x) crc = tab[((crc 24) ^ (x)) 255] ^ (crc 8) Jeff Angielski The PTR Group www.theptrgroup.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cross compiling fw_printenv on big endian
Joakim Tjernlund wrote: Jeff Angielski j...@theptrgroup.com wrote on 2010/03/17 16:10:50: Joakim Tjernlund wrote: Wolfgang Denk w...@denx.de wrote on 2010/03/17 12:57:31: Dear Joakim Tjernlund, In message OFF4AB0804.BE309218-ONC12576E9.003A69DF-C12576E9. 003b4...@transmode.se you wrote: hmm, I recently discovered that normal user space headers always define both __LITTLE_ENDIAN and __BIG_ENDIAN so therefore a # ifdef __LITTLE_ENDIAN # define DO_CRC(x) crc = tab[(crc ^ (x)) 255] ^ (crc 8) # else # define DO_CRC(x) crc = tab[((crc 24) ^ (x)) 255] ^ (crc 8) # endif Wont work. One have to use #if __BYTE_ORDER == __LITTLE_ENDIAN instead. Wenn... Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se Looks as if this were your very own commit. Do you have a fix in the works? I know, but I don't have anything ATM. I am too busy debugging serious customer problems. Jocke This appears to work for me on my big endian PowerPC target. Perhaps somebody with a little endian target can verify it does not break their env tools. diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c index 468b397..27335a3 100644 --- a/lib_generic/crc32.c +++ b/lib_generic/crc32.c @@ -163,7 +163,7 @@ const uint32_t * ZEXPORT get_crc_table() #endif /* = */ -# ifdef __LITTLE_ENDIAN +# if __BYTE_ORDER == __LITTLE_ENDIAN # define DO_CRC(x) crc = tab[(crc ^ (x)) 255] ^ (crc 8) # else # define DO_CRC(x) crc = tab[((crc 24) ^ (x)) 255] ^ (crc 8) I THINK this will work. Looking at include/linux/byteorder/big_endian.h it says: #define __BYTE_ORDER__BIG_ENDIAN so it seems like the __BYTE_ORDER logic is in place in u-boot. Someone with a LE CPU should confirm this. Mind doing a proper patch? See attached file. -- Jeff Angielski The PTR Group www.theptrgroup.com From 45c007e857990bd01f13c5dbbe61e6f9fc75f390 Mon Sep 17 00:00:00 2001 From: Jeff Angielski j...@theptrgroup.com Date: Wed, 17 Mar 2010 15:09:26 -0400 Subject: [PATCH] env: fix endian ordering in crc table The crc table was being built as little endian for big endian targets. This would cause fw_printenv to always fail with Warning: Bad CRC, using default environment messages. Signed-off-by: Jeff Angielski j...@theptrgroup.com --- lib_generic/crc32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c index 468b397..27335a3 100644 --- a/lib_generic/crc32.c +++ b/lib_generic/crc32.c @@ -163,7 +163,7 @@ const uint32_t * ZEXPORT get_crc_table() #endif /* = */ -# ifdef __LITTLE_ENDIAN +# if __BYTE_ORDER == __LITTLE_ENDIAN # define DO_CRC(x) crc = tab[(crc ^ (x)) 255] ^ (crc 8) # else # define DO_CRC(x) crc = tab[((crc 24) ^ (x)) 255] ^ (crc 8) -- 1.6.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env: fix endian ordering in crc table
The crc table was being built as little endian for big endian targets. This would cause fw_printenv to always fail with Warning: Bad CRC, using default environment messages. Signed-off-by: Jeff Angielski j...@theptrgroup.com --- lib_generic/crc32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c index 468b397..27335a3 100644 --- a/lib_generic/crc32.c +++ b/lib_generic/crc32.c @@ -163,7 +163,7 @@ const uint32_t * ZEXPORT get_crc_table() #endif /* = */ -# ifdef __LITTLE_ENDIAN +# if __BYTE_ORDER == __LITTLE_ENDIAN # define DO_CRC(x) crc = tab[(crc ^ (x)) 255] ^ (crc 8) # else # define DO_CRC(x) crc = tab[((crc 24) ^ (x)) 255] ^ (crc 8) -- 1.6.3.3 -- Jeff Angielski The PTR Group www.theptrgroup.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] cross compiling fw_printenv on big endian
I seem to be having a problem with fw_printenv on my PowerPC 85xx target whereby I constantly get CRC32 errors: # fw_printenv Warning: Bad CRC, using default environment I tracked this down to the fact that u-boot/lib_generic/crc32.c is getting compiled with the __LITTLE_ENDIAN defined even though I have CROSS_COMPILE setup correctly [e.g. I can build u-boot.bin just fine]. Is there a special way to cross compile fw_printenv so that the __LITTLE_ENDIAN is not defined? Are there other PowerPC users that are building fw_printenv? I'd rather do the proper thing than resort of hacking the crc32.c file. -- Jeff Angielski The PTR Group www.theptrgroup.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ubi part failing on NAND
Stefan Roese wrote: On Friday 18 December 2009 13:35:26 hedwin wrote: Jeff, what is the size of your allocateble memory. Had to increase it to 4MB to get it working. I've got 1MByte for my test on Kilauea. This should be enough. There is already a compile-time check in the UBI code: #if (CONFIG_SYS_MALLOC_LEN (512 10)) #error Malloc area too small for UBI, increase CONFIG_SYS_MALLOC_LEN to = 512k #endif Please let me know if this really is not enough. But for me, 1MB is working. As per Hedwin's suggestion I increased my CONFIG_SYS_MALLOC_LEN to 4MB and the error disappeared. Thanks Hedwin! And now the UBI output matches my part (e.g. PEB size). = nand erase 0x0 0x4000 = ubi part fs1 Creating 1 MTD partitions on nand0: 0x-0x2000 : mtd=0 UBI: attaching mtd2 to ubi0 UBI: physical eraseblock size: 262144 bytes (256 KiB) UBI: logical eraseblock size:253952 bytes UBI: smallest flash I/O unit:4096 UBI: VID header offset: 4096 (aligned 4096) UBI: data offset:8192 UBI: empty MTD device detected UBI: create volume table (copy #1) UBI: create volume table (copy #2) UBI: attached mtd2 to ubi0 UBI: MTD device name:mtd=0 UBI: MTD device size:512 MiB UBI: number of good PEBs:2045 UBI: number of bad PEBs: 3 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold:4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 0 UBI: available PEBs: 2021 UBI: total number of reserved PEBs: 24 UBI: number of PEBs reserved for bad PEB handling: 20 UBI: max/mean erase counter: 0/0 = -- Jeff Angielski The PTR Group www.theptrgroup.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ubi part failing on NAND
The ubi part command is failing for me on my PowerPC 85xx board. I am not trying to do anything special, just create the partitions and volumes so that I can try writing an ubi.img. It spits out enough information that it looks like it did work but it prints out an error nonetheless. And of course there is the long standing issue of the reported MTD number not making any sense. But previous posts have discounted this as an issue. Here is the snippet of the error: UBI error: ubi_init: cannot attach mtd2 UBI: mtd2 is detached from ubi0 UBI error: ubi_init: UBI error: cannot initialize UBI, error -17 UBI init error -17 Here is a cleaned up version of the session log: = mtdparts device nor0 f800.nor, # parts = 8 #: namesizeoffset mask_flags 0: config 0x0002 0x 0 1: kernel 0x0026 0x0002 0 2: fdt 0x0002 0x0028 0 3: tinyfs 0x0060 0x002a 0 4: rootfs 0x076a 0x008a 0 5: u-boot-env-r0x0002 0x07f4 1 6: u-boot-env 0x0002 0x07f6 1 7: u-boot 0x0008 0x07f8 1 device nand0 f400.nand, # parts = 2 #: namesizeoffset mask_flags 0: fs1 0x2000 0x 0 1: fs2 0x2000 0x2000 0 = nand erase 0x0 0x4000 NAND erase: device 0 whole chip Skipping bad block at 0x0120 Skipping bad block at 0x0e88 Skipping bad block at 0x1cd8 Skipping bad block at 0x2b30 Skipping bad block at 0x323c Skipping bad block at 0x364c Skipping bad block at 0x37cc Erasing at 0x3ffc -- 100% complete. OK = ubi part fs1 Creating 1 MTD partitions on nand0: 0x-0x2000 : mtd=0 UBI: attaching mtd2 to ubi0 UBI: physical eraseblock size: 262144 bytes (256 KiB) UBI: logical eraseblock size:253952 bytes UBI: smallest flash I/O unit:4096 UBI: VID header offset: 4096 (aligned 4096) UBI: data offset:8192 UBI: empty MTD device detected UBI: create volume table (copy #1) UBI: create volume table (copy #2) UBI: attached mtd2 to ubi0 UBI: MTD device name:mtd=0 UBI: MTD device size:512 MiB UBI: number of good PEBs:2045 UBI: number of bad PEBs: 3 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold:4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 0 UBI: available PEBs: 2021 UBI: total number of reserved PEBs: 24 UBI: number of PEBs reserved for bad PEB handling: 20 UBI: max/mean erase counter: 0/0 UBI error: ubi_init: cannot attach mtd2 UBI: mtd2 is detached from ubi0 UBI error: ubi_init: UBI error: cannot initialize UBI, error -17 UBI init error -17 exit not allowed from main input shell. My last sync with the denx git was when 2.6.31 was released. Here is my version: = ver U-Boot 2009.08-00213-gfdf80f7 (Dec 17 2009 - 12:57:07) Jeff Angielski The PTR Group www.theptrgroup.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad CPU identification on MPC8544DS
On Tue, 2009-03-03 at 14:04 -0500, jeff angielski wrote: Despite the SVR being the same (0x803c0011), the latest u-boot is misidentifying the CPU when compared against the original 1.3.0 u-boot. The CPU is a 8544E but u-boot is reporting 8533E. The wierd part of this is that according to the Chip Errata for the MPC8544E, the SVR *should* be 0x803c01xx - which is different than both the 1.3 and latest git version are reading. Can any of the Freescale guys explain this discrepancy between the manual, the Freescale BSP u-boot, and the latest u-boot? The problem has been resolved. It would appear that two forces were at work. The older u-boot only looked at 16 bits when determining the CPU type and could incorrectly identify the various MPC85xx CPUs. The second issue was that the MPC8544DS hardware was being deployed with incorrect jumper settings. These jumpers relate to the CPU ID. Manufacturing never picked up on this error because of the first problem. So the latest u-boot is correct. -- Jeff Angielski The PTR Group www.theptrgroup.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Bad CPU identification on MPC8544DS
Despite the SVR being the same (0x803c0011), the latest u-boot is misidentifying the CPU when compared against the original 1.3.0 u-boot. The CPU is a 8544E but u-boot is reporting 8533E. The wierd part of this is that according to the Chip Errata for the MPC8544E, the SVR *should* be 0x803c01xx - which is different than both the 1.3 and latest git version are reading. Can any of the Freescale guys explain this discrepancy between the manual, the Freescale BSP u-boot, and the latest u-boot? Using the u-boot that is built with the LTIB and ships with the MPC8544DS board: U-Boot 1.3.0-rc3 (Mar 28 2008 - 11:13:50) CPU: 8544_E, Version: 1.1, (0x803c0011) Core: E500, Version: 2.2, (0x80210022) Clock Configuration: CPU: 999 MHz, CCB: 399 MHz, DDR: 199 MHz, LBC: 24 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Using the latest u-boot: U-Boot 2009.03-rc1-00031-gd82fd0f-dirty (Mar 03 2009 - 13:09:00) CPU: 8533E, Version: 1.1, (0x803c0011) Core: E500, Version: 2.2, (0x80210022) Clock Configuration: CPU0:1000 MHz, CCB:400 MHz, DDR:200 MHz (400 MT/s data rate), LBC:25 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: MPC8544DS, System ID: 0x12, System Version: 0x20, FPGA Version: 0x31 -- Jeff Angielski The PTR Group www.theptrgroup.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
