On Fri, 4 Jun 1999, Bjorn Eriksson wrote:
> >> .org 0xfff0 ; Power-up Entry Point
> >> JMP_AP(0xf000, power_onA)
> >[...]
> >> .org 0xf200
> >> power_onA:
> >> cli
> >> cld
> >>
> >> mov ax, cs
> >> mov ds, ax
> >
> >Uhh, I don't think this is kosher. On x86, the instruction pointer at
> >reset is always at the very top of the physical address space (minus 0xf).
> >That means on a 32-bit bus, it's up at 0xfffffff0 (some chips, like the
> >386EX, only have 64MB of address space). So even though in 16-bit mode,
> >you can only see CS holding 0xf000, the selector that's loaded into it on
> >power-up is _actually_ pointing up at 0xffff0000. It's not very clear from
> >the reference manuals, I know, but that's what it's doing.
>
> Because of this you have to have a far jump (JMP_AP()-macro here) in the top
> 16 bytes of you boot-PROM if you're using a PROM/Flash/Sram larger than 1MB on
> the AMD SCxxx (SC300, SC400 etc). It's actually alot more complex/flexible with
> these processors, you have to tell the processor exaclty what areas are meant for
> what chips, Dram, PROM/Flash/Sram, ISA bus etc.
>
> Anyway, I hope that the first far-jump JMP_AP(0xF000, 0xF200) reloads CS with
> 0xF000 and that CS after this is ok to copy to DS.
No, not quite what I meant. If you look at CS:IP at boot, it _looks like_
it's set to F000:FFF0, or an address of 0x000FFFF0. CS is _actually_
loaded with a 32-bit selector, which makes CS effectively FFFF000, making
the real address referred to be 0xFFFFFFF0. If you change CS, or try to
copy CS, you will lose the invisible upper bits. Meaning don't do a far
jump and don't try to access your boot rom relative to DS!
> >This means you can't copy CS to DS and get what you want - you'll be
> >pointing in the low megabyte, but your boot ROM will be in the upper meg.
> >Instead you have to access all your data relative to cs with segment
> >overrides, use immediate data, or copy your bootstrap to some part of the
> >lower meg. Of course, if you do that, you have to do it after you've setup
> >the chipset to configure the RAM. And if your boot device is FLASH, you'll
> >have to copy your code to lower memory if you want to add a
> >FLASH-programming routine - the bus cycles of programming the part
> >generally can't be interleaved with reading (and executing).
>
> Oh, I see what you're getting at. Now, the 0xF000-0xFFFF segment is
> special here. At power on (always?) an access to that segment drives
> the CS0, which is the Chip Select for the PROM/Flash/Sram part.
It's special at boot because even though it says 0xF000, there is a 32 bit
selector loaded. If you modify it, you'll lose it.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
