AMD SC410 boot problems with recent kernels

AMD SC410 boot problems with recent kernels

[Robert Schwebel]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1872 bytes --]

Hi,

As I reported some days ago in

  http://marc.theaimsgroup.com/?l=linux-kernel&m=100876129529834&q=raw

there are boot problems with new kernels on AMD SC410 processors. Symptom
is that the machine reboots right in the middle of the initialisation of
the serial port (indeed, right in the middle of a printk message).

In the meantime I've tracked down the problem, but cannot fully find the
origin. Here are some facts:

- The problem came in in 2.4.15. Linus has merged in some changes to
  the boot code by H. Peter Anvin (which basically are a Good Thing(TM)).
  They affect arch/i386/boot/setup.S.

- I could narrow it down to the A20 gate routines. My machine's BIOS
  doesn't seem to have the appropiate routine, so the algorithm falls
  back to using the keyboard controller method (which was also used
  in the old code).

- The problem seems to come from the code that waits for A20 gate to
  be _really_ enabled (shortly after a20_kbc:).

Attached is a experimental patch which demonstrates the problem: in line
687 you can change with a jump to "old_wait" or "new_wait" which routine
shall be used. With the old one the machine starts, with the new one it
reboots.

I must say I do not really understand what the problem is. First I thought
that maybe the loop counter overruns, but it doesn't seem to happen. I
have written the counter value to a port with LEDs and it seems to contain
"1" when the waiting loop detects the successful A20 switch.

Any idea would be helpful...

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+







[-- Attachment #2: Type: TEXT/PLAIN, Size: 2529 bytes --]

--- setup-2.4.15.S	Fri Nov  9 22:58:02 2001
+++ setup.S	Fri Dec 21 21:49:50 2001
@@ -684,6 +684,62 @@
 	outb	%al, $0x60
 	call	empty_8042
 
+	jmp	new_wait
+
+# ----- old wait routine -----
+
+old_wait: 
+
+# wait until a20 really *is* enabled; it can take a fair amount of
+# time on certain systems; Toshiba Tecras are known to have this
+# problem.  The memory location used here (0x200) is the int 0x80
+# vector, which should be safe to use.
+
+
+	pushw	%dx
+	pushw	%cx
+	xorw	%dx,%dx
+	xorw	%cx,%cx
+
+        xorw    %ax, %ax                        # segment 0x0000
+        movw    %ax, %fs
+        decw    %ax                             # segment 0xffff (HMA)
+        movw    %ax, %gs
+a20_wait_old:
+	incw	%cx
+	jnz	goon
+	incw	%dx
+goon:	
+        incw    %ax                             # unused memory location <0xfff0
+        movw    %ax, %fs:(0x200)                # we use the "int 0x80" vector
+        cmpw    %gs:(0x210), %ax                # and its corresponding HMA addr
+        je      a20_wait_old                    # loop until no longer aliased
+
+	pushw	%ax
+
+	movb    $0xa5,%al                       # select PAMR...
+	outb    %al,$0x22                       # ... via CSCIR
+	movb    $0xff,%al                       # all lines are output
+	outb    %al,$0x23                       # ... on CSCDR
+
+	movb    $0xa9,%al                       # select PADR...
+	outb    %al,$0x22                       # ... via CSCIR
+	movb    %ch,%al				# 				
+	outb    %al,$0x23
+
+	popw	%ax
+
+
+
+	popw	%cx
+	popw	%dx
+
+	jmp	rs_wait_done
+
+# ----- new wait routine -----
+
+new_wait: 
+
 	# Wait until a20 really *is* enabled; it can take a fair amount of
 	# time on certain systems; Toshiba Tecras are known to have this
 	# problem.
@@ -694,6 +750,10 @@
 	jnz	a20_done
 	loop	a20_kbc_wait_loop
 
+rs_wait_done:
+
+# ----- end of wait -----
+
 	# Final attempt: use "configuration port A"
 a20_fast:
 	inb	$0x92, %al			# Configuration Port A
@@ -909,12 +969,12 @@
 	pushw	%cx
 	pushw	%ax
 	xorw	%cx, %cx
-	movw	%cx, %fs			# Low memory
+	movw	%cx, %fs			# Low memory (segment 0x0000)
 	decw	%cx
-	movw	%cx, %gs			# High memory area
+	movw	%cx, %gs			# High memory area (segment 0xffff)
 	movw	$A20_TEST_LOOPS, %cx
-	movw	%fs:(A20_TEST_ADDR), %ax
-	pushw	%ax
+	movw	%fs:(A20_TEST_ADDR), %ax	# put content of test address...
+	pushw	%ax				# ... on stack
 a20_test_wait:
 	incw	%ax
 	movw	%ax, %fs:(A20_TEST_ADDR)

Re: AMD SC410 boot problems with recent kernels

[H. Peter Anvin]

Robert Schwebel wrote:

> Hi,
> 
> As I reported some days ago in
> 
>   http://marc.theaimsgroup.com/?l=linux-kernel&m=100876129529834&q=raw
> 
> there are boot problems with new kernels on AMD SC410 processors.


"On one particular SC410 board."


> Symptom
> is that the machine reboots right in the middle of the initialisation of
> the serial port (indeed, right in the middle of a printk message).
> 
> In the meantime I've tracked down the problem, but cannot fully find the
> origin. Here are some facts:
> 
> - The problem came in in 2.4.15. Linus has merged in some changes to
>   the boot code by H. Peter Anvin (which basically are a Good Thing(TM)).
>   They affect arch/i386/boot/setup.S.
> 
> - I could narrow it down to the A20 gate routines. My machine's BIOS
>   doesn't seem to have the appropiate routine, so the algorithm falls
>   back to using the keyboard controller method (which was also used
>   in the old code).
> 
> - The problem seems to come from the code that waits for A20 gate to
>   be _really_ enabled (shortly after a20_kbc:).
> 
> Attached is a experimental patch which demonstrates the problem: in line
> 687 you can change with a jump to "old_wait" or "new_wait" which routine
> shall be used. With the old one the machine starts, with the new one it
> reboots.
> 
> I must say I do not really understand what the problem is. First I thought
> that maybe the loop counter overruns, but it doesn't seem to happen. I
> have written the counter value to a port with LEDs and it seems to contain
> "1" when the waiting loop detects the successful A20 switch.
> 
> Any idea would be helpful...
> 


The loop counter you're outputting is the 2nd byte of the loop counter,
which really isn't interesting; what probably makes more sense to output
is the value of %dx in your code.

I would like to suggest making the following changes and try them out:

a) Change A20_TEST_LOOPS to something like 32768 in the new kernel code.

b) Add a "call delay" between the movw and the cmpw in your old_loop
   and see if it suddenly breaks;

c) Check what your %dx value is (if it's nonzero, there might be an
   issue.)

d) Once again, please complain to your motherboard/BIOS vendor and tell
   them to implement int 15h, ax=2401h.

e) Add a strictly serializing instruction sequence, such as:

	pushw %dx
	smsw %dx
	lmsw %dx
	popw %dx		

   ... where the "call delay" call is in a20_test.

	-hpa

Re: AMD SC410 boot problems with recent kernels

[Robert Schwebel]

On Fri, 21 Dec 2001, H. Peter Anvin wrote:
> > there are boot problems with new kernels on AMD SC410 processors.
>
> "On one particular SC410 board."

Ok, but it's one of the most widespread embedded x86 boards in Europe.

> The loop counter you're outputting is the 2nd byte of the loop counter,
> which really isn't interesting;

This was just from the last test: the result was %ch=0 and %cl=1.

> what probably makes more sense to output is the value of %dx in your
> code.

%dx? Do you mean %cx or do I not understand the code? ;)

> I would like to suggest making the following changes and try them out:
>
> a) Change A20_TEST_LOOPS to something like 32768 in the new kernel code.

Still reboots.

> b) Add a "call delay" between the movw and the cmpw in your old_loop
>    and see if it suddenly breaks;

No, it still works.

> c) Check what your %dx value is (if it's nonzero, there might be an
>    issue.)

I assume you mean in my old_wait code, at the lines where I give out the
stuff to the LED ports? Neither %dl nor %dh has something different from
0 here. How could something come into %dx here?

> d) Once again, please complain to your motherboard/BIOS vendor and tell
>    them to implement int 15h, ax=2401h.

I'll do that, but this won't help for the hundrets of boards which are
still out there and worked fine with the previous code...

> e) Add a strictly serializing instruction sequence, such as:
>
> 	pushw %dx
> 	smsw %dx
> 	lmsw %dx
> 	popw %dx
>
>    ... where the "call delay" call is in a20_test.

Hope I understand you correctly - I'm not an assembler wizzard yet ;) Is
this correct:

----------8<----------
a20_test:
        pushw   %cx
        pushw   %ax
        xorw    %cx, %cx
        movw    %cx, %fs                  # Low memory (segment 0x0000)
        decw    %cx
        movw    %cx, %gs                  # High memory area (segment 0xffff)
        movw    $A20_TEST_LOOPS, %cx
        movw    %fs:(A20_TEST_ADDR), %ax  # put content of test address...
        pushw   %ax                       # ... on stack
a20_test_wait:
        incw    %ax
        movw    %ax, %fs:(A20_TEST_ADDR)

        pushw   %dx
        smsw    %dx

        call    delay                     # Serialize and make delay constant

        lmsw    %dx
        popw    %dx

        cmpw    %gs:(A20_TEST_ADDR+0x10), %ax
        loope   a20_test_wait

        popw    %fs:(A20_TEST_ADDR)
        popw    %ax
        popw    %cx
        ret
---------->8----------

Still reboots with this code.

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: AMD SC410 boot problems with recent kernels

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.33.0112221520300.10528-100000@callisto.local>
By author:    Robert Schwebel <robert@schwebel.de>
In newsgroup: linux.dev.kernel
> 
> > what probably makes more sense to output is the value of %dx in your
> > code.
> 
> %dx? Do you mean %cx or do I not understand the code? ;)
> 

I mean %dx -- you'd built a 32-bit counter into %dx:%cx.

> > I would like to suggest making the following changes and try them out:
> >
> > a) Change A20_TEST_LOOPS to something like 32768 in the new kernel code.
> 
> Still reboots.
> 
> > b) Add a "call delay" between the movw and the cmpw in your old_loop
> >    and see if it suddenly breaks;
> 
> No, it still works.
> 
> > c) Check what your %dx value is (if it's nonzero, there might be an
> >    issue.)
> 
> I assume you mean in my old_wait code, at the lines where I give out the
> stuff to the LED ports? Neither %dl nor %dh has something different from
> 0 here. How could something come into %dx here?

It's part of the counter.  This seems to be *your* code, since there
is nothing even closely similar in any previous kernel, so I don't
know what you're trying to do here...

> > d) Once again, please complain to your motherboard/BIOS vendor and tell
> >    them to implement int 15h, ax=2401h.
> 
> I'll do that, but this won't help for the hundrets of boards which are
> still out there and worked fine with the previous code...

Doesn't change the fact that the board is still broken, and they
didn't provide the BIOS routine to compensate.  At that point, the
fact that the old code worked by accident is unfortunately irrelevant;
especially since you obviously have a workaround that you can use.

> > e) Add a strictly serializing instruction sequence, such as:
> >
> > 	pushw %dx
> > 	smsw %dx
> > 	lmsw %dx
> > 	popw %dx
> >
> >    ... where the "call delay" call is in a20_test.
> 
> Hope I understand you correctly - I'm not an assembler wizzard yet ;) Is
> this correct:
> 

No, but the sequence in verbatim either before or after the call
delay.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: AMD SC410 boot problems with recent kernels

[Robert Schwebel]

On 22 Dec 2001, H. Peter Anvin wrote:
> I mean %dx -- you'd built a 32-bit counter into %dx:%cx.

Ok - didn't know this. Sorry for confusion - it's the first time I'm
digging deeper into x86 assembler stuff. My conclusion is that %dx:%cx is
0000:0001 after the old wait routine.

> It's part of the counter.  This seems to be *your* code, since there
> is nothing even closely similar in any previous kernel, so I don't
> know what you're trying to do here...

See above - the code after a20_wait_old just outputs stuff to an 8 bit
dioport with LEDs attached.

> Doesn't change the fact that the board is still broken, and they
> didn't provide the BIOS routine to compensate.

Hmm, I still don't understand this. Ok, the BIOS does not have the
routine, but this is rather common on embedded boards which do not have a
full featured BIOS. I mean - the procedure used by your code is to use
BIOS, then KBC and then 'fast' method one after the other until everything
fails. So it should be ok if KBC method worked, shouldn't it? I mean - not
taking into accout that due to some strange reasons the KBC method does
_not_ work correctly at the moment, but that's another question.

> At that point, the fact that the old code worked by accident is
> unfortunately irrelevant; especially since you obviously have a
> workaround that you can use.

