patch like kexec for MIPS possible?
Salve!
Does the MIPS CPUs makes a patch like kexec possible?
Kexec is a kernel patch which allows you to start another kernel.
IMHO would such a kernel patch would be handy, especialy for small MIPS Linux boxes. For more info about kexec read e.g.
http://www-106.ibm.com/developerworks/linux/library/l-kexec.html
And please don't get me wrong - as a non-kernel-developer I'm very happy with your work - my question is not a request, I'm just interested if there is a limitation of the MIPS platform to do something like this or not.
Greetings,
rob
PS: And _if_ it would be possible, maybe sombody read this and join thinking that this feature would be realy cool ;)
Quoted 5 lines · Robert Michel
Salve!
Does the MIPS CPUs makes a patch like kexec possible?
Kexec is a kernel patch which allows you to start another kernel.
MIPS kernels are usually position dependent code, and loaded in unmapped memory, so a kernel would need to overwrite itself for kexec. I don't know if kexec is flexible enough to handle this.
Quoted 3 lines
IMHO would such a kernel patch would be handy, especialy for small MIPS Linux boxes. For more info about kexec read e.g.
http://www-106.ibm.com/developerworks/linux/library/l-kexec.html
Frankly, I don't see what kexec is good for. Who else besides kernel developers would need to reboot a machine continuously?
Thiemo
Salve Thiemo!
Thiemo Seufer schrieb am Samstag, den 05. Februar 2005 um 18:41h:
Quoted 3 lines
MIPS kernels are usually position dependent code, and loaded in unmapped memory, so a kernel would need to overwrite itself for kexec. I don't know if kexec is flexible enough to handle this.
Kexec is written for x86 (yet) - but the (my) question is if this would be possible with MIPS, too.
--snip--
The magic of kexec
One of the biggest challenges in the development of kexec comes from the fact that the Linux kernel runs from a fixed address in memory. This means that the new kernel needs to sit at the same place that the current kernel is running from. On x86 systems, the kernel sits at the physical address 0x100000 (virtual address 0xc0000000, known as PAGE_OFFSET). The task of overwriting the old kernel with the new one is done in three stages:
1. Copy the new kernel into memory.
2. Move this kernel image into dynamic kernel memory.
3. Copy this image into the real destination (overwriting the current kernel), and start the new kernel.
--snap--
http://www-106.ibm.com/developerworks/library/l-kexec.html?ca=dnt-518
Quoted 6 lines
Quoted 3 lines
IMHO would such a kernel patch would be handy, especialy for small MIPS Linux boxes. For more info about kexec read e.g.
http://www-106.ibm.com/developerworks/linux/library/l-kexec.htmlFrankly, I don't see what kexec is good for. Who else besides kernel developers would need to reboot a machine continuously?
Does GRUB run on MIPS? Does GRUB support SSH2? Does most MIPS bootlaoders support USB-sticks or booting via VPNs?
LinuxBios is a "nice" project, but for most boards/boxes Linuxer could be happy to be able to boot it - to develop a nice boadloader is depended from the hard/firmware of the systems.
A kernel with a kexec like patch could be used into the bootchain for several reasons:
- making developing and hacking more easy
- booting with options
- choice which kernel to boot
- booting from original not supported devices (usb, network)
- remote control for the boot process
- bypassing memoryrestrictions of the bootloader
- more flexibility - independance from proprietary bootloader
- developing security, statistic features...
- fail save boot
- starting restore system, analyse tools....
- option for modular system
- for upgrades lower downtimes (Router, Firewalls....)
- perversive computing, the box could be on a place without physicaly access
- the kernel would be more often updated, than the bootloader
- just for fun
- just because it could be usefull - an implemented feature may become the base for other features - unthinkable before this first step
- ...
So my point is not to boot a machine continuously, but to expand the bootchain:
IMHO would be the most powerfull and flexible way
to boot a linux kernel,
to boot it just from an other linux kernel.
;)
Greetings
rob
Quoted 3 lines · In message <[email protected]> you wrote:
Kexec is written for x86 (yet) - but the (my) question is if this would be possible with MIPS, too.
Other, smilar solutions exist for other architectures, like Magnus Damm's "relf" tool for PowerPC and x86 (relf - reload elf: a driver to load and start a new elf file from within Linux). Adaptions for other processors are more or less trivial.
Quoted 2 lines
Does GRUB run on MIPS? Does GRUB support SSH2? Does most MIPS bootlaoders support USB-sticks or booting via VPNs?
Use U-Boot :-)
Quoted 3 lines
LinuxBios is a "nice" project, but for most boards/boxes Linuxer could be happy to be able to boot it - to develop a nice boadloader is depended from the hard/firmware of the systems.
Use U-Boot :-)
Quoted 2 lines
A kernel with a kexec like patch could be used into the bootchain for several reasons:
...
Quoted 1 line
- booting from original not supported devices (usb, network)
...
Quoted 1 line
- for upgrades lower downtimes (Router, Firewalls....)
These are IMHO the only valid reasons for such an approach.
Quoted 3 lines
IMHO would be the most powerfull and flexible way
to boot a linux kernel,
to boot it just from an other linux kernel.
We've been using "relf" in some projects (x86 - where we were stuck with really dumb BIOSes), but I cannot see many situations where kexec is actually better or more powerful than a decent bootloader line U-Boot. OK, I'm obviously biased.
Best regards,
Wolfgang Denk
Signature · 4 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected] In an organization, each person rises to the level of his own incom- petency - The Peter Principle
Quoted 3 lines · Wolfgang Denk
..... but I cannot see many situations where
kexec is actually better or more powerful than a decent bootloader line U-Boot. OK, I'm obviously biased.
I agree. I've played with booting kernels from kernels in both PowerPC and MIPS in the past, and the problem I always run into is drivers or kernel functions that assume a particular power up state. When rebooting from another kernel you don't have the same state as from power up, and
some software doesn't like this. I suspect main reason for
kexec is the horrible x86 bios and nothing that can be done about it.
Oh, and I agree with your assessment, not that you are biased :-)
-- Dan
Quoted 4 lines · In message <[email protected]> you wrote:
some software doesn't like this. I suspect main reason for
kexec is the horrible x86 bios and nothing that can be done about it.
Ummm.. some people got U-Boot running on x86 systems, too. But this is off topic here :-)
Best regards,
Wolfgang Denk
Signature · 3 lines
Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [email protected] Hindsight is an exact science.
Quoted 6 lines · Robert Michel
Salve Thiemo!
Thiemo Seufer schrieb am Samstag, den 05. Februar 2005 um 18:41h:
Quoted 3 lines
MIPS kernels are usually position dependent code, and loaded in unmapped memory, so a kernel would need to overwrite itself for kexec. I don't know if kexec is flexible enough to handle this.
[snip]
Quoted 7 lines
The task of overwriting the old kernel with the new one is done in three stages:
1. Copy the new kernel into memory.
2. Move this kernel image into dynamic kernel memory.
3. Copy this image into the real destination (overwriting the current kernel), and start the new kernel.
Ok, so is no exception WRT.
Quoted 4 lines
Quoted 2 lines
Frankly, I don't see what kexec is good for. Who else besides kernel developers would need to reboot a machine continuously?
Does GRUB run on MIPS?
No.
Quoted 1 line
Does GRUB support SSH2?
No idea.
Quoted 1 line
Does most MIPS bootlaoders support USB-sticks or booting via VPNs?
There are various, and usually they are open source, ao adding such features shouldn't be a problem.
[snip]
Quoted 1 line
- making developing and hacking more easy
Usually done via netboot or JTAG download.
Quoted 6 lines
- booting with options
- choice which kernel to boot
- booting from original not supported devices (usb, network)
- remote control for the boot process
- bypassing memoryrestrictions of the bootloader
- more flexibility - independance from proprietary bootloader
Those things should be fixed in the bootloader.
Quoted 4 lines
- developing security, statistic features...
- fail save boot
- starting restore system, analyse tools....
- option for modular system
?
Quoted 1 line
- for upgrades lower downtimes (Router, Firewalls....)
30 seconds for the tftp, and you have to hope the previous kernel left everything in a sane state.
Quoted 2 lines
- perversive computing, the box could be on a place without physicaly access
You don't want to do that without a safe fallback (aka serial console).
Quoted 7 lines
- the kernel would be more often updated, than the bootloader
- just for fun
- just because it could be usefull - an implemented feature may become the base for other features - unthinkable before this first step
- ...
Quoted 7 lines
So my point is not to boot a machine continuously, but to expand the bootchain:
IMHO would be the most powerfull and flexible way
to boot a linux kernel,
to boot it just from an other linux kernel.
;)
What if any of both is buggy? Either you have a working fallback, or you'll be screwed sooner or later.
Thiemo
Salve all & Thiemo!
First thank you all for your answers, as I understud you right, is there no restriction by the MIPS CPU/Memory architecture that makes a patch for starting another kernel unpossible.
This was the focus of my question - not the use of this. ;)
Thiemo Seufer schrieb am Sonntag, den 06. Februar 2005 um 01:28h:
Quoted 2 lines
30 seconds for the tftp, and you have to hope the previous kernel left everything in a sane state.
I know now (due your answers) u-boot which supports tftp like grub. But both lake SSH2 to access and control the bootloader during boot time.
Quoted 4 lines
Quoted 2 lines
- perversive computing, the box could be on a place without physicaly access
You don't want to do that without a safe fallback (aka serial console).
I _will_ be able to to this - not because I need it today - I'm just shure that it will be a handy feature.
You are right, it's usefull to have a safe fallback, but on many embedded systems you need a screw driver, maby soldering iron and a RS232 port for "debricking a box".
Beside of a hardware-hangup a box could have a hangup because of a user software error, kernel error or a black hat attack. Kernel do have security updates - so if your box does have any kind of interface/network it will need kernelupgrades and it exist the danger, that someone attack and "ownz" this box.
When you have a watchdog or just a timer to reboot the box the primary kernel form a secure, read-only medium (CD-Rom, Floppy, E-Prom...).
After booting a clean system, this box could ask a server via a secure Network what it should do:
- booting the lokal system
- overwrite the lokal system with a clean/newer system.
Now the question, should the bootloader runs SSH2 or would it better to have an old, sercure, rudimental kernel to do this. (Hardcore paranoiacs would use multiple tricks to make the box secure)
IMHO is it not only more easy to use a kernel instead of forking a bootloader - also in case of unsecure code, it is more easier to use a normal kernel/dep patch, than write this myself for my personal bootloader-fork.
Today you could realise this with RS232 and a second box, second IP..... this would make the systems more expensive, bigger, create a higher power consumption - so somethink that nobody likes for perversive computing.
Probably the link to the IBM article without expaining my idea was not so good, that article is IMHO concentrating to much on the speed of reboot.
My point is that such a feature could have a use for different cases (even more that I can imagine).
I just see that it would be nice to have this feature also on non x86 platforms - so this is why I ask you if it would be principle possible to run it on the MIPS platform.
Quoted 10 lines
Quoted 7 lines
So my point is not to boot a machine continuously, but to expand the bootchain:
IMHO would be the most powerfull and flexible way
to boot a linux kernel,
to boot it just from an other linux kernel.
;)What if any of both is buggy? Either you have a working fallback, or you'll be screwed sooner or later.
No question, sooner or later will fail every system, but the question is to make the probability as low as possible.
Greetings,
rob
PS: The radio for the Huygens to Cassini communications had a small bandwidth and the frequencies was written in ROM (to minimice the power consumption). But the enginneers forgot to calculate the doppler effect
- so on the first look it seems that no data receiving on Cassini would be possible. The workaround was a changed flight path of Cassini to change the doppler effect.
http://www.thespacereview.com/article/306/1
Quoted 2 lines
Frankly, I don't see what kexec is good for. Who else besides kernel developers would need to reboot a machine continuously?
Yeah. And, speaking from experience, it is often caused by the hardware entering such an invalid state that requires a hard reset anyway.
Stanislaw Skowronek
Quoted 5 lines · Stanislaw Skowronek
Quoted 2 lines
Frankly, I don't see what kexec is good for. Who else besides kernel developers would need to reboot a machine continuously?
Yeah. And, speaking from experience, it is often caused by the hardware entering such an invalid state that requires a hard reset anyway.
I guess only the big iron fraction among us will really be missing something like kexec - firmware reinitialization may take minutes on that calibre of system so being able to get around that would be a good thing.
Ralf
Quoted 6 lines
Quoted 2 lines
Yeah. And, speaking from experience, it is often caused by the hardware entering such an invalid state that requires a hard reset anyway.
I guess only the big iron fraction among us will really be missing something like kexec - firmware reinitialization may take minutes on that calibre of system so being able to get around that would be a good thing.
Well, a firmware reinitialization on my Octane (the old one) takes minutes. Still, the kernel requires the hardware to be initalized by PROM (just like on Origins, really) so kexec is of no help here.
Stanislaw
Quoted 7 lines · Stanislaw Skowronek
Quoted 3 lines
I guess only the big iron fraction among us will really be missing something like kexec - firmware reinitialization may take minutes on that calibre of system so being able to get around that would be a good thing.
Well, a firmware reinitialization on my Octane (the old one) takes minutes. Still, the kernel requires the hardware to be initalized by PROM (just like on Origins, really) so kexec is of no help here.
That's something that could be dealt with.
On Origins I usually disable memory test which helps a little but still is slower than I'd like. For general hacking eval boards that need like a second to reset just rock :-)
Ralf