[adsp.sw] ColdReboot

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