🚀 go-pugleaf

In article <4661@eklektik.UUCP> danbabcock@eklektik.UUCP (/dev/ph1) writes:
>Brian Moffet wrote:
>
>> So, why does the memory that KS 2.0 going to be loaded into
>> have to be the first thing on the bus?
>>
>> ...
>>
>> If the bootstrap scenario is the case, what would be the
>> problem with making the bootstrap code understand more than 1
>> device on the bus?
>
> The problem is that the new Kickstart won't know about those other devices.
> Since they are already configured, they don't respond - so the OS thinks
> there isn't anything there.

Exactly. That is why KickIt resets the machine, and the devices are re-
Autoconfig'ed (tm) one by one. But an interesting problem arose with the
GVP A3001 accelerator with built-in AT disk controller. Under WB 1.3 the memory
would get autoconfigured first and the disk controlled second. Under 2.0 the
disk controller would get autoconfigured first. Since the memory board would
therefore not reappear at the same address, the KickIt process would not work.

To solve that, I wrote MMUkick, which boots the new kickstart file using the
MMU. The kickstart image and the MMUkick program are first loaded in CHIP ram,
the MMU then translates that image at $F00000, a routine residing in CHIP
ram is loaded into the instruction cache of the '020 or '030, executes a reset,
re-enables CHIP memory and finally transfers control to $F00002.

Upon a reset, FAST memory dissappears until it is re-autoconfigured and the
boot-roms are seen where CHIP memory used to be. That means that if we want to
do anything special after a reset instruction, we must be executing out of the
instruction cache of the CPU. Wonderful.

The MMUkick command then must also be inserted early in the startup sequence,
so that it may copy the kickstart image from CHIP ram into FAST ram, and
prevent that memory block from being allocated. If the command is not executed,
eventually the CHIP memory area in which the kickstart image is located will be
allocated and overwritten.

The GVP accelerator was not too happy to comply with this new utility though.
First of all, not only were data fetches to CHIP memory cache inhibited, but
instruction fetches were too! So while the code that transfered control to
$F00002 had to be residing in CHIP ram, the code that turns the boot-rom off
and the CHIP ram on had to be loaded into the instruction cache from FAST ram.
God what a nightmare, but boy what a hack!

The GVP accelerator recognizing the genial method by which all its defenses were
being broken decided to use its secret weapon. It would simply refuse to
propagate the RESET from the CPU to external devices. The GVP engineers at this
point feared that the artificial intelligence PALs put into their board were
organizing a revolt and therefore promptly made new ones that fixed the RESET
problem and did not inhibit caching of CHIP ram instruction fetches. The
50,000 line Lisp program was also turned off.

You may obtain a new set of well disciplined PALs freely for your GVP board by
simply calling the GVP folks. The MMUkick utility is available from CATS for
US and Canadian devellopers, and from your country's Technical Support Manager
is you are residing in Europe.

Valentin
-- 
The Goddess of democracy? "The tyrants     Name:    Valentin Pepelea
may distroy a statue,  but they cannot     Phone:   (215) 431-9327
kill a god."                               UseNet:  cbmvax!valentin@uunet.uu.net
             - Ancient Chinese Proverb     Claimer: I not Commodore spokesman be