[RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Andrea Adami]

Reading the post about gnu-tar I remember we talked about a new way to
install 2.6 kernels and images on Zaurus.

Well, there are very good reasons to make this now obsolete:
- we can flash from console (2.6 userspace)
- we have a different image-layout (kernel in /boot), thus we can boot
from every hd partition
- we can create jffs2 images (see Narcissus) and flash these from
console, without striping the legacy headers. We can even have 2
images in nand

My idea would be:

-refactor updater.sh and flash only kernels
-provide an updater script

An example of the commands on c7x0 (see
http://www.h5.dion.ne.jp/~rimemoon/zaurus/pic/nandmap.jpg):

Kernel:
nandlogical /dev/mtd1 WRITE 0x0E0000 0x140000 zImage.bin

Rootfs:
flash_eraseall -j /dev/mtd2
nandwrite /dev/mtd2 rootfs.jffs2

Optionally:
flash_eraseall -j /dev/mtd3
nandwrite /dev/mtd3 rootfs.jffs2


Better ideas?

Andrea

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Marcin Juszkiewicz]

Dnia niedziela, 17 stycznia 2010 o 15:06:19 Andrea Adami napisał(a):
> Reading the post about gnu-tar I remember we talked about a new way to
> install 2.6 kernels and images on Zaurus.

Any way is good but I hope that there still be a way to install OE build 
results on SharpROM based Zaurus.
 
> Well, there are very good reasons to make this now obsolete:
> - we can flash from console (2.6 userspace)
> - we have a different image-layout (kernel in /boot), thus we can boot
> from every hd partition
> - we can create jffs2 images (see Narcissus) and flash these from
> console, without striping the legacy headers. We can even have 2
> images in nand
 
> My idea would be:
> 
> -refactor updater.sh and flash only kernels
> -provide an updater script

What about this (note that I do not track kexecboot work):

- make updater.sh which will flash kexecboot kernel and reboot
- let kexecboot initramfs checks for CARD/sysupdate.sh
- CARD/sysupdate.sh will update rootfs/kernel etc and reboot

sysupdate.sh name is chosen to allow updater.sh (for crappy bootloader) and 
real update script to be on same card. This way you can update any Zaurus 
nevermind what kind of OS it had before. And as kexecboot kernel will have our 
nand split table inside anything can be done in sysupdate.sh script (formating 
/ and /home for example or installing them from card images etc).
 
Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Yuri Bushmelev]

Hello!
> Dnia niedziela, 17 stycznia 2010 o 15:06:19 Andrea Adami napisał(a):
> > Reading the post about gnu-tar I remember we talked about a new way to
> > install 2.6 kernels and images on Zaurus.
> 
> Any way is good but I hope that there still be a way to install OE build
> results on SharpROM based Zaurus.

You can boot old 2.4 based ROM's with kexecboot too. I have reports of 
success booting of Cacko e.g.

> What about this (note that I do not track kexecboot work):
> 
> - make updater.sh which will flash kexecboot kernel and reboot
> - let kexecboot initramfs checks for CARD/sysupdate.sh
> - CARD/sysupdate.sh will update rootfs/kernel etc and reboot
> 
> sysupdate.sh name is chosen to allow updater.sh (for crappy bootloader)
>  and real update script to be on same card. This way you can update any
>  Zaurus nevermind what kind of OS it had before. And as kexecboot kernel
>  will have our nand split table inside anything can be done in
>  sysupdate.sh script (formating / and /home for example or installing
>  them from card images etc).

We should not update kernel while using kexecboot. We can only update distro 
(rootfs with kernel inside) in NAND.
I'm not sure that we have too much ordinary users who will flash to NAND 
instead of external SD/CF. Advanced user can boot from console-image from SD 
and 'flash' by hands according to some README/wiki instructions. Or we can 
provide special NAND-installer image for this.

But anyway having something like legacy-updater.bb is good idea.

-- 
Yuri Bushmelev

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Andrea Adami]

I probably did not explicit that actual Narcissus images cannot be
flashed on nand if renamed initrd.bin.
And the OE-built images have the 16bytes header thus cannot be flashed
'vanilla' using nandwrite.

We should abandon the
  cat ${STAGING_LIBDIR}/sharp-flash-header/header-c700.bin
we have now in zaurus-clamshel.inc during jffs image creation and remove the
  /sbin/bcut -s 16 -o $TMPHEAD $TARGETFILE
in updater.sh.

Dunno about retro-compatibility, though.
That headers cruft could be made distro-specific for sharp-compatible.

My 2 cents

Andrea

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Andrea Adami]

Again about that Sharp headers...I tried to see why these were
necessary long ago:

Reading here  http://www.oesf.org/index.php?title=C3000_Device_Specifics#Creation_of_a_new_initrd_for_the_SL-C3000
it seems there was even an header appended to the kernel, not only one
header prepended to the initrd.

I suspect we have already broken the compatibility with original
layout (Version and Master version blocks)... so I'd go ahead
simplifying the script!

Regards

Andrea


