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 |
+--------------------------------------------------------+
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
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 |
+--------------------------------------------------------+
Followup to: <[email protected]>
By author: Robert Schwebel <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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 |
+--------------------------------------------------------+
Followup to: <[email protected]>
By author: Robert Schwebel <[email protected]>
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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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?"
Followup to: <[email protected]>
By author: [email protected] (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
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
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 |
+--------------------------------------------------------+
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
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 <[email protected]>
First attempt of a patch for the Elan series
http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0667.html
- Jason Sodergren <[email protected]>
Clock patch
- Christer Weinigel <[email protected]>
Serial interface patch, A20 patch
- H. Peter Anvin <[email protected]>
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 <[email protected]>
*
+ * New A20 code ported from SYSLINUX by H. Peter Anvin. AMD Elan bugfixes
+ * by Robert Schwebel, December 2001 <[email protected]>
+ *
*/
#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 <[email protected]> (Modified by Theodore Ts'o)
*
+ * 12/01: Fix for AMD Elan bug in transmit irq routine, by
+ * Christer Weinigel <[email protected]>,
+ * Robert Schwebel <[email protected]>
*/
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 |
+--------------------------------------------------------+
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 <[email protected]>
> *
> + * New A20 code ported from SYSLINUX by H. Peter Anvin. AMD Elan bugfixes
> + * by Robert Schwebel, December 2001 <[email protected]>
> + *
> */
>
> #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
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 |
+--------------------------------------------------------+
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
> 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?"
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
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
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
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?"
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?"
> 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)
> 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
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?"
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 |
+--------------------------------------------------------+
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 |
+--------------------------------------------------------+
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 |
+--------------------------------------------------------+
> > 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
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 <[email protected]>
- Revision 2.4.17.3 released.
- Loop inserted to check if A20 gate was
_really_ activated.
H. Peter Anvin <[email protected]>
- 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 |
+--------------------------------------------------------+
> 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
> 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
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 |
+--------------------------------------------------------+
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 |
+--------------------------------------------------------+
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?"
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
> 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
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.
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
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
> 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
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: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
> > 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.
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 |
+--------------------------------------------------------+
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 |
+--------------------------------------------------------+
Alan Cox <[email protected]> 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
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 <[email protected]>
First attempt of a patch for the Elan series
http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0667.html
- Jason Sodergren <[email protected]>
Clock patch
- Christer Weinigel <[email protected]>
Serial interface patch, A20 patch
- H. Peter Anvin <[email protected]>
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: [email protected]
+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: [email protected]
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 <[email protected]>
*
+ * New A20 code ported from SYSLINUX by H. Peter Anvin. AMD Elan bugfixes
+ * by Robert Schwebel, December 2001 <[email protected]>
+ *
*/
#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 <[email protected]> (Modified by Theodore Ts'o)
*
+ * 12/01: Fix for AMD Elan bug in transmit irq routine, by
+ * Christer Weinigel <[email protected]>,
+ * Robert Schwebel <[email protected]>
*/
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 |
+--------------------------------------------------------+
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 <[email protected]>
First attempt of a patch for the Elan series
http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0667.html
- Jason Sodergren <[email protected]>
Clock patch
- Christer Weinigel <[email protected]>
Serial interface patch, A20 patch
- H. Peter Anvin <[email protected]>
Discussions and ideas about the A20 stuff
- Juergen Beisert <[email protected]>
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: [email protected]
+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: [email protected]
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 <[email protected]>
*
+ * New A20 code ported from SYSLINUX by H. Peter Anvin. AMD Elan bugfixes
+ * by Robert Schwebel, December 2001 <[email protected]>
+ *
*/
#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 <[email protected]> (Modified by Theodore Ts'o)
*
+ * 12/01: Fix for AMD Elan bug in transmit irq routine, by
+ * Christer Weinigel <[email protected]>,
+ * Robert Schwebel <[email protected]>
*/
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 |
+--------------------------------------------------------+
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.
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 |
+--------------------------------------------------------+
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
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 |
+--------------------------------------------------------+
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: [email protected]
+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: [email protected]
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 <[email protected]>
*
+ * New A20 code ported from SYSLINUX by H. Peter Anvin. AMD Elan bugfixes
+ * by Robert Schwebel, December 2001 <[email protected]>
+ *
*/
#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 <[email protected]> (Modified by Theodore Ts'o)
*
+ * 12/01: Fix for AMD Elan bug in transmit irq routine, by
+ * Christer Weinigel <[email protected]>,
+ * Robert Schwebel <[email protected]>
+ * Juergen Beisert <[email protected]>
*/
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 |
+--------------------------------------------------------+
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
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 <[email protected]>
- 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 |
+--------------------------------------------------------+
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 |
+--------------------------------------------------------+
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 <[email protected]>
- Revision 2.4.18-pre7.2 released.
- Bugfix in serial.c; the problem occured if
CONFIG_ELAN was not activated.
Thanks to Arnd Bergmann <[email protected]>
----------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 |
+--------------------------------------------------------+