blob-cvs-commit

Update

[Tim R. <Ti...@Ri...>]

There were a few places in blob that were using md5s and expecting to
put the results in a u32. md5 digests are 4 u32s.

load_kernel is now used instead of a raw copy if you --enable jffs2,
cramfs or zImage.

There is a bug someplace at least with shannon. When the image is loaded
at boot the md5 is different that if you just type "load kernel".

and the image loaded on boot fails to decompress, but a manually loaded
image boots.

I'm getting:

Kernel command line: console=ttySA0,115200 console=tty1
root=/dev/mtdblock1 init=/linuxrc

...

Using static partition definition
Creating 2 MTD partitions on "SA1100 flash":
0x00000000-0x00020000 : "BLOB boot loader"  
0x00020000-0x00400000 : "rootfs"          

...

Freeing init memory: 72K             
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000300:
0x0071 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000304:
0x0071 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000308:
0x0071 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000030c:
0x0071 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000310:
0x0071 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000314:
0x0071 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000318:
0x0071 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000031c:
0x0071 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000320:
0x0071 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000324:
0x0071 instead
Further such events for this erase block will not be
printed                         


on shannon with a fixed up kernel and a valid jffs2 filesystem on
mtdblock1

can't find the 0x0071 anywhere. thoughts?
-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

Re: Update

[Russ D. <Rus...@as...>]

On Sat, 2002-04-27 at 04:33, Tim Riker wrote:
> There were a few places in blob that were using md5s and expecting to
> put the results in a u32. md5 digests are 4 u32s.
> 
> load_kernel is now used instead of a raw copy if you --enable jffs2,
> cramfs or zImage.
> 
> There is a bug someplace at least with shannon. When the image is loaded
> at boot the md5 is different that if you just type "load kernel".
> 
> and the image loaded on boot fails to decompress, but a manually loaded
> image boots.
> 

thats a bit confusing, why would the rootfs be the place where there is
a difference?

Re: Update

[Tim R. <Ti...@Ri...>]

no idea. still investigating.

Russ Dill wrote:
> 
> On Sat, 2002-04-27 at 04:33, Tim Riker wrote:
> > There were a few places in blob that were using md5s and expecting to
> > put the results in a u32. md5 digests are 4 u32s.
> >
> > load_kernel is now used instead of a raw copy if you --enable jffs2,
> > cramfs or zImage.
> >
> > There is a bug someplace at least with shannon. When the image is loaded
> > at boot the md5 is different that if you just type "load kernel".
> >
> > and the image loaded on boot fails to decompress, but a manually loaded
> > image boots.
> >
> 
> thats a bit confusing, why would the rootfs be the place where there is
> a difference?

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.