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!rbabeldaveh@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
harald@boink.UUCP (Harald Milne) (08/18/90)
In article <13839@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) writes: > > 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*). No ROMs after boot? Not on my A2620! There a posting about entering the ROM monitor, which I proceeded to fool around with. Realizing that while in the monitor, the ROMs had to be in the Amiga address space, I searched for them and found them at address F80000. Being curious, I had thoughts about how to access this ROM (after the bootup sequence completed). You told me before during a phone discussion we had (it was about running the 68020 and 68000 simultaneously) that the ROMs were disabled after boot. At this point, fully believing the ROMs would go poof, I rebooted to snoop around with the Manx db debugger. Just for the hell of it, I looked at the same address, and lo, the ROMs were still in the Amiga's address space! What Im leading up to Dave, is I still believe you, and therefore would like to know if I have a different A2620 than perhaps what is the production A2620. I bought the A2620 immediatly upon hearing of it release, and not long after this, supply dried up for a while. This same store also sold me an A2000 with the cherry keyboard. I must be buying this stuff too soon. Really curious now, I looked at what controlled the ROM access. On sheet 1 of the schematics in the A2620 manual, there is _CSROM (with an interesting ? by the label). On sheet 3, _CSROM appears to be generated by the PAL U304. I guess I must have a really old set of PALs. Perhaps preproduction? Am I making the correct assumptions here? 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? Do newer PALs fix any other problems or known inconsistancies? I kind of like, and don't mind the ROMs being there. That is unless it may become a problem in the future. As always, thank you very much for your time and infinite patience. > 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! -- Harald Milne RISCy business uunet!ccicpg!boink!harald
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
peter@sugar.hackercorp.com (Peter da Silva) (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, 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? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
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!
daveh@cbmvax.commodore.com (Dave Haynie) (08/21/90)
In article <892@boink.UUCP> harald@boink.UUCP (Harald Milne) writes: >In article <13839@cbmvax.commodore.com>, daveh@cbmvax.commodore.com (Dave Haynie) writes: > At this point, fully believing the ROMs would go poof, I rebooted to snoop >around with the Manx db debugger. Just for the hell of it, I looked at the >same address, and lo, the ROMs were still in the Amiga's address space! > What Im leading up to Dave, is I still believe you, and therefore would like >to know if I have a different A2620 than perhaps what is the production A2620. Probably not. The only issue here is ROM revision. There was at least one A2620-only release. Some time after that, there were several releases that added A2630 knowledge and fixed a few bugs. The A2630 I have here, which is very likely using A2620-vintage ROMs, also shows $00f8xxxx within AmigaOS. > Really curious now, I looked at what controlled the ROM access. On sheet >1 of the schematics in the A2620 manual, there is _CSROM (with an interesting >? by the label). On sheet 3, _CSROM appears to be generated by the PAL U304. > I guess I must have a really old set of PALs. Perhaps preproduction? Well, CSROM* is certainly the PAL that creates that chip select. But it's the first configuration register that controls which memory ranges the ROM will be selected for. This register is set up by the A26x0 ROMs before AmigaOS is invoked. The ROMs can be left at $0000xxxx, $00F8xxxx, or neither of these. >I remember hearing about a change for the GVP disk controller after the A2620 >was initially released, Again, that was a bug in the ROM code. The A2620 ROMs code for autoconfig was confused about 128K devices. This was never an issue in normal operation, but could be seen when booting into the menu/monitor. There has only been one set of PALs for the A2620 (all 12 of them...). > I kind of like, and don't mind the ROMs being there. That is unless it >may become a problem in the future. If the $00F8xxxx overlay is a problem with 2.0, you will want a ROM set that fixed that. Other than for that, however, you're not likely to need a change. >Harald Milne RISCy business uunet!ccicpg!boink!harald -- 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
jms@tardis.Tymnet.COM (Joe Smith) (08/26/90)
In article <03065.AA03065@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel) writes:
:> 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 ...
But interrupts can't come along after the CPU executes a RESET instruction.
The RESET instruction clears all the interupt-enable bits. The existing
version of ColdReboot() is OK in that respect.
--
Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com
BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms
PO Box 49019, MS-C51 | BIX: smithjoe | 12 PDP-10s still running! "POPJ P,"
San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga speaks for me."rbabel@babylon.UUCP (Ralph Babel) (08/27/90)
In article <1191@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: > But interrupts can't come along after the CPU executes a > RESET instruction. The RESET instruction clears all the > interupt-enable bits. The existing version of > ColdReboot() is OK in that respect. No, it's not! This is straight from the Motorola manual: "Description: The reset line is asserted for 124 clocks, causing all external devices to be reset. The processor state, other than the program counter, is unaffected and execution continues with the next instruction." And by the way: I've tested it. Ralph
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (08/29/90)
In article <03267.AA03267@babylon.UUCP> rbabel@babylon.UUCP (Ralph Babel) writes: >In article <1191@tardis.Tymnet.COM> jms@tardis.Tymnet.COM >(Joe Smith) writes: >> But interrupts can't come along after the CPU executes a >> RESET instruction. The RESET instruction clears all the >> interupt-enable bits. >No, it's not! Nevertheless, the current implementation of Supervisor() disables interrupts. -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."
valentin@cbmvax.commodore.com (Valentin Pepelea) (08/29/90)
In article <1147@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP (Michael van Elst) writes: > > Nevertheless, the current implementation of Supervisor() disables > interrupts. Not according to the source code. 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
BAXTER_A@wehi.dn.mu.oz (08/30/90)
In article <14037@cbmvax.commodore.com>, valentin@cbmvax.commodore.com (Valentin Pepelea) writes: > In article <1147@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP > (Michael van Elst) writes: >> >> Nevertheless, the current implementation of Supervisor() disables >> interrupts. > > Not according to the source code. > > Valentin Sort of the ultimate in trumping someone, isn't it? Regards Alan
p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) (08/31/90)
In article <14037@cbmvax.commodore.com> valentin@cbmvax (Valentin Pepelea) writes: >In article <1147@mpirbn.mpifr-bonn.mpg.de> p554mve@mpirbn.UUCP >(Michael van Elst) writes: >> Nevertheless, the current implementation of Supervisor() disables >> interrupts. > >Not according to the source code. I'm beaten. Supervisor() does NOT disable interrupts. (It does an ORI #$2000,sr to switch to supervisor). -- Michael van Elst UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve Internet: p554mve@mpirbn.mpifr-bonn.mpg.de "A potential Snark may lurk in every tree."