Could you elaborate why you think that the old code worked only by
accident? [please be patient - I'm no native speaker and it may be that I
do sometimes not understand everything correctly. I'm trying hard.] As I
said above: before I do not understand _why_ the new code breaks it's
rather difficult to draw conclusions.

If the board is really _broken_ I have no problem with the fact that in
the future the manufacturer has either to supply a correct BIOS or a
workaround patch has to be used. If it's only uggly that there's no BIOS
routine it would IMHO be better to find a way to make it work again. There
are fixes for other uggly architectures in the code as well, see the
Toshiba Laptop reference. If the board may be PC compatible, Linux should
IMHO boot without further changes.

Are there other x86 boards where the BIOS doesn't provide the routine and
where the KBC method actually _works_? Would be interesting; I'm not sure
that much people have tested this yet, as most "normal" motherboards today
have full featured BIOSes. So any comments from embedded people using the
mechanimsm on other boards (SC410 or something different) would be
helpful.

> No, but the sequence in verbatim either before or after the call
> delay.

Now, I've tried these variants in the section after a20_test_wait:

----------8<----------
        call    delay           # Serialize and make delay constant

        pushw   %dx
        smsw    %dx
        lmsw    %dx
        popw    %dx
---------->8----------
        pushw   %dx
        smsw    %dx
        lmsw    %dx
        popw    %dx

        call    delay           # Serialize and make delay constant
----------8<----------

Still no change -> reboots.

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: AMD SC410 boot problems with recent kernels

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.33.0112231009500.10528-100000@callisto.local>
By author:    Robert Schwebel <robert@schwebel.de>
In newsgroup: linux.dev.kernel
> 
> Could you elaborate why you think that the old code worked only by
> accident? [please be patient - I'm no native speaker and it may be that I
> do sometimes not understand everything correctly. I'm trying hard.] As I
> said above: before I do not understand _why_ the new code breaks it's
> rather difficult to draw conclusions.
> 
> If the board is really _broken_ I have no problem with the fact that in
> the future the manufacturer has either to supply a correct BIOS or a
> workaround patch has to be used. If it's only uggly that there's no BIOS
> routine it would IMHO be better to find a way to make it work again. There
> are fixes for other uggly architectures in the code as well, see the
> Toshiba Laptop reference. If the board may be PC compatible, Linux should
> IMHO boot without further changes.
> 

The weird part about your board is that the code clearly *works*, or
your kernel wouldn't boot at all.  It somehow poisons the system,
though, and that's utterly bizarre.

I don't think this is debuggable without access to hardware (and maybe
not even then.)

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: AMD SC410 boot problems with recent kernels

[Christer Weinigel]

hpa wrote:
>> If the board is really _broken_ I have no problem with the fact that in
>> the future the manufacturer has either to supply a correct BIOS or a
>> workaround patch has to be used. If it's only uggly that there's no BIOS
>> routine it would IMHO be better to find a way to make it work again. There
>> are fixes for other uggly architectures in the code as well, see the
>> Toshiba Laptop reference. If the board may be PC compatible, Linux should
>> IMHO boot without further changes.

It is an embedded board with a _mostly_ PC compatible CPU, but it
has a few strange bugs/features that have to be worked around. For
example look a the fix for the timer and serial port in:

    http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0667.html

Especially the serial fix is (IMHO) too ugly to live in the standard
kernel.

I'd also suggest that you change the whole gate A20-mess to:

    inb $0xee, %al

this will enable A20 propagation on the SC410 and always works, 
the disadvantage is that it won't work on a normal PC anymore.

>The weird part about your board is that the code clearly *works*, or
>your kernel wouldn't boot at all.  It somehow poisons the system,
>though, and that's utterly bizarre.
>
>I don't think this is debuggable without access to hardware (and maybe
>not even then.)

It has been a few years since I was working on an Elan SC400 board, but
if I remember correctly, the Elan CPU has some configuration registers
located at some I/O ports that on a normal PC are either "safe" or used
for something else.  

Additionally, since there normally isn't a keyboard controller on the 
SC410, accesss to port 0x60 and 0x64 trap into SMI mode, doing I/O to 
those ports could mess up a badly written BIOS.  

My belief is that the SC410 based boards are so strange that one has
to have a custom kernel anyways, so asking why it isn't 100% PC
compatible and trying to fix that is rather pointless.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Re: AMD SC410 boot problems with recent kernels

[H. Peter Anvin]

Followup to:  <20011223131658.3944A36FA8@hog.ctrl-c.liu.se>
By author:    wingel@hog.ctrl-c.liu.se (Christer Weinigel)
In newsgroup: linux.dev.kernel
> 
> It is an embedded board with a _mostly_ PC compatible CPU, but it
> has a few strange bugs/features that have to be worked around. For
> example look a the fix for the timer and serial port in:
> 
>     http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0667.html
> 
> Especially the serial fix is (IMHO) too ugly to live in the standard
> kernel.
> 

#ifdef CONFIG_SC410 time?

> My belief is that the SC410 based boards are so strange that one has
> to have a custom kernel anyways, so asking why it isn't 100% PC
> compatible and trying to fix that is rather pointless.

Thanks for confirming my suspicion.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>

Re: AMD SC410 boot problems with recent kernels

[Robert Schwebel]

On 23 Dec 2001, H. Peter Anvin wrote:
> #ifdef CONFIG_SC410 time?

What would be the best place to include this into the kernel config
scheme?  Make an option, e.g. 'AMD Elan SC410 support' in "Processor type
and features"?

I'll make an update for my SC410 patchlet on

  http://www.schwebel.de/software/dnp/index_en.html

during the next days, to add the fix for the serial port bug and the A20
problem.

Do these problems (A20, serial port, timer) only exist on AMD's SC410
chips or are they also present on the SC520s?

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: AMD SC410 boot problems with recent kernels

[H. Peter Anvin]

Robert Schwebel wrote:

> On 23 Dec 2001, H. Peter Anvin wrote:
> 
>>#ifdef CONFIG_SC410 time?
>>
> 
> What would be the best place to include this into the kernel config
> scheme?  Make an option, e.g. 'AMD Elan SC410 support' in "Processor type
> and features"?
> 


All of this is really a chipset issue, not a processor issue; I think it 
should go in the same place as "Toshiba laptop support" and such...


> I'll make an update for my SC410 patchlet on
> 
>   http://www.schwebel.de/software/dnp/index_en.html
> 
> during the next days, to add the fix for the serial port bug and the A20
> problem.
> 
> Do these problems (A20, serial port, timer) only exist on AMD's SC410
> chips or are they also present on the SC520s?


Don't know.  Perhaps someone at AMD can say?

	-hpa

[PATCH][RFC] AMD Elan patch

[Robert Schwebel]

Hi,

the following patch for linux-2.4.17 fixes problems with the AMD Elan CPUs
which are popular x86 devices for embedded applications.

Content of the patch:
---------------------

	1. add a new processor type "Elan" in "Processor type
	   and features", with CONFIG_MELAN, is introduced

	2. fix the A20 code which was broken since the cleanup
	   in 2.4.17

	3. correct the ioport resource registration for Elans
	   (standard kernel reserves ports which are special
	   function registers on Elans)

	4. fix UART transmit bug

	5. fix timer 0 frequency to correct the clock

Details:
--------

1. As discussed on LKML the Elan processors have some
   "features" which need to be fixed but should not live
   in a standard kernel. Therefore, we propose a new
   configuration option CONFIG_MELAN. Ideas for better
   places for this option in the configuration tree are
   welcome.

2. In 2.4.15 H. Peter Anvin ported the A20 gate code from
   syslinux to the kernel, which is much more sophisticated
   than the code we had before. This leads to the Elan
   processors not booting any more (they did before without
   any problem, but that was more luck than intention). If
   you try to boot kernels newer than 2.4.14 the system
   reboots right in the middle of the initialisation
   sequence. As the Elans don't have a keyboard controller
   a special A20 gate sequence is added according to the
   config option introduced in 1.

3. Due to the fact that the ports of the PIC of the original
   PC are mirrored to several adresses Linux normally reserves
   the areas 0x20..0x3f and 0xa0..0xbf for pic1 and pic2,
   although the PICs use only the first two adresses of each
   block. This part of the patch uses only the "real" adresses,
   (0x20,0x21 / 0xa0,0xa1) as the Elan processors have special
   function registers in these blocks for the integrated
   peripherals.

4. The on-chip serial interface has a bug: the UART_LSR_THRE
   bit is delayed one bit clock after the interrupt line is
   asserted, i.e. if the serial port is running at 1200 bps, and
   the tranmitter becomes empty and causes an interupt, the
   interrupt is signalled about a millisecond (1/1200second)
   _before_ the THRE bit is set. This means that when the
   interrupt handler is entered after the interrupt, the THRE
   bit is still clear, the handler believes that there is
   nothing to be done and returns.

5. A normal PC has a basic frequency for the system timer 0
   of 1.19318 MHz, whereas the Elans have 1.1892 MHz due to the
   fact that all clocks are derived from a single oscillator.
   Without the patch the clock is wrong.

Credits:
--------

- Anders Larsen <anders@alarsen.net>
  First attempt of a patch for the Elan series
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0667.html

- Jason Sodergren <jason@mugwump.taiga.com>
  Clock patch

- Christer Weinigel <wingel@hog.ctrl-c.liu.se>
  Serial interface patch, A20 patch

- H. Peter Anvin <hpa@zytor.com>
  Discussions and ideas about the A20 stuff

Patch:
------

The latest version of this patch can always be found on

  http://www.pengutronix.de/software/elan_en.html

The following code is version 2.4.17.2 of the patch. Suggestions for
further improvement are welcome.

----------8<----------8<----------8<----------8<----------8<----------
diff -urN -X kernel-patches/dontdiff linux-2.4.17/Documentation/Configure.help linux-2.4.17-rs/Documentation/Configure.help
--- linux-2.4.17/Documentation/Configure.help	Fri Dec 21 18:41:53 2001
+++ linux-2.4.17-rs/Documentation/Configure.help	Mon Dec 31 17:12:58 2001
@@ -3813,6 +3813,7 @@
    - "Pentium-4" for the Intel Pentium 4.
    - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
    - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
+   - "Elan" for the AMD Elan family (Elan SC400/SC410).
    - "Crusoe" for the Transmeta Crusoe series.
    - "Winchip-C6" for original IDT Winchip.
    - "Winchip-2" for IDT Winchip 2.
diff -urN -X kernel-patches/dontdiff linux-2.4.17/arch/i386/boot/setup.S linux-2.4.17-rs/arch/i386/boot/setup.S
--- linux-2.4.17/arch/i386/boot/setup.S	Fri Nov  9 22:58:02 2001
+++ linux-2.4.17-rs/arch/i386/boot/setup.S	Mon Dec 31 17:20:17 2001
@@ -42,6 +42,9 @@
  * if CX/DX have been changed in the e801 call and if so use AX/BX .
  * Michael Miller, April 2001 <michaelm@mjmm.org>
  *
+ * New A20 code ported from SYSLINUX by H. Peter Anvin. AMD Elan bugfixes
+ * by Robert Schwebel, December 2001 <robert@schwebel.de>
+ *
  */

 #include <linux/config.h>
@@ -646,7 +649,14 @@
 #
 # Enable A20.  This is at the very best an annoying procedure.
 # A20 code ported from SYSLINUX 1.52-1.63 by H. Peter Anvin.
+# AMD Elan bug fix by Robert Schwebel.
 #
+
+#if defined(CONFIG_MELAN)
+	inb $0xee, %al			# reading 0xee enables A20
+	jmp a20_done
+#endif
+

 A20_TEST_LOOPS		=  32		# Iterations per wait
 A20_ENABLE_LOOPS	= 255		# Total loops to try
diff -urN -X kernel-patches/dontdiff linux-2.4.17/arch/i386/config.in linux-2.4.17-rs/arch/i386/config.in
--- linux-2.4.17/arch/i386/config.in	Fri Dec 21 18:41:53 2001
+++ linux-2.4.17-rs/arch/i386/config.in	Mon Dec 31 15:22:06 2001
@@ -37,6 +37,7 @@
 	 Pentium-4				CONFIG_MPENTIUM4 \
 	 K6/K6-II/K6-III			CONFIG_MK6 \
 	 Athlon/Duron/K7			CONFIG_MK7 \
+	 Elan					CONFIG_MELAN \
 	 Crusoe					CONFIG_MCRUSOE \
 	 Winchip-C6				CONFIG_MWINCHIPC6 \
 	 Winchip-2				CONFIG_MWINCHIP2 \
@@ -125,6 +126,11 @@
    define_bool CONFIG_X86_USE_3DNOW y
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
+fi
+if [ "$CONFIG_MELAN" = "y" ]; then
+   define_int  CONFIG_X86_L1_CACHE_SHIFT 4
+   define_bool CONFIG_X86_USE_STRING_486 y
+   define_bool CONFIG_X86_ALIGNMENT_16 y
 fi
 if [ "$CONFIG_MCYRIXIII" = "y" ]; then
    define_int  CONFIG_X86_L1_CACHE_SHIFT 5
