Re: PR/22140

[Gunther Nikl <gni%gecko.de@localhost>]

Hello,

> Regarding disabling DMA before copying, is this because /dev/reload
> assumes that DMA from some device or another might write to some
> location inside the kernel code?

  Yes. An ongoing DMA transfer might clobber data just copied.

> If it no longer depends on chipmem, then I can't see that being a concern
> any longer.

  Memory at location zero is still required. It just happens to be chipmem
  on the Amiga. You need memory at PA zero because the kernel in fastmem is
  mapped with VA == 0. When the MMU is turned off, the cpu continues work
  at the next instruction but now in chipmem (in the code just copied to
  this location)! Thats another reason that doboot and kernel_reload must be
  in the first 512k of the kernel image. Without memory at location zero
  neither doboot nor kernel_reload can work. Thus, since kernel_reload and
  doboot both copy into chipmem DMA must be deactivated at booth places I
  guess.
  I did remove the chipmem size limitation. Now the kernel to reload can
  be larger than the available chipmem size because the kernel is copied
  directly to its final fastmem destination.

> But how long does it take for the reloaded kernel to start initialising
> hardware?

  It starts immediately and uses the information about memory, expansion
  cards, flags, etc. provided by the first boot. However, I noticed a small
  problem of /dev/reload with my P-IV: reloading a kernel without the cirrus
  code isn't a good idea. Since the flickerfixer of the P-IV is never
  activated and the card never gets initialized I don't get any output from
  the custom chips... The system boots but I have to make a manual reboot
  immediately (typing blindly isn't fun ;-) There might be other traps.

  Gunther

-- 
Linux is only free if your time has no value
 - Jamie Zawinsky