Re: Softkicking on a DKB Cobra/1240
- From: "Hypex" <hypex@xxxxxxxxxxxxx>
- Date: 6 Feb 2006 05:06:52 -0800
Thomas Richter wrote:
Hi,
First of all, you don't know what the ROM code of the DKB does. Second,
the bootstrap code of the Os checks whether the exec version in RAM matches
the one in ROM and refuses to use an old ExecBase. Then, furthermore, you
don't know what happens with the mapping RESET has been applied. It wouldn't
surprise me that the RAM the code runs in is removed from the CPUspace and
thus you pull the rug under your feet because the CPU cannot see the code
anymore.
There are some issues here and I did wonder about some of them.
1. How and what executes the ROM code of an expansion board?
2. If I destroy SysBase does the OS look for it elsewhere?
3. If the rug is pulled will it just pull back to the ROM at $f80000?
Here is some code:
CacheClearU()
MOVE.W#$4000,$DFF09A
CacheControl(0,-1)
This might or might not do something useful.
Okay.
SuperState()
MOVEQ #-1,D0
MOVE.L D0,4 -> Destroy Exec base
RESET
cobraflags[]:=(flags OR DKB_MAPROM)
MOVE.Lrommem,A0
ADD.L #ROMSIZE,A0
SUBA.L -$14(A0),A0
MOVEA.L 4(A0),A0
SUBQ.L #2,A0
JMP (A0)-> Direct jump into new ROM
The code below won't work for the reason given above. *If* you want to
reset manually, you can at most execute *one single instruction* before
jumping to a ROM location, and only that. The reason is that you do not
know what the hardware does with the memory mapping once reset has been
applied. For that, there might be room for one single indirect jump
after reset, e.g. JMP (A0) and nothing more. And, both the reset and the
jump must be placed at the start of a cache line (address mod 16 = 0)
so the processor loads both instructions at once in one prefetch.
I did wonder how ColdReboot() did that aligning. BTW, I also tried a
routine without the RESET, same result.
If the jump goes into a relocated RAM space, as in your case,
all bets are off. You don't know whether the remapping logic is resetted
by the RESET. You don't know whether the hardware of the DKB is resetted
on the reset. You don't know whether the RAM remains visible after the
reset.
All I know is that the code I am following lowers the upper region of
the fast ram to the location of the new ROM, or in other words just
lowers it by 512K. So, with my 32MB simmm, the new ROM and upper memory
gets set to $11F80000. That's seems a pretty nifty address,and might
explain how it fools the the hardware into reading from fast, but it
doesn't seem to work out exactly as a mask for $F80000 for other simmm
sizes.
So, by reserving this location and protecting it from an allocation,
would seem to indicate that the memory and header are left intact after
reset.
About the only thing you know is: All motherboard resources remain
visible: The custom chipset, the ROM space, and the chip mem (and
ranger mem, if any). Thus, it might or might not help to
a) copy the code to chipmem,
Would this be specific or would MEMF_KICK do as well?
b) enable or reenable DKB hardware remapping after the reset if this
is possible. Maybe not, if this hardware is mapped in by the autoconfig
mechanism - it then would just vanish, along with the RAM containing
the remapping.
So, I would be in chip ram and perform a RESET, then enable DKB
remapping, and then directly jump to ROM in›a preset Ax register?
This has got me thinking, thanks Thomas.
.
- Follow-Ups:
- Re: Softkicking on a DKB Cobra/1240
- From: Thomas Richter
- Re: Softkicking on a DKB Cobra/1240
- References:
- Softkicking on a DKB Cobra/1240
- From: Hypex
- Re: Softkicking on a DKB Cobra/1240
- From: Thomas Richter
- Softkicking on a DKB Cobra/1240
- Prev by Date: Re: Softkicking on a DKB Cobra/1240
- Next by Date: Re: Softkicking on a DKB Cobra/1240
- Previous by thread: Re: Softkicking on a DKB Cobra/1240
- Next by thread: Re: Softkicking on a DKB Cobra/1240
- Index(es):
Relevant Pages
|