diff -urN -X kernel-patches/dontdiff linux-2.4.17/arch/i386/kernel/setup.c linux-2.4.17-rs/arch/i386/kernel/setup.c
--- linux-2.4.17/arch/i386/kernel/setup.c	Fri Dec 21 18:41:53 2001
+++ linux-2.4.17-rs/arch/i386/kernel/setup.c	Mon Dec 31 18:46:15 2001
@@ -329,6 +329,10 @@
 	{ "dma2", 0xc0, 0xdf, IORESOURCE_BUSY },
 	{ "fpu", 0xf0, 0xff, IORESOURCE_BUSY }
 };
+#ifdef CONFIG_ELAN
+standard_io_resources[1] = { "pic1", 0x20, 0x21, IORESOURCE_BUSY };
+standard_io_resources[5] = { "pic2", 0xa0, 0xa1, IORESOURCE_BUSY };
+#endif

 #define STANDARD_IO_RESOURCES (sizeof(standard_io_resources)/sizeof(struct resource))

diff -urN -X kernel-patches/dontdiff linux-2.4.17/drivers/char/serial.c linux-2.4.17-rs/drivers/char/serial.c
--- linux-2.4.17/drivers/char/serial.c	Fri Dec 21 18:41:54 2001
+++ linux-2.4.17-rs/drivers/char/serial.c	Mon Dec 31 17:53:45 2001
@@ -57,6 +57,9 @@
  * 10/00: add in optional software flow control for serial console.
  *	  Kanoj Sarcar <kanoj@sgi.com>  (Modified by Theodore Ts'o)
  *
+ * 12/01: Fix for AMD Elan bug in transmit irq routine, by
+ *	  Christer Weinigel <wingel@hog.ctrl-c.liu.se>,
+ *	  Robert Schwebel <robert@schwebel.de>
  */

 static char *serial_version = "5.05c";
@@ -853,7 +856,7 @@
 		if (!info) {
 			info = IRQ_ports[irq];
 			if (pass_counter++ > RS_ISR_PASS_LIMIT) {
-#if 0
+#ifdef SERIAL_DEBUG_INTR
 				printk("rs loop break\n");
 #endif
 				break; 	/* Prevent infinite loops */
@@ -886,6 +889,9 @@
 	int first_multi = 0;
 	struct rs_multiport_struct *multi;
 #endif
+#ifdef CONFIG_MELAN
+	int iir;
+#endif

 #ifdef SERIAL_DEBUG_INTR
 	printk("rs_interrupt_single(%d)...", irq);
@@ -900,7 +906,9 @@
 	if (multi->port_monitor)
 		first_multi = inb(multi->port_monitor);
 #endif
-
+#ifdef CONFIG_MELAN
+	iir = serial_in(info, UART_IIR);
+#endif
 	do {
 		status = serial_inp(info, UART_LSR);
 #ifdef SERIAL_DEBUG_INTR
@@ -909,10 +917,24 @@
 		if (status & UART_LSR_DR)
 			receive_chars(info, &status, regs);
 		check_modem_status(info);
+
+#ifdef CONFIG_M_ELAN
+		/*
+		 * There is a bug in the UART on the AMD Elan SC4x0
+		 * embedded processor series; the THRE bit of the line
+		 * status register seems to be delayed one bit clock after
+		 * the interrupt is generated, so kludge this if the
+		 * IIR indicates a Transmit Holding Register Interrupt
+		 *
+		 */
+		if (status & UART_LSR_THRE || (iir & UART_IIR_ID) == UART_IIR_THRI)
+			transmit_chars(info, 0);
+#else
 		if (status & UART_LSR_THRE)
 			transmit_chars(info, 0);
+#endif
 		if (pass_counter++ > RS_ISR_PASS_LIMIT) {
-#if 0
+#ifdef SERIAL_DEBUG_INTR
 			printk("rs_single loop break.\n");
 #endif
 			break;
diff -urN -X kernel-patches/dontdiff linux-2.4.17/include/asm-i386/timex.h linux-2.4.17-rs/include/asm-i386/timex.h
--- linux-2.4.17/include/asm-i386/timex.h	Thu Nov 22 20:46:18 2001
+++ linux-2.4.17-rs/include/asm-i386/timex.h	Mon Dec 31 16:08:55 2001
@@ -9,7 +9,12 @@
 #include <linux/config.h>
 #include <asm/msr.h>

-#define CLOCK_TICK_RATE	1193180 /* Underlying HZ */
+#ifdef CONFIG_MELAN
+#  define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
+#else
+#  define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
+#endif
+
 #define CLOCK_TICK_FACTOR	20	/* Factor of both 1000000 and CLOCK_TICK_RATE */
 #define FINETUNE ((((((long)LATCH * HZ - CLOCK_TICK_RATE) << SHIFT_HZ) * \
 	(1000000/CLOCK_TICK_FACTOR) / (CLOCK_TICK_RATE/CLOCK_TICK_FACTOR)) \
----------8<----------8<----------8<----------8<----------8<----------

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH][RFC] AMD Elan patch

[H. Peter Anvin]

Robert Schwebel wrote:

> diff -urN -X kernel-patches/dontdiff linux-2.4.17/arch/i386/boot/setup.S linux-2.4.17-rs/arch/i386/boot/setup.S
> --- linux-2.4.17/arch/i386/boot/setup.S	Fri Nov  9 22:58:02 2001
> +++ linux-2.4.17-rs/arch/i386/boot/setup.S	Mon Dec 31 17:20:17 2001
> @@ -42,6 +42,9 @@
>   * if CX/DX have been changed in the e801 call and if so use AX/BX .
>   * Michael Miller, April 2001 <michaelm@mjmm.org>
>   *
> + * New A20 code ported from SYSLINUX by H. Peter Anvin. AMD Elan bugfixes
> + * by Robert Schwebel, December 2001 <robert@schwebel.de>
> + *
>   */
> 
>  #include <linux/config.h>
> @@ -646,7 +649,14 @@
>  #
>  # Enable A20.  This is at the very best an annoying procedure.
>  # A20 code ported from SYSLINUX 1.52-1.63 by H. Peter Anvin.
> +# AMD Elan bug fix by Robert Schwebel.
>  #
> +
> +#if defined(CONFIG_MELAN)
> +	inb $0xee, %al			# reading 0xee enables A20
> +	jmp a20_done
> +#endif
> +
> 


Do you have documentation which verifies that A20 is enabled by the time 
the IN instruction returns?  If not, you probably don't want to jump to 
a20_done, but rather fall into a loop like the following:

#if defined(CONFIG_MELAN)
	inb $0xee, %al
a20_elan_wait:
	call a20_test
	jz a20_elan_wait
	jmp a20_done
#endif

Furthermore, I would still like to argue that this does not belong into 
"processor type and features", because all of these are *chipset* 
issues; in fact, in this particular case you're more than anything 
working around a BIOS bug (not having INT 15h AX=2401h do the right thing).

I'm also very uncomfortable with putting this where you do; I think it 
should be put before a20_kbc instead.  If the BIOS is implemented 
correctly, it should be used.

	-hpa

Re: [PATCH][RFC] AMD Elan patch

[Robert Schwebel]

On Tue, 1 Jan 2002, H. Peter Anvin wrote:
> Do you have documentation which verifies that A20 is enabled by the
> time the IN instruction returns?

The manual says:

----------8<----------
Alternate Gate A20 Control Register (Port 00EEh) A special 8-bit
read/write control register provides a fast and reliable way to control
the CPU A20 signal.  A dummy read of this register returns a value of FFh
and forces the CPU A20 to propagate to the core logic, while a dummy write
to this register will cause the CPU A20 signal to be forced Low as long as
no other A20 gate control sources are forcing the CPU A20 signal to
propagate.
---------->8----------

But neither this nor the register description ("Alternate GateA20 Control
This register can be used to cause the same type of masking of the CPU A20
signal that was historically performed by an external SCP (System Control
Processor) in a PC/AT Compatible system, but much faster.") says something
about _how_ fast it is done.

> If not, you probably don't want to jump to a20_done, but rather fall
> into a loop like the following:
>
> #if defined(CONFIG_MELAN)
> 	inb $0xee, %al
> a20_elan_wait:
> 	call a20_test
> 	jz a20_elan_wait
> 	jmp a20_done
> #endif

Sounds good, I'll integrate it.

> Furthermore, I would still like to argue that this does not belong
> into "processor type and features", because all of these are *chipset*
> issues;

Hmm, there is no special section for chipset issues, the only ones I could
find are "Toshiba Laptop support" and "Dell Laptop Support" (also in
"Processor type and features"). Other chipset bugfix options are in the
IDE driver section, but this doesn't apply here. So the options would be

- add something like "Elan Support" in "Processor type and features"
- add a new section for general chipset fixes

What do you think?

> I'm also very uncomfortable with putting this where you do; I think it
> should be put before a20_kbc instead.  If the BIOS is implemented
> correctly, it should be used.

ACK, I'll have a look at it tomorow.

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH][RFC] AMD Elan patch

[H. Peter Anvin]

Robert Schwebel wrote:

> 
> ----------8<----------
> Alternate Gate A20 Control Register (Port 00EEh) A special 8-bit
> read/write control register provides a fast and reliable way to control
> the CPU A20 signal.  A dummy read of this register returns a value of FFh
> and forces the CPU A20 to propagate to the core logic, while a dummy write
> to this register will cause the CPU A20 signal to be forced Low as long as
> no other A20 gate control sources are forcing the CPU A20 signal to
> propagate.
> ---------->8----------
> 
> But neither this nor the register description ("Alternate GateA20 Control
> This register can be used to cause the same type of masking of the CPU A20
> signal that was historically performed by an external SCP (System Control
> Processor) in a PC/AT Compatible system, but much faster.") says something
> about _how_ fast it is done.
> 


Right, so you need the explicit synchronization.

Do you happen to know if there is an easy and safe way to detect an Elan 
at runtime?  If so, it might make more sense to make this a runtime 
decision instead.

> 
> Hmm, there is no special section for chipset issues, the only ones I could
> find are "Toshiba Laptop support" and "Dell Laptop Support" (also in
> "Processor type and features"). Other chipset bugfix options are in the
> IDE driver section, but this doesn't apply here. So the options would be
> 
> - add something like "Elan Support" in "Processor type and features"
> - add a new section for general chipset fixes
> 
> What do you think?
> 


"Processor type and features" is good enough for now, I think.  It's not 
a very large section.

	-hpa

Re: [PATCH][RFC] AMD Elan patch

[Dave Jones]

On Tue, 1 Jan 2002, H. Peter Anvin wrote:

> Do you happen to know if there is an easy and safe way to detect an Elan
> at runtime? If so, it might make more sense to make this a runtime
> decision instead.

Family 4 Model 10 or so my information tells me.
Unless there are also others with the same name and different cpuid info.

Dave.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH][RFC] AMD Elan patch

[Christer Weinigel]

> H. Peter Anvin wrote:

> Do you have documentation which verifies that A20 is enabled by the time 
> the IN instruction returns?  

>From the manual for the SC410 (found on AMD's homepage):

    Alternate Gate A20 Control Register (Port 00EEh) A special 8-bit
    read/write control register provides a fast and reliable way to
    control the CPU A20 signal. A dummy read of this register returns
    a value of FFh and forces the CPU A20 to propagate to the core
    logic, while a dummy write to this register will cause the CPU A20
    signal to be forced Low as long as no other A20 gate control
    sources are forcing the CPU A20 signal to propagate.

I think it's safe to assume that it takes effect immediately.

> Furthermore, I would still like to argue that this does not belong into 
> "processor type and features", because all of these are *chipset* 
> issues; in fact, in this particular case you're more than anything 
> working around a BIOS bug (not having INT 15h AX=2401h do the right thing).

I agree that it might be better to have a chipset option similar to
CONFIG_VISWS:

bool 'SGI Visual Workstation support' CONFIG_VISWS
...
bool 'AMD Elan SC4x0 support' CONFIG_ELAN_SC4x0
if [ "$CONFIG_ELAN_SC4x0" != "n" ]; then
    bool '  Use "inb 0xee" to control A20' CONFIG_ELAN_SC4x0_A20
fi

> I'm also very uncomfortable with putting this where you do; I think it 
> should be put before a20_kbc instead.  If the BIOS is implemented 
> correctly, it should be used.

I disagree, the Elan SC410 is an embedded CPU, it's used in systems
that might not even have a BIOS (such as the Ericsson eBox that I've
been working with).  Since there has to be a config option for this
CPU (the clock frequency selection) and a SC410-enabled kernel won't
work properly on a normal PC anyway, why not modify the boot sequence
so that it _always_ works on this CPU.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Re: [PATCH][RFC] AMD Elan patch

[H. Peter Anvin]

Dave Jones wrote:

> On Tue, 1 Jan 2002, H. Peter Anvin wrote:
> 
> 
>>Do you happen to know if there is an easy and safe way to detect an Elan
>>at runtime? If so, it might make more sense to make this a runtime
>>decision instead.
>>
> 
> Family 4 Model 10 or so my information tells me.
> Unless there are also others with the same name and different cpuid info.
> 


That identifies the CPU core, but not the chipset -- and it's quite 
likely the CPU core will pop up in other uses.

Not trustworthy.

	-hpa

Re: [PATCH][RFC] AMD Elan patch

[H. Peter Anvin]

Christer Weinigel wrote:

> 
>     Alternate Gate A20 Control Register (Port 00EEh) A special 8-bit
>     read/write control register provides a fast and reliable way to
>     control the CPU A20 signal. A dummy read of this register returns
>     a value of FFh and forces the CPU A20 to propagate to the core
>     logic, while a dummy write to this register will cause the CPU A20
>     signal to be forced Low as long as no other A20 gate control
>     sources are forcing the CPU A20 signal to propagate.
> 
> I think it's safe to assume that it takes effect immediately.
> 


What leads you to that conclusion?  There is nothing in the above 
paragraph that would lead you to believe that.

> 
>>I'm also very uncomfortable with putting this where you do; I think it 
>>should be put before a20_kbc instead.  If the BIOS is implemented 
>>correctly, it should be used.
>>
> 
> I disagree, the Elan SC410 is an embedded CPU, it's used in systems
> that might not even have a BIOS (such as the Ericsson eBox that I've
> been working with).  Since there has to be a config option for this
> CPU (the clock frequency selection) and a SC410-enabled kernel won't
> work properly on a normal PC anyway, why not modify the boot sequence
> so that it _always_ works on this CPU.
> 


If used sans BIOS you need *massive* modifications to the setup anyway, 
and you're talking a completely custom kernel.  The reason to use the 
BIOS first is to give the platform vendor a hook to deal with 
platform-specific issues, and God knows there are plenty of those when 
it comes to A20.  (The fact that the BIOSes on the boards we have 
discussed haven't provided such a hook is a bug in itself.)

	-hpa

Re: [RFC] Embedded X86 systems Was: [PATCH][RFC] AMD Elan patch

[Christer Weinigel]

H. Peter Anvin wrote:
> Robert Schwebel wrote:
> > Hmm, there is no special section for chipset issues, the only ones I could
> > find are "Toshiba Laptop support" and "Dell Laptop Support" (also in
> > "Processor type and features"). Other chipset bugfix options are in the
> > IDE driver section, but this doesn't apply here. So the options would be
> > 
> > - add something like "Elan Support" in "Processor type and features"
> > - add a new section for general chipset fixes
> 
> "Processor type and features" is good enough for now, I think.  It's not 
> a very large section.

I belive that we're going to see a lot more x86-based embedded systems
in the future, some that won't even have a normal PC BIOS.  So I think
that we ought to do something like the m68k and arm architectures
where it's possible to have different setup code for different CPUs,
chipsets and specific board designs.  

I've been working with three different NatSemi Geode based designs
lately (two really PC compatible, one requiring special boot code) and
I think it would be good to come up with some guidelines for where to
put these config options and how to name them.

The different x86 embedded CPUs I've been working with are the AMD
Elan SC410, Cyrix MediaGX/National Semiconducgtor Geode with the
Cx5530 companion chip, National SC2200 (basically a Geode + Cx5530 on
a chip) and ZF Embedded.  All of these have some quirks or features
that could use some configuration options.

Some CPUs/Chipsets/Design choices will stop the kernel from working
properly on a normal PC, e.g. an Elan enabled kernel will have the
wrong clock, while some other options such as the National SC2200 only
have some extra chipset features that can be safely detected and
ignored when not present.

Right now I'm working on a Natsemi SC2200 design and this is how I
feel the support for this design should be split up:

Processor family:

Maybe add a CONFIG_GEODE option since all Geode CPUs have a cache line
size of 16 bytes, so CONFIG_X86_L1_CACHE_SHIFT should be 4.  How
important is the cache line size for the performance of the kernel,
does it really make a difference, if it doesn't the generic M586
option is enough.

Chipset:

There is the basic Cx5530 chipset, which could have support in the
Linux kernel (IDE, graphics and sound).

"IA on a chip" SCx200 which is an integrated Geode + Cx5530, so most
of the the 5530 options would apply here.  Additionally there is a
built in watchdog timer in the CPU, some GPIO lines, and a high
precision timer that could be used instead of the TSC to get a good
time of day reading.

There are three different SCx200 variants, some features are common
for all chips, some are specific for a variant, such as the video
input port and graphics overlay/genlock.

Board design:

There are a lot of different designs based on the Geode family CPUs
and chipsets, and they are all different.  Some are mostly PC
compatible and some are wholly customised, the IRQ routing can be
unique for each board and GPIOs can have multiplexed functions, so
that if one isn't careful, it's possible to configure the TFT screen
outputs as an parallell port instead and possibly fry the screen.

Firmware, BIOS or boot loader:

Right now the design I'm working on uses an Insyde BIOS which is a
rather normal PC BIOS, but I'm looking at the possibility of doing my
own bootloader in the future, to lose the licence fees and to
implement some features such as a serial or network console.  This
means that right now the board looks and boots like a PC but in the
future there might be no BIOS functions available at all.

So, does anyone have any ideas on how to organize the configuration
options?  How should they be named?  The choices I've made so far are:

I've added a config option (near CONFIG_VISWS) for the chipset:

    bool 'National Geode SCx200 support' CONFIG_ARCH_SCx200

and right after it have an option to do board-specific initialization:

    mainmenu_option next_comment
    comment 'NatSemi SCx200 implementations'
    bool '  My little design' CONFIG_SCx200_MY_LITTLE_DESIGN

For the generic SCx200 features, I've added drivers in the respective
directories such as a watchdog driver in drivers/char:

    dep_tristate '  NatSemi SCx200 Watchdog' CONFIG_SCx200_WATCHDOG \
					     $CONFIG_ARCH_SCx200

Does this organization look good?  Any suggestions on what to call a
config option that changes the setup code to work with a custom
bootloader or board:

    bool '  Normal PC BIOS support' CONFIG_SETUP_PC_BIOS
    bool '  Ericsson eBox boot protocol' CONFIG_SETUP_EB100
    bool '  Magic GRUB variant as BIOS' CONFIG_SETUP_MAGIC_GRUB_VARIANT

  /Christer (being a wee bit to verbose again)

-- 
"Just how much can I get away with and still go to heaven?"

Re: [PATCH][RFC] AMD Elan patch

[Christer Weinigel]

H. Peter Anvin wrote:

> The reason to use the BIOS first is to give the platform vendor a
> hook to deal with platform-specific issues, and God knows there are
> plenty of those when it comes to A20. 

Well, the Elan SC4x0 doesn't have a lot of issues, everything having
to do with A20 is on the chip itself, so it would take a really brain
damaged design to mess this up. :-)

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Re: [RFC] Embedded X86 systems Was: [PATCH][RFC] AMD Elan patch

[Alan Cox]

> There is the basic Cx5530 chipset, which could have support in the
> Linux kernel (IDE, graphics and sound).

It already does. Has done for ages. The non SB emulation mode of the audio
is not supported but that I don't think matters.

> for all chips, some are specific for a variant, such as the video
> input port and graphics overlay/genlock.

X11

In general if we want to support lots of weird crap then the ARM folks have
a very nice model and a lot of weird crap to have developed their ideas
against. Personal preference

	Type of system	(PC, Embedded)

then for PC leave as is, for embedded
	
	Board type (blah, blah , blah)
	Firmware (PC BIOS, LinuxBIOS, RedBoot)

Re: [RFC] Embedded X86 systems Was: [PATCH][RFC] AMD Elan patch

[Christer Weinigel]

Alan Cox wrote:
> > There is the basic Cx5530 chipset, which could have support in the
> > Linux kernel (IDE, graphics and sound).
> 
> It already does. Has done for ages. The non SB emulation mode of the audio
> is not supported but that I don't think matters.

I think that only the Cx550 IDE stuff is in the main kernel though,
the Cx5530 audio is a separate patch.  Also, the PCI IDs have change
for the SCx200, so the IDE driver needs to be updated.  I have a patch
for this and it seems to work, but I want to test it a bit more first.

> In general if we want to support lots of weird crap then the ARM folks have
> a very nice model and a lot of weird crap to have developed their ideas
> against. Personal preference
> 
> 	Type of system	(PC, Embedded)
>
> then for PC leave as is, for embedded
> 	
> 	Board type (blah, blah , blah)
> 	Firmware (PC BIOS, LinuxBIOS, RedBoot)

Sounds good.

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Re: [RFC] Embedded X86 systems Was: [PATCH][RFC] AMD Elan patch

[Alan Cox]

> I think that only the Cx550 IDE stuff is in the main kernel though,
> the Cx5530 audio is a separate patch.  Also, the PCI IDs have change

The 5530 audio is emulated SB16 by the BIOS firmware. There is a hideous
native mode driver but it was too disgusting to even consider a merge and
needs bios stuff that pretty much no real world 5530 based device has.

> for the SCx200, so the IDE driver needs to be updated.  I have a patch
> for this and it seems to work, but I want to test it a bit more first.

Ok

Re: [PATCH][RFC] AMD Elan patch

[Robert Schwebel]

On Wed, 2 Jan 2002, Dave Jones wrote:
> Family 4 Model 10 or so my information tells me. Unless there are also
> others with the same name and different cpuid info.

That's what /proc/cpuinfo says. Is there an instance where one can find
the "official" families and model numbers? Something like a standard?

The only thing I've found on the net is this:

  http://grafi.ii.pw.edu.pl/gbm/x86/cpuid.html#AuthenticAMD

Which doesn't list the ELANs. I couldn't also find something on AMD's
page.

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH][RFC] AMD Elan patch

[Robert Schwebel]

On Wed, 2 Jan 2002, Christer Weinigel wrote:
> > I'm also very uncomfortable with putting this where you do; I think it
> > should be put before a20_kbc instead.  If the BIOS is implemented
> > correctly, it should be used.
>
> I disagree, the Elan SC410 is an embedded CPU, it's used in systems
> that might not even have a BIOS (such as the Ericsson eBox that I've
> been working with).

Agreed. I think the CPU type is meant for "physical" CPU families, and the
Elan family is one, similar to "K6/K6-II/K6-III", "Athlon/Duron/K7" etc.
At the moment I don't change the category, let's hear what the maintainers
say once we've discussed the other bits and pieces.

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH][RFC] AMD Elan patch

[Robert Schwebel]

On Wed, 2 Jan 2002, Christer Weinigel wrote:
> Well, the Elan SC4x0 doesn't have a lot of issues, everything having
> to do with A20 is on the chip itself, so it would take a really brain
> damaged design to mess this up. :-)

True, but does "Family 4, Model 10" always mean "Elan SC410"? An official
source from AMD would be great here. Is anybody from AMD on the list or
does anybody have the address of a contact person?

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH][RFC] AMD Elan patch

