On 21 Apr 2000, Stuart Lynne wrote:
> In article <Pine.LNX.3.95.1000420074505.6790A-100000@chaos.analogic.com>,
> Richard B. Johnson <root@chaos.analogic.com> wrote:
> >On Wed, 19 Apr 2000, Anders Larsen wrote:
> >
> >> Hi,
> >>
> >> the enclosed benign patch solves two independent problems with the AMD
> >> Elan SC400 series of embedded CPUs (a 486 with DRAM controller, 8253,
> >> dual 8259, 16550 and EPP on a single chip):
> >>
> >
> >How did you get it to boot? I have the same "demo-board". Linux comes
> >up and crashes immediately with an unrecognizable scroll of high-speed
> >junk on the screen. Further, the boot-ROM seems to leave the machine
> >in virtual-86 mode after a reset so setting the PE bit traps to the
> >built-in debugger.
> >
> >I have to boot DOS, then warm-boot Linux. NotGood(tm)
>
> Are you using the AMD SC400 Eval board? I did a project on it last summer
> and it worked fine with Linux (2.2.9).
>
> What BIOS are you using? The eval board comes with several. Perhaps you will
> get better results with a different BIOS.
>
The latest and greatest, the AMD SC520. We also have a SC400 which works
with Linux although it takes about 5 minutes to boot and crawls.
I am using the General Software BIOS. If I use that, it sort-of boots
to DOS. It will crash when loading Linux.
I have my own BIOS. The BIOS I wrote presumes that the hardware has
been fully built, i.e., there is RAM, the device ports exist, etc.
In other words, it will boot any PC/AT class machine that has the
generic hardware. However, this chip-set leaves the final construction
to software. And, the documentation is ruinous at best. There isn't
any evidence that my startup-code is even being found. It is a kludge
that uses side-effects of the CPUs strange reset state ostensibly to
have the boot PROM get control at the top of 32-bit address space
where it shouldn't even be. It's supposed to be at F000:FFF0.
The documentation warns that the first jump from that location must
be a short jump to startup code, not the usual far jump. The problem
is that all short jumps are relative. A short jump to offset, say
360, is correct if the chip is addressed at F000:FFF0. However,
where does the instruction-pointer go when the chip is addressed as
FFFF:0000 (the exact same absolute address). The answer is "hyper-space".
There are some strange incantations in software (disassembled from
the existing PROM) that I copied, hoping I could at least get control.
This so-called software, filled with non-existent instructions,
(0xff, 0xfe, 0x66, 0xff, 0xae), etc., plus some strange write to
a port, that is supposed to do something helpful. However, this
software is never even getting executed. If I look at the chip-select
of the PROM during reset, I get one 120 ns enable and that's that.
This means that whatever location in the 512k PROM that, at that
instant is addressed, does not contain whatever is necessary to
continue code-fetches from that PROM. I cloned my BIOS/startup
at every 64k interval throughout the PROM. It didn't help.
The AMD email "help" desk assumes that I am a 12-year-old trying
to boot Windows and does not respond with any useful information.
A new product is being built with this chip-set, and I will attempt
to get that chip-set canceled if I can't get any help from the
Vendor.
Cheers,
Dick Johnson
Penguin : Linux version 2.3.41 on an i686 machine (800.63 BogoMips).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:18 EST