Hi Ken,
Ken Lyons - SplinterFL wrote:
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.
Correct. Start simple and work up.
-- Have you made any progress on your kernels, I wouldn't mind testing
them before I attempt to make my own.
No yet. I'm *still* recovering from a drive problem (months ago) so my
bitbaking virtual machine is on ice. Also, it may prove to be a little
difficult to prise the hx2110 from the g/f's hands :)
I would, however, like to include the hx2000 series as supported for RR
so I will need to include a build tree for it's kernel and test it at
some stage.
>> 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.
I don't see the point.
> 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.
Docs are old (2004?)
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).
The easy way is to have a single kernel that does the job.
Actually, two kernels:
- one for Ramdisk Rescue, and another for the installed system.
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.
kexec.
Hum.. HaRET -> LAB kernel?
doubt it, talk to Joshua Wise (? LAB author) & Paul Sokolovsky.
Seen this: http://www.embeddedarm.com/linux/linuxbootloader.htm
linux to linux bootloader, isn't that pretty much the same as kexec
All appears to be 2.4-kernel related. Not suitable.
> 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.
heh ... 4 to 5 thousand lines of shell script, multiple machines .... *sigh*
The idea is simple ... but it's quite complicated :)
> 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.
Ramdisk Rescue will never carry kernel modules. There is not enough room,
and is something that should be handled by a monolithic kernel.
In the end, we still need one or more kernels that have more drivers
than they currently do.
Yes.
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.
No. Overcomplicated, too hard to maintain, etc.
If you are unable to make your own kernel at this stage you might have to
wait for me (or the port maintainers) to come up with a *simple* solution.
I have ben revising the menu system in RR (in C) so that it's faster and
more capable. Once that's up and running in my "test lab" I'll work on
extended capabilities like (optional) advanced partitioning, etc.
This will then lead to testing on all the machines I have available and I
will then be in a position to share a (hopefully working) monolithic kernel.
Have fun! :)
Marcus.
_______________________________________________
Hx2000-port mailing list
[email protected]
https://www.handhelds.org/mailman/listinfo/hx2000-port
