>> .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.
>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.
//Bj�rn Eriksson.