[Dave Jones]

> > Family 4 Model 10 or so my information tells me. Unless there are also
> > others with the same name and different cpuid info.
> That's what /proc/cpuinfo says. Is there an instance where one can find
> the "official" families and model numbers? Something like a standard?

x86info is the closest thing to a complete list, but as hpa pointed out,
the problem identifying the cpu is easy, identifying the chipset is the
hard part.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH][RFC] AMD Elan patch

[Robert Schwebel]

Hi,

Version 2.4.17.3 of the AMD Elan patch is on

  http://www.pengutronix.de/software/elan_en.html

Changelog:
----------

01/02/2002      Robert Schwebel <robert@schwebel.de>

                - Revision 2.4.17.3 released.
                - Loop inserted to check if A20 gate was
                  _really_ activated.
                  H. Peter Anvin <hpa@zytor.com>
                - We are currently unsure which would be the
                  best position for the Elan patch in the
                  kernel configuration tree. Has to be
                  discussed with maintainers.

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH][RFC] AMD Elan patch

[Alan Cox]

> Which doesn't list the ELANs. I couldn't also find something on AMD's
> page.

The Elan 410 docs are on the AMD site. Look under embedded processors

Re: [PATCH][RFC] AMD Elan patch

[Alan Cox]

> x86info is the closest thing to a complete list, but as hpa pointed out,
> the problem identifying the cpu is easy, identifying the chipset is the
> hard part.

I can guarantee 100% correct chipset identification. If you meet an ELAN410
it is the chipset too. The ISA and VLB come directly off the CPU

Re: [PATCH][RFC] AMD Elan patch

[Robert Schwebel]

On Wed, 2 Jan 2002, Alan Cox wrote:
> The Elan 410 docs are on the AMD site. Look under embedded processors

