Unified Milo images

Ka'plaagh 28-Feb-1996 0854 +0000 (rusling@rdgeng.enet.dec.com)
Wed, 28 Feb 96 09:51:37 MET


All,
there's a new set of sources and executables on
gatekeeper.dec.com in ~ftp/pub/Digital/Linux-Alpha/Miniloader.
What is new is that these are unified all-purpose images.
The source is /src/milo-1.3.68.tgz (caught up with Linus at
last) and the test-images directory contains all new images.
You'll notice that there is no longer a milo and a milo.arc;
there's just "milo". This image can be loaded from the
Debug Monitor and from Windows NT ARC. In theory, it can
also be loaded via the SRM but I haven't tried that yet. To
do this, Milo goes through the following steps:

(1) micropal.S. This code figures out what mode Milo was
entered in and then copies itself to the correct place in
memory. It then calls the milo stub code. As the name
implies, micropal.S is just enough PALcode to cope with
memory access violations.

(2) This code puts Milo where it should go in memory (0x200000
physical) and returns control to micropal.S passing it the
address of Milo's PALcode in memory. micropal.S transfers
control to Milo's PALcode.

(3) Milo's PALcode goes through its reset actions and then
passes control to the decompression code. The decompression
code lives at 0x210000 and has access to a gzip'd version of
Milo. This PALcode (0x200000:0x210000) stays in memory so
that Linux can use it.

(4) The decompression code gunzip's Milo (not the PALcode) into
memory at 0x250000 and transfers control to it.

(5) Milo, the real Milo, runs and you see the main screen allowing
you to boot. Meanwhile, it leaves the compressed Milo and the
decompression code in memory so that the Linux kernel can halt()
back to it (it will then start at step (3) above). This gives
an overhead of about 350K (PALcode + decompress code + gzip'd
Milo).

Easy really. My next step is to make "shutdown -r now" work
in all circumstances...

Dave