rbabel@babylon.UUCP (Ralph Babel) (08/15/90)
Brief history: The original "ColdReboot()" (new Amiga Hardware Reference Manual, page 219) didn't work on some (IMHO) broken A2000s (Kickstart ROM doesn't reappear at location 0 after RESET). The current version (AmigaMail March/April 1990) jumps directly into Kickstart and therefore doesn't co-operate with boot-ROMs (not to be confused with Autoboot driver ROMs) that show up at location 0 after a software RESET (e.g. it leaves the A1000's WCS write-enabled and does not work with GVP's '030 boot-ROMs - dunno about A2620/A2630). Presumably this bug also prevents the current versions of "MMUKick" and "SetCPU ROMBOOT" from working with boot-ROMs. So what about the following solution? ------------------------ cut here ------------------------ * This is Beer-Ware. If you find this program useful, you * are morally obliged to buy me a drink at the next Amiga * show or devcon. :-) csect "text",0,1,0,4 include "exec/types.i" include "exec/execbase.i" AbsExecBase equ 4 _LVOSupervisor equ -30 _LVOColdReboot equ -726 LIBRARY_VERSION_2_0 equ 36 _ColdReboot movea.l AbsExecBase.w,a6 cmp.w #LIBRARY_VERSION_2_0,LIB_VERSION(a6) blt.b 1$ jmp _LVOColdReboot(a6) 1$ lea 2$(pc),a5 jsr _LVOSupervisor(a6) * * in case our boot-ROM doesn't show up at location 0 ... * * romsize equ $00ffffec * romend equ $01000000 * * $000002: bra.b $000008 * $000004: AbsExecBase * $000008: lea romend+4,a0 * $00000e: suba.l romsize-(romend+4)(a0),a0 * $000012: movea.l (a0),a0 * $000014: subq.l #2,a0 * $000016: jmp (a0) * 2$ lea (2).w,a0 movea.l a0,a1 move.w #$6004,(a1)+ addq.l #4,a1 move.l #$41f90100,(a1)+ move.l #$000491e8,(a1)+ move.l #$ffe82050,(a1)+ move.l #$55884ed0,(a1) btst.b #AFB_68020,AttnFlags+1(a6) beq.b 3$ movec.l cacr,d0 bset.l #3,d0 movec.l d0,cacr 3$ cnop 0,4 reset jmp (a0) end ------------------------ cut here ------------------------ Restrictions: Does not support '040 under pre-2.0; assumes all boot-ROMs have a JMP-$absolute at location 2; and the usual MMU restriction (turn off MMU before rebooting). Maybe Dave has a good idea on how to turn off the MMU without pulling the rug from under your own feet (SetCPU ROMBOOT)? Comments appreciated, Ralph Babel ...!cbmvax!cbmehq!babylon!rbabel
daveh@cbmvax.commodore.com (Dave Haynie) (08/16/90)
In article <03021.AA03021@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel) writes: >Brief history: >The current version (AmigaMail March/April 1990) jumps >directly into Kickstart and therefore doesn't co-operate >with boot-ROMs (not to be confused with Autoboot driver >ROMs) that show up at location 0 after a software RESET >(e.g. it leaves the A1000's WCS write-enabled and does not >work with GVP's '030 boot-ROMs - dunno about A2620/A2630). >Presumably this bug also prevents the current versions of >"MMUKick" and "SetCPU ROMBOOT" from working with boot-ROMs. I'm not sure what the GVP boot ROMs actually do, but with the A2620 and A2630, these ROMs are gone forever by the time you're into AmigaOS the first time after a full system reset (eg, powerup, keyboard, or any other condition that yanks both RST* and HLT*). Basically, after a full system reset, the A26x0 ROMs are mapped at 0 and a magic A26x0 control register is mapped into the $00e8xxxx space normally used for AUTOCONFIG units. This magic control register is similar to, but not identical to, a normal AUTOCONFIG unit, and Exec would certainly choke on it. The control register is actually at $00e80040, and it can be written to repeatedly until the configuration bit in the register is set. At that point, this magic control register goes away, normally until the next full-system reset. It is replaced at $00e8xxxx by the configuration unit for the A26x0 on-board memory, which is a true AUTOCONFIG unit understood by expansion.library and all. Any CPU-generated RESET will bring you back to this state, but not back to the initial state where the magic register is accessible or A26x0 ROMs are visible. >Maybe Dave has a good idea on how to turn off the MMU without >pulling the rug from under your own feet (SetCPU ROMBOOT)? If the MMU is on, make sure you're done running any OS code before you turn it off. That's about all you can do. For SetCPU ROMBOOT, I do just this. If you're running under 2.0, SetCPU setfunctions its own reset routine, which will [a] not live in emulated ROM at the time of reset, and [b] turn off the MMU just prior to resetting. >Ralph Babel -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Get that coffee outta my face, put a Margarita in its place!
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/17/90)
In article <03021.AA03021@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel) writes: > > The original "ColdReboot()" (new Amiga Hardware Reference Manual, page 219) > didn't work on some (IMHO) broken A2000s (Kickstart ROM doesn't reappear at > location 0 after RESET). > > (e.g. it leaves the A1000's WCS write-enabled and does not work with GVP's > '030 boot-ROMs - dunno about A2620/A2630). Presumably this bug also prevents > the current versions of "MMUKick" and "SetCPU ROMBOOT" from working with > boot-ROMs. I'm not sure what you are talking about here. I wrote MMUkick with the specific purpose to allow GVP accelerator owners to boot OS 2.0 kickfiles. I even had to help GVP find out why initially, MMUkick would not work. To fix that they had to replace their PALs with new ones which properly propagate the *RESET signal frlom the CPU to external devices, and did not inhibit the cache for CPU fetches from chip memory. > So what about the following solution? Self modifying code is dangerous to your health. In this case, remember to Disable() all interrupts before entering the critical region. 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
rbabel@babylon.UUCP (Ralph Babel) (08/17/90)
In article <13839@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > If the MMU is on, make sure you're done running any OS > code before you turn it off. And if I'm currently executing out of a memory region that has been remapped? In article <13847@cbmvax.commodore.com> valentin@cbmvax.commodore.com (Valentin Pepelea) writes: > I'm not sure what you are talking about here. About trying to make ColdReboot() (and other programs using the RESET instruction) more compatible with existing hardware (e.g. the A1000). > I wrote MMUkick with the specific purpose to allow GVP > accelerator owners to boot OS 2.0 kickfiles. No-one said that it didn't work absolutely perfectly fine! I merely pointed out that after a CPU-RESET something might appear at location 0 (and also at $00e8xxxx - thanks Dave!) that Exec and Expansion might choke on. Unless you know what it is, the only way to get rid of this "something" is by jumping to location 2. Fortunately, this "something" does not show up on a GVP '030 board unless you remove a jumper. > Self modifying code is dangerous to your health. So is jumping into Kickstart. I'm checking for version numbers and I'm clearing the code cache, so I'm more compatible than, for example, the 1.3 LoadSeg(). :-) > In this case, remember to Disable() all interrupts before > entering the critical region. Thanks for the reminder! It's one more reason to replace the current version of ColdReboot() - just imagine an interrupt coming along after the CPU-RESET has caused all interrupt vectors to disappear ... Thanks, Ralph
rbabel@babylon.UUCP (Ralph Babel) (08/18/90)
In article <892@boink.UUCP> harald@boink.UUCP (Harald Milne) writes: > No ROMs after boot? Not on my A2620! Sure, they're still at $f80000, but what Dave probably meant to say was: You cannot make them reappear at location 0 (and the special registers at $e8xxxx) without a _hard_ RESET (i.e. you should not be able to enter the boot menu/monitor after a CPU-generated RESET). > Just for reference, what is the current PAL revision? I > remember hearing about a change for the GVP disk > controller after the A2620 was initially released, which I > don't have (I have a A2091 now), so I was unconcerned > about it at the time. > > Should I bother getting new PALs? As far as I remember, it was new ROMs, not PALs. Dave? > I kind of like, and don't mind the ROMs being there. That > is unless it may become a problem in the future. Kickstart at $f80000, maybe? Ralph
daveh@cbmvax.commodore.com (Dave Haynie) (08/20/90)
In article <03065.AA03065@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel) writes: >In article <13839@cbmvax.commodore.com> >daveh@cbmvax.commodore.com (Dave Haynie) writes: >> If the MMU is on, make sure you're done running any OS >> code before you turn it off. >And if I'm currently executing out of a memory region that >has been remapped? Well, don't. Currently, you have very little chance of that being the case. If you're experimenting with virtual memory, you will have to make sure that your reset code runs from unmapped memory. If you're mapping memory that's not ROM code and not virtual memory, try to figure out why you've mapped it; there's probably not a good reason for this. And keep in mind that it's only the reset code itself that needs to be in unmapped physical memory. That code is only entered, and the result of its execution is that every other task in the system is destroyed. >About trying to make ColdReboot() (and other programs using >the RESET instruction) more compatible with existing >hardware (e.g. the A1000). First of all, when you have ColdReboot() (eg, OS 2.0 and later), any program using RESET other than ColdReboot() is probably in error. A tool like SetCPU, which isn't really OS supported, is about the only thing than should be doing a direct RESET, and even it attempts to coexist with the ColdReboot() mechanism. >I merely pointed out that after a CPU-RESET something might >appear at location 0 (and also at $00e8xxxx - thanks Dave!) >that Exec and Expansion might choke on. But as I mentioned, it IS incorrect for that to be a problem. A ColdReboot() cannot legally give you back something at location 0 or $00e8xxxx that is not understood by Exec and Expansion. You see, ColdReboot() is an AmigaOS function designed to give you back AmigaOS. Anything that tries to go beyond this and provide some kind of super-shell for choosing between OSs at boot time, like the A26x0 ROMs, must be designed such that it doesn't interfere with the normal operation of any OS, once that OS is running. Since ColdReboot() is a perfectly valid thing to do under AmigaOS, any hardware that prevents that action from doing what's expected is wrong. >Ralph -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Get that coffee outta my face, put a Margarita in its place!
daveh@cbmvax.commodore.com (Dave Haynie) (08/20/90)
In article <03125.AA03125@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel) writes: >In article <892@boink.UUCP> harald@boink.UUCP (Harald Milne) >writes: >> No ROMs after boot? Not on my A2620! >Sure, they're still at $f80000, >> Should I bother getting new PALs? >As far as I remember, it was new ROMs, not PALs. Dave? The A26x0 control register, as I've explained in detail here before, allows these ROMs to be banked in at 0 or at $00f8xxxx. The proper action is for the A26x0 ROMs to be shut off before AmigaOS is started, in both locations. If that's not what's happening, that's a bug, and I suspect the latest set of A26x0 ROMs already fix this. It hasn't been much of an issue yet, since most of the machines in the world use 1.3, which of course starts at $00fc0000, and of those running 2.0, most A26x0 are using KickIt, MMUKick, SetCPU, etc. and also not colliding with this ROM, assuming its still there. Whatever the setup, by the time you're running AmigaOS, you're locked into that setup. >Ralph -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Get that coffee outta my face, put a Margarita in its place!
rbabel@babylon.UUCP (Ralph Babel) (08/21/90)
In article <13895@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > If you're mapping memory that's not ROM code and not > virtual memory, try to figure out why you've mapped it; > there's probably not a good reason for this. Well, I didn't remap anything (except for FASTROM, my own debugging tools, and some VM experiments), but do _I_ know what other people are using the MMU for? > First of all, when you have ColdReboot() (eg, OS 2.0 and > later), any program using RESET other than ColdReboot() is > probably in error. I agree, but you misunderstood me! All the time I was basically referring to the 1.3-compatible version of ColdReboot() (the one from AmigaMail). > A ColdReboot() cannot legally give you back something at > location 0 or $00e8xxxx that is not understood by Exec and > Expansion. But I don't even want it back! All I want is that the 1.3 version of ColdReboot() takes care of the A1000 WCS etc. And the version I posted (plus the fix Valentin suggested) exactly does that. > Since ColdReboot() is a perfectly valid thing to do under > AmigaOS, any hardware that prevents that action from doing > what's expected is wrong. Sure, you're 100% right. But if ColdReboot() can be made _more_ compatible than it is right now, why not do it? In article <6397@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> Sure, they're still at $f80000, but what Dave probably meant >> to say was: You cannot make them reappear at location 0 (and >> the special registers at $e8xxxx) without a _hard_ RESET > > What about with judicious use of the MMU? Sorry, no. You might be able to move the ROM image back to location 0, but the registers at $e8xxxx are gone. Similar to the expansion space of a memory board (the area that gets copied to an ExpansionRom structure) or a board that is told to "shut up", once you strobe a certain bit/byte/whatever, the registers are no longer part of your address space. If you plan to intercept that strobe with the help of a RESET-resident utility using the MMU, sorry again! The special registers at $e8xxxx _have_to_ move/disappear, before the expansion.library can start its AutoConfig process. Ralph