Path: utzoo!utgpu!watserv1!watmath!att!rutgers!cbmvax!valentin From: valentin@cbmvax.commodore.com (Valentin Pepelea) Newsgroups: comp.sys.amiga.tech Subject: Re: KickIt Explained (hi K.C.Lee) Message-ID: <13352@cbmvax.commodore.com> Date: 21 Jul 90 05:04:49 GMT References: <4661@eklektik.UUCP> Reply-To: valentin@cbmvax (Valentin Pepelea) Organization: Commodore, West Chester, PA Lines: 66 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