patch like kexec for MIPS possible?

patch like kexec for MIPS possible?

[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.

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 ;)

Re: patch like kexec for MIPS possible?

[Thiemo Seufer]

Robert Michel wrote:
> 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.

> 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

Re: patch like kexec for MIPS possible?

[Robert Michel]

Salve Thiemo!

Thiemo Seufer schrieb am Samstag, den 05. Februar 2005 um 18:41h:
> 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


> > 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?

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

Re: patch like kexec for MIPS possible?

[Wolfgang Denk]

In message <20050205191110.GD3071@mail.robertmichel.de> 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.

> Does GRUB run on MIPS? Does GRUB support SSH2? Does most MIPS
> bootlaoders support USB-sticks or booting via VPNs?

Use U-Boot :-)

> 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 :-)

> A kernel with a kexec like patch could be used into the bootchain
> for several reasons:
...
> - booting from original not supported devices (usb, network)
...
> - for upgrades lower downtimes (Router, Firewalls....)

These are IMHO the only valid reasons for such an approach.

> 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
In an organization, each person rises to the level of his own  incom-
petency                                         - The Peter Principle

Re: patch like kexec for MIPS possible?

[Dan Malek]

On Feb 5, 2005, at 3:33 PM, Wolfgang Denk wrote:

> .....   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

Re: patch like kexec for MIPS possible?

[Wolfgang Denk]

In message <efcfca49cf2c4494a661ba916f2e1546@embeddededge.com> 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Hindsight is an exact science.

Re: patch like kexec for MIPS possible?

[Thiemo Seufer]

Robert Michel wrote:
> Salve Thiemo!
> 
> Thiemo Seufer schrieb am Samstag, den 05. Februar 2005 um 18:41h:
> > 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]
> 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.

> > 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.

> Does GRUB support SSH2?

No idea.

> 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]
> - making developing and hacking more easy

Usually done via netboot or JTAG download.

> - 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.

> - developing security, statistic features...
> - fail save boot
> - starting restore system, analyse tools....
> - option for modular system 

?

> - 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.

> - 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).

> - 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.
> ;)

What if any of both is buggy? Either you have a working fallback,
or you'll be screwed sooner or later.


Thiemo

Re: patch like kexec for MIPS possible?

[Robert Michel]

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:
> 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.

> > - 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.


> > 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

Re: patch like kexec for MIPS possible?

[Stanislaw Skowronek]

> 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

Re: patch like kexec for MIPS possible?

[Ralf Baechle]

On Sat, Feb 05, 2005 at 08:26:04PM +0100, Stanislaw Skowronek wrote:

> > 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

Re: patch like kexec for MIPS possible?

[Stanislaw Skowronek]

> > 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

Re: patch like kexec for MIPS possible?

[Ralf Baechle]

On Sun, Feb 06, 2005 at 05:11:53PM +0100, Stanislaw Skowronek wrote:

> > 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