iLiad Unbrickable Developer Iliad Idea

[scotty1024]

While I'm sure iRex is confidently moving forwards with their concept in how to do an iLiad restore, and this will have a useful place for developers and users alike...

As I was re-hacking my iLiad a thought came to me, especially in light of the root fs space crisis.

What if developers could boot the iLiad from an ext2 CF instead of the Sandisk Disk on Chip?

I looked at the code in linuxrc and other than some possible needed extra modprobes to have the kernel ready to mount the CF the concept looks trivial to implement.

This concept could also possibly make development internally at iRex easier as well. For us external developers it would mean we could reload our bricked CF cards and be back up very quickly.

One possible fringe benefit: faster boots. I've benchmarked my Sandisk 4GB CF card as faster on the iLiad than the Sandisk Disk on Chip.

[kapoira]

i vote to a yes to this solution, but the only problem i see could be this

that after a time the developers will have a "real" linux in the iliad, the average joe, wants the aplications, but he only have the internal memory for the linux, in this way we are assuming that everybody have a CF, (i will buy one, but i'm waiting to see a 4gb cheap).

For the developers are no problem, the problem can be in the use of the iliad and about irex how to sell it,... that we are fighting to have a linux machine, with the e-ink, and seems that irex want only a e-book reader.... (i'm not talking about matthijs)

[CommanderROR]

That would indeed be cool.
I am no dev myself, but even I can see the benefits here. The only danger I can see is that there would have to be some edit to one of the bootup system files, one of the very lowlvel and basic ones, to check for a bootable CF image before it starts booting from the Iliad internal chip. That way, it should even be possible to use an alternate OS, returning to the original would then just be removing the CF card with the alternate bootfiles. If you can really pull this off it could work much like rockbox for mp3 players...:-)

[arivero]

Originally Posted by scotty1024

I looked at the code in linuxrc and other than some possible needed extra modprobes to have the kernel ready to mount the CF the concept looks trivial to implement.
.

Indeed my expectations about the alternate boot is that it will be based on a modified linuxrc too. I would be surprised if other solution is produced, at iRex or elsewhere.

[scotty1024]

Originally Posted by arivero

I would be surprised if other solution is produced, at iRex or elsewhere.

The tool iRex is developing would still be useful for reloading the Sandisk Disk on Chip...

The intriguing thing about this one: we could do it ourselves... but it might cost a couple bricked iliads but you would think iRex could develop it in a day or so as it is a natural extension of their existing technique.

[Matthijs]

Is there enough room on tffsa1 for the CF driver and everything needed for it? I don't think there is. Other than that its quite a nice idea...

What we are working on actually resides in the bootloader, before the Linux kernel is loaded. This would mean that if you flash random data to your kernel location, it would still allow recovery. This suggested method would not, it relies on the kernel to do the right thing and load TFFS filesystem support and read from tffsa1.

[Antartica]

Originally Posted by Matthijs

What we are working on actually resides in the bootloader, before the Linux kernel is loaded. This would mean that if you flash random data to your kernel location, it would still allow recovery.

I agree. The place for that utility is the bootloader (as was done with the HH.org bootloader for the iPAQ, and to some extent, with the zaurus -- in the zaurus is more complex, and I like more the solution of the iPAQ, and what you say you're doing).

What Scotty is proposing about the CF solution could be handly for testing kernels, using monte/kmonte, bootimg or kexec instead of modifying the iliad startup files. Any of these solutions (monte/kexec...) provides a way lo load a linux kernel and a ramdisk from another running kernel (like loadlin did to load Linux from DOS in the old days). IIRC the linkstation/terastation/kurobox hacking guys used it to load alternative kernels from the official one...

More information:

monte: http://sourceforge.net/projects/monte
bootimg: http://bootimg.sourceforge.net/
kexec: http://www.xmission.com/~ebiederm/files/kexec/ http://www-128.ibm.com/developerwork...y/l-kexec.html

[scotty1024]

Yes but most of us are content to play with user space applications, scripts and the occasional loadable kernel module. We are more at risk of doing something silly to the boot sequence and being bricked than we are of bricking our kernel.

A possible solution to the issues you raise would be to put the CF card support in the kernel, which does have room, instead of using loadable kernel modules.

[arivero]

Originally Posted by Matthijs

Is there enough room on tffsa1 for the CF driver and everything needed for it? I don't think there is. Other than that its quite a nice idea...

What we are working on actually resides in the bootloader, before the Linux kernel is loaded. This would mean that if you flash random data to your kernel location, it would still allow recovery. This suggested method would not, it relies on the kernel to do the right thing and load TFFS filesystem support and read from tffsa1.

Of course if you can do something in the bootloader is it a lot better!!

The trivial idea of including the CF and Memory Card drivers in tffsa1... I acknowledge I have not checked space I am sort of lazy checking this kind of things: if you had put /bin/cp in tffsa1 I had survived to the 2.4 update... but I did not checked for it, I just assumed it was.

[arivero]

Originally Posted by scotty1024

A possible solution to the issues you raise would be to put the CF card support in the kernel, which does have room, instead of using loadable kernel modules.

So there is room there?

Another solution is to store them in a directory of the reserved partition, they are small enough to allow room for the update process, and moreover the update from iRex is very modular now.

In fact his solution, using the reserved partition, is within the reach of advanced users.

And again, if iRex can do something with the bootloader, that is very good news. I'd prefer such solution.

[Matthijs]

I don't have time to put something like this together now, but if you guys would like to help, I will test.

So if you provide me with a new tffsa1* and the files to put on my /mnt/protected/ and on my CF card, I promise to test it.

That way nobody but me will brick his iLiad

*) take update.image.gz from pre-2.7-update, gunzip and mount it on your Linux PC with "mount -o loop update.image <dir>"

[scotty1024]

Originally Posted by Matthijs

I don't have time to put something like this together now, but if you guys would like to help, I will test.

So if you provide me with a new tffsa1* and the files to put on my /mnt/protected/ and on my CF card, I promise to test it.

That way nobody but me will brick his iLiad

*) take update.image.gz from pre-2.7-update, gunzip and mount it on your Linux PC with "mount -o loop update.image <dir>"

Thanks Matthijs! This will help keep my mind off it being -3C outside with the power still out.

[R2D2]

Originally Posted by scotty1024

Thanks Matthijs! This will help keep my mind off it being -3C outside with the power still out.

No power? Go ask Arivero to give you his plans for a steam powered ilIad. ;-)