Porteus

Hi Ahau,

testing your ARM version I was deeply impressed: SPLENDID work

I would like to port it to Cubox and Cubieboard, as these devices include an SATA port.
It shouldn't be a problem to build the Porteus kernel for those devices but I have no clue how to include the initramfs...
Once it is starting I would like to create a version based on AlienBob's armv7hf port.

Is there any chance that you can provide the files you are including with CONFIG_INITRAMFS_SOURCE="/mnt/mmcblk0p1/initrd/initramfs-excheat"?

Thanks in advance,

Manfred

Hi Quax! Thank you! I was doing some reading about your fluxflux ARM work and had been considering sending you an email about something (though right now I can't remember what!). I'm glad to hear from you

I've put the initramfs files online: http://porteus-arm.googlecode.com/files ... les.tar.gz

It has been a few months since I worked on this and, admittedly this could use some work to make it run more smoothly. If the Cubox and Cubieboard have an easy way to insert kernel parameters, I'd probably use semething much closer to the standard porteus linuxrc without going through the gymnastics involved for 'excheat' (this slows down booting, by perhaps as much as 10 seconds). Also, if you're able to specify the initramfs through the bootloader, it may be desireable to split the initramfs rather than building it into the kernel image. I have to do it this way for my tablet because the bootloader is locked and doesn't support passing arguments like cheatcodes and initrd paths.

I'm tied up with getting my contributions to Porteus 2.1 (x86) polished and ready these days, but my goal still remains to get my Slackware armv6 port (http://ahau.porteus.org/slackwarearmv6.html) up to snuff and then rebase Porteus-ARM on that so it will have hard float support. Armv7 is better yet with thumb2 support, but we had a number of folks who seemed interested in getting Porteus on the Raspberry Pi, so that's why I went with v6. It would be nice to do some benchmarking to see what kind of actual improvement is seen between these ports.

One other thing on my To Do list is test out compressing my ARM modules with lzo compression rather than xz. The modules would be larger in size but lzo seems to have a lower processor overhead for decompressing, which comes into play with these slower devices. You might want to play with that a bit on your end too.

Anyway, just drop me a line if you have any questions, I'll be interested to see what you're working on!

Ahau wrote:...I've put the initramfs files online: http://porteus-arm.googlecode.com/files ... les.tar.gz

Thanks!

...test out compressing my ARM modules with lzo compression rather than xz.
The modules would be larger in size but lzo seems to have a lower processor overhead for decompressing, which comes into play with these slower devices.

Have a look at this benchmark. I can't imagine that you really want to increase the module size by at least factor 2
Most actual ARM devices are running at least 1GHz x2 and IMX6/Cortex A31/Tegra 4 quad cores are the way to go in future .
Imho they won't care for the difference between lzo/xz, while Raspberry Pi being a nice toy but not a device for serious every day or commercial office use.

For me the most important fact is that those systems would take profit of mounting modules via httpfs, as they mostly have a 2GB/4GB internal flash chip only.
Why not challenge IOS/Android with a kind of Modstore ...

Anyway, just drop me a line if you have any questions, I'll be interested to see what you're working on!

I will do though I have not decided yet whether to use berryboot for FluxFlux instead.
They are using squashfs/aufs with their kernel, perhaps the whole module system could be ported to that 8)

You should have a look at their Qt based booting gui!

Manfred

Quax wrote: I can't imagine that you really want to increase the module size by at least factor 2

Hey, size isn't everything! (insert crude joke of your choice) It's a balancing act. Take a look at the same benchmark you linked to, and you'll see lzo decompresses nearly five times faster than xz. So, it depends on the bottleneck. Is it the processor or is it the SD card? I've only done a small amount of testing, but found the results interesting enough that I think it warrants a deeper look to see how lzo would perform. I agree that faster devices are the future so in the long run, xz (or some future algorithm) will be the clear choice.

To be honest, I also think these devices with 2 or 4 gb built-in sdcards without an expansion slot are also a very limited duration product. My last flash purchase was $20 US for a 32 GB class 10 name-brand microsd card, so those limitations should relax with time as well.

At the end of the day, having an armv6 port is rather like having an i586 port; it's not likely to stay relevant for decades to come, but it is a tremendous learning experience for me and has some current-day benefits to those who have the right hardware.

I'll take a look at berryboot, thanks for the link!