Dual boot setup

[anonuk]

could i use this to flash pdaxrom to sd on a 860?

Actually I ran the script to try and create the image, it runs fine, formats and then says

Copying current rom to temp image....
Segmentation Fault
umount: /tmp/tmp_src Invalid argument
Making modifications to new filesystem image.
cp: cannot create regular file \'/tmp/tmp_dest/root/etc/rc.d/rc.sysinit\': No such file or directory

followed by lots of No such file or directory errors...

Any ideas whats wrong - i end up with a 4kb initrd.bin?
im using cacko 1.20 rom...

[derekp]

could i use this to flash pdaxrom to sd on a 860?

You can use the basic concepts, but you\'d have to do a slightly different implimentation.
For one, the 5500\'s initrd.bin file is a cramfs image, whereas the other zaurus models (including the 860) is a jffs2 image.  Therefore you\'d have to modify the modrom-dualboot script accordingly.
Unless your refering to taking the pdaxrom and putting it on the SD to run it on a 5500.  For this, you can use the bulk of the oz2sd.sh script, but the last part of oz2sd.sh applies some patches that are specific to openzaurus (some of these patches help it run better off the SD card, others are needed becausing were still running off a standard kernel instead of openzaurus\'s kernel).  Also, the X server for the 860 I believe won\'t work on the 5500 (I tried this already), you\'d have to swap in one for the 5500\'s chipset.

This will be my next project, to get the pdaxrom working on the 5500 off the sd card.

[jerrybme]

Thanks, great work derekp! I\'ll try it out tomorrow.  

[derekp]

One thing I just caught.
If you are running tkcrom, then you will need to enter \"unset LD_LIBRARY_PATH\" before running oz2sd.sh.
The reason is, tkcrom sets LD_LIBRARY_PATH to point to /mnt/card/lib.  This causes any command executed after oz is extracted to the SD card to pick up the wrong libraries.

[jerrybme]

derek:
I\'m trying to modify your modrom-dualboot.sh to dual boot my C750 from Cacko ROM to pdaXrom on SD.  

Since the latest Cacko Qt ROM uses both cramfs & jffs2, I tried your script on the 1.18 version (no need to make it any more difficult!). By increasing the tmp_img_size to 64 and mtdblock0 to mtdblock2 I\'ve gotten it to work up to the creation of the initrd.bin.

 Since it needs to be jffs2, I was looking at the build scripts for the file systems. I copied the binary mkfs.jffs2 to the Z but am struggling with the command to create the initrd.bin. I can\'t get the syntax correct

Code: [Select]

/home/root/usr/bin/mkfs.jffs2 -r /tmp/tmp_dest $OUTFILE

Obviously this isn\'t working. Any clues you could send me would be greatly appreciated.

Can\'t wait to try hacking on the oz2sd.sh to try and get it to extract the xrom  :shock:

[derekp]

Code: [Select]

/home/root/usr/bin/mkfs.jffs2 -r /tmp/tmp_dest $OUTFILE

Try it with \"-o $OUTFILE\", the rest of the command line looks ok (at least according to the manpage for mkfs.jffs2).
Also, be careful with modifying the 750 (unless you already know what your are doing), I\'ve read of a few people on this board bricking theirs.
Also, when you get to modifying the oz2sd.sh script, most of it can be used as is, but you\'ll have to take out/replace the bottom part where it applies some oz-specific patches (but leave in the section where it creates the init.card file).
Good luck
--derek

[Joshp]

/.

[stampsm]

has anyone tried this on 5600

[jerrybme]

Well, I give up for tonight. I can\'t get the mkfs.jffs2 syntax to work right. Keep getting -> mkfs.jffs2: 1: Syntax error: \"(\" unexpected <- no matter how I try. The man pages aren\'t that helpful in usage.  I tried following the example in the build.sh script that is used to create initrd.bin from the sharp rootfs, but same damn error :evil:

[derekp]

jerrybme, where\'d you get your copy of mkfs.jffs2?  From the error, it looks like it is a shell script.  If so, the problem might be that it uses bash syntax, and the default shell on the zaurus is a smaller stripped-down shell.  Therefore you\'d need to install bash.

[jerrybme]

jerrybme, where\'d you get your copy of mkfs.jffs2?  From the error, it looks like it is a shell script.  If so, the problem might be that it uses bash syntax, and the default shell on the zaurus is a smaller stripped-down shell.  Therefore you\'d need to install bash.

Well, I\'ve tried several sources, but they all give same error. I\'m using the mkfs.jffs2 from the C7X0_rootfs that sashz posted a while back, it was for the 1.18 version. It was in the bin directory with the build.sh script. I\'ll try installing bash, but I\'m also of thinking about just directly editing the rc.sysinit file directly and creating the sbin/init your modrom_dualboot.sh script creates.

Thanks for your help and showing the way

[jerrybme]

derekp: while I wait for the reflash to finish, I\'m looking at the rc.rofilesys scripts in Cacko Qt & pdaXrom and they are very different. Are the rc.rofilesys scripts the same in OZ & Sharp? If so, to get this to work, I\'m thinking that when booting to pdaXrom, it may be necessary to have the pdaXrom\'s rofilesys script run after the detection of the rc.card on the SD. Is that even possible? Do we need the rofilesys run before that call is made?

Sorry for the potentially stupid questions, but as a linux newbie, I\'m in WAY over my head  :shock:

Thanks

[derekp]

jerrybme,
I had actually combined two independant projects into one.  The part that is used to dualboot another os from the SD card is in the /sbin/init replacement script (don\'t forget to put the old copy of /sbin/init into /sbin/sys/init).  Another project I had was to optionally boot up with /home on SD.  That\'s where the rc.sysinit changes come into play.   If you are just inplementing the os dualboot part, you can leave out modifying the rc.sysinit script.

As for how rc.rofilesys and rc.sysinit work, on the sharp (and tkc) rom, they boot up with a read-only root file system, pointing to the cramfs image in rom.  The rc.sysinit script calls rc.rofilesys, which will initialize a new ramdisk if this is the first boot after a reset.  Then rc.sysinit will mount the ramdisk to /home.  What my home-on-sd modifications do is check for the existance of an rc.card script (on the SD) to execute prior to mounting up the ramdisk /home.  This rc.card script can then be written to do a number of things, but the primary purpose is to mount the SD as home instead of the ramdisk.  The rc.card and SD setup is done by the script \"prep-home-sd.sh\".  This is basically the same setup I sent into Proto, which is included in the tckrom 2.0 alpha3 release.

Again, the dualboot rom (/sbin/init changes) and the dualboot home-on-sd (modified /etc/rc.sysinit) are two independant projects, I just combined them both in the modrom script convenience.

When I get a free moment, I\'ll download some of the initrd.bin\'s for the other Zaurus models and try to figure them out a bit.

--derek

[jerrybme]

I gave up on mkfs.jffs2, I found a bash.ipk, had to mount -o rw,remount / to get it to install, but still no joy. Decided to modify the ROM directly and created a new init & card.init scripts. I figured if I can get it at least dual boot, I\'ll tackle home on SD later.

Since I wasn\'t trying to copy out the ROM, I decided to go back to the latest Cacko ROM. I found that the Cacko 1.20\'s init file is really a symlink to telinit, I moved it anyway and found that reboot is only possible with a battery pull (but at least it still booted ok with the new init file).

Getting the oz2sd script to work on the pdaxrom initrd.bin, proved difficult as well, kept getting device is full error, swap errors plus the mtdram & jffs2 modules were throwing errors. I commented out the OZ revisions, the jffs2 insmod and increased the swap file to 25, but still device errors. So I gave up and just mounted the initrd.bin on my linux box and copied out the file structure to a tmp folder to copy to the SD. Wierd thing was the total file system was a little over 8 megs, sigh.

Learning lots, but getting nowhere. Back to trying to figure out why not everything is getting written out of the 20+ meg pdaXrom initrd..

A lot of work just to find out whether this\'ll work, but it is fun in a frustrating way

[jerrybme]

So far still no luck    but I have made some progress and perhaps someone with more linux knowledge will, either point me in the right direction or take this project up. I think being able to dual boot the CXXX series would be so cool (and useful)

Status so far-] I gave up trying to get derekp\'s scripts to work on the C750, I think there are too many differences from the 5500. So, I made the init and init.card files manually (and yes chmoded them correctly) Finally got the mounting of the jffs2 image of the pdaXrom initrd.bin to work correctly on my linux box and copied it to a 256 mb SD card, I copied over the init.card file that derekp\'s script is supposed to create.

The init file must be very different from the 5500, as it is a symlink to telinit and when you move it to /sbin/sys (still pointing back to telinit) the Z won\'t reboot without a battery pull (this was true for both the cacko 1.18 & 1.20 versions). The telinit file is not a script, looks to be code (at least when you try and view it in Midnight Commander). I went ahead anyway and moved the new init in place.

On reboot, the init file doesn\'t kick off the init.card as it is supposed to. I installed a kernel that shows the boot up messages but couldn\'t make much out of the text as it flew by. I did halt the boot process and went to a linux terminal by pressing a key during the Wait..1, 2 message. At that point in the booting process the SD drivers are already insmodded and if I tried

Code: [Select]

exec init
I\'d get the messeage

Code: [Select]

Usage: init 0123456SsQqAaBbCcUu

I then tried running the commands in the init script. Nothing worked until I got to the copy init.card to /dev. Then I could run the init.card from /dev however, it would work until it reached the command

Code: [Select]

exec /sbin/init
Which of course would throw the error listed above. follwed by the error,

Code: [Select]

spawning ln too fast, wait 5 minutes..

So, that\'s as far as I could take this, until until someone explains to me how the init process works on the CXXX series. If anyone has a clue please let me know.

Cheers,
Jerry