I've already searched through all manuals I could find on the AMD site
(http://www.amd.com/epd/processors/4.32bitcont/13.lan4xxfam/23.lansc410/index.html)
but couldn't find anything related to the CPUID command...

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH][RFC] AMD Elan patch

[Robert Schwebel]

On Wed, 2 Jan 2002, Robert Schwebel wrote:
> I've already searched through all manuals I could find on the AMD site
> (http://www.amd.com/epd/processors/4.32bitcont/13.lan4xxfam/23.lansc410/index.html)
> but couldn't find anything related to the CPUID command...

Aaargh, does anyone have a brown paper bag for me? The infomration is in
the User Manual.

Model  0ah means "enhanced Am486 SX1 write back mode"
Family 04h means "Am486 CPU"

Which IMHO doesn't say that this combination means _exactly_ the SC410.

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH][RFC] AMD Elan patch

[Christer Weinigel]

Robert Schwebel wrote:
> True, but does "Family 4, Model 10" always mean "Elan SC410"? An official
> source from AMD would be great here. Is anybody from AMD on the list or
> does anybody have the address of a contact person?

It seems as if "Family 4, Model 10" isn't enought, but the Users
Manual describes how to detect an Elan SC4x0 Processor:

3.6 CPU CORE IDENTIFICATION USING THE CPUID INSTRUCTION

The ElanSC400 and ElanSC410 microcontrollers are the first members of
a new family of embedded devices. The CPUID instruction can be used to
identify a processor as belonging to this family.

The Am486 CPU core in the ElanSC400 and ElanSC410 microcontrollers is
the first CPU AMD has made with a write-back cache and no FPU, so
these tests should be sufficient to uniquely identify the family.

Using the CPUID instruction the microcontroller can be done with the
following steps, as shown in the code sample in Section 3.6.3:

    * Make sure the manufacturer name is "AuthenticAMD".

    * Make sure the device is described as a 486 SX1 with a write-back
      cache.  

If it passes all the tests it must be an ElanSC400 microcontroller or
derivative.

If it's worth it or not, I don't know, I'm just curious, it has been
years since I did anything with the Elan processor for real. :-)

  /Christer

-- 
"Just how much can I get away with and still go to heaven?"

Re: [PATCH][RFC] AMD Elan patch

[H. Peter Anvin]

Alan Cox wrote:

>>x86info is the closest thing to a complete list, but as hpa pointed out,
>>the problem identifying the cpu is easy, identifying the chipset is the
>>hard part.
>>
> 
> I can guarantee 100% correct chipset identification. If you meet an ELAN410
> it is the chipset too. The ISA and VLB come directly off the CPU
> 

That's not the problem, really... the problems is that CPUID identifies 
the CPU core, and embedded CPU cores tend to be used and reused many 
times -- in fact, AMD are quite good at that.

	-hpa

Re: [PATCH][RFC] AMD Elan patch

[H. Peter Anvin]

Alan Cox wrote:

> 
> The 400/410 this isnt a problem for. Its discontinued and the 5x0 detect
> differently (and actually have working serial ports I believe). So its
> an end of life core
> 

It's end of lifed in this particular product, does that mean the core 
itself won't find itself embedded in something? ...

	-hpa

Re: [PATCH][RFC] AMD Elan patch

[Peter Wächtler]

Robert Schwebel schrieb:
> 
> On Wed, 2 Jan 2002, Robert Schwebel wrote:
> > I've already searched through all manuals I could find on the AMD site
> > (http://www.amd.com/epd/processors/4.32bitcont/13.lan4xxfam/23.lansc410/index.html)
> > but couldn't find anything related to the CPUID command...
> 
> Aaargh, does anyone have a brown paper bag for me? The infomration is in
> the User Manual.
> 
> Model  0ah means "enhanced Am486 SX1 write back mode"
> Family 04h means "Am486 CPU"
> 
> Which IMHO doesn't say that this combination means _exactly_ the SC410.
> 

IIRC the difference between SC410 and SC400 is an embedded PCMCIA controller
and perhaps a LCD controller.
The CPU core should be the same.

Re: [PATCH][RFC] AMD Elan patch

[Alan Cox]

> That's not the problem, really... the problems is that CPUID identifies 
> the CPU core, and embedded CPU cores tend to be used and reused many 
> times -- in fact, AMD are quite good at that.

The 400/410 this isnt a problem for. Its discontinued and the 5x0 detect
differently (and actually have working serial ports I believe). So its
an end of life core

Re: [PATCH][RFC] AMD Elan patch

[H. Peter Anvin]

Peter Wächtler wrote:

>>
>>Model  0ah means "enhanced Am486 SX1 write back mode"
>>Family 04h means "Am486 CPU"
>>
>>Which IMHO doesn't say that this combination means _exactly_ the SC410.
>>
> IIRC the difference between SC410 and SC400 is an embedded PCMCIA controller
> and perhaps a LCD controller.
> The CPU core should be the same.
> 

The problem is that we're talking about problems in the chipset portion.

	-hpa

Re: [PATCH][RFC] AMD Elan patch

[Alan Cox]

> It's end of lifed in this particular product, does that mean the core 
> itself won't find itself embedded in something? ...

I think we can be confident of that yes

Re: [PATCH][RFC] AMD Elan patch

[Robert Kaiser]

On Wed, 2 Jan 2002, Alan Cox wrote:

> The 400/410 this isnt a problem for. Its discontinued and the 5x0 detect
> differently (and actually have working serial ports I believe). 
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This part is not true AFAIK. I understand they "ported" that
incompatibility from the 4x0 to the 520.

> So its an end of life core

Yes, but is that an excuse for Linux to not support it ? I mean,
Linux still does support the 386 ...

Rob

----------------------------------------------------------------
Robert Kaiser                          email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany    fax:   (49) 6136 9948-10

Re: [PATCH][RFC] AMD Elan patch

[Alan Cox]

> > differently (and actually have working serial ports I believe). 
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This part is not true AFAIK. I understand they "ported" that
> incompatibility from the 4x0 to the 520.

Groan. Has anyone got a spare daisycutter ..

> > So its an end of life core
> 
> Yes, but is that an excuse for Linux to not support it ? I mean,
> Linux still does support the 386 ...

I meant that as in "so it wont be appearing in any new form" not that we
should not support it.

Re: [PATCH][RFC] AMD Elan patch

[Robert Schwebel]

On Wed, 2 Jan 2002, H. Peter Anvin wrote:
> That's not the problem, really... the problems is that CPUID identifies
> the CPU core, and embedded CPU cores tend to be used and reused many
> times -- in fact, AMD are quite good at that.

Sounds reasonably. I think we should stay with the configuration option at
the moment.

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH][RFC] AMD Elan patch

[Robert Schwebel]

On Wed, 2 Jan 2002, H. Peter Anvin wrote:
> It's end of lifed in this particular product, does that mean the core
> itself won't find itself embedded in something? ...

The probability is rather low, as the 486 cores are definitely a dying
species. AMD is, as many other manufacturers, going the 586 way on it's
embedded roadmaps, as modern embedded 586 cores have the same low power
requirements and there are designs available which have all the advantages
of the [34]86s but a more modern core and stuff like PCI interfaces.

But nevertheless, relying on assumptions is no good design, so we should
stay with the current solution. If somebody adds stuff for the SC520 it
should be no problem to add something for differentiation.

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [RFC] Embedded X86 systems Was: [PATCH][RFC] AMD Elan patch

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> > There is the basic Cx5530 chipset, which could have support in the
> > Linux kernel (IDE, graphics and sound).
> 
> It already does. Has done for ages. The non SB emulation mode of the audio
> is not supported but that I don't think matters.
> 
> > for all chips, some are specific for a variant, such as the video
> > input port and graphics overlay/genlock.
> 
> X11
> 
> In general if we want to support lots of weird crap then the ARM folks have
> a very nice model and a lot of weird crap to have developed their ideas
> against. Personal preference
> 
> 	Type of system	(PC, Embedded)
> 
> then for PC leave as is, for embedded
> 	
> 	Board type (blah, blah , blah)
> 	Firmware (PC BIOS, LinuxBIOS, RedBoot)

A couple of thoughts on this. 

With LinuxBIOS it is one of my design goals that you not need to know
the board type.  Plus I frequently run kernels that allow me to boot
with either LinuxBIOS or a PC BIOS, as that makes reverse engineering
easier.

Further in cases where we actually control the firmware (LinuxBIOS,
RedBoot?) it makes sense to have the firmware pass us configuration
values for places where it deviates from the norm.  This doesn't incur
any extra firmware overhead as firmware is already board specific, and
with flash chips it is easy enough to update.  The linux kernel then
would just need to handle a new configuration option.

For the truly weird, horrible or expedient cases we probably want to
have the choice be 
       Type of system (PC, Dedicated).  
I believe dedicated describes the category better.  Embedded refers to
computers in small hidden places.  Where dedicated just means a
computer setup that doesn't need to handle the general case.  That
plus I have trouble seeing a SGI workstation, or a 512 node cluster
running LinuxBIOS as an embedded system :)

Having Board type under dedicated/embedded sounds quite reasonable.
And for weird things like LinuxBIOS it probably makes sense to at
least develop their support under something like dedicated.  And only
if it becomes more general purpose move it out of there.

I'm thinking this through carefully as I'm getting close to doing
figuring out what I need to do to get LinuxBIOS support into the
kernel.  The structure is finally starting to look good enough that
this is reasonable. 

Eric

[PATCH] AMD Elan patch

[Robert Schwebel]

Hello Marcelo,

Here's the latest version of the AMD Elan patch. It was discussed on LKML,
and as nobody seems to have objections any more I would like to ask you to
apply it.

Description:

The following patch for linux-2.4.18-pre3 fixes problems with the AMD Elan
CPUs which are popular x86 devices for embedded applications.

Content of the patch:
---------------------

	1. add a new processor type "Elan" in "Processor type
	   and features", with CONFIG_MELAN, is introduced

	2. fix the A20 code which was broken since the cleanup
	   in 2.4.15

	3. correct the ioport resource registration for Elans
	   (standard kernel reserves ports which are special
	   function registers on Elans)

	4. fix UART transmit bug

	5. fix timer 0 frequency to correct the clock

Details:
--------

1. As discussed on LKML the Elan processors have some
   "features" which need to be fixed but should not live
   in a standard kernel. Therefore, we propose a new
   configuration option CONFIG_MELAN. Ideas for better
   places for this option in the configuration tree are
   welcome.

2. In 2.4.15 H. Peter Anvin ported the A20 gate code from
   syslinux to the kernel, which is much more sophisticated
   than the code we had before. This leads to the Elan
   processors not booting any more (they did before without
   any problem, but that was more luck than intention). If
   you try to boot kernels newer than 2.4.14 the system
   reboots right in the middle of the initialisation
   sequence. As the Elans don't have a keyboard controller
   a special A20 gate sequence is added according to the
   config option introduced in 1.

3. Due to the fact that the ports of the PIC of the original
   PC are mirrored to several adresses Linux normally reserves
   the areas 0x20..0x3f and 0xa0..0xbf for pic1 and pic2,
   although the PICs use only the first two adresses of each
   block. This part of the patch uses only the "real" adresses,
   (0x20,0x21 / 0xa0,0xa1) as the Elan processors have special
   function registers in these blocks for the integrated
   peripherals.

4. The on-chip serial interface has a bug: the UART_LSR_THRE
   bit is delayed one bit clock after the interrupt line is
   asserted, i.e. if the serial port is running at 1200 bps, and
   the tranmitter becomes empty and causes an interupt, the
   interrupt is signalled about a millisecond (1/1200second)
   _before_ the THRE bit is set. This means that when the
   interrupt handler is entered after the interrupt, the THRE
   bit is still clear, the handler believes that there is
   nothing to be done and returns.

5. A normal PC has a basic frequency for the system timer 0
   of 1.19318 MHz, whereas the Elans have 1.1892 MHz due to the
   fact that all clocks are derived from a single oscillator.
   Without the patch the clock is wrong.

Credits:
--------

- Anders Larsen <anders@alarsen.net>
  First attempt of a patch for the Elan series
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0667.html

- Jason Sodergren <jason@mugwump.taiga.com>
  Clock patch

- Christer Weinigel <wingel@hog.ctrl-c.liu.se>
  Serial interface patch, A20 patch

- H. Peter Anvin <hpa@zytor.com>
  Discussions and ideas about the A20 stuff

Patch:
------

The latest version of this patch can always be found on

  http://www.pengutronix.de/software/elan_en.html

The following code is version 2.4.18-pre3.1 of the patch. Suggestions for
further improvement are welcome.

----------8<----------8<----------8<----------8<----------8<----------
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre3/CREDITS linux-2.4.18-pre3-elan/CREDITS
--- linux-2.4.18-pre3/CREDITS	Fri Jan 11 08:27:41 2002
+++ linux-2.4.18-pre3-elan/CREDITS	Fri Jan 11 08:42:38 2002
@@ -2652,6 +2652,16 @@
 S: Oldenburg
 S: Germany

