[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[HeLei]

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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

>
> 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[HeLei]

Thank you, Jocke
 

> Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?
> To: leon.he at msn.com
> CC: u-boot at lists.denx.de
> From: joakim.tjernlund at 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

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 at msn.com
> > CC: u-boot at lists.denx.de
> > From: joakim.tjernlund at 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

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 at msn.com
> > CC: u-boot at lists.denx.de
> > From: joakim.tjernlund at 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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crc32-new.c
Type: application/octet-stream
Size: 16057 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20091103/0e661951/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crc32defs.h
Type: application/octet-stream
Size: 1072 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20091103/0e661951/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crc32table.h
Type: application/octet-stream
Size: 9976 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20091103/0e661951/attachment-0002.obj 

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[HeLei]

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 at msn.com
> CC: u-boot at lists.denx.de
> From: joakim.tjernlund at 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 at msn.com
> > > CC: u-boot at lists.denx.de
> > > From: joakim.tjernlund at 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[HeLei]

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 at msn.com
> CC: u-boot at lists.denx.de
> From: joakim.tjernlund at 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 at msn.com
> > > CC: u-boot at lists.denx.de
> > > From: joakim.tjernlund at 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[HeLei]

> Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2	scaning time?
> To: leon.he at msn.com
> CC: u-boot at lists.denx.de
> From: joakim.tjernlund at 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

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 at msn.com
> > CC: u-boot at lists.denx.de
> > From: joakim.tjernlund at 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[HeLei]

> Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2	scaning time?
> To: leon.he at msn.com
> CC: u-boot at lists.denx.de
> From: joakim.tjernlund at 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[HeLei]

> Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2	scaning time?
> To: leon.he at msn.com
> CC: u-boot at lists.denx.de
> From: joakim.tjernlund at 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 at msn.com
> > > CC: u-boot at lists.denx.de
> > > From: joakim.tjernlund at 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

>
> 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[HeLei]

> Subject: Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2	scaning time?
> CC: leon.he at msn.com; u-boot at lists.denx.de
> From: joakim.tjernlund at 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.   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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

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 at msn.com; u-boot at lists.denx.de
> > From: joakim.tjernlund at 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[HeLei]

> Subject: RE: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2	scaning time?
> To: leon.he at msn.com
> CC: u-boot at lists.denx.de
> From: joakim.tjernlund at 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 at msn.com; u-boot at lists.denx.de
> > > From: joakim.tjernlund at 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Wolfgang Denk]

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.
> >
> >      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 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

-- 
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: wd at denx.de
People are always a lot more complicated than you  think.  It's  very
important to remember that.             - Terry Pratchett, _Truckers_

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 03/11/2009 14:21:08:
>
> Dear Joakim Tjernlund,
>
> In message <OF0C7E2190.C549E7B4-ONC1257663.003B88C7-C1257663.
> 003BFEAC at 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.
> > >
> > >      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 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[Joakim Tjernlund]

Wolfgang Denk <wd@denx.de> wrote on 03/11/2009 14:21:08:
>
> Dear Joakim Tjernlund,
>
> In message <OF0C7E2190.C549E7B4-ONC1257663.003B88C7-C1257663.
> 003BFEAC at 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.
> > >
> > >      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 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

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

[HeLei]

>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