General 
------- 

1. Logically separate the UI, filesystems and kernel bootstrap from the 
rest so that they can be linked against kernel drivers for a full-blown 
MILO as well as against SRM callbacks to provide an aboot-like thing 
with MILO interface for consistency. 

2. Put kernel driver compiling under MILO's control: this way MILO will 
only require kernel sources, which is, I believe, a reasonable 
requirement. Kernel configuration will also be controlled by MILO. 
I have already modified MILO configuration scripts to include kernel 
configuration for this "new generation" MILO, but couldn't do much more 
than that due to serios lack of time. 

3. Separate platform-dependent and platform-independent files. By 
"platform-dependent" I mean those with #ifdef CONFIG_ALPHA_...; it is a 
good idea to reduce the number of such files as much as possible. 

It is a question whether the target platform is a configuration option 
or not. I would rather see it not belonging to the configuration, for 
it would make building distributions easier: configure once, build as 
many times as necessary for different platforms. 

It would be nice to not have to re-compile anything when the target 
platform changes, just by giving appropriate objects to the linker. 
The code generated will be generic, not using BWX and stuff, but that 
does not really seem important. 

Should the kernel drivers be compiled as generic or a separate set for 
each system? I tend to prefer them being generic to simplify the 
process. 

New features 
------------ 

1. The wtint PALcall, which is missing in MILO, although required by the 
Digital UNIX PALcode specification. It is a nice power-saving facility. 
I implanted it into my MILO as an experimental feature by 
reverse-engineering from the SRM PALcode, and this immediately reduced 
the CPU fan noise while the machine is idle. (The kernel needs 
modifications to use wtint, though.) The problem is that it seems to be 
highly platform-specific and I did not see any documentation how to 
enter low power mode except for the 21066 family CPUs. 

We can at least provide a stub to facilitate the use of wtint in the 
mainstream kernel. Those who boot from SRM will benefit from it. 

2. Some nice things from the console specification, such as console 
print routines for early kernel panic diagnostics, and correct reaction 
to the CPU restart flags in HWRPB to distinguish between halt, cold 
reboot and warm reboot. 

3. Ability to run programs under MILO. This will be useful for various 
console tools such as diagnostic and tuning routines, which we don't 
want to keep inside MILO. 

Technical reorganisation 
------------------------ 

At the moment, nearly everything is in a wrong place. Files should be 
rearranged to make maintenance easier. Memory layouts should be less 
dependent on Makefile settings and driven by linker scripts. 

I'm thinking of integrating linload.exe into MILO: its code will then 
shrink to a trivial swppal. This can be arranged as a 512-byte preamble 
containing the ARC COFF header and a small code segment. SRM will be 
able to easily skip the preamble as it is exactly one sector long. 

I intend to move MILO to lower physical addresses; then both the 
compressed and uncompressed images will fit below the kernel, making 
MILO memory management easier and the kernel's page map less fragmented. 
I don't know if this will bring us any benefit, though. 

Memory sizing is easy to implement by querying core logic chipset 
rather than doing silly things like relying on SRM or AlphaBIOS or PAL 
impure area to provide the information. 

There is also a lot of things to do to streamline MILO startup and 
general logic (what goes after what, when to build HWRPB, how to manage 
environment etc.) 

Speaking of environment, I propose to replace the current MILO reboot 
block with an environment block which would preserve MILO variables 
across kernel bootstrap/halt. On systems equipped with NVRAM that MILO 
can read, environments will be merged. Stuff like the boot command, 
which is currently kept in the reboot block, will always go to the RAM 
portion. An initial RAM environment block will reside inside the MILO 
image and will be configurable by tools like miloctl - this is useful 
for systems without NVRAM. Variables can control which device to be 
used as the console terminal (VGA or serial), verbosity level, default 
bootstrap command, timeouts etc. 

OK. I have more concrete details on most of the topics discussed, but I 
think that would be just too much for the first time. 

Comments, opinions, suggestions anyone? 

Nikita 