+N: Robert Schwebel
+E: robert@schwebel.de
+W: http://www.schwebel.de
+D: Embedded hacker and book author,
+D: AMD Elan support for Linux
+S: Pengutronix
+S: Braunschweiger Strasse 79
+S: 31134 Hildesheim
+S: Germany
+
 N: Darren Senn
 E: sinster@darkwater.com
 D: Whatever I notice needs doing (so far: itimers, /proc)
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre3/Documentation/Configure.help linux-2.4.18-pre3-elan/Documentation/Configure.help
--- linux-2.4.18-pre3/Documentation/Configure.help	Fri Jan 11 08:27:41 2002
+++ linux-2.4.18-pre3-elan/Documentation/Configure.help	Fri Jan 11 08:34:57 2002
@@ -3813,6 +3813,7 @@
    - "Pentium-4" for the Intel Pentium 4.
    - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
    - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
+   - "Elan" for the AMD Elan family (Elan SC400/SC410).
    - "Crusoe" for the Transmeta Crusoe series.
    - "Winchip-C6" for original IDT Winchip.
    - "Winchip-2" for IDT Winchip 2.
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre3/arch/i386/boot/setup.S linux-2.4.18-pre3-elan/arch/i386/boot/setup.S
--- linux-2.4.18-pre3/arch/i386/boot/setup.S	Fri Jan 11 08:27:42 2002
+++ linux-2.4.18-pre3-elan/arch/i386/boot/setup.S	Fri Jan 11 08:34:57 2002
@@ -42,6 +42,9 @@
  * if CX/DX have been changed in the e801 call and if so use AX/BX .
  * Michael Miller, April 2001 <michaelm@mjmm.org>
  *
+ * New A20 code ported from SYSLINUX by H. Peter Anvin. AMD Elan bugfixes
+ * by Robert Schwebel, December 2001 <robert@schwebel.de>
+ *
  */

 #include <linux/config.h>
@@ -651,7 +654,17 @@
 #
 # Enable A20.  This is at the very best an annoying procedure.
 # A20 code ported from SYSLINUX 1.52-1.63 by H. Peter Anvin.
+# AMD Elan bug fix by Robert Schwebel.
 #
+
+#if defined(CONFIG_MELAN)
+	inb $0xee, %al			# reading 0xee enables A20
+a20_elan_wait:
+        call a20_test
+        jz a20_elan_wait
+	jmp a20_done
+#endif
+

 A20_TEST_LOOPS		=  32		# Iterations per wait
 A20_ENABLE_LOOPS	= 255		# Total loops to try
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre3/arch/i386/config.in linux-2.4.18-pre3-elan/arch/i386/config.in
--- linux-2.4.18-pre3/arch/i386/config.in	Fri Dec 21 18:41:53 2001
+++ linux-2.4.18-pre3-elan/arch/i386/config.in	Fri Jan 11 08:34:57 2002
@@ -37,6 +37,7 @@
 	 Pentium-4				CONFIG_MPENTIUM4 \
 	 K6/K6-II/K6-III			CONFIG_MK6 \
 	 Athlon/Duron/K7			CONFIG_MK7 \
+	 Elan					CONFIG_MELAN \
 	 Crusoe					CONFIG_MCRUSOE \
 	 Winchip-C6				CONFIG_MWINCHIPC6 \
 	 Winchip-2				CONFIG_MWINCHIP2 \
@@ -125,6 +126,11 @@
    define_bool CONFIG_X86_USE_3DNOW y
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
+fi
+if [ "$CONFIG_MELAN" = "y" ]; then
+   define_int  CONFIG_X86_L1_CACHE_SHIFT 4
+   define_bool CONFIG_X86_USE_STRING_486 y
+   define_bool CONFIG_X86_ALIGNMENT_16 y
 fi
 if [ "$CONFIG_MCYRIXIII" = "y" ]; then
    define_int  CONFIG_X86_L1_CACHE_SHIFT 5
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre3/arch/i386/kernel/setup.c linux-2.4.18-pre3-elan/arch/i386/kernel/setup.c
--- linux-2.4.18-pre3/arch/i386/kernel/setup.c	Fri Jan 11 08:27:42 2002
+++ linux-2.4.18-pre3-elan/arch/i386/kernel/setup.c	Fri Jan 11 08:34:57 2002
@@ -329,6 +329,10 @@
 	{ "dma2", 0xc0, 0xdf, IORESOURCE_BUSY },
 	{ "fpu", 0xf0, 0xff, IORESOURCE_BUSY }
 };
+#ifdef CONFIG_ELAN
+standard_io_resources[1] = { "pic1", 0x20, 0x21, IORESOURCE_BUSY };
+standard_io_resources[5] = { "pic2", 0xa0, 0xa1, IORESOURCE_BUSY };
+#endif

 #define STANDARD_IO_RESOURCES (sizeof(standard_io_resources)/sizeof(struct resource))

diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre3/drivers/char/serial.c linux-2.4.18-pre3-elan/drivers/char/serial.c
--- linux-2.4.18-pre3/drivers/char/serial.c	Fri Jan 11 08:27:47 2002
+++ linux-2.4.18-pre3-elan/drivers/char/serial.c	Fri Jan 11 08:34:57 2002
@@ -57,6 +57,9 @@
  * 10/00: add in optional software flow control for serial console.
  *	  Kanoj Sarcar <kanoj@sgi.com>  (Modified by Theodore Ts'o)
  *
+ * 12/01: Fix for AMD Elan bug in transmit irq routine, by
+ *	  Christer Weinigel <wingel@hog.ctrl-c.liu.se>,
+ *	  Robert Schwebel <robert@schwebel.de>
  */

 static char *serial_version = "5.05c";
@@ -853,7 +856,7 @@
 		if (!info) {
 			info = IRQ_ports[irq];
 			if (pass_counter++ > RS_ISR_PASS_LIMIT) {
-#if 0
+#ifdef SERIAL_DEBUG_INTR
 				printk("rs loop break\n");
 #endif
 				break; 	/* Prevent infinite loops */
@@ -886,6 +889,9 @@
 	int first_multi = 0;
 	struct rs_multiport_struct *multi;
 #endif
+#ifdef CONFIG_MELAN
+	int iir;
+#endif

 #ifdef SERIAL_DEBUG_INTR
 	printk("rs_interrupt_single(%d)...", irq);
@@ -900,7 +906,9 @@
 	if (multi->port_monitor)
 		first_multi = inb(multi->port_monitor);
 #endif
-
+#ifdef CONFIG_MELAN
+	iir = serial_in(info, UART_IIR);
+#endif
 	do {
 		status = serial_inp(info, UART_LSR);
 #ifdef SERIAL_DEBUG_INTR
@@ -909,10 +917,24 @@
 		if (status & UART_LSR_DR)
 			receive_chars(info, &status, regs);
 		check_modem_status(info);
+
+#ifdef CONFIG_M_ELAN
+		/*
+		 * There is a bug in the UART on the AMD Elan SC4x0
+		 * embedded processor series; the THRE bit of the line
+		 * status register seems to be delayed one bit clock after
+		 * the interrupt is generated, so kludge this if the
+		 * IIR indicates a Transmit Holding Register Interrupt
+		 *
+		 */
+		if (status & UART_LSR_THRE || (iir & UART_IIR_ID) == UART_IIR_THRI)
+			transmit_chars(info, 0);
+#else
 		if (status & UART_LSR_THRE)
 			transmit_chars(info, 0);
+#endif
 		if (pass_counter++ > RS_ISR_PASS_LIMIT) {
-#if 0
+#ifdef SERIAL_DEBUG_INTR
 			printk("rs_single loop break.\n");
 #endif
 			break;
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre3/include/asm-i386/timex.h linux-2.4.18-pre3-elan/include/asm-i386/timex.h
--- linux-2.4.18-pre3/include/asm-i386/timex.h	Thu Nov 22 20:46:18 2001
+++ linux-2.4.18-pre3-elan/include/asm-i386/timex.h	Fri Jan 11 08:47:57 2002
@@ -9,7 +9,12 @@
 #include <linux/config.h>
 #include <asm/msr.h>

-#define CLOCK_TICK_RATE	1193180 /* Underlying HZ */
+#ifdef CONFIG_MELAN
+#  define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
+#else
+#  define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
+#endif
+
 #define CLOCK_TICK_FACTOR	20	/* Factor of both 1000000 and CLOCK_TICK_RATE */
 #define FINETUNE ((((((long)LATCH * HZ - CLOCK_TICK_RATE) << SHIFT_HZ) * \
 	(1000000/CLOCK_TICK_FACTOR) / (CLOCK_TICK_RATE/CLOCK_TICK_FACTOR)) \
----------8<----------8<----------8<----------8<----------8<----------

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

New version of AMD Elan patch

[Robert Schwebel]

Hi Marcelo and Alan,

Here's a new version of the AMD Elan patch, against 2.4.18-pre4. Please
apply.

Description:

The following patch for linux-2.4.18-pre3 fixes problems with the AMD Elan
CPUs which are popular x86 devices for embedded applications.

Content of the patch:
---------------------

	1. add a new processor type "Elan" in "Processor type
	   and features", with CONFIG_MELAN, is introduced

	2. fix the A20 code which was broken since the cleanup
	   in 2.4.15

	3. correct the ioport resource registration for Elans
	   (standard kernel reserves ports which are special
	   function registers on Elans)

	4. fix UART transmit bug

	5. fix timer 0 frequency to correct the clock

Details:
--------

1. As discussed on LKML the Elan processors have some
   "features" which need to be fixed but should not live
   in a standard kernel. Therefore, we propose a new
   configuration option CONFIG_MELAN. Ideas for better
   places for this option in the configuration tree are
   welcome.

2. In 2.4.15 H. Peter Anvin ported the A20 gate code from
   syslinux to the kernel, which is much more sophisticated
   than the code we had before. This leads to the Elan
   processors not booting any more (they did before without
   any problem, but that was more luck than intention). If
   you try to boot kernels newer than 2.4.14 the system
   reboots right in the middle of the initialisation
   sequence. As the Elans don't have a keyboard controller
   a special A20 gate sequence is added according to the
   config option introduced in 1.

3. Due to the fact that the ports of the PIC of the original
   PC are mirrored to several adresses Linux normally reserves
   the areas 0x20..0x3f and 0xa0..0xbf for pic1 and pic2,
   although the PICs use only the first two adresses of each
   block. This part of the patch uses only the "real" adresses,
   (0x20,0x21 / 0xa0,0xa1) as the Elan processors have special
   function registers in these blocks for the integrated
   peripherals.

4. The on-chip serial interface has a bug: the UART_LSR_THRE
   bit is delayed one bit clock after the interrupt line is
   asserted, i.e. if the serial port is running at 1200 bps, and
   the tranmitter becomes empty and causes an interupt, the
   interrupt is signalled about a millisecond (1/1200second)
   _before_ the THRE bit is set. This means that when the
   interrupt handler is entered after the interrupt, the THRE
   bit is still clear, the handler believes that there is
   nothing to be done and returns.

5. A normal PC has a basic frequency for the system timer 0
   of 1.19318 MHz, whereas the Elans have 1.1892 MHz due to the
   fact that all clocks are derived from a single oscillator.
   Without the patch the clock is wrong.

Credits:
--------

- Anders Larsen <anders@alarsen.net>
  First attempt of a patch for the Elan series
  http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0667.html

- Jason Sodergren <jason@mugwump.taiga.com>
  Clock patch

- Christer Weinigel <wingel@hog.ctrl-c.liu.se>
  Serial interface patch, A20 patch

- H. Peter Anvin <hpa@zytor.com>
  Discussions and ideas about the A20 stuff

- Juergen Beisert <jbeisert@eurodsn.de>
  Tests on SC520, suggestions for boot sequence changes, RS232

Patch:
------

The latest version of this patch can always be found on

  http://www.pengutronix.de/software/elan_en.html

The following code is version 2.4.18-pre4.1 of the patch. Suggestions for
further improvement are welcome.

----------8<----------8<----------8<----------8<----------8<----------
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre4/CREDITS linux-2.4.18-pre4-elan/CREDITS
--- linux-2.4.18-pre4/CREDITS	Sun Jan 20 20:39:06 2002
+++ linux-2.4.18-pre4-elan/CREDITS	Sun Jan 20 21:35:37 2002
@@ -2659,6 +2659,16 @@
 S: Oldenburg
 S: Germany

+N: Robert Schwebel
+E: robert@schwebel.de
+W: http://www.schwebel.de
+D: Embedded hacker and book author,
+D: AMD Elan support for Linux
+S: Pengutronix
+S: Braunschweiger Strasse 79
+S: 31134 Hildesheim
+S: Germany
+
 N: Darren Senn
 E: sinster@darkwater.com
 D: Whatever I notice needs doing (so far: itimers, /proc)
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre4/Documentation/Configure.help linux-2.4.18-pre4-elan/Documentation/Configure.help
--- linux-2.4.18-pre4/Documentation/Configure.help	Sun Jan 20 20:39:06 2002
+++ linux-2.4.18-pre4-elan/Documentation/Configure.help	Sun Jan 20 21:35:38 2002
@@ -3813,6 +3813,7 @@
    - "Pentium-4" for the Intel Pentium 4.
    - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
    - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
+   - "Elan" for the AMD Elan family (Elan SC400/SC410).
    - "Crusoe" for the Transmeta Crusoe series.
    - "Winchip-C6" for original IDT Winchip.
    - "Winchip-2" for IDT Winchip 2.
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre4/arch/i386/boot/setup.S linux-2.4.18-pre4-elan/arch/i386/boot/setup.S
--- linux-2.4.18-pre4/arch/i386/boot/setup.S	Sun Jan 20 20:39:07 2002
+++ linux-2.4.18-pre4-elan/arch/i386/boot/setup.S	Mon Jan 21 07:44:20 2002
@@ -42,6 +42,9 @@
  * if CX/DX have been changed in the e801 call and if so use AX/BX .
  * Michael Miller, April 2001 <michaelm@mjmm.org>
  *
+ * New A20 code ported from SYSLINUX by H. Peter Anvin. AMD Elan bugfixes
+ * by Robert Schwebel, December 2001 <robert@schwebel.de>
+ *
  */

 #include <linux/config.h>
@@ -651,7 +654,18 @@
 #
 # Enable A20.  This is at the very best an annoying procedure.
 # A20 code ported from SYSLINUX 1.52-1.63 by H. Peter Anvin.
+# AMD Elan bug fix by Robert Schwebel.
 #
+
+#if defined(CONFIG_MELAN)
+	movb $0x02, %al			# alternate A20 gate
+	outb %al, $0x92			# this works on SC410/SC520
+a20_elan_wait:
+        call a20_test
+        jz a20_elan_wait
+	jmp a20_done
+#endif
+

 A20_TEST_LOOPS		=  32		# Iterations per wait
 A20_ENABLE_LOOPS	= 255		# Total loops to try
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre4/arch/i386/config.in linux-2.4.18-pre4-elan/arch/i386/config.in
--- linux-2.4.18-pre4/arch/i386/config.in	Fri Dec 21 18:41:53 2001
+++ linux-2.4.18-pre4-elan/arch/i386/config.in	Sun Jan 20 21:35:38 2002
@@ -37,6 +37,7 @@
 	 Pentium-4				CONFIG_MPENTIUM4 \
 	 K6/K6-II/K6-III			CONFIG_MK6 \
 	 Athlon/Duron/K7			CONFIG_MK7 \
+	 Elan					CONFIG_MELAN \
 	 Crusoe					CONFIG_MCRUSOE \
 	 Winchip-C6				CONFIG_MWINCHIPC6 \
 	 Winchip-2				CONFIG_MWINCHIP2 \
@@ -125,6 +126,11 @@
    define_bool CONFIG_X86_USE_3DNOW y
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
+fi
+if [ "$CONFIG_MELAN" = "y" ]; then
+   define_int  CONFIG_X86_L1_CACHE_SHIFT 4
+   define_bool CONFIG_X86_USE_STRING_486 y
+   define_bool CONFIG_X86_ALIGNMENT_16 y
 fi
 if [ "$CONFIG_MCYRIXIII" = "y" ]; then
    define_int  CONFIG_X86_L1_CACHE_SHIFT 5
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre4/arch/i386/kernel/setup.c linux-2.4.18-pre4-elan/arch/i386/kernel/setup.c
--- linux-2.4.18-pre4/arch/i386/kernel/setup.c	Sun Jan 20 20:39:07 2002
+++ linux-2.4.18-pre4-elan/arch/i386/kernel/setup.c	Sun Jan 20 21:35:38 2002
@@ -329,6 +329,10 @@
 	{ "dma2", 0xc0, 0xdf, IORESOURCE_BUSY },
 	{ "fpu", 0xf0, 0xff, IORESOURCE_BUSY }
 };
+#ifdef CONFIG_ELAN
+standard_io_resources[1] = { "pic1", 0x20, 0x21, IORESOURCE_BUSY };
+standard_io_resources[5] = { "pic2", 0xa0, 0xa1, IORESOURCE_BUSY };
+#endif

 #define STANDARD_IO_RESOURCES (sizeof(standard_io_resources)/sizeof(struct resource))

diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre4/drivers/char/serial.c linux-2.4.18-pre4-elan/drivers/char/serial.c
--- linux-2.4.18-pre4/drivers/char/serial.c	Sun Jan 20 20:39:13 2002
+++ linux-2.4.18-pre4-elan/drivers/char/serial.c	Sun Jan 20 21:35:38 2002
@@ -57,6 +57,9 @@
  * 10/00: add in optional software flow control for serial console.
  *	  Kanoj Sarcar <kanoj@sgi.com>  (Modified by Theodore Ts'o)
  *
+ * 12/01: Fix for AMD Elan bug in transmit irq routine, by
+ *	  Christer Weinigel <wingel@hog.ctrl-c.liu.se>,
+ *	  Robert Schwebel <robert@schwebel.de>
  */

 static char *serial_version = "5.05c";
@@ -853,7 +856,7 @@
 		if (!info) {
 			info = IRQ_ports[irq];
 			if (pass_counter++ > RS_ISR_PASS_LIMIT) {
-#if 0
+#ifdef SERIAL_DEBUG_INTR
 				printk("rs loop break\n");
 #endif
 				break; 	/* Prevent infinite loops */
@@ -886,6 +889,9 @@
 	int first_multi = 0;
 	struct rs_multiport_struct *multi;
 #endif
+#ifdef CONFIG_MELAN
+	int iir;
+#endif

 #ifdef SERIAL_DEBUG_INTR
 	printk("rs_interrupt_single(%d)...", irq);
@@ -900,7 +906,9 @@
 	if (multi->port_monitor)
 		first_multi = inb(multi->port_monitor);
 #endif
-
+#ifdef CONFIG_MELAN
+	iir = serial_in(info, UART_IIR);
+#endif
 	do {
 		status = serial_inp(info, UART_LSR);
 #ifdef SERIAL_DEBUG_INTR
@@ -909,10 +917,24 @@
 		if (status & UART_LSR_DR)
 			receive_chars(info, &status, regs);
 		check_modem_status(info);
+
+#ifdef CONFIG_M_ELAN
+		/*
+		 * There is a bug in the UART on the AMD Elan SC4x0
+		 * embedded processor series; the THRE bit of the line
+		 * status register seems to be delayed one bit clock after
+		 * the interrupt is generated, so kludge this if the
+		 * IIR indicates a Transmit Holding Register Interrupt
+		 *
+		 */
+		if (status & UART_LSR_THRE || (iir & UART_IIR_ID) == UART_IIR_THRI)
+			transmit_chars(info, 0);
+#else
 		if (status & UART_LSR_THRE)
 			transmit_chars(info, 0);
+#endif
 		if (pass_counter++ > RS_ISR_PASS_LIMIT) {
-#if 0
+#ifdef SERIAL_DEBUG_INTR
 			printk("rs_single loop break.\n");
 #endif
 			break;
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre4/include/asm-i386/timex.h linux-2.4.18-pre4-elan/include/asm-i386/timex.h
--- linux-2.4.18-pre4/include/asm-i386/timex.h	Thu Nov 22 20:46:18 2001
+++ linux-2.4.18-pre4-elan/include/asm-i386/timex.h	Sun Jan 20 21:41:35 2002
@@ -9,7 +9,12 @@
 #include <linux/config.h>
 #include <asm/msr.h>

-#define CLOCK_TICK_RATE	1193180 /* Underlying HZ */
+#ifdef CONFIG_MELAN
+#  define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
+#else
+#  define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
+#endif
+
 #define CLOCK_TICK_FACTOR	20	/* Factor of both 1000000 and CLOCK_TICK_RATE */
 #define FINETUNE ((((((long)LATCH * HZ - CLOCK_TICK_RATE) << SHIFT_HZ) * \
 	(1000000/CLOCK_TICK_FACTOR) / (CLOCK_TICK_RATE/CLOCK_TICK_FACTOR)) \
----------8<----------8<----------8<----------8<----------8<----------

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: New version of AMD Elan patch

[Marcelo Tosatti]

Applied.

On Mon, 21 Jan 2002, Robert Schwebel wrote:

> Hi Marcelo and Alan,
> 
> Here's a new version of the AMD Elan patch, against 2.4.18-pre4. Please
> apply.

Re: [PATCH][RFC] AMD Elan patch

[Robert Schwebel]

Hi,

[please send answers also per mail]

I've uploaded a new version of the patch (2.4.18-pre4.2) which basically
includes a change to the serial port code by Juergen Beisert. This patch
should fix problems with systems that use interrupt sharing UARTs.

Latest stuff is as usual on

  http://www.pengutronix.de/software/elan_en.html

Please test this extensively and report about your success.

I have another patch from Sven Geggus in the pipeline which makes it
possible to change the CPU's clock frequency on the fly. I would like to
integrate it but do not have a more-than-33-MHz Elan system available for
testing. If someone has a contact to a hardware supplyer who wants to send
me a board please tell me - SSV seems not to be cooperative here.

Other stuff waiting for integration:

- watchdog driver
- support for systems with external timer 0 clock source
- CS8900 bug ("transmission underflow")

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH][RFC] AMD Elan patch

[Dave Jones]

On Tue, Jan 22, 2002 at 03:47:32PM +0100, Robert Schwebel wrote:
 > 
 > I have another patch from Sven Geggus in the pipeline which makes it
 > possible to change the CPU's clock frequency on the fly.

 It would probably be a good idea to make this fit the cpufreq
 API that Russell King, myself and a few others created.
 It's in the ARM Linux CVS with the modulename cpufreq.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

New version of AMD Elan patch available

[Robert Schwebel]

Hi,

[please send comments per mail]

today it's quick-release-time. There's another version of the AMD Elan
patch available which adds Sven Geggus' driver for changing the CPU
frequency. See the latest patch on

  http://www.pengutronix.de/software/elan_en.html

Please note that this is a very first and experimental version of this
driver. The API will most likely change to the cpufreq API from the ARM
architecture (Dave, I'll have a look at it tomorrow).

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

[PATCH] AMD Elan patch

[Robert Schwebel]

Hi Marcelo,

the changelog for -pre5 has my AMD Elan fixes included, but unfortunately
you seem to have forgotten to apply the patch...

Here is the most recent version, against 2.4.18-pre6. Please note that the
CPU frequency driver is not included in this patch (it will be ported to
the cpufreq interface first), so this is purely bug fixing stuff.

Changelog as always on

  http://www.pengutronix.de/software/elan_en.html

----------8<----------8<----------8<----------8<----------
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre6/CREDITS linux-2.4.18-pre6-elan/CREDITS
--- linux-2.4.18-pre6/CREDITS	Wed Jan 23 07:51:48 2002
+++ linux-2.4.18-pre6-elan/CREDITS	Wed Jan 23 09:58:10 2002
@@ -2653,6 +2653,16 @@
 S: Oldenburg
 S: Germany

+N: Robert Schwebel
+E: robert@schwebel.de
+W: http://www.schwebel.de
+D: Embedded hacker and book author,
+D: AMD Elan support for Linux
+S: Pengutronix
+S: Braunschweiger Strasse 79
+S: 31134 Hildesheim
+S: Germany
+
 N: Darren Senn
 E: sinster@darkwater.com
 D: Whatever I notice needs doing (so far: itimers, /proc)
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre6/Documentation/Configure.help linux-2.4.18-pre6-elan/Documentation/Configure.help
--- linux-2.4.18-pre6/Documentation/Configure.help	Wed Jan 23 07:51:48 2002
+++ linux-2.4.18-pre6-elan/Documentation/Configure.help	Wed Jan 23 10:02:51 2002
@@ -3813,6 +3829,7 @@
    - "Pentium-4" for the Intel Pentium 4.
    - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
    - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
+   - "Elan" for the AMD Elan family (Elan SC400/SC410).
    - "Crusoe" for the Transmeta Crusoe series.
    - "Winchip-C6" for original IDT Winchip.
    - "Winchip-2" for IDT Winchip 2.
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre6/arch/i386/boot/setup.S linux-2.4.18-pre6-elan/arch/i386/boot/setup.S
--- linux-2.4.18-pre6/arch/i386/boot/setup.S	Wed Jan 23 07:51:49 2002
+++ linux-2.4.18-pre6-elan/arch/i386/boot/setup.S	Wed Jan 23 10:02:51 2002
@@ -42,6 +42,9 @@
  * if CX/DX have been changed in the e801 call and if so use AX/BX .
  * Michael Miller, April 2001 <michaelm@mjmm.org>
  *
+ * New A20 code ported from SYSLINUX by H. Peter Anvin. AMD Elan bugfixes
+ * by Robert Schwebel, December 2001 <robert@schwebel.de>
+ *
  */

 #include <linux/config.h>
@@ -651,7 +654,18 @@
 #
 # Enable A20.  This is at the very best an annoying procedure.
 # A20 code ported from SYSLINUX 1.52-1.63 by H. Peter Anvin.
+# AMD Elan bug fix by Robert Schwebel.
 #
+
+#if defined(CONFIG_MELAN)
+	movb $0x02, %al			# alternate A20 gate
+	outb %al, $0x92			# this works on SC410/SC520
+a20_elan_wait:
+        call a20_test
+        jz a20_elan_wait
+	jmp a20_done
+#endif
+

 A20_TEST_LOOPS		=  32		# Iterations per wait
 A20_ENABLE_LOOPS	= 255		# Total loops to try
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre6/arch/i386/config.in linux-2.4.18-pre6-elan/arch/i386/config.in
--- linux-2.4.18-pre6/arch/i386/config.in	Fri Dec 21 18:41:53 2001
+++ linux-2.4.18-pre6-elan/arch/i386/config.in	Wed Jan 23 10:02:51 2002
@@ -37,6 +37,7 @@
 	 Pentium-4				CONFIG_MPENTIUM4 \
 	 K6/K6-II/K6-III			CONFIG_MK6 \
 	 Athlon/Duron/K7			CONFIG_MK7 \
+	 Elan					CONFIG_MELAN \
 	 Crusoe					CONFIG_MCRUSOE \
 	 Winchip-C6				CONFIG_MWINCHIPC6 \
 	 Winchip-2				CONFIG_MWINCHIP2 \
@@ -125,6 +126,11 @@
    define_bool CONFIG_X86_USE_3DNOW y
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
+fi
+if [ "$CONFIG_MELAN" = "y" ]; then
+   define_int  CONFIG_X86_L1_CACHE_SHIFT 4
+   define_bool CONFIG_X86_USE_STRING_486 y
+   define_bool CONFIG_X86_ALIGNMENT_16 y
 fi
 if [ "$CONFIG_MCYRIXIII" = "y" ]; then
    define_int  CONFIG_X86_L1_CACHE_SHIFT 5
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre6/arch/i386/kernel/setup.c linux-2.4.18-pre6-elan/arch/i386/kernel/setup.c
--- linux-2.4.18-pre6/arch/i386/kernel/setup.c	Wed Jan 23 07:51:50 2002
+++ linux-2.4.18-pre6-elan/arch/i386/kernel/setup.c	Wed Jan 23 10:02:51 2002
@@ -329,6 +329,10 @@
 	{ "dma2", 0xc0, 0xdf, IORESOURCE_BUSY },
 	{ "fpu", 0xf0, 0xff, IORESOURCE_BUSY }
 };
+#ifdef CONFIG_ELAN
+standard_io_resources[1] = { "pic1", 0x20, 0x21, IORESOURCE_BUSY };
+standard_io_resources[5] = { "pic2", 0xa0, 0xa1, IORESOURCE_BUSY };
+#endif

 #define STANDARD_IO_RESOURCES (sizeof(standard_io_resources)/sizeof(struct resource))

diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre6/drivers/char/serial.c linux-2.4.18-pre6-elan/drivers/char/serial.c
--- linux-2.4.18-pre6/drivers/char/serial.c	Wed Jan 23 07:52:03 2002
+++ linux-2.4.18-pre6-elan/drivers/char/serial.c	Wed Jan 23 10:02:51 2002
@@ -57,6 +57,10 @@
  * 10/00: add in optional software flow control for serial console.
  *	  Kanoj Sarcar <kanoj@sgi.com>  (Modified by Theodore Ts'o)
  *
+ * 12/01: Fix for AMD Elan bug in transmit irq routine, by
+ *	  Christer Weinigel <wingel@hog.ctrl-c.liu.se>,
+ *	  Robert Schwebel <robert@schwebel.de>
+ *	  Juergen Beisert <jbeisert@eurodsn.de>
  */

 static char *serial_version = "5.05c";
@@ -802,6 +806,7 @@
 static void rs_interrupt(int irq, void *dev_id, struct pt_regs * regs)
 {
 	int status;
+	int iir;
 	struct async_struct * info;
 	int pass_counter = 0;
 	struct async_struct *end_mark = 0;
@@ -825,12 +830,24 @@
 #endif

 	do {
-		if (!info->tty ||
-		    (serial_in(info, UART_IIR) & UART_IIR_NO_INT)) {
-			if (!end_mark)
-				end_mark = info;
+
+		/*
+		 * It seems to be important in a SC520 systems to read
+		 * the UART_IIR register only once per loop. But I think
+		 * this small correction does not disturb the normal
+		 * implementation.
+		 */
+
+		/* Something to test? */
+		/* Or is this UART the source of the interrupt? */
+
+		if (!info->tty ||
+		    ((iir=serial_inp(info, UART_IIR)) & 0x01)) {
+			if (!end_mark)			/* last reached?     */
+				end_mark = info;	/* ..yes, leave loop */
 			goto next;
-		}
+                }
+
 #ifdef SERIAL_DEBUG_INTR
 		printk("IIR = %x...", serial_in(info, UART_IIR));
 #endif
@@ -839,6 +856,24 @@
 		info->last_active = jiffies;

 		status = serial_inp(info, UART_LSR);
+
+#ifdef CONFIG_MELAN
+
+		/*
+		 * There is a bug (misfeature?) in the UART on the AMD Elan
+		 * SC4x0 and SC520 embedded processor series; the THRE bit of
+		 * the line status register seems to be delayed one bit
+		 * clock after the interrupt is generated, so kludge this
+		 * if the IIR indicates a Transmit Holding Register Interrupt
+		 */
+		if ((iir & UART_IIR_ID) == UART_IIR_THRI) {
+			status |= UART_LSR_THRE;
+#ifdef SERIAL_DEBUG_INTR
+			printk("|%x", status);
+#endif
+		}
+#endif /* CONFIG_MELAN */
+
 #ifdef SERIAL_DEBUG_INTR
 		printk("status = %x...", status);
 #endif
@@ -853,7 +888,7 @@
 		if (!info) {
 			info = IRQ_ports[irq];
 			if (pass_counter++ > RS_ISR_PASS_LIMIT) {
-#if 0
+#ifdef SERIAL_DEBUG_INTR
 				printk("rs loop break\n");
 #endif
 				break; 	/* Prevent infinite loops */
@@ -886,6 +921,9 @@
 	int first_multi = 0;
 	struct rs_multiport_struct *multi;
 #endif
+#ifdef CONFIG_MELAN
+	int iir;
+#endif

 #ifdef SERIAL_DEBUG_INTR
 	printk("rs_interrupt_single(%d)...", irq);
@@ -900,7 +938,9 @@
 	if (multi->port_monitor)
 		first_multi = inb(multi->port_monitor);
 #endif
-
+#ifdef CONFIG_MELAN
+	iir = serial_in(info, UART_IIR);
+#endif
 	do {
 		status = serial_inp(info, UART_LSR);
 #ifdef SERIAL_DEBUG_INTR
@@ -909,10 +949,25 @@
 		if (status & UART_LSR_DR)
 			receive_chars(info, &status, regs);
 		check_modem_status(info);
+
+#ifdef CONFIG_MELAN
+
+		/*
+		 * There is a bug (misfeature?) in the UART on the AMD Elan
+		 * SC4x0 and SC520 embedded processor series; the THRE bit of
+		 * the line status register seems to be delayed one bit
+		 * clock after the interrupt is generated, so kludge this
+		 * if the IIR indicates a Transmit Holding Register Interrupt
+		 */
+
+		if ((iir & UART_IIR_ID) == UART_IIR_THRI)
+			status |= UART_LSR_THRE;
+#endif
 		if (status & UART_LSR_THRE)
 			transmit_chars(info, 0);
+
 		if (pass_counter++ > RS_ISR_PASS_LIMIT) {
-#if 0
+#ifdef SERIAL_DEBUG_INTR
 			printk("rs_single loop break.\n");
 #endif
 			break;
@@ -920,7 +975,7 @@
 #ifdef SERIAL_DEBUG_INTR
 		printk("IIR = %x...", serial_in(info, UART_IIR));
 #endif
-	} while (!(serial_in(info, UART_IIR) & UART_IIR_NO_INT));
+	} while (!((iir = serial_in(info, UART_IIR)) & UART_IIR_NO_INT));
 	info->last_active = jiffies;
 #ifdef CONFIG_SERIAL_MULTIPORT
 	if (multi->port_monitor)
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre6/include/asm-i386/timex.h linux-2.4.18-pre6-elan/include/asm-i386/timex.h
--- linux-2.4.18-pre6/include/asm-i386/timex.h	Thu Nov 22 20:46:18 2001
+++ linux-2.4.18-pre6-elan/include/asm-i386/timex.h	Wed Jan 23 10:02:51 2002
@@ -9,7 +9,12 @@
 #include <linux/config.h>
 #include <asm/msr.h>

-#define CLOCK_TICK_RATE	1193180 /* Underlying HZ */
+#ifdef CONFIG_MELAN
+#  define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
+#else
+#  define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
+#endif
+
 #define CLOCK_TICK_FACTOR	20	/* Factor of both 1000000 and CLOCK_TICK_RATE */
 #define FINETUNE ((((((long)LATCH * HZ - CLOCK_TICK_RATE) << SHIFT_HZ) * \
 	(1000000/CLOCK_TICK_FACTOR) / (CLOCK_TICK_RATE/CLOCK_TICK_FACTOR)) \
----------8<----------8<----------8<----------8<----------

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: [PATCH] AMD Elan patch

[Marcelo Tosatti]

On Wed, 23 Jan 2002, Robert Schwebel wrote:

> Hi Marcelo,
> 
> the changelog for -pre5 has my AMD Elan fixes included, but unfortunately
> you seem to have forgotten to apply the patch...

I have not applied the serial.c hunk since it breaks compilation without CONFIG_MELAN.

Please fix that and resend me a patch to serial.c only.

Thanks

Re: New version of AMD Elan patch

[Robert Schwebel]

Hi Marcelo,

thanks for applying the Elan patch. Unfortunately, I've discovered a typo,
patch below.

For the list: the remaining stuff against -pre7 is as usual on

  http://www.pengutronix.de/software/elan_en.wml

Changelog:

01/24/2002      Robert Schwebel <robert@schwebel.de>

                - Revision 2.4.18-pre7.1 released.
                - Marcelo has integrated everything but the serial
                  driver stuff into the latest pre-patch. I'll have
                  to send the rest to tytso...
                - striped out the applied stuff
                - typo in arch/i386/kernel/setup.c

Robert

----------8<----------
diff -urN -X kernel-patches/dontdiff linux-2.4.18-pre7/arch/i386/kernel/setup.c linux-2.4.18-pre7-elan/arch/i386/kernel/setup.c
--- linux-2.4.18-pre7/arch/i386/kernel/setup.c	Thu Jan 24 07:36:14 2002
+++ linux-2.4.18-pre7-elan/arch/i386/kernel/setup.c	Thu Jan 24 08:51:01 2002
@@ -329,7 +329,7 @@
 	{ "dma2", 0xc0, 0xdf, IORESOURCE_BUSY },
 	{ "fpu", 0xf0, 0xff, IORESOURCE_BUSY }
 };
-#ifdef CONFIG_ELAN
+#ifdef CONFIG_MELAN
 standard_io_resources[1] = { "pic1", 0x20, 0x21, IORESOURCE_BUSY };
 standard_io_resources[5] = { "pic2", 0xa0, 0xa1, IORESOURCE_BUSY };
 #endif
----------8<----------
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

Re: New version of AMD Elan patch

[Robert Schwebel]

On Thu, 24 Jan 2002, Robert Schwebel wrote:
> For the list: the remaining stuff against -pre7 is as usual on
>
>   http://www.pengutronix.de/software/elan_en.wml

Oops, should be

  http://www.pengutronix.de/software/elan_en.html

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+

New version of AMD Elan patch available

[Robert Schwebel]

Here is another bugfix release of the AMD Elan patch. Changelog included,
the patch is as usual on

  http://www.pengutronix.de/software/elan_en.html


----------8<----------8<----------8<----------8<----------
02/01/2002	Robert Schwebel <robert@schwebel.de>

		- Revision 2.4.18-pre7.2 released.
		- Bugfix in serial.c; the problem occured if
		  CONFIG_ELAN was not activated.
		  Thanks to Arnd Bergmann <abe@ist1.de>
----------8<----------8<----------8<----------8<----------

Robert
--
 +--------------------------------------------------------+
 | Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
 | Pengutronix - Linux Solutions for Science and Industry |
 |   Braunschweiger Str. 79,  31134 Hildesheim, Germany   |
 |    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4    |
 +--------------------------------------------------------+