P.S. about flashing the kernel (on clamshells, not collie)
nandlogical /dev/mtd1 WRITE 0x0E0000 0x140000 zImage.bin
vs
nandlogical /dev/mtd1 WRITE 0x0E0000 0x13C000 zImage.bin

What are these 0x4000 = 16KiB between kernel1 and kernel2?
( http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm )

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Rolf Leggewie]

Andrea Adami wrote:
> I suspect we have already broken the compatibility with original
> layout (Version and Master version blocks)... so I'd go ahead
> simplifying the script!

seems like we're wildly experimenting here.  I guess that can't be
helped.  But please document the lessons learned in a prominent place.
Thank you for your work.

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Andrea Adami]

Just for sanity I repeat here the command for c7x0:

nandlogical /dev/mtd1 WRITE 0xE0000 0x13C0000 zImage.bin

I'm still dubious about the extra space at the end of mtd1...after checksums?

Andrea

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Andrea Adami]

Again on this:

chatting with Eric about the pxa-linking-bug-r1 patch, it seems it is
needed because of a bug in updater.sh:

Same was reported here:
http://www.oesf.org/index.php?title=SL-C3000_Updater_Script

				## Bug in Sharp bit
				## original line...
				## /sbin/nandlogical $LOGOCAL_MTD WRITE $ADDR $DATASIZE $TMPDATA >
/dev/null 2>&1
				## didn't use correctly determined block size
				## cause problems for other kernels
				/sbin/nandlogical $LOGOCAL_MTD WRITE $ADDR $TMPSIZE $TMPDATA >
/dev/null 2>&1
				ADDR=`expr $ADDR + $TMPSIZE`
			fi


OpenEmbedded updater.sh still has the 'wrong' line...

Opinions?

Andrea

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Andrea Adami]

Well, I tested this patch on c7x0 and got two results:

1) we can avoid the pxa-linking-bug-r1 patch
2) we can boot 2.6.33-r6 (and some older too :)

Unexplicable (for me) unalignement issues...thx to Eric Miao for the hint!

I propose therefore to fix the updater.sh and fork the new minimal one
from this revised version.
I'd like just a couple of tests on spitz and tosa, then I'd push.

Regards

Andrea

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Rolf Leggewie]

Andrea Adami wrote:
> I'd like just a couple of tests on spitz and tosa, then I'd push.

If you let me know what and how to test, I can test the collie, too.

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Graeme Gregory]

On Tue, Feb 02, 2010 at 12:21:09AM +0100, Rolf Leggewie wrote:
> Andrea Adami wrote:
> > I'd like just a couple of tests on spitz and tosa, then I'd push.
> 
> If you let me know what and how to test, I can test the collie, too.
> 
You obviously not used your collie for a long time, its the model
that has flasher in ROM :-)

Graeme

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Andrea Adami]

Ok, I committed the fix to updater.sh, now bumped to r24.
Painfully enough, I got mixed reports about unsuccessfull flashing
(no reboot) with the latest 2.6.33-rc6 lzma-compressed kernels on C700
and C1000:

C5600 ?

C700 KO
C750 OK
C860 OK
C1000 KO
C3000 OK
C3100 ?
C3200 OK
6000* ?

Pls help testing missing models.
Thx

Andrea

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Andrea Adami]

On Sun, Feb 7, 2010 at 12:09 AM, Andrea Adami <andrea.adami@gmail.com> wrote:
> Ok, I committed the fix to updater.sh, now bumped to r24.

I forgot to say, this change only affects c7x0 models. Akita and Spitz
have own nandlogical routines.

Andrea

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Andrea Adami]

I rebump the topic because a couple of weeks ago I did some changes to
zaurus-updater.

The actual revision in OE has following targets (in capitals too):

Part.  File

mtd1 uboot.bin  =  u-boot (deprecated - old testing)

mtd1  zImage/zImage.bin  =  kernel
mtd2  initrd.bin  =  rootfs (now *with or without 16b sharp-headers*)
mtd3  home.bin  =  here you can flash a second rootfs or restore a
backup of /home if set on mtdblock3 in fstab
hdd1  hdimage1.tgz  =  rootfs on first hdd partition (spitz only. Do
we really need this one and gnu-tar for the installer?)


I suppose that all models where originally shipped with 'signed'
binaries, to have a coherent master version.
We still don't have a precise idea about the used checksum...


Regards

Andrea

Re: [RFC] Zaurus: make updater.sh obsolete for poodle, clamshells and tosa

[Rolf Leggewie]

Andrea Adami wrote:
> Well, there are very good reasons to make this now obsolete:
> - we can flash from console (2.6 userspace)
> - we have a different image-layout (kernel in /boot), thus we can boot
> from every hd partition
> - we can create jffs2 images (see Narcissus) and flash these from
> console, without striping the legacy headers. We can even have 2
> images in nand

Great.  Would be nice to see this documented somewhere in the wiki in a
language that mere humans understand.  I'll volunteer as tester.  I
think I'm stupid enough to qualify ;-)