Thanks for clearing up the model info for me.
h2000= hx21xx, hx24xx, hx27xx
> Ramdisk Rescue, you will probably be shocked to realise, is a couple
> of ash (busybox) shell scripts wrapped up in an initrd. It's intention
> is to be machine neutral, so that a suitable kernel for your device
> *should* be the only thing required to do something useful. However,
> the kernels produced by most projects are unsuitable as they do not
> have essential modules built statically into the kernel, eg: ext2,
> ide_cs, pcmcia*, mmc* ... etc. So, my "major" work as far as RR goes
> is to compile such kernels for each device.
I'll experiment with it, but it still looks like the issue is getting
a decent kernel that can do everything.
-- Have you made any progress on your kernels, I wouldn't mind testing
them before I attempt to make my own.
>> HaRET ->
>> 1st-zImage(s) (load, detect all media, find all ext2 partitions:
>> Then display a boot menu of all valid EXT2 partitions)
> Not without writing a driver for windows that can read ext2!
Well there is a driver for desktops, but I wasn't refering to windows
reading it.
Just a mini-kernal that could that load with enought media drivers
to start another.
> However, with kexec, a minimal initrd could quite possibly kexec
> another kernel and it's associated rootfs. This should actually be
> quite achievable with RR.
Looked up kexec... It seems a long way off on being ported, and most
of it's complextity is because it's
made to reboot.
Is there an easier way... HaRET already gave us a 'clean state',
can't we pass that on.
Make the mini-kernel load to a different part of memory?, then load the
big kernel and assembly JUMP to start the other kernel (-- at least
in real mode DOS, back in the days).
I'm just thinking.. HaRET is able to get a kernel going...is there
anyway have our initrd
repeat what it did to get us going for the next kernel.
Hum.. HaRET -> LAB kernel?
Seen this: http://www.embeddedarm.com/linux/linuxbootloader.htm
linux to linux bootloader, isn't that pretty much the same as kexec
> RR is even more basic than that.
> The buttons are remapped to "real commands", framebuffer console
> (no graphics), and the graphics you see are handmade screen dumps
> (then modified) and dumped back into the framebuffer when needed.
That is all that is needed if a menu were to be added...just something
simple.
> Even with the advent of a generic kernel, RR (or any initrd with kexec)
> would probably not be able to hold the number of modules to make this
> feasible.
Depends on how the module are put in memory, the number and if something
ahead of it could
some how narrow the list.... Maybe instead of trying to do an all in
one, just a simple setup program that could
figure out what the user has, and choose a premade kernel with all the
minium drivers for that hardware, then
proceed to load add-on modules.
In the end, we still need one or more kernels that have more drivers
than they currently do.
To me the Ipaq has a lot of ram and storage on the cards compared to
some embedded projects
that have 4-16MB of flash and 16MB ram, dynamic loading of modules
shouldn't take up much
memory if they are unloaded when not needed. Could a script at the
RC.local level,
simply load each module, test if that feature or device is present,
note it in a status-log file and unload.
Then later prompt the user and say... a GPS SDIO device was found or a
SD card with an XFS FS on partition 1 were found..
... Do you want to mount the SD card? (then loads the modules for SD &
XFS and mounts)
It's more work for the user, but then you could have a HUGE kernel that
doesn't take much space, unless you loaded every module at once.
Ken
_______________________________________________
Hx2000-port mailing list
[email protected]
https://www.handhelds.org/mailman/listinfo/hx2000-port
