[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
Hi, All
Each time JFFS2 initialized, uboot need to scan the whole flash. This is fairly time consuming.
So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I believe this can also be used to UBOOT to reduce booting time.
Does UBOOT support this feature? or does any other solution in uboot to reduce JFFS2 scaning time?
thanks
Leon _________________________________________________________________ MSN十周年庆典，查看MSN注册时间，赢取神秘大奖 http://10.msn.com.cn
Hi, All
Each time JFFS2 initialized, uboot need to scan the whole flash. This is fairly time consuming.
So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I believe this can also be used to UBOOT to reduce booting time.
Does UBOOT support this feature? or does any other solution in uboot to reduce JFFS2 scaning time?
Don't think EBS is going to buy you much. The main problem is that the scanning of JFFS2 in u-boot is inefficient. u-boot could take a hint from the kernel impl. of JFFS2 to reduce scanning. The biggest ones are: - do no scan the whole EB when it is empty. - impl. a better crc32(use the one from linux) - Don't scan more than you have to, that is, ls/read /some/file should only scan and keep records to do the ls/read of that particular file.
There were some patches floating around quite some time ago to improve scanning but I don't think they made it into the u-boot repo.
Jocke
Thank you, Jocke
Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time? To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 08:41:08 +0100
Hi, All
Each time JFFS2 initialized, uboot need to scan the whole flash. This is fairly time consuming.
So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I believe this can also be used to UBOOT to reduce booting time.
Does UBOOT support this feature? or does any other solution in uboot to reduce JFFS2 scaning time?
Don't think EBS is going to buy you much. The main problem is that the
You mean even EBS is used in UBOOT, it will not give me much help. But it seems there is great efficiency in jffs2 mounting, from some artical in internet, such as:http://www.embedded-linux.co.uk/tutorial/jffs2-summary
scanning of JFFS2 in u-boot is inefficient. u-boot could take a hint from the kernel impl. of JFFS2 to reduce scanning. The biggest ones are:
- do no scan the whole EB when it is empty.
If we don't scan the block, how can we tell the EB is empty?
- impl. a better crc32(use the one from linux)
- Don't scan more than you have to, that is, ls/read /some/file
should only scan and keep records to do the ls/read of that particular file.
So we have to have an index, or something like that, to tell which file in which EBs. This index is always generated by the scan for the first time.
The only workaround like this idea is to divide the flash into several paritions, the scan is performed on certain partition each time.
There were some patches floating around quite some time ago to improve scanning but I don't think they made it into the u-boot repo.
As far as I know, YAFFS2 also has this problem however the code is ported from linux. It's also inefficient for YAFFS2 scanning?
Jocke
_________________________________________________________________ 上Windows Live 中国首页，下载Messenger2009安全版！ http://www.windowslive.cn
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2
scaning time?
To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 08:41:08 +0100
Hi, All
Each time JFFS2 initialized, uboot need to scan the whole flash. This is fairly time consuming.
So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I believe this can also be used to UBOOT to reduce booting time.
Does UBOOT support this feature? or does any other solution in uboot to reduce JFFS2 scaning time?
Don't think EBS is going to buy you much. The main problem is that the
You mean even EBS is used in UBOOT, it will not give me much help. But it seems there is great efficiency in jffs2 mounting, from some artical in internet, such as:http://www.embedded-linux.co.uk/tutorial/jffs2-summary
I tried summary long time ago and it wasn't such a big win. It has other drawbacks too such as not beeing able to mark nodes on NOR flash obsolete.
scanning of JFFS2 in u-boot is inefficient. u-boot could take a hint from the kernel impl. of JFFS2 to reduce scanning. The biggest ones are:
- do no scan the whole EB when it is empty.
If we don't scan the block, how can we tell the EB is empty?
This was the key for me. I added an optimization that had been forgotten: just scan the first 512-1024 bytes, if these are empty, assume that the rest of the EB is too. You can find this optimization in the kernel also.
Once this optimization was in place, summary didn't help me.
- impl. a better crc32(use the one from linux)
- Don't scan more than you have to, that is, ls/read /some/file
should only scan and keep records to do the ls/read of that particular file.
So we have to have an index, or something like that, to tell which file in which EBs. This index is always generated by the scan for the first time. The only workaround like this idea is to divide the flash into several paritions, the scan is performed on certain partition each time.
There were some patches floating around quite some time ago to improve scanning but I don't think they made it into the u-boot repo.
As far as I know, YAFFS2 also has this problem however the code is ported from linux. It's also inefficient for YAFFS2 scanning?
No idea, I am not using YAFFS2
Ok, thank you, jocke.
Can you tell me how much time can be saved according to your idea, by your experience?
Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time? To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 10:08:06 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2
scaning time?
To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 08:41:08 +0100
Hi, All
Each time JFFS2 initialized, uboot need to scan the whole flash. This is fairly time consuming.
So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I believe this can also be used to UBOOT to reduce booting time.
Does UBOOT support this feature? or does any other solution in uboot to reduce JFFS2 scaning time?
Don't think EBS is going to buy you much. The main problem is that the
You mean even EBS is used in UBOOT, it will not give me much help. But it seems there is great efficiency in jffs2 mounting, from some artical in internet, such as:http://www.embedded-linux.co.uk/tutorial/jffs2-summary
I tried summary long time ago and it wasn't such a big win. It has other drawbacks too such as not beeing able to mark nodes on NOR flash obsolete.
scanning of JFFS2 in u-boot is inefficient. u-boot could take a hint from the kernel impl. of JFFS2 to reduce scanning. The biggest ones are:
- do no scan the whole EB when it is empty.
If we don't scan the block, how can we tell the EB is empty?
This was the key for me. I added an optimization that had been forgotten: just scan the first 512-1024 bytes, if these are empty, assume that the rest of the EB is too. You can find this optimization in the kernel also.
Once this optimization was in place, summary didn't help me.
- impl. a better crc32(use the one from linux)
- Don't scan more than you have to, that is, ls/read /some/file
should only scan and keep records to do the ls/read of that particular file.
So we have to have an index, or something like that, to tell which file in which EBs. This index is always generated by the scan for the first time. The only workaround like this idea is to divide the flash into several paritions, the scan is performed on certain partition each time.
There were some patches floating around quite some time ago to improve scanning but I don't think they made it into the u-boot repo.
As far as I know, YAFFS2 also has this problem however the code is ported from linux. It's also inefficient for YAFFS2 scanning?
No idea, I am not using YAFFS2
_________________________________________________________________ MSN十年回馈，每位用户可免费获得价值25元的卡巴斯基反病毒软件2010激活码，快来领取！ http://kaba.msn.com.cn/?k=1
HeLei leon.he@msn.com wrote on 03/11/2009 10:21:13:
Ok, thank you, jocke. Can you tell me how much time can be saved according to your idea, by your experience?
Can't remember any figures, but is was lots by not scanning empty space. It all depends on how full your fs is.
Jocke
Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time? To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 10:29:47 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 10:21:13:
Ok, thank you, jocke. Can you tell me how much time can be saved according to your idea, by your experience?
Can't remember any figures, but is was lots by not scanning empty space. It all depends on how full your fs is.
Thanks, I got it! I think the problem of JFFS2 is it never store the index of file system in flash. However 1~2GiB flash is quite popular, how JFFS2 face such situation :(
Jocke
_________________________________________________________________ 上Windows Live 中国首页，下载Messenger2009安全版！ http://www.windowslive.cn
HeLei leon.he@msn.com wrote on 03/11/2009 10:39:48:
Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2
scaning time?
To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 10:29:47 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 10:21:13:
Ok, thank you, jocke. Can you tell me how much time can be saved according to your idea, by your
experience?
Can't remember any figures, but is was lots by not scanning empty space. It all depends on how full your fs is.
Thanks, I got it! I think the problem of JFFS2 is it never store the index of file system in flash. However 1~2GiB flash is quite popular, how JFFS2 face such situation :(
JFFS2 isn't really suited for such big FS:es and works best on NOR flash. You should consider some other FS(YAFFS, LogFS, UBIFS etc.). I can't say which tough as I haven't used any of them.
Jocke
Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time? To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 10:52:06 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 10:39:48:
Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2
scaning time?
To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 10:29:47 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 10:21:13:
Ok, thank you, jocke. Can you tell me how much time can be saved according to your idea, by your
experience?
Can't remember any figures, but is was lots by not scanning empty space. It all depends on how full your fs is.
Thanks, I got it! I think the problem of JFFS2 is it never store the index of file system in flash. However 1~2GiB flash is quite popular, how JFFS2 face such situation :(
JFFS2 isn't really suited for such big FS:es and works best on NOR flash. You should consider some other FS(YAFFS, LogFS, UBIFS etc.). I can't say which tough as I haven't used any of them.
I got it, thanks
Jocke
_________________________________________________________________ 上Windows Live 中国首页，下载Messenger2009安全版！ http://www.windowslive.cn
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2
scaning time?
To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 08:41:08 +0100
Hi, All
Each time JFFS2 initialized, uboot need to scan the whole flash. This is fairly time consuming.
So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I believe this can also be used to UBOOT to reduce booting time.
Does UBOOT support this feature? or does any other solution in uboot to reduce JFFS2 scaning time?
Don't think EBS is going to buy you much. The main problem is that the
You mean even EBS is used in UBOOT, it will not give me much help. But it seems there is great efficiency in jffs2 mounting, from some artical in internet, such as:http://www.embedded-linux.co.uk/tutorial/jffs2-summary
scanning of JFFS2 in u-boot is inefficient. u-boot could take a hint from the kernel impl. of JFFS2 to reduce scanning. The biggest ones are:
- do no scan the whole EB when it is empty.
If we don't scan the block, how can we tell the EB is empty?
- impl. a better crc32(use the one from linux)
Attaching a very crude port of linux crc32. This boots a linux img for me and handles the environment crc as well. Feel free to clean it up and submit to u-boot.
Jocke
(See attached file: crc32-new.c)(See attached file: crc32defs.h)(See attached file: crc32table.h)
Jocke, you are so kind.Thank you very much:)
Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time? To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 10:20:19 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2
scaning time?
To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 08:41:08 +0100
Hi, All
Each time JFFS2 initialized, uboot need to scan the whole flash. This is fairly time consuming.
So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I believe this can also be used to UBOOT to reduce booting time.
Does UBOOT support this feature? or does any other solution in uboot to reduce JFFS2 scaning time?
Don't think EBS is going to buy you much. The main problem is that the
You mean even EBS is used in UBOOT, it will not give me much help. But it seems there is great efficiency in jffs2 mounting, from some artical in internet, such as:http://www.embedded-linux.co.uk/tutorial/jffs2-summary
scanning of JFFS2 in u-boot is inefficient. u-boot could take a hint from the kernel impl. of JFFS2 to reduce scanning. The biggest ones are:
- do no scan the whole EB when it is empty.
If we don't scan the block, how can we tell the EB is empty?
- impl. a better crc32(use the one from linux)
Attaching a very crude port of linux crc32. This boots a linux img for me and handles the environment crc as well. Feel free to clean it up and submit to u-boot.
Jocke (See attached file: crc32-new.c)(See attached file: crc32defs.h)(See attached file: crc32table.h)
_________________________________________________________________ 约会说不清地方？来试试微软地图最新msn互动功能！ http://ditu.live.com/?form=TL&swm=1
HeLei leon.he@msn.com wrote on 03/11/2009 10:26:44:
Jocke, you are so kind. Thank you very much:)
NP, it was easy considering I did the first impl. for linux :) It is probably easier to paste the missing bits into the current crc32 impl. though.
Jocke
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
- impl. a better crc32(use the one from linux)
Attaching a very crude port of linux crc32. This boots a linux img for me and handles the environment crc as well. Feel free to clean it up and submit to u-boot.
Jocke
So I could not help myself, here is a better port of crc32 to u-boot. You will probably get at small conflict due to LINK_OFF, just remove the LINK_OFF stuff for now. Could you test and report? Do you have a little or big endian target?
Jocke
From 7b98aab2aa940b47b81d3a548c8d786016cd2ee8 Mon Sep 17 00:00:00 2001
From: Joakim Tjernlund Joakim.Tjernlund@transmode.se Date: Tue, 3 Nov 2009 11:39:43 +0100 Subject: [PATCH] crc32: Impl. linux optimized crc32()
Ported over the more efficient linux crc32() function. --- lib_generic/crc32.c | 208 +++++++++++++++++++++++++++++---------------------- 1 files changed, 117 insertions(+), 91 deletions(-)
diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c index 2e11548..d3bb92b 100644 --- a/lib_generic/crc32.c +++ b/lib_generic/crc32.c @@ -13,6 +13,7 @@ #else #include <stdint.h> #endif +#include <asm/byteorder.h>
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) #include <watchdog.h> @@ -52,6 +53,7 @@ local void make_crc_table OF((void)); the information needed to generate CRC's on data a byte at a time for all combinations of CRC register values and incoming bytes. */ +#define tole(x) cpu_to_le32(x) local void make_crc_table() { uint32_t c; @@ -70,7 +72,7 @@ local void make_crc_table() c = (uLong)n; for (k = 0; k < 8; k++) c = c & 1 ? poly ^ (c >> 1) : c >> 1; - crc_table[n] = c; + crc_table[n] = tole(c); } crc_table_empty = 0; } @@ -78,59 +80,73 @@ local void make_crc_table() /* ======================================================================== * Table of CRC-32's of all single-byte values (made by make_crc_table) */ +#define tole(x) __constant_cpu_to_le32(x) + local const uint32_t crc_table[256] = { - 0x00000000L, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L, - 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L, - 0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L, - 0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL, - 0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L, - 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L, - 0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L, - 0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL, - 0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L, - 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL, - 0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L, - 0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L, - 0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L, - 0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL, - 0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL, - 0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L, - 0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL, - 0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L, - 0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L, - 0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L, - 0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL, - 0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L, - 0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L, - 0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL, - 0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L, - 0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L, - 0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L, - 0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L, - 0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L, - 0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL, - 0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL, - 0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L, - 0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L, - 0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL, - 0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL, - 0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L, - 0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, 0xc5ba3bbeL, - 0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, 0xc2d7ffa7L, 0xb5d0cf31L, - 0x2cd99e8bL, 0x5bdeae1dL, 0x9b64c2b0L, 0xec63f226L, 0x756aa39cL, - 0x026d930aL, 0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L, - 0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, 0x92d28e9bL, - 0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, 0x86d3d2d4L, 0xf1d4e242L, - 0x68ddb3f8L, 0x1fda836eL, 0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L, - 0x18b74777L, 0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL, - 0x8f659effL, 0xf862ae69L, 0x616bffd3L, 0x166ccf45L, 0xa00ae278L, - 0xd70dd2eeL, 0x4e048354L, 0x3903b3c2L, 0xa7672661L, 0xd06016f7L, - 0x4969474dL, 0x3e6e77dbL, 0xaed16a4aL, 0xd9d65adcL, 0x40df0b66L, - 0x37d83bf0L, 0xa9bcae53L, 0xdebb9ec5L, 0x47b2cf7fL, 0x30b5ffe9L, - 0xbdbdf21cL, 0xcabac28aL, 0x53b39330L, 0x24b4a3a6L, 0xbad03605L, - 0xcdd70693L, 0x54de5729L, 0x23d967bfL, 0xb3667a2eL, 0xc4614ab8L, - 0x5d681b02L, 0x2a6f2b94L, 0xb40bbe37L, 0xc30c8ea1L, 0x5a05df1bL, - 0x2d02ef8dL +tole(0x00000000L), tole(0x77073096L), tole(0xee0e612cL), tole(0x990951baL), +tole(0x076dc419L), tole(0x706af48fL), tole(0xe963a535L), tole(0x9e6495a3L), +tole(0x0edb8832L), tole(0x79dcb8a4L), tole(0xe0d5e91eL), tole(0x97d2d988L), +tole(0x09b64c2bL), tole(0x7eb17cbdL), tole(0xe7b82d07L), tole(0x90bf1d91L), +tole(0x1db71064L), tole(0x6ab020f2L), tole(0xf3b97148L), tole(0x84be41deL), +tole(0x1adad47dL), tole(0x6ddde4ebL), tole(0xf4d4b551L), tole(0x83d385c7L), +tole(0x136c9856L), tole(0x646ba8c0L), tole(0xfd62f97aL), tole(0x8a65c9ecL), +tole(0x14015c4fL), tole(0x63066cd9L), tole(0xfa0f3d63L), tole(0x8d080df5L), +tole(0x3b6e20c8L), tole(0x4c69105eL), tole(0xd56041e4L), tole(0xa2677172L), +tole(0x3c03e4d1L), tole(0x4b04d447L), tole(0xd20d85fdL), tole(0xa50ab56bL), +tole(0x35b5a8faL), tole(0x42b2986cL), tole(0xdbbbc9d6L), tole(0xacbcf940L), +tole(0x32d86ce3L), tole(0x45df5c75L), tole(0xdcd60dcfL), tole(0xabd13d59L), +tole(0x26d930acL), tole(0x51de003aL), tole(0xc8d75180L), tole(0xbfd06116L), +tole(0x21b4f4b5L), tole(0x56b3c423L), tole(0xcfba9599L), tole(0xb8bda50fL), +tole(0x2802b89eL), tole(0x5f058808L), tole(0xc60cd9b2L), tole(0xb10be924L), +tole(0x2f6f7c87L), tole(0x58684c11L), tole(0xc1611dabL), tole(0xb6662d3dL), +tole(0x76dc4190L), tole(0x01db7106L), tole(0x98d220bcL), tole(0xefd5102aL), +tole(0x71b18589L), tole(0x06b6b51fL), tole(0x9fbfe4a5L), tole(0xe8b8d433L), +tole(0x7807c9a2L), tole(0x0f00f934L), tole(0x9609a88eL), tole(0xe10e9818L), +tole(0x7f6a0dbbL), tole(0x086d3d2dL), tole(0x91646c97L), tole(0xe6635c01L), +tole(0x6b6b51f4L), tole(0x1c6c6162L), tole(0x856530d8L), tole(0xf262004eL), +tole(0x6c0695edL), tole(0x1b01a57bL), tole(0x8208f4c1L), tole(0xf50fc457L), +tole(0x65b0d9c6L), tole(0x12b7e950L), tole(0x8bbeb8eaL), tole(0xfcb9887cL), +tole(0x62dd1ddfL), tole(0x15da2d49L), tole(0x8cd37cf3L), tole(0xfbd44c65L), +tole(0x4db26158L), tole(0x3ab551ceL), tole(0xa3bc0074L), tole(0xd4bb30e2L), +tole(0x4adfa541L), tole(0x3dd895d7L), tole(0xa4d1c46dL), tole(0xd3d6f4fbL), +tole(0x4369e96aL), tole(0x346ed9fcL), tole(0xad678846L), tole(0xda60b8d0L), +tole(0x44042d73L), tole(0x33031de5L), tole(0xaa0a4c5fL), tole(0xdd0d7cc9L), +tole(0x5005713cL), tole(0x270241aaL), tole(0xbe0b1010L), tole(0xc90c2086L), +tole(0x5768b525L), tole(0x206f85b3L), tole(0xb966d409L), tole(0xce61e49fL), +tole(0x5edef90eL), tole(0x29d9c998L), tole(0xb0d09822L), tole(0xc7d7a8b4L), +tole(0x59b33d17L), tole(0x2eb40d81L), tole(0xb7bd5c3bL), tole(0xc0ba6cadL), +tole(0xedb88320L), tole(0x9abfb3b6L), tole(0x03b6e20cL), tole(0x74b1d29aL), +tole(0xead54739L), tole(0x9dd277afL), tole(0x04db2615L), tole(0x73dc1683L), +tole(0xe3630b12L), tole(0x94643b84L), tole(0x0d6d6a3eL), tole(0x7a6a5aa8L), +tole(0xe40ecf0bL), tole(0x9309ff9dL), tole(0x0a00ae27L), tole(0x7d079eb1L), +tole(0xf00f9344L), tole(0x8708a3d2L), tole(0x1e01f268L), tole(0x6906c2feL), +tole(0xf762575dL), tole(0x806567cbL), tole(0x196c3671L), tole(0x6e6b06e7L), +tole(0xfed41b76L), tole(0x89d32be0L), tole(0x10da7a5aL), tole(0x67dd4accL), +tole(0xf9b9df6fL), tole(0x8ebeeff9L), tole(0x17b7be43L), tole(0x60b08ed5L), +tole(0xd6d6a3e8L), tole(0xa1d1937eL), tole(0x38d8c2c4L), tole(0x4fdff252L), +tole(0xd1bb67f1L), tole(0xa6bc5767L), tole(0x3fb506ddL), tole(0x48b2364bL), +tole(0xd80d2bdaL), tole(0xaf0a1b4cL), tole(0x36034af6L), tole(0x41047a60L), +tole(0xdf60efc3L), tole(0xa867df55L), tole(0x316e8eefL), tole(0x4669be79L), +tole(0xcb61b38cL), tole(0xbc66831aL), tole(0x256fd2a0L), tole(0x5268e236L), +tole(0xcc0c7795L), tole(0xbb0b4703L), tole(0x220216b9L), tole(0x5505262fL), +tole(0xc5ba3bbeL), tole(0xb2bd0b28L), tole(0x2bb45a92L), tole(0x5cb36a04L), +tole(0xc2d7ffa7L), tole(0xb5d0cf31L), tole(0x2cd99e8bL), tole(0x5bdeae1dL), +tole(0x9b64c2b0L), tole(0xec63f226L), tole(0x756aa39cL), tole(0x026d930aL), +tole(0x9c0906a9L), tole(0xeb0e363fL), tole(0x72076785L), tole(0x05005713L), +tole(0x95bf4a82L), tole(0xe2b87a14L), tole(0x7bb12baeL), tole(0x0cb61b38L), +tole(0x92d28e9bL), tole(0xe5d5be0dL), tole(0x7cdcefb7L), tole(0x0bdbdf21L), +tole(0x86d3d2d4L), tole(0xf1d4e242L), tole(0x68ddb3f8L), tole(0x1fda836eL), +tole(0x81be16cdL), tole(0xf6b9265bL), tole(0x6fb077e1L), tole(0x18b74777L), +tole(0x88085ae6L), tole(0xff0f6a70L), tole(0x66063bcaL), tole(0x11010b5cL), +tole(0x8f659effL), tole(0xf862ae69L), tole(0x616bffd3L), tole(0x166ccf45L), +tole(0xa00ae278L), tole(0xd70dd2eeL), tole(0x4e048354L), tole(0x3903b3c2L), +tole(0xa7672661L), tole(0xd06016f7L), tole(0x4969474dL), tole(0x3e6e77dbL), +tole(0xaed16a4aL), tole(0xd9d65adcL), tole(0x40df0b66L), tole(0x37d83bf0L), +tole(0xa9bcae53L), tole(0xdebb9ec5L), tole(0x47b2cf7fL), tole(0x30b5ffe9L), +tole(0xbdbdf21cL), tole(0xcabac28aL), tole(0x53b39330L), tole(0x24b4a3a6L), +tole(0xbad03605L), tole(0xcdd70693L), tole(0x54de5729L), tole(0x23d967bfL), +tole(0xb3667a2eL), tole(0xc4614ab8L), tole(0x5d681b02L), tole(0x2a6f2b94L), +tole(0xb40bbe37L), tole(0xc30c8ea1L), tole(0x5a05df1bL), tole(0x2d02ef8dL) }; #endif
@@ -148,60 +164,70 @@ const uint32_t * ZEXPORT get_crc_table() #endif
/* ========================================================================= */ -#define DO1(buf) crc = crc_tab[((int)crc ^ (*buf++)) & 0xff] ^ (crc >> 8); -#define DO2(buf) DO1(buf); DO1(buf); -#define DO4(buf) DO2(buf); DO2(buf); -#define DO8(buf) DO4(buf); DO4(buf); +# 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
/* ========================================================================= */ -uint32_t ZEXPORT crc32 (uint32_t crc, const Bytef *buf, uInt len) + +/* No ones complement version. JFFS2 (and other things ?) + * don't use ones compliment in their CRC calculations. + */ +uint32_t ZEXPORT crc32_no_comp(uint32_t crc, const Bytef *p, uInt len) { #ifdef LINK_OFF - const uint32_t *crc_tab = LINK_OFF(crc_table); + const uint32_t *tab = LINK_OFF(crc_table); #else - const uint32_t *crc_tab = crc_table; + const uint32_t *tab = crc_table; #endif + const uint32_t *b =(uint32_t *)p; #ifdef DYNAMIC_CRC_TABLE if (crc_table_empty) make_crc_table(); #endif - crc = crc ^ 0xffffffffL; - while (len >= 8) - { - DO8(buf); - len -= 8; + crc = __cpu_to_le32(crc); + /* Align it */ + if(((long)b)&3 && len){ + do { + uint8_t *p = (uint8_t *)b; + DO_CRC(*p++); + b = (void *)p; + } while ((--len) && ((long)b)&3 ); } - if (len) do { - DO1(buf); - } while (--len); - return crc ^ 0xffffffffL; + if(len >= 4){ + /* load data 32 bits wide, xor data 32 bits wide. */ + size_t save_len = len & 3; + len = len >> 2; + --b; /* use pre increment below(*++b) for speed */ + do { + crc ^= *++b; + DO_CRC(0); + DO_CRC(0); + DO_CRC(0); + DO_CRC(0); + } while (--len); + b++; /* point to next byte(s) */ + len = save_len; + } + /* And the last few bytes */ + if(len){ + do { + uint8_t *p = (uint8_t *)b; + DO_CRC(*p++); + b = (void *)p; + } while (--len); + } + return __le32_to_cpu(crc); } +#undef DO_CRC
-#if defined(CONFIG_CMD_JFFS2) || defined(CONFIG_CMD_NAND) - -/* No ones complement version. JFFS2 (and other things ?) - * don't use ones compliment in their CRC calculations. - */ -uint32_t ZEXPORT crc32_no_comp(uint32_t crc, const Bytef *buf, uInt len) +uint32_t ZEXPORT crc32 (uint32_t crc, const Bytef *p, uInt len) { -#ifdef DYNAMIC_CRC_TABLE - if (crc_table_empty) - make_crc_table(); -#endif - while (len >= 8) - { - DO8(buf); - len -= 8; - } - if (len) do { - DO1(buf); - } while (--len); - - return crc; + return crc32_no_comp(crc ^ 0xffffffffL, p, len) ^ 0xffffffffL; }
-#endif - /* * Calculate the crc32 checksum triggering the watchdog every 'chunk_sz' bytes * of input. -- 1.6.4.4
Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time? CC: leon.he@msn.com; u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 11:55:18 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
- impl. a better crc32(use the one from linux)
Attaching a very crude port of linux crc32. This boots a linux img for me and handles the environment crc as well. Feel free to clean it up and submit to u-boot.
JockeSo I could not help myself, here is a better port of crc32 to u-boot. You will probably get at small conflict due to LINK_OFF, just remove the LINK_OFF stuff for now. Could you test and report? Do you have a little or big endian target?
I cannot test it for current stage, for project time issue. I'll test it and report some time later. Our target is ARM11, little endian.
Jocke
From 7b98aab2aa940b47b81d3a548c8d786016cd2ee8 Mon Sep 17 00:00:00 2001 From: Joakim Tjernlund Joakim.Tjernlund@transmode.se Date: Tue, 3 Nov 2009 11:39:43 +0100 Subject: [PATCH] crc32: Impl. linux optimized crc32()
Ported over the more efficient linux crc32() function.
lib_generic/crc32.c | 208 +++++++++++++++++++++++++++++---------------------- 1 files changed, 117 insertions(+), 91 deletions(-)
diff --git a/lib_generic/crc32.c b/lib_generic/crc32.c index 2e11548..d3bb92b 100644 --- a/lib_generic/crc32.c +++ b/lib_generic/crc32.c @@ -13,6 +13,7 @@ #else #include <stdint.h> #endif +#include <asm/byteorder.h>
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) #include <watchdog.h> @@ -52,6 +53,7 @@ local void make_crc_table OF((void)); the information needed to generate CRC's on data a byte at a time for all combinations of CRC register values and incoming bytes. */ +#define tole(x) cpu_to_le32(x) local void make_crc_table() { uint32_t c; @@ -70,7 +72,7 @@ local void make_crc_table() c = (uLong)n; for (k = 0; k < 8; k++) c = c & 1 ? poly ^ (c >> 1) : c >> 1;
- crc_table[n] = c;
- crc_table[n] = tole(c); } crc_table_empty = 0;
} @@ -78,59 +80,73 @@ local void make_crc_table() /* ========================================================================
- Table of CRC-32's of all single-byte values (made by make_crc_table)
*/ +#define tole(x) __constant_cpu_to_le32(x)
local const uint32_t crc_table[256] = {
- 0x00000000L, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L,
- 0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L,
- 0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L,
- 0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL,
- 0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L,
- 0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L,
- 0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L,
- 0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL,
- 0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L,
- 0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL,
- 0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L,
- 0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L,
- 0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L,
- 0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL,
- 0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL,
- 0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L,
- 0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL,
- 0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L,
- 0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L,
- 0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L,
- 0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL,
- 0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L,
- 0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L,
- 0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL,
- 0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L,
- 0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L,
- 0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L,
- 0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L,
- 0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L,
- 0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL,
- 0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL,
- 0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L,
- 0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L,
- 0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL,
- 0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL,
- 0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L,
- 0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, 0xc5ba3bbeL,
- 0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, 0xc2d7ffa7L, 0xb5d0cf31L,
- 0x2cd99e8bL, 0x5bdeae1dL, 0x9b64c2b0L, 0xec63f226L, 0x756aa39cL,
- 0x026d930aL, 0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L,
- 0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, 0x92d28e9bL,
- 0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, 0x86d3d2d4L, 0xf1d4e242L,
- 0x68ddb3f8L, 0x1fda836eL, 0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L,
- 0x18b74777L, 0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL,
- 0x8f659effL, 0xf862ae69L, 0x616bffd3L, 0x166ccf45L, 0xa00ae278L,
- 0xd70dd2eeL, 0x4e048354L, 0x3903b3c2L, 0xa7672661L, 0xd06016f7L,
- 0x4969474dL, 0x3e6e77dbL, 0xaed16a4aL, 0xd9d65adcL, 0x40df0b66L,
- 0x37d83bf0L, 0xa9bcae53L, 0xdebb9ec5L, 0x47b2cf7fL, 0x30b5ffe9L,
- 0xbdbdf21cL, 0xcabac28aL, 0x53b39330L, 0x24b4a3a6L, 0xbad03605L,
- 0xcdd70693L, 0x54de5729L, 0x23d967bfL, 0xb3667a2eL, 0xc4614ab8L,
- 0x5d681b02L, 0x2a6f2b94L, 0xb40bbe37L, 0xc30c8ea1L, 0x5a05df1bL,
- 0x2d02ef8dL
+tole(0x00000000L), tole(0x77073096L), tole(0xee0e612cL), tole(0x990951baL), +tole(0x076dc419L), tole(0x706af48fL), tole(0xe963a535L), tole(0x9e6495a3L), +tole(0x0edb8832L), tole(0x79dcb8a4L), tole(0xe0d5e91eL), tole(0x97d2d988L), +tole(0x09b64c2bL), tole(0x7eb17cbdL), tole(0xe7b82d07L), tole(0x90bf1d91L), +tole(0x1db71064L), tole(0x6ab020f2L), tole(0xf3b97148L), tole(0x84be41deL), +tole(0x1adad47dL), tole(0x6ddde4ebL), tole(0xf4d4b551L), tole(0x83d385c7L), +tole(0x136c9856L), tole(0x646ba8c0L), tole(0xfd62f97aL), tole(0x8a65c9ecL), +tole(0x14015c4fL), tole(0x63066cd9L), tole(0xfa0f3d63L), tole(0x8d080df5L), +tole(0x3b6e20c8L), tole(0x4c69105eL), tole(0xd56041e4L), tole(0xa2677172L), +tole(0x3c03e4d1L), tole(0x4b04d447L), tole(0xd20d85fdL), tole(0xa50ab56bL), +tole(0x35b5a8faL), tole(0x42b2986cL), tole(0xdbbbc9d6L), tole(0xacbcf940L), +tole(0x32d86ce3L), tole(0x45df5c75L), tole(0xdcd60dcfL), tole(0xabd13d59L), +tole(0x26d930acL), tole(0x51de003aL), tole(0xc8d75180L), tole(0xbfd06116L), +tole(0x21b4f4b5L), tole(0x56b3c423L), tole(0xcfba9599L), tole(0xb8bda50fL), +tole(0x2802b89eL), tole(0x5f058808L), tole(0xc60cd9b2L), tole(0xb10be924L), +tole(0x2f6f7c87L), tole(0x58684c11L), tole(0xc1611dabL), tole(0xb6662d3dL), +tole(0x76dc4190L), tole(0x01db7106L), tole(0x98d220bcL), tole(0xefd5102aL), +tole(0x71b18589L), tole(0x06b6b51fL), tole(0x9fbfe4a5L), tole(0xe8b8d433L), +tole(0x7807c9a2L), tole(0x0f00f934L), tole(0x9609a88eL), tole(0xe10e9818L), +tole(0x7f6a0dbbL), tole(0x086d3d2dL), tole(0x91646c97L), tole(0xe6635c01L), +tole(0x6b6b51f4L), tole(0x1c6c6162L), tole(0x856530d8L), tole(0xf262004eL), +tole(0x6c0695edL), tole(0x1b01a57bL), tole(0x8208f4c1L), tole(0xf50fc457L), +tole(0x65b0d9c6L), tole(0x12b7e950L), tole(0x8bbeb8eaL), tole(0xfcb9887cL), +tole(0x62dd1ddfL), tole(0x15da2d49L), tole(0x8cd37cf3L), tole(0xfbd44c65L), +tole(0x4db26158L), tole(0x3ab551ceL), tole(0xa3bc0074L), tole(0xd4bb30e2L), +tole(0x4adfa541L), tole(0x3dd895d7L), tole(0xa4d1c46dL), tole(0xd3d6f4fbL), +tole(0x4369e96aL), tole(0x346ed9fcL), tole(0xad678846L), tole(0xda60b8d0L), +tole(0x44042d73L), tole(0x33031de5L), tole(0xaa0a4c5fL), tole(0xdd0d7cc9L), +tole(0x5005713cL), tole(0x270241aaL), tole(0xbe0b1010L), tole(0xc90c2086L), +tole(0x5768b525L), tole(0x206f85b3L), tole(0xb966d409L), tole(0xce61e49fL), +tole(0x5edef90eL), tole(0x29d9c998L), tole(0xb0d09822L), tole(0xc7d7a8b4L), +tole(0x59b33d17L), tole(0x2eb40d81L), tole(0xb7bd5c3bL), tole(0xc0ba6cadL), +tole(0xedb88320L), tole(0x9abfb3b6L), tole(0x03b6e20cL), tole(0x74b1d29aL), +tole(0xead54739L), tole(0x9dd277afL), tole(0x04db2615L), tole(0x73dc1683L), +tole(0xe3630b12L), tole(0x94643b84L), tole(0x0d6d6a3eL), tole(0x7a6a5aa8L), +tole(0xe40ecf0bL), tole(0x9309ff9dL), tole(0x0a00ae27L), tole(0x7d079eb1L), +tole(0xf00f9344L), tole(0x8708a3d2L), tole(0x1e01f268L), tole(0x6906c2feL), +tole(0xf762575dL), tole(0x806567cbL), tole(0x196c3671L), tole(0x6e6b06e7L), +tole(0xfed41b76L), tole(0x89d32be0L), tole(0x10da7a5aL), tole(0x67dd4accL), +tole(0xf9b9df6fL), tole(0x8ebeeff9L), tole(0x17b7be43L), tole(0x60b08ed5L), +tole(0xd6d6a3e8L), tole(0xa1d1937eL), tole(0x38d8c2c4L), tole(0x4fdff252L), +tole(0xd1bb67f1L), tole(0xa6bc5767L), tole(0x3fb506ddL), tole(0x48b2364bL), +tole(0xd80d2bdaL), tole(0xaf0a1b4cL), tole(0x36034af6L), tole(0x41047a60L), +tole(0xdf60efc3L), tole(0xa867df55L), tole(0x316e8eefL), tole(0x4669be79L), +tole(0xcb61b38cL), tole(0xbc66831aL), tole(0x256fd2a0L), tole(0x5268e236L), +tole(0xcc0c7795L), tole(0xbb0b4703L), tole(0x220216b9L), tole(0x5505262fL), +tole(0xc5ba3bbeL), tole(0xb2bd0b28L), tole(0x2bb45a92L), tole(0x5cb36a04L), +tole(0xc2d7ffa7L), tole(0xb5d0cf31L), tole(0x2cd99e8bL), tole(0x5bdeae1dL), +tole(0x9b64c2b0L), tole(0xec63f226L), tole(0x756aa39cL), tole(0x026d930aL), +tole(0x9c0906a9L), tole(0xeb0e363fL), tole(0x72076785L), tole(0x05005713L), +tole(0x95bf4a82L), tole(0xe2b87a14L), tole(0x7bb12baeL), tole(0x0cb61b38L), +tole(0x92d28e9bL), tole(0xe5d5be0dL), tole(0x7cdcefb7L), tole(0x0bdbdf21L), +tole(0x86d3d2d4L), tole(0xf1d4e242L), tole(0x68ddb3f8L), tole(0x1fda836eL), +tole(0x81be16cdL), tole(0xf6b9265bL), tole(0x6fb077e1L), tole(0x18b74777L), +tole(0x88085ae6L), tole(0xff0f6a70L), tole(0x66063bcaL), tole(0x11010b5cL), +tole(0x8f659effL), tole(0xf862ae69L), tole(0x616bffd3L), tole(0x166ccf45L), +tole(0xa00ae278L), tole(0xd70dd2eeL), tole(0x4e048354L), tole(0x3903b3c2L), +tole(0xa7672661L), tole(0xd06016f7L), tole(0x4969474dL), tole(0x3e6e77dbL), +tole(0xaed16a4aL), tole(0xd9d65adcL), tole(0x40df0b66L), tole(0x37d83bf0L), +tole(0xa9bcae53L), tole(0xdebb9ec5L), tole(0x47b2cf7fL), tole(0x30b5ffe9L), +tole(0xbdbdf21cL), tole(0xcabac28aL), tole(0x53b39330L), tole(0x24b4a3a6L), +tole(0xbad03605L), tole(0xcdd70693L), tole(0x54de5729L), tole(0x23d967bfL), +tole(0xb3667a2eL), tole(0xc4614ab8L), tole(0x5d681b02L), tole(0x2a6f2b94L), +tole(0xb40bbe37L), tole(0xc30c8ea1L), tole(0x5a05df1bL), tole(0x2d02ef8dL) }; #endif
@@ -148,60 +164,70 @@ const uint32_t * ZEXPORT get_crc_table() #endif
/* ========================================================================= */ -#define DO1(buf) crc = crc_tab[((int)crc ^ (*buf++)) & 0xff] ^ (crc >> 8); -#define DO2(buf) DO1(buf); DO1(buf); -#define DO4(buf) DO2(buf); DO2(buf); -#define DO8(buf) DO4(buf); DO4(buf); +# 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
/* ========================================================================= */ -uint32_t ZEXPORT crc32 (uint32_t crc, const Bytef *buf, uInt len)
+/* No ones complement version. JFFS2 (and other things ?)
- don't use ones compliment in their CRC calculations.
- */
+uint32_t ZEXPORT crc32_no_comp(uint32_t crc, const Bytef *p, uInt len) { #ifdef LINK_OFF
- const uint32_t *crc_tab = LINK_OFF(crc_table);
- const uint32_t *tab = LINK_OFF(crc_table);
#else
- const uint32_t *crc_tab = crc_table;
- const uint32_t *tab = crc_table;
#endif
- const uint32_t *b =(uint32_t *)p;
#ifdef DYNAMIC_CRC_TABLE if (crc_table_empty) make_crc_table(); #endif
- crc = crc ^ 0xffffffffL;
- while (len >= 8)
- {
DO8(buf);len -= 8;
- crc = __cpu_to_le32(crc);
- /* Align it */
- if(((long)b)&3 && len){
do {uint8_t *p = (uint8_t *)b;DO_CRC(*p++);b = (void *)p;} while ((--len) && ((long)b)&3 );
- if (len) do {
DO1(buf);- } while (--len);
- return crc ^ 0xffffffffL;
- if(len >= 4){
/* load data 32 bits wide, xor data 32 bits wide. */size_t save_len = len & 3;len = len >> 2;--b; /* use pre increment below(*++b) for speed */do {crc ^= *++b;DO_CRC(0);DO_CRC(0);DO_CRC(0);DO_CRC(0);} while (--len);b++; /* point to next byte(s) */len = save_len;- }
- /* And the last few bytes */
- if(len){
do {uint8_t *p = (uint8_t *)b;DO_CRC(*p++);b = (void *)p;} while (--len);- }
- return __le32_to_cpu(crc);
} +#undef DO_CRC
-#if defined(CONFIG_CMD_JFFS2) || defined(CONFIG_CMD_NAND)
-/* No ones complement version. JFFS2 (and other things ?)
- don't use ones compliment in their CRC calculations.
- */
-uint32_t ZEXPORT crc32_no_comp(uint32_t crc, const Bytef *buf, uInt len) +uint32_t ZEXPORT crc32 (uint32_t crc, const Bytef *p, uInt len) { -#ifdef DYNAMIC_CRC_TABLE
- if (crc_table_empty)
make_crc_table();-#endif
- while (len >= 8)
- {
DO8(buf);len -= 8;- }
- if (len) do {
DO1(buf);- } while (--len);
- return crc;
return crc32_no_comp(crc ^ 0xffffffffL, p, len) ^ 0xffffffffL;}
-#endif
/*
- Calculate the crc32 checksum triggering the watchdog every 'chunk_sz' bytes
- of input.
-- 1.6.4.4
_________________________________________________________________ MSN十年回馈，每位用户可免费获得价值25元的卡巴斯基反病毒软件2010激活码，快来领取！ http://kaba.msn.com.cn/?k=1
HeLei leon.he@msn.com wrote on 03/11/2009 12:08:39:
Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2
scaning time?
CC: leon.he@msn.com; u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 11:55:18 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
- impl. a better crc32(use the one from linux)
Attaching a very crude port of linux crc32. This boots a linux img for me and handles the environment crc as well. Feel free to clean it up and submit to u-boot.
Jocke
So I could not help myself, here is a better port of crc32 to u-boot. You will probably get at small conflict due to LINK_OFF, just remove the LINK_OFF stuff for now. Could you test and report? Do you have a little or big endian target?
I cannot test it for current stage, for project time issue. I'll test it and report some time later.
OK, when then? In the near future or weeks away?
Our target is ARM11, little endian.
Good, I got big endian(PPC).
Please trim your replies, including my patch in the reply is just a waste of space.
Jocke
Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time? To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 12:13:11 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 12:08:39:
Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2
scaning time?
CC: leon.he@msn.com; u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 11:55:18 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
- impl. a better crc32(use the one from linux)
Attaching a very crude port of linux crc32. This boots a linux img for me and handles the environment crc as well. Feel free to clean it up and submit to u-boot.
Jocke
So I could not help myself, here is a better port of crc32 to u-boot. You will probably get at small conflict due to LINK_OFF, just remove the LINK_OFF stuff for now. Could you test and report? Do you have a little or big endian target?
I cannot test it for current stage, for project time issue. I'll test it and report some time later.
OK, when then? In the near future or weeks away? Weeks away, I'm sorry. This week I have to spend time on project. And I have to leave the office for continuous 3 weeks for my wife will give a birth to my baby:)
Our target is ARM11, little endian.
Good, I got big endian(PPC).
Please trim your replies, including my patch in the reply is just a waste of space.
Jocke
_________________________________________________________________ “游日本，拿现金”MClub白领股神大赛火热报名中 http://club.msn.cn/pr/?a=emoney
Dear Joakim Tjernlund,
In message OF0C7E2190.C549E7B4-ONC1257663.003B88C7-C1257663.003BFEAC@transmode.se you wrote:
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
- impl. a better crc32(use the one from linux)
Attaching a very crude port of linux crc32. This boots a linux img for me and handles the environment crc as well. Feel free to clean it up and submit to u-boot.
JockeSo I could not help myself, here is a better port of crc32 to u-boot. You will probably get at small conflict due to LINK_OFF, just remove the LINK_OFF stuff for now. Could you test and report? Do you have a little or big endian target?
I understand you will resend this patch with a proper Subject: for real review on the list?
You also might want to explain in which way this patch is "more efficient" - in terms of memory footprint, or execution time, or both? And by how much? Tested in which envrionment(s) ?
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote on 03/11/2009 14:21:08:
Dear Joakim Tjernlund,
In message <OF0C7E2190.C549E7B4-ONC1257663.003B88C7-C1257663. 003BFEAC@transmode.se> you wrote:
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
- impl. a better crc32(use the one from linux)
Attaching a very crude port of linux crc32. This boots a linux img for me and handles the environment crc as well. Feel free to clean it up and submit to u-boot.
JockeSo I could not help myself, here is a better port of crc32 to u-boot. You will probably get at small conflict due to LINK_OFF, just remove the LINK_OFF stuff for now. Could you test and report? Do you have a little or big endian target?
I understand you will resend this patch with a proper Subject: for real review on the list?
Yes, I just wanted some external testing but this seems not to happen.
You also might want to explain in which way this patch is "more efficient" - in terms of memory footprint, or execution time, or both? And by how much? Tested in which envrionment(s) ?
hmm, I did this optimization many years ago for JFFS2 in linux. I don't have any numbers but I can give you some hints w.r.t number of insn in the inner loop(later though). Footprint will be higher.
Jocke
Wolfgang Denk wd@denx.de wrote on 03/11/2009 14:21:08:
Dear Joakim Tjernlund,
In message <OF0C7E2190.C549E7B4-ONC1257663.003B88C7-C1257663. 003BFEAC@transmode.se> you wrote:
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
Thank you, Jocke
- impl. a better crc32(use the one from linux)
Attaching a very crude port of linux crc32. This boots a linux img for me and handles the environment crc as well. Feel free to clean it up and submit to u-boot.
JockeSo I could not help myself, here is a better port of crc32 to u-boot. You will probably get at small conflict due to LINK_OFF, just remove the LINK_OFF stuff for now. Could you test and report? Do you have a little or big endian target?
I understand you will resend this patch with a proper Subject: for real review on the list?
You also might want to explain in which way this patch is "more efficient" - in terms of memory footprint, or execution time, or both? And by how much? Tested in which envrionment(s) ?
Wolfgang, I hope the new patch I sent with some data points in the commit msg will do.
Jocke
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
- Don't scan more than you have to, that is, ls/read /some/file
should only scan and keep records to do the ls/read of that particular file.
So we have to have an index, or something like that, to tell which file in which EBs. This index is always generated by the scan for the first time. The only workaround like this idea is to divide the flash into several paritions, the scan is performed on certain partition each time.
Forgot to comment on this one :) I belive u-boot creates a cache for the whole FS a first access so that later accesses are fast. I think this is suboptimal. Consider the common case to boot a linux kernel, you only want to get at the kernel image so creating a cache for the whole FS is a waste.
Partitions works too, but is a waste of flash and it can be hard to get the partition size(s) right.
Jocke
Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time? To: leon.he@msn.com CC: u-boot@lists.denx.de From: joakim.tjernlund@transmode.se Date: Tue, 3 Nov 2009 10:43:46 +0100
HeLei leon.he@msn.com wrote on 03/11/2009 09:21:04:
- Don't scan more than you have to, that is, ls/read /some/file
should only scan and keep records to do the ls/read of that particular file.
So we have to have an index, or something like that, to tell which file in which EBs. This index is always generated by the scan for the first time. The only workaround like this idea is to divide the flash into several paritions, the scan is performed on certain partition each time.
Forgot to comment on this one :) I belive u-boot creates a cache for the whole FS a first access so that later accesses are fast. I think this is suboptimal. Consider the common case to boot a linux kernel, you only want to get at the kernel image so creating a cache for the whole FS is a waste. Yes, I agree!
Partitions works too, but is a waste of flash and it can be hard to get the partition size(s) right. Yes, this need another information on partition size as well as starting address. I think uboot environment can handle this.
Jocke
_________________________________________________________________ 约会说不清地方？来试试微软地图最新msn互动功能！ http://ditu.live.com/?form=TL&swm=1
Hi, All
Each time JFFS2 initialized, uboot need to scan the whole flash. This is fairly time consuming.
So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I believe this can also be used to UBOOT to reduce booting time.
Does UBOOT support this feature? or does any other solution in uboot to reduce JFFS2 scaning time?
Well, I well answer the question myself, after I review the code. U-boot supports this feature around since 2008-12, but it just supports EBS for NOR flash. NAND flash EBS is still not supported yet. I think it's more important for NAND flash, for NAND reading-cycle consumes more time as far as I know. _________________________________________________________________ MSN十年回馈，每位用户可免费获得价值25元的卡巴斯基反病毒软件2010激活码，快来领取！ http://kaba.msn.com.cn/?k=1
participants (3)
-
HeLei -
Joakim Tjernlund -
Wolfgang Denk