* Re: atkbd_init lockup with 2.6.11-rc1
From: Dmitry Torokhov @ 2005-01-28 15:22 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <20050128145511.GA29340@suse.de>
On Fri, 28 Jan 2005 15:55:11 +0100, Olaf Hering <olh@suse.de> wrote:
> On Fri, Jan 28, Dmitry Torokhov wrote:
>
> > On Fri, 28 Jan 2005 14:58:27 +0100, Olaf Hering <olh@suse.de> wrote:
> > > On Fri, Jan 28, Olaf Hering wrote:
> > >
> > > >
> > > > My IBM RS/6000 B50 locks up with 2.6.11rc1, it dies in atkbd_init():
> > >
> > > It fails also on PReP, not only on CHRP. 2.6.10 looks like this:
> > >
> > > Calling initcall 0xc03bc430: atkbd_init+0x0/0x2c()
> > > atkbd.c: keyboard reset failed on isa0060/serio1
> > > atkbd.c: keyboard reset failed on isa0060/serio0
> > >
> >
> > So it could not reset it even before, but it was not getting stuch
> > tough... What about passing atkbd.reset=0?
>
> I will try that.
> Adding a printk after the outb() fixes it as well.
Fixes as in "it reports that reset fails" again or it resets the
keyboard cleanly and works fine?
> Do you have a version of that i8042 delay patch for 2.6.11-rc2-bk6?
> Maybe it will help.
>
No I don't, and I don't think you need all of it. What happens if you
edit drivers/input/serio/i8042.c manually and stick udelay(7); in
front of calls to i8042_write_data() in i8042_kbd_write() and
i8042_aux_write()?
--
Dmitry
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Olaf Hering @ 2005-01-28 14:55 UTC (permalink / raw)
To: dtor_core; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <d120d50005012806435a17fe98@mail.gmail.com>
On Fri, Jan 28, Dmitry Torokhov wrote:
> On Fri, 28 Jan 2005 14:58:27 +0100, Olaf Hering <olh@suse.de> wrote:
> > On Fri, Jan 28, Olaf Hering wrote:
> >
> > >
> > > My IBM RS/6000 B50 locks up with 2.6.11rc1, it dies in atkbd_init():
> >
> > It fails also on PReP, not only on CHRP. 2.6.10 looks like this:
> >
> > Calling initcall 0xc03bc430: atkbd_init+0x0/0x2c()
> > atkbd.c: keyboard reset failed on isa0060/serio1
> > atkbd.c: keyboard reset failed on isa0060/serio0
> >
>
> So it could not reset it even before, but it was not getting stuch
> tough... What about passing atkbd.reset=0?
I will try that.
Adding a printk after the outb() fixes it as well.
Do you have a version of that i8042 delay patch for 2.6.11-rc2-bk6?
Maybe it will help.
^ permalink raw reply
* networking-related oopses on 2.6.9
From: Marco d'Itri @ 2005-01-28 14:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev
[Please Cc me, I'm not subscribed to either list.]
In the last few days, after about two months it was running, one of my
servers (an IBM B50) running 2.6.9 vanilla started oopsing.
A twin server running the same kernel had no problems, but it's less
loaded.
Now I switched it back to 2.6.6, which never showed problems (but I need
something newer, because SSM multicast is broken in this release).
I have been able to capture the latest two oopses from the serial
console, is this a known problem?
KERNEL: assertion (!skb_queue_empty(&sk->sk_write_queue)) failed at net/ipv4/tc
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C01B3BBC LR: C01B3B8C SP: D01D7DF0 REGS: d01d7d40 TRAP: 0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000048, DSISR: 40000000
TASK = cf5439d0[9999] 'bryar.cgi' THREAD: d01d6000Last syscall: 6
GPR00: 00000000 D01D7DF0 CF5439D0 000004B8 00000500 00000308 00000000 C034A250
GPR08: 000004B8 FFFFFFF5 00000000 00000000 34D0744B 1001B8D4 00000000 00000000
GPR16: 00000000 00000080 102E1FE8 00000000 102E1FDC 102E1FF0 00000000 10003078
GPR24: C0360000 C0340000 C0360000 000004B8 C0310000 CC4371E0 CC4373B4 00000000
NIP [c01b3bbc] tcp_retransmit_skb+0x54/0x39c
LR [c01b3b8c] tcp_retransmit_skb+0x24/0x39c
Call trace:
[c01b61f0] tcp_retransmit_timer+0x134/0x47c
[c01b65fc] tcp_write_timer+0xc4/0xec
[c002396c] run_timer_softirq+0xf8/0x1ac
[c001f004] __do_softirq+0xdc/0xec
[c001f06c] do_softirq+0x58/0x5c
[c00083bc] timer_interrupt+0x1fc/0x22c
[c0006660] ret_from_except+0x0/0x14
Kernel panic - not syncing: Aiee, killing interrupt handler!
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C01AB880 LR: C01AC6D0 SP: C030FBE0 REGS: c030fb30 TRAP: 0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000050, DSISR: 40000000
TASK = c02973e0[0] 'swapper' THREAD: c030e000Last syscall: 120
GPR00: 00000000 C030FBE0 C02973E0 00000001 D21EEB34 00000003 00000001 0000021D
GPR08: 00000000 00000000 001AA19A 00000000 2401C088 00000000 00000000 00000000
GPR16: 00000000 00000000 00000000 00000000 C0340000 00000004 DFD37648 00000006
GPR24: C0310000 00000003 00000000 00000000 7ABF8951 D21EE960 D21EE960 D21EEB34
NIP [c01ab880] tcp_time_to_recover+0x84/0x1f4
LR [c01ac6d0] tcp_fastretrans_alert+0x1a4/0x7ac
Call trace:
[c01ac6d0] tcp_fastretrans_alert+0x1a4/0x7ac
[c01adc90] tcp_ack+0x178/0x560
[c01b0a34] tcp_rcv_established+0x410/0x824
[c020cf18] tcp_v6_do_rcv+0x2a0/0x320
[c020d5d0] tcp_v6_rcv+0x638/0x854
[c01ec188] ip6_input+0x1dc/0x384
[c01ebe98] ipv6_rcv+0x1a8/0x2bc
[c01882cc] netif_receive_skb+0x178/0x250
[c018844c] process_backlog+0xa8/0x188
[c01885c4] net_rx_action+0x98/0x178
[c001f004] __do_softirq+0xdc/0xec
[c001f06c] do_softirq+0x58/0x5c
[c0007e70] do_IRQ+0xc8/0xcc
[c0006660] ret_from_except+0x0/0x14
[c0008140] default_idle+0x14/0x5c
Kernel panic - not syncing: Aiee, killing interrupt handler!
--
ciao,
Marco
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Dmitry Torokhov @ 2005-01-28 14:43 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <20050128135827.GA28784@suse.de>
On Fri, 28 Jan 2005 14:58:27 +0100, Olaf Hering <olh@suse.de> wrote:
> On Fri, Jan 28, Olaf Hering wrote:
>
> >
> > My IBM RS/6000 B50 locks up with 2.6.11rc1, it dies in atkbd_init():
>
> It fails also on PReP, not only on CHRP. 2.6.10 looks like this:
>
> Calling initcall 0xc03bc430: atkbd_init+0x0/0x2c()
> atkbd.c: keyboard reset failed on isa0060/serio1
> atkbd.c: keyboard reset failed on isa0060/serio0
>
So it could not reset it even before, but it was not getting stuch
tough... What about passing atkbd.reset=0?
--
Dmitry
^ permalink raw reply
* 8021q and change_mtu problem
From: Laurent Lagrange @ 2005-01-28 14:29 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have tried to use the "change_mtu" function with a 8021q network device.
I have compare this function with an other one define for ethernet devices
in /drivers/net/net_init.c.
These functions always return -EINVAL when the new mtu value is invalid.
But for a valid mtu value the first one returns the new value and the second
one returns 0.
I use a linux 2.6.9 kernel from kernel.org.
I have tried this very simple patch and the function works fine.
--- net/8021q/vlan_dev.c Fri Jan 28 15:07:58 2005
+++ net/8021q/vlan_dev.c Fri Jan 28 15:12:12 2005
@@ -527,7 +527,7 @@
dev->mtu = new_mtu;
- return new_mtu;
+ return 0;
Laurent
^ permalink raw reply
* Re: problem executing simple app on ppc target running linux
From: Jerry Van Baren @ 2005-01-28 14:16 UTC (permalink / raw)
To: LinuxPPC Support
In-Reply-To: <BAY1-DAV565FDDF51898BE3F6E73D8B790@phx.gbl>
Vijay Padiyar wrote:
> Hi
>
> I have a doubt regarding execution of applications on Linux.
>
> I am developing applications to execute on an MPC8260 (PowerPC) target. I
> started off by building a toolchain for the target (using Kegel's
> crosstool).
>
> The compiler created for my target bears the name
> 'powerpc-603e-linux-gnu-gcc.'
>
> Then I built the Linux 2.6.10 kernel with this cross-compiler and got the
> executable image. I downloaded this image on the target and executed it
> successfully. I have now obtained the Linux command prompt.
>
> I am using U-Boot 1.1.1 as the bootloader and am loading the JFFS2 partition
> on my Flash directly as the root drive, using the boot argument
> 'root=/dev/mtdblock3.'
>
> The directory structure on my JFFS2 partition is as follows:
>
> /bin (with Busybox)
> /dev
> /etc
> /home (for my programs)
> /lib (currently empty)
> /proc (empty)
> /sbin
> /tmp
> /usr - bin, sbin
> /var
>
> Now, I built a simple "Hello, World!" application with my cross-compiler
> with the following command:
>
> $ powerpc-603e-linux-gnu-gcc -o hello hello.c
>
> When I try to execute the resulting file on my target from the Linux kernel
> prompt, I get a message saying:
>
> /home # ./hello
> /bin/sh: hello: No such file or directory
It didn't find your hello program. You didn't copy it over, it isn't
executable, it is in the wrong directory, _______ (fill in the blank).
> When I compile the above file with my native gcc and execute on the target,
> I get a message saying:
>
> /home # ./hello
> /bin/sh: hello: Line 1: Unexpected '(' in file (or something to that effect)
Running silly things give silly results.
> I know I can't execute apps built with gcc on the target. But why does it
> not work even when built with the cross-compiler?
>
> Another thing is, how do I compile applications with shared libraries? And
> how do I know which specific shared library files I need to put in the /lib
> and /usr/lib folders on my target JFFS2 partition for the program to execute
> successfully?
>
> Please give me some guidance. I'm a bit new to Linux.
>
> Regards
>
> Vijay Padiyar
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Wolfgang Denk <http://denx.de> has an Embedded Linux Development Toolkit
(ELDK) that is a pre-packaged solution for cross compiling, target
system ramdisks, etc. for 82xx (and 8xx and lots of others) targets. He
also has a " The DENX U-Boot and Linux Guide (DULG)" manual that tells
you lots (perhaps even all :-) of what you need to know.
I have found ELDK and DULG are necessary and sufficient :-). If you
understand ELDK and DULG, you will probably be able to answer your own
questions.
References:
<http://denx.de/e/index1.php?head=docs-head&main=docs&subnav=docs-subnav&logo=logo-se&mainnav=docsnav&bottom=bottom-se>
<http://www.denx.de/twiki/bin/view/DULG/Manual>
gvb
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Dmitry Torokhov @ 2005-01-28 13:58 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <20050128132202.GA27323@suse.de>
On Fri, 28 Jan 2005 14:22:02 +0100, Olaf Hering <olh@suse.de> wrote:
>
> My IBM RS/6000 B50 locks up with 2.6.11rc1, it dies in atkbd_init():
>
> Calling initcall 0xc03c272c: atkbd_init+0x0/0x38()
> ps2_init(224) swapper(1):c0,j4294680939 enter
> atkbd_connect(793) swapper(1):c0,j4294680993 type 1000000
> serio_open(606) swapper(1):c0,j4294681061 enter
> serio_set_drv(594) swapper(1):c0,j4294681117 enter
> serio_set_drv(600) swapper(1):c0,j4294681176 leave
> i8042_write_command(69) swapper(1):c0,j4294681236 enter
> i8042_write_data(62) swapper(1):c0,j4294681236 enter
> serio_open(614) swapper(1):c0,j4294681363 leave0
> atkbd_probe(497) swapper(1):c0,j4294681421 enter
> ps2_command(91) swapper(1):c0,j4294681478 enter
> ps2_sendbyte(57) swapper(1):c0,j4294681534 enter
> serio_write(95) swapper(1):c0,j4294681591 write c01b65ac
> i8042_aux_write(253) swapper(1):c0,j4294681658 enter
> i8042_write_command(69) swapper(1):c0,j4294681720 enter
> i8042_write_data(62) swapper(1):c0,j4294681720 enter
>
> Any idea how to fix it? There is no keyboard or mouse detected. I think
> it works ok on ppc64, Anton did not complain yet.
>
Hi,
It looks like it is hanging in checking AUX, while writing data into
controller. It is simple outb but it is stuck... Could you please
reboot with i8042.debug boot option and resend the log. Also, you may
try booting with i8042.noaux to check if keyboard alone works.
--
Dmitry
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Olaf Hering @ 2005-01-28 14:02 UTC (permalink / raw)
To: dtor_core; +Cc: linuxppc-dev, Vojtech Pavlik, linux-kernel
In-Reply-To: <d120d500050128055837df3a93@mail.gmail.com>
On Fri, Jan 28, Dmitry Torokhov wrote:
> It looks like it is hanging in checking AUX, while writing data into
> controller. It is simple outb but it is stuck... Could you please
> reboot with i8042.debug boot option and resend the log. Also, you may
> try booting with i8042.noaux to check if keyboard alone works.
It looks like this:
Kernel command line: root=/dev/sda3 selinux=0 elevator=cfq debug initcall_debug panic=1 i8042.nomux=1 console=ttyS0 i8042.debug i8042.noaux
...
Calling initcall 0xc03a3a14: atkbd_init+0x0/0x38()
ps2_init(224) swapper(1):c0,j4294681251 enter
atkbd_connect(793) swapper(1):c0,j4294681305 type 6000000
serio_open(606) swapper(1):c0,j4294681372 enter
serio_set_drv(594) swapper(1):c0,j4294681428 enter
serio_set_drv(600) swapper(1):c0,j4294681488 leave
/home/olaf/kernel/b50/linux-2.6.11-rc2-olh/drivers/input/serio/i8042.c: 60 -> i8042 (command) [3767]
i8042_write_command(69) swapper(1):c0,j4294681548 enter
/home/olaf/kernel/b50/linux-2.6.11-rc2-olh/drivers/input/serio/i8042.c: 61 -> i8042 (parameter) [3767]
i8042_write_data(62) swapper(1):c0,j4294681548 enter
serio_open(614) swapper(1):c0,j4294681911 leave0
atkbd_probe(497) swapper(1):c0,j4294681968 enter
ps2_command(91) swapper(1):c0,j4294682026 enter
ps2_sendbyte(57) swapper(1):c0,j4294682082 enter
serio_write(95) swapper(1):c0,j4294682139 write c01b9d48
/home/olaf/kernel/b50/linux-2.6.11-rc2-olh/drivers/input/serio/i8042.c: ff -> i8042 (kbd-data) [4424]
i8042_write_data(62) swapper(1):c0,j4294682205 enter
^ permalink raw reply
* Re: atkbd_init lockup with 2.6.11-rc1
From: Olaf Hering @ 2005-01-28 13:58 UTC (permalink / raw)
To: Vojtech Pavlik, Dmitry Torokhov; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20050128132202.GA27323@suse.de>
On Fri, Jan 28, Olaf Hering wrote:
>
> My IBM RS/6000 B50 locks up with 2.6.11rc1, it dies in atkbd_init():
It fails also on PReP, not only on CHRP. 2.6.10 looks like this:
Calling initcall 0xc03bc430: atkbd_init+0x0/0x2c()
atkbd.c: keyboard reset failed on isa0060/serio1
atkbd.c: keyboard reset failed on isa0060/serio0
I'm able to break into xmon, cpu is in cpu_idle, maybe its spinning
somewhere.
^ permalink raw reply
* problem executing simple app on ppc target running linux
From: Vijay Padiyar @ 2005-01-28 13:58 UTC (permalink / raw)
To: LinuxPPC Support
Hi
I have a doubt regarding execution of applications on Linux.
I am developing applications to execute on an MPC8260 (PowerPC) target. I
started off by building a toolchain for the target (using Kegel's
crosstool).
The compiler created for my target bears the name
'powerpc-603e-linux-gnu-gcc.'
Then I built the Linux 2.6.10 kernel with this cross-compiler and got the
executable image. I downloaded this image on the target and executed it
successfully. I have now obtained the Linux command prompt.
I am using U-Boot 1.1.1 as the bootloader and am loading the JFFS2 partition
on my Flash directly as the root drive, using the boot argument
'root=/dev/mtdblock3.'
The directory structure on my JFFS2 partition is as follows:
/bin (with Busybox)
/dev
/etc
/home (for my programs)
/lib (currently empty)
/proc (empty)
/sbin
/tmp
/usr - bin, sbin
/var
Now, I built a simple "Hello, World!" application with my cross-compiler
with the following command:
$ powerpc-603e-linux-gnu-gcc -o hello hello.c
When I try to execute the resulting file on my target from the Linux kernel
prompt, I get a message saying:
/home # ./hello
/bin/sh: hello: No such file or directory
When I compile the above file with my native gcc and execute on the target,
I get a message saying:
/home # ./hello
/bin/sh: hello: Line 1: Unexpected '(' in file (or something to that effect)
I know I can't execute apps built with gcc on the target. But why does it
not work even when built with the cross-compiler?
Another thing is, how do I compile applications with shared libraries? And
how do I know which specific shared library files I need to put in the /lib
and /usr/lib folders on my target JFFS2 partition for the program to execute
successfully?
Please give me some guidance. I'm a bit new to Linux.
Regards
Vijay Padiyar
^ permalink raw reply
* atkbd_init lockup with 2.6.11-rc1
From: Olaf Hering @ 2005-01-28 13:22 UTC (permalink / raw)
To: Vojtech Pavlik, Dmitry Torokhov; +Cc: linuxppc-dev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]
My IBM RS/6000 B50 locks up with 2.6.11rc1, it dies in atkbd_init():
Calling initcall 0xc03c272c: atkbd_init+0x0/0x38()
ps2_init(224) swapper(1):c0,j4294680939 enter
atkbd_connect(793) swapper(1):c0,j4294680993 type 1000000
serio_open(606) swapper(1):c0,j4294681061 enter
serio_set_drv(594) swapper(1):c0,j4294681117 enter
serio_set_drv(600) swapper(1):c0,j4294681176 leave
i8042_write_command(69) swapper(1):c0,j4294681236 enter
i8042_write_data(62) swapper(1):c0,j4294681236 enter
serio_open(614) swapper(1):c0,j4294681363 leave0
atkbd_probe(497) swapper(1):c0,j4294681421 enter
ps2_command(91) swapper(1):c0,j4294681478 enter
ps2_sendbyte(57) swapper(1):c0,j4294681534 enter
serio_write(95) swapper(1):c0,j4294681591 write c01b65ac
i8042_aux_write(253) swapper(1):c0,j4294681658 enter
i8042_write_command(69) swapper(1):c0,j4294681720 enter
i8042_write_data(62) swapper(1):c0,j4294681720 enter
Any idea how to fix it? There is no keyboard or mouse detected. I think
it works ok on ppc64, Anton did not complain yet.
[-- Attachment #2: 2.6.11-rc2-bk5-b50-atkbd_init-lockup.txt.gz --]
[-- Type: application/x-gunzip, Size: 4197 bytes --]
^ permalink raw reply
* Re: [PATCH] radeonfb: massive update of PM code
From: Colin Leroy @ 2005-01-28 12:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1106866874.6250.97.camel@gaston>
On 28 Jan 2005 at 10h01, Benjamin Herrenschmidt wrote:
Hi,=20
> Well, this is basically equivalent to sleep #7 patch, so I'm not sure
> what's wrong...
Maybe the dynclk parameter which default changed? I'll do more tests
as soon as possible...
--=20
Colin
4. la d=E9t=E9rioration de la t=EAte peut avoir de graves cons=E9quences.=
=20
^ permalink raw reply
* Re: Serial console problem on MPC8272ADS board
From: ning @ 2005-01-28 10:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <41F602F8.1090007@yandex.ru>
Hello,Vitaly
Thanks for your reply.
I added SCC4 to rs_table as following:
static struct serial_state rs_table[] = {
/* UART CLK PORT IRQ FLAGS NUM */
{ 0, 0, PROFF_SCC1, SIU_INT_SCC1, 0, (0 |
NUM_IS_SCC) }, /* SCC1 ttyS0 */
{ 0, 0, PROFF_SCC4, SIU_INT_SCC4, 0, (3 |
NUM_IS_SCC) }, /* SCC4 ttyS1 */
};
ttyS0,ttyS1 work as COM port,but linux boot log only is
outputed at ttyS0,how can I redirect it at ttyS1?
After linux boots successfully,linux prompt will display
at ttyS1,and I use it normally.
(u-boot parameter: setenv bootargs root=/dev/nfs rw
console=ttyS1,115200n8
rootfs: /dev/console --> ttyS1)
at \arch\ppc\boot\simple\m8260_tty.c,Even if I define
SCC_CONSOLE to 4,Linux boot log is outputed at ttyS0.
the following comment is written at m8260_tty.c:
/* If defined, enables serial console. The value (1
through 4) should designate which SCC is used, but this
isn't complete. Only SCC1 is known to work at this time.
*/
#ifdef CONFIG_SCC_CONSOLE
#define SCC_CONSOLE 4
#endif
Maybe it is true.
--- Vitaly Bordug <vvv75@yandex.ru> からのメッセージ：
> Ning,
> Well, AFAIK the serial console on the second UART
> (and second UART on
> SCC4 as well) haven't been included yet to the
> community tree. To be
> sure you can take a look in the 8260_io/uart.c where
> in rs_table
> structure second entry should be {0, 0, PROFF_SCC4
> ... Implementation is
> not that hard, you need only make proper mentioned
> entry, enable
> transceiver (BCSR+4), and program parallel port pins
> (take a look at
> chapter 37 of MPC8272 reference manual, grep for
> SCC4).
>
> --
> Regards, Vitaly
__________________________________
Let's Celebrate Together!
Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/so2005/
^ permalink raw reply
* RE: console_init() question
From: Povolotsky, Alexander @ 2005-01-28 2:56 UTC (permalink / raw)
To: 'linuxppc-dev@lists.linuxppc.org',
'linuxppc-embedded@ozlabs.org'
-----Original Message-----
>From: Dan Malek [mailto:dan@embeddededge.com]
>Sent: Thursday, January 27, 2005 9:38 PM
>To: Povolotsky, Alexander
>Cc: 'linuxppc-dev@lists.linuxppc.org'; 'linuxppc-embedded@ozlabs.org'
>Subject: Re: console_init() question=20
>Do you boot over a network? Does your boot loader shut down
>the network controller and interrupts before jumping to the kernel?
No - also, please note that the serial works during the "simple =
bootloader
time" (see my "add on" question below)
>Everything looks OK until the CPM and serial port are reconfigured
>by Linux, so something is amiss with that. Could be many reasons
>such as location of BDs and buffers, some part of the CPM still
>running a peripheral from the boot loader that Linux doesn't know
>about, and so on.
That why I asked (OK ..., may be I did not ask that ...)
for some "CPM diagnostic" software, that could
be run upon kernel booting
- (something what PPCbug might have already - not sure, though, just
guessing ...)
-- Dan
Alternatively (or addionally) to my original questin - why not =
(optionally)
to
allow for the kernel to use the simple serial console mechanism
(putc( ), puts( ), puthex( )) which is used (and, by the way, works in =
my
case - as one could=20
see from the quotted below booting output) in the "simple" bootloader =
(the
'middle-man' between the primary=20
bootloader and the kernel ) - may be by making it available to the =
kernel as
a library ?
-----Original Message-----
>From: Andrew Williams [mailto:awilliam@nortelnetworks.com]
>Sent: Thursday, January 27, 2005 9:33 PM
>To: Povolotsky, Alexander; 'linuxppc-dev@lists.linuxppc.org';
'linuxppc-embedded@ozlabs.org'
>Subject: RE: console_init() question=20
>Here's a reference doc, that I found extremely usefull/interesting=20
>when working on board bring up.=20
> <http://www.tldp.org/LDP/cpg/Custom-Porting-Guide.pdf>=20
>Andrew=20
Thanks - I have already look at that - those lucky guys had simple =
serial
UART (without CPM complexity)=20
> -----Original Message-----
> From: Povolotsky, Alexander =20
> Sent: Thursday, January 27, 2005 9:07 PM
> To: 'linuxppc-dev@lists.linuxppc.org'; 'linuxppc-embedded@ozlabs.org'
> Subject: console_init() question=20
>=20
> Hi,
>=20
> I am struggling with bringing up the MPC 880 board on Linux =
2.6-10.rc3 ...
> I could see that only 3 characters (see below) from the linux_banner =
are
> printed
> in __init start_kernel() (init/main.c) upon booting.
> Then a lot of garbage is outputted and eventually kernel hangs ...
> ...
> after gunzip
> done.
> Now booting the kernel
> =
Lin=FF=FF=FF=FF=FF=FF=FF=FF=C0=FF=FF=FF=FF=FF=FF=FF=FF=C08=C0=FF=FF=FF=FF=
=FF=FF=FF=FF=C0X=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0x=C0=FF=FF=FF=FF=FF=FF=FF=FF=
=C0~=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0=B8=C0=FF=FF=FF=FF=FF=FF=FF
> =FF=C0=D8=C0=FF=FF
> <more garbage>
> <hangs> ...=20
> ...
>=20
> Very laborious debugging (without BDM and soft reset button - but =
with
> great help) shows that the hang is caused by the console
> serial driver at about (or just soon after)=20
>=20
> console_drivers =3D console;
>=20
> statement in
>=20
> register_console(struct console * console)
>=20
> function (in kernel/printk.c )=20
> =20
> I can not find (so far ) any specific error in values supplied via =
bd_info
> from the ("custom" modified pSOS bootloader) causing above problem.
> =20
> The debug output showing my serial settings was saved into log buffer =
and
> read at "bootloader time" after=20
> "software stimulated" "soft reboot" - it is listed here.
> Could someone kindly spare 5 min examining supplied debug output =
from
> both cpm_uart_set_termios()
> (in drivers/serial/cpm_uart/cpm_uart_core.c) and cpm_setbrg() (in
> arch/ppc/8xx_io/commproc.c) and tell
> me what is wrong there ?
> The output is supplied at the end of my e-mail after the listings of
> functions (with my print statements)
>=20
> Thanks,
> Alex
>=20
> PS - I noticed (with help and via "trial and error" way) that
> console_init() code is written to work only with
> "boot" (unmapped) memory and therefore only could work if =
executed
> prior to mem_init().=20
> Suppose I would disable (comment out in main.c ) the =
console_init()
> call
> and suppose (I do not know yet since did not tried that) the
> kernel booting
> will continue without any additional problems and will =
sucessfully
> finish (just without the console ;-) )
> - is there any existant "non-standard" "debugging" =
"experimental"
> code,
> which I could integrate and execute with the aim to "late" =
launch
> my serial console at that point ?
>=20
> ***************** drivers/serial/cpm_uart/cpm_uart_core.c
> ******************
> ....
> #define DEBUG=20
> ....
> static void cpm_uart_set_termios(struct uart_port *port,
> struct termios *termios, struct =
termios
> *old)
> {
> int baud;
> unsigned long flags;
> u16 cval, scval, prev_mode;
> int bits, sbits;
> struct uart_cpm_port *pinfo =3D (struct uart_cpm_port *)port;
> volatile smc_t *smcp =3D pinfo->smcp;
> volatile scc_t *sccp =3D pinfo->sccp;
> #ifdef DEBUG
> pr_debug("CPM uart[%d]:set_termios\n", port->line);
> #endif
>=20
> baud =3D uart_get_baud_rate(port, termios, old, 0, =
port->uartclk /
> 16);
>=20
> #ifdef DEBUG
> pr_debug("CPM uart baud=3D%d\n", baud);
> #endif
> /* Character length programmed into the mode register is the
> * sum of: 1 start bit, number of data bits, 0 or 1 parity =
bit,
> * 1 or 2 stop bits, minus 1.
> * The value 'bits' counts this for us.
> */
> cval =3D 0;
> scval =3D 0;
>=20
> /* byte size */
> switch (termios->c_cflag & CSIZE) {
> case CS5:
> bits =3D 5;
> break;
> case CS6:
> bits =3D 6;
> break;
> case CS7:
> bits =3D 7;
> break;
> case CS8:
> bits =3D 8;
> break;
> /* Never happens, but GCC is too dumb to figure it =
out */
> default:
> bits =3D 8;
> break;
> }
> sbits =3D bits - 5;
> #ifdef DEBUG
> pr_debug("CPM uart bits=3D%d\n", bits);
> pr_debug("CPM uart sbits=3D%d\n", sbits);
> #endif
>=20
> if (termios->c_cflag & CSTOPB) {
> cval |=3D SMCMR_SL; /* Two stops */
> scval |=3D SCU_PSMR_SL;
> bits++;
> }
>=20
> if (termios->c_cflag & PARENB) {
> cval |=3D SMCMR_PEN;
> scval |=3D SCU_PSMR_PEN;
> bits++;
> if (!(termios->c_cflag & PARODD)) {
> cval |=3D SMCMR_PM_EVEN;
> scval |=3D (SCU_PSMR_REVP | SCU_PSMR_TEVP);
> }
> }
> #ifdef DEBUG
> pr_debug("CPM uart bits=3D%d\n", bits);
> pr_debug("CPM uart cval=3D%d\n", cval);
> pr_debug("CPM uart scval=3D%d\n", scval);
> #endif
>=20
> /*
> * Set up parity check flag
> */
> #define RELEVANT_IFLAG(iflag) (iflag &
> (IGNBRK|BRKINT|IGNPAR|PARMRK|INPCK))
>=20
> port->read_status_mask =3D (BD_SC_EMPTY | BD_SC_OV);
> if (termios->c_iflag & INPCK)
> port->read_status_mask |=3D BD_SC_FR | BD_SC_PR;
> if ((termios->c_iflag & BRKINT) || (termios->c_iflag & =
PARMRK))
> port->read_status_mask |=3D BD_SC_BR;
>=20
> /*
> * Characters to ignore
> */
> port->ignore_status_mask =3D 0;
> if (termios->c_iflag & IGNPAR)
> port->ignore_status_mask |=3D BD_SC_PR | BD_SC_FR;
> if (termios->c_iflag & IGNBRK) {
> port->ignore_status_mask |=3D BD_SC_BR;
> /*
> * If we're ignore parity and break indicators, =
ignore
> * overruns too. (For real raw support).
> */
> if (termios->c_iflag & IGNPAR)
> port->ignore_status_mask |=3D BD_SC_OV;
> ifdef DEBUG
> if (termios->c_iflag & IGNPAR)
> pr_debug("CPM uart real raw support");
> endif
> }
> /*
> * !!! ignore all characters if CREAD is not set
> */
> if ((termios->c_cflag & CREAD) =3D=3D 0)
> port->read_status_mask &=3D ~BD_SC_EMPTY;
> ifdef DEBUG
> if ((termios->c_cflag & CREAD) =3D=3D 0)
> pr_debug("CPM uart CREAD is not set");
> endif
>=20
> spin_lock_irqsave(&port->lock, flags);
>=20
> /* Start bit has not been added (so don't, because we would =
just
> * subtract it later), and we need to add one for the number =
of
> * stops bits (there is always at least one).
> */
> bits++;
> ifdef DEBUG
> pr_debug("CPM uart bits=3D%d\n", bits);
> endif
> if (IS_SMC(pinfo)) {
> /* Set the mode register. We want to keep a copy of =
the
> * enables, because we want to put them back if they =
were
> * present.
> */
> prev_mode =3D smcp->smc_smcmr;
> smcp->smc_smcmr =3D smcr_mk_clen(bits) | cval |
> SMCMR_SM_UART;
> smcp->smc_smcmr |=3D (prev_mode & (SMCMR_REN | =
SMCMR_TEN));
> ifdef DEBUG
> pr_debug("CPM uart IS_SMCpinfo > 0 \n");
> endif
> } else {
> sccp->scc_psmr =3D (sbits << 12) | scval;
> }
>=20
> cpm_set_brg(pinfo->brg - 1, baud);
> ifdef DEBUG
> pr_debug(" returned from cpm_set_brg");
> endif
> spin_unlock_irqrestore(&port->lock, flags);
> ifdef DEBUG
> pr_debug("after spin_unlock_irqrestore");
> #endif
> *(int*)0 =3D 0xdeadbeef; <=3D=3D=3D=3D I have inserted here =
to force
> crash and soft reboot - it works !
> #ifdef DEBUG
> pr_debug("after deadbeef"); <<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
I have inserted here
> for double check - never reached ...
> #endif
>=20
> }
>=20
> ***************************** arch/ppc/8xx_io/commproc.c
> ***********************************=20
>=20
> #define BRG_INT_CLK (((bd_t *)__res)->bi_intfreq)
> #define BRG_UART_CLK (BRG_INT_CLK/16)
> #define BRG_UART_CLK_DIV16 (BRG_UART_CLK/16)
>=20
> void
> cpm_setbrg(uint brg, uint rate)
> {
> volatile uint *bp;
> unsigned long brgUrtClkDiv16 =3D BRG_UART_CLK_DIV16;
>=20
> /* This is good enough to get SMCs running.....
> */
> bp =3D (uint *)&cpmp->cp_brgc1;
>=20
> printk("cpm_setbrg: BRG_UART_CLK_DIV16 %lu",brgUrtClkDiv16);
> printk("cpm_setbrg: *bp came as %u",*bp);
> printk("cpm_setbrg: rate came as %u",rate);
> bp +=3D brg;
>=20
> printk("cpm_setbrg: *bp is now %u",*bp);
> /* The BRG has a 12-bit counter. For really slow baud rates =
(or
> * really fast processors), we may have to further divide by =
16.
> */
> if (((BRG_UART_CLK / rate) - 1) < 4096)
> *bp =3D (((BRG_UART_CLK / rate) - 1) << 1) | =
CPM_BRG_EN;
> else
> *bp =3D (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) |
> CPM_BRG_EN |
> CPM_BRG_DIV16;
>=20
>=20
> printk("cpm_setbrg: *bp is set to %u",*bp);
>=20
> }
>=20
> ****************************
> Now the output in the log buffer from both cpm_uart_set_termios() and
> cpm_setbrg() ) :
> *********************************************
>=20
> < 7>CPM uart[0]:set_termios.
> <7>CPM uart baud =3D115200.
> <7>CPM uart bits=3D8.
> .<7>CPM uart cval=3D0.
> .<7>CPM uart bits=3D9.
> .<4>cpm_setbrg: BRG_UART_CLK_DIV16 195312
> cpm_setbrg: *bp came as 65588
> cpm_setbrg: rate came as 115200
> cpm_setbrg: *bp is now 65588
> cpm_setbrg: *bp is set to 65588
> <7>returned from cpm_set_brg
> <7>after spin_unlock_irqrestore
>=20
^ permalink raw reply
* RE: console_init() question
From: Andrew Williams @ 2005-01-28 2:32 UTC (permalink / raw)
To: Povolotsky, Alexander, 'linuxppc-dev@lists.linuxppc.org',
'linuxppc-embedded@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 162 bytes --]
Here's a reference doc, that I found extremely usefull/interesting
when working on board bring up.
http://www.tldp.org/LDP/cpg/Custom-Porting-Guide.pdf
Andrew
[-- Attachment #2: Type: text/html, Size: 662 bytes --]
^ permalink raw reply
* Re: console_init() question
From: Dan Malek @ 2005-01-28 2:37 UTC (permalink / raw)
To: Povolotsky, Alexander
Cc: 'linuxppc-dev@lists.linuxppc.org',
'linuxppc-embedded@ozlabs.org'
In-Reply-To: <313680C9A886D511A06000204840E1CF0A6475BC@whq-msgusr-02.pit.comms.marconi.com>
On Jan 27, 2005, at 6:07 PM, Povolotsky, Alexander wrote:
> I can not find (so far ) any specific error in values supplied vi
> bd_info
> from the ("custom" modified pSOS bootloader) causing above problem.
Do you boot over a network? Does your boot loader shut down
the network controller and interrupts before jumping to the kernel?
Everything looks OK until the CPM and serial port are reconfigured
by Linux, so something is amiss with that. Could be many reasons
such as location of BDs and buffers, some part of the CPM still
running a peripheral from the boot loader that Linux doesn't know
about, and so on.
-- Dan
^ permalink raw reply
* console_init() question
From: Povolotsky, Alexander @ 2005-01-28 2:07 UTC (permalink / raw)
To: 'linuxppc-dev@lists.linuxppc.org',
'linuxppc-embedded@ozlabs.org'
> Hi,
>=20
I am struggling with bringing up the MPC 880 board on Linux 2.6-10.rc3 =
...
I could see that only 3 characters (see below) from the linux_banner =
are
printed
in __init start_kernel() (init/main.c) upon booting.
Then a lot of garbage is outputted and eventually kernel hangs ...
...
after gunzip
done.
Now booting the kernel
Lin=FF=FF=FF=FF=FF=FF=FF=FF=C0=FF=FF=FF=FF=FF=FF=FF=FF=C08=C0=FF=FF=FF=FF=
=FF=FF=FF=FF=C0X=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0x=C0=FF=FF=FF=FF=FF=FF=FF=FF=
=C0~=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0=B8=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0
=D8=C0=FF=FF
<more garbage>
<hangs> ...=20
...
Very laborious debugging (without BDM and soft reset button - but with =
great
help) shows that the hang is caused by the console
serial driver at about (or just soon after)=20
console_drivers =3D console;
statement in
register_console(struct console * console)
function (in kernel/printk.c )=20
=20
I can not find (so far ) any specific error in values supplied vi =
bd_info
from the ("custom" modified pSOS bootloader) causing above problem.
> =20
The debug output showing my serial settings was saved into log buffer =
and
read at "bootloader time" after=20
"software stimulated" "soft reboot" - it is listed here.
Could someone kindly spare 5 min examining supplied debug output from =
both
cpm_uart_set_termios()
> (in drivers/serial/cpm_uart/cpm_uart_core.c) and cpm_setbrg() (in
> arch/ppc/8xx_io/commproc.c) and tell
me what is wrong there ?
> The output is supplied at the end of my e-mail after the listings of
> functions (with my print statements)
>=20
> Thanks,
> Alex
>=20
PS - I noticed (with help and via "trial and error" way) that =
console_init()
code is written to work only with
"boot" (unmapped) memory and therefore only could work if
executed prior to mem_init().=20
Suppose I would disable (comment out in main.c ) the =
console_init()
call
and suppose (I do not know yet since did not tried that) the =
kernel
booting
will continue without any additional problems and will =
sucessfully
finish (just without the console ;-) )
- is there any existant "non-standard" "debugging" =
"experimental"
code,
which I could integrate and execute with the aim to "late" =
launch my
serial console at that point ?
> ***************** drivers/serial/cpm_uart/cpm_uart_core.c
> ******************
> ....
> #define DEBUG=20
> ....
> static void cpm_uart_set_termios(struct uart_port *port,
> struct termios *termios, struct =
termios
> *old)
> {
> int baud;
> unsigned long flags;
> u16 cval, scval, prev_mode;
> int bits, sbits;
> struct uart_cpm_port *pinfo =3D (struct uart_cpm_port *)port;
> volatile smc_t *smcp =3D pinfo->smcp;
> volatile scc_t *sccp =3D pinfo->sccp;
> #ifdef DEBUG
> pr_debug("CPM uart[%d]:set_termios\n", port->line);
> #endif
>=20
> baud =3D uart_get_baud_rate(port, termios, old, 0, =
port->uartclk /
> 16);
>=20
> #ifdef DEBUG
> pr_debug("CPM uart baud=3D%d\n", baud);
> #endif
> /* Character length programmed into the mode register is the
> * sum of: 1 start bit, number of data bits, 0 or 1 parity =
bit,
> * 1 or 2 stop bits, minus 1.
> * The value 'bits' counts this for us.
> */
> cval =3D 0;
> scval =3D 0;
>=20
> /* byte size */
> switch (termios->c_cflag & CSIZE) {
> case CS5:
> bits =3D 5;
> break;
> case CS6:
> bits =3D 6;
> break;
> case CS7:
> bits =3D 7;
> break;
> case CS8:
> bits =3D 8;
> break;
> /* Never happens, but GCC is too dumb to figure it =
out */
> default:
> bits =3D 8;
> break;
> }
> sbits =3D bits - 5;
> #ifdef DEBUG
> pr_debug("CPM uart bits=3D%d\n", bits);
> pr_debug("CPM uart sbits=3D%d\n", sbits);
> #endif
>=20
> if (termios->c_cflag & CSTOPB) {
> cval |=3D SMCMR_SL; /* Two stops */
> scval |=3D SCU_PSMR_SL;
> bits++;
> }
>=20
> if (termios->c_cflag & PARENB) {
> cval |=3D SMCMR_PEN;
> scval |=3D SCU_PSMR_PEN;
> bits++;
> if (!(termios->c_cflag & PARODD)) {
> cval |=3D SMCMR_PM_EVEN;
> scval |=3D (SCU_PSMR_REVP | SCU_PSMR_TEVP);
> }
> }
> #ifdef DEBUG
> pr_debug("CPM uart bits=3D%d\n", bits);
> pr_debug("CPM uart cval=3D%d\n", cval);
> pr_debug("CPM uart scval=3D%d\n", scval);
> #endif
>=20
> /*
> * Set up parity check flag
> */
> #define RELEVANT_IFLAG(iflag) (iflag &
> (IGNBRK|BRKINT|IGNPAR|PARMRK|INPCK))
>=20
> port->read_status_mask =3D (BD_SC_EMPTY | BD_SC_OV);
> if (termios->c_iflag & INPCK)
> port->read_status_mask |=3D BD_SC_FR | BD_SC_PR;
> if ((termios->c_iflag & BRKINT) || (termios->c_iflag & =
PARMRK))
> port->read_status_mask |=3D BD_SC_BR;
>=20
> /*
> * Characters to ignore
> */
> port->ignore_status_mask =3D 0;
> if (termios->c_iflag & IGNPAR)
> port->ignore_status_mask |=3D BD_SC_PR | BD_SC_FR;
> if (termios->c_iflag & IGNBRK) {
> port->ignore_status_mask |=3D BD_SC_BR;
> /*
> * If we're ignore parity and break indicators, =
ignore
> * overruns too. (For real raw support).
> */
> if (termios->c_iflag & IGNPAR)
> port->ignore_status_mask |=3D BD_SC_OV;
> ifdef DEBUG
> if (termios->c_iflag & IGNPAR)
> pr_debug("CPM uart real raw support");
> endif
> }
> /*
> * !!! ignore all characters if CREAD is not set
> */
> if ((termios->c_cflag & CREAD) =3D=3D 0)
> port->read_status_mask &=3D ~BD_SC_EMPTY;
> ifdef DEBUG
> if ((termios->c_cflag & CREAD) =3D=3D 0)
> pr_debug("CPM uart CREAD is not set");
> endif
>=20
> spin_lock_irqsave(&port->lock, flags);
>=20
> /* Start bit has not been added (so don't, because we would =
just
> * subtract it later), and we need to add one for the number =
of
> * stops bits (there is always at least one).
> */
> bits++;
> ifdef DEBUG
> pr_debug("CPM uart bits=3D%d\n", bits);
> endif
> if (IS_SMC(pinfo)) {
> /* Set the mode register. We want to keep a copy of =
the
> * enables, because we want to put them back if they =
were
> * present.
> */
> prev_mode =3D smcp->smc_smcmr;
> smcp->smc_smcmr =3D smcr_mk_clen(bits) | cval |
> SMCMR_SM_UART;
> smcp->smc_smcmr |=3D (prev_mode & (SMCMR_REN | =
SMCMR_TEN));
> ifdef DEBUG
> pr_debug("CPM uart IS_SMCpinfo > 0 \n");
> endif
> } else {
> sccp->scc_psmr =3D (sbits << 12) | scval;
> }
>=20
> cpm_set_brg(pinfo->brg - 1, baud);
> ifdef DEBUG
> pr_debug(" returned from cpm_set_brg");
> endif
> spin_unlock_irqrestore(&port->lock, flags);
> ifdef DEBUG
> pr_debug("after spin_unlock_irqrestore");
> #endif
> *(int*)0 =3D 0xdeadbeef; <=3D=3D=3D=3D I have inserted here =
to force
> crash and soft reboot - it works !
> #ifdef DEBUG
> pr_debug("after deadbeef"); <<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
I have inserted here
> for double check - never reached ...
> #endif
>=20
> }
>=20
> ***************************** arch/ppc/8xx_io/commproc.c
> ***********************************=20
>=20
> #define BRG_INT_CLK (((bd_t *)__res)->bi_intfreq)
> #define BRG_UART_CLK (BRG_INT_CLK/16)
> #define BRG_UART_CLK_DIV16 (BRG_UART_CLK/16)
>=20
> void
> cpm_setbrg(uint brg, uint rate)
> {
> volatile uint *bp;
> unsigned long brgUrtClkDiv16 =3D BRG_UART_CLK_DIV16;
>=20
> /* This is good enough to get SMCs running.....
> */
> bp =3D (uint *)&cpmp->cp_brgc1;
>=20
> printk("cpm_setbrg: BRG_UART_CLK_DIV16 %lu",brgUrtClkDiv16);
> printk("cpm_setbrg: *bp came as %u",*bp);
> printk("cpm_setbrg: rate came as %u",rate);
> bp +=3D brg;
>=20
> printk("cpm_setbrg: *bp is now %u",*bp);
> /* The BRG has a 12-bit counter. For really slow baud rates =
(or
> * really fast processors), we may have to further divide by =
16.
> */
> if (((BRG_UART_CLK / rate) - 1) < 4096)
> *bp =3D (((BRG_UART_CLK / rate) - 1) << 1) | =
CPM_BRG_EN;
> else
> *bp =3D (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) |
> CPM_BRG_EN |
> CPM_BRG_DIV16;
>=20
>=20
> printk("cpm_setbrg: *bp is set to %u",*bp);
>=20
> }
>=20
> ****************************
> Now the output in the log buffer from both cpm_uart_set_termios() and
> cpm_setbrg() ) :
> *********************************************
>=20
> < 7>CPM uart[0]:set_termios.
> <7>CPM uart baud =3D115200.
> <7>CPM uart bits=3D8.
> .<7>CPM uart cval=3D0.
> .<7>CPM uart bits=3D9.
> .<4>cpm_setbrg: BRG_UART_CLK_DIV16 195312
> cpm_setbrg: *bp came as 65588
> cpm_setbrg: rate came as 115200
> cpm_setbrg: *bp is now 65588
> cpm_setbrg: *bp is set to 65588
> <7>returned from cpm_set_brg
> <7>after spin_unlock_irqrestore
>=20
^ permalink raw reply
* Re: Relocating interrupt vectors in ppc440?
From: Shawn Jin @ 2005-01-28 1:55 UTC (permalink / raw)
To: linuxppc
In-Reply-To: <20050127134117.D4266@cox.net>
> > I guess the value set to PPC_MEMSTART should be the offset to the
> > physical starting address of 2GB SDRAM not the absolute physical
> > address, right?
>
> It would be 0x00000000 for the first processor and 0x40000000 for the
> second processor. Note that head_44x.S is a major place where a lot
> of "system memory is at zero" assumptions take place that need to
> be addressed for the second processor.
The theory behind changing PPC_MEMSTART is to change MMU configuration
and to let it translate 0xC0000000 to 0x40000000 for the 2nd
processor. Right?
One place I found the assumption is when loading the kernel physical address.
/* Kernel is at the base of RAM */
li r4, 0 /* Load the kernel physical address */
I'll find out more places as you indicated.
Best regards,
-Shawn.
^ permalink raw reply
* [PATCH][PPC32] Workaround for mpc10x speculative PCI read erratum
From: Mark A. Greer @ 2005-01-28 1:37 UTC (permalink / raw)
To: akpm; +Cc: Embedded PPC Linux list
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
824x and 107 bridges from Freescale/Tundra have an erratum where
speculative PCI reads may return stale data. One of the two documented
workarounds is to turn of speculative PCI reads. This patch does that.
Please apply.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
[-- Attachment #2: mpc10x.patch --]
[-- Type: text/plain, Size: 1334 bytes --]
diff -Nru a/arch/ppc/syslib/mpc10x_common.c b/arch/ppc/syslib/mpc10x_common.c
--- a/arch/ppc/syslib/mpc10x_common.c 2005-01-27 18:31:21 -07:00
+++ b/arch/ppc/syslib/mpc10x_common.c 2005-01-27 18:31:21 -07:00
@@ -306,6 +306,23 @@
mpc10x_disable_store_gathering(hose);
#endif
+ /*
+ * 8240 erratum 26, 8241/8245 erratum 29, 107 erratum 23: speculative
+ * PCI reads may return stale data so turn off.
+ */
+ if ((host_bridge == MPC10X_BRIDGE_8240)
+ || (host_bridge == MPC10X_BRIDGE_8245)
+ || (host_bridge == MPC10X_BRIDGE_107)) {
+
+ early_read_config_dword(hose, 0, PCI_DEVFN(0,0),
+ MPC10X_CFG_PICR1_REG, &picr1);
+
+ picr1 &= ~MPC10X_CFG_PICR1_SPEC_PCI_RD;
+
+ early_write_config_dword(hose, 0, PCI_DEVFN(0,0),
+ MPC10X_CFG_PICR1_REG, picr1);
+ }
+
if (ppc_md.progress) ppc_md.progress("mpc10x:exit", 0x100);
return 0;
}
diff -Nru a/include/asm-ppc/mpc10x.h b/include/asm-ppc/mpc10x.h
--- a/include/asm-ppc/mpc10x.h 2005-01-27 18:31:21 -07:00
+++ b/include/asm-ppc/mpc10x.h 2005-01-27 18:31:21 -07:00
@@ -105,6 +105,7 @@
#define MPC10X_CFG_PICR1_ADDR_MAP_MASK 0x00010000
#define MPC10X_CFG_PICR1_ADDR_MAP_A 0x00010000
#define MPC10X_CFG_PICR1_ADDR_MAP_B 0x00000000
+#define MPC10X_CFG_PICR1_SPEC_PCI_RD 0x00000004
#define MPC10X_CFG_PICR1_ST_GATH_EN 0x00000040
#define MPC10X_CFG_MAPB_OPTIONS_REG 0xe0
^ permalink raw reply
* Re: [PATCH] radeonfb: massive update of PM code
From: Benjamin Herrenschmidt @ 2005-01-27 23:01 UTC (permalink / raw)
To: Colin Leroy; +Cc: linuxppc-dev list
In-Reply-To: <20050127195730.07d3b4e9@jack.colino.net>
On Thu, 2005-01-27 at 19:57 +0100, Colin Leroy wrote:
> On 18 Jan 2005 at 12h01, Benjamin Herrenschmidt wrote:
>
> Hi,
>
> > +module_param(default_dynclk, int, -2);
>
> Btw, I have been told that module_param()'s third parameters is an octal
> used for permissions (as 0644).
Ah ... oh well, I'll have to check that out with Rusty
Ben.
^ permalink raw reply
* Re: [PATCH] radeonfb: massive update of PM code
From: Benjamin Herrenschmidt @ 2005-01-27 23:01 UTC (permalink / raw)
To: Colin Leroy; +Cc: linuxppc-dev list
In-Reply-To: <20050127195205.192c8c28@jack.colino.net>
On Thu, 2005-01-27 at 19:52 +0100, Colin Leroy wrote:
> On 18 Jan 2005 at 12h01, Benjamin Herrenschmidt wrote:
>
> Hi Ben,
>
> > This patch is a quite massive update to radeonfb. It adds the ability
> > to reboot from scratch the various chip models used on the recent
> > powermac laptops, adds a bunch of new chips (including R420 support,
> > untested), plus various fixes here or there including LCD & flat panel
> > blanking, abuse of stack usage in radeonfb_set_par(), and finally,
> > adapts the PM code to the recent powermac changes.
>
> I just upgraded to 2.6.10, applied the 6 other patches you sent and this
> one. This one makes some heavy video corruption on my iBook G4
> (PowerBook6,3). The patch applies with a 27 lines offset at most hunks,
> but does no rejects.
>
> I'm using xorg 6.7.0, and your test sleep patch #7 on 2.6.9 worked fine.
>
> Tell me if I can be of any help...
Well, this is basically equivalent to sleep #7 patch, so I'm not sure
what's wrong...
Ben.
^ permalink raw reply
* Re: [PATCH] netdrv gianfar: Fix usage of gfar_read in debug code
From: Jeff Garzik @ 2005-01-27 22:08 UTC (permalink / raw)
To: Kumar Gala; +Cc: akpm, linux-kernel, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0501251814480.26772@blarg.somerset.sps.mot.com>
applied
^ permalink raw reply
* Re: Relocating interrupt vectors in ppc440?
From: Matt Porter @ 2005-01-27 20:41 UTC (permalink / raw)
To: Shawn Jin; +Cc: linuxppc
In-Reply-To: <c3d0340b050127121826b92395@mail.gmail.com>
On Thu, Jan 27, 2005 at 12:18:45PM -0800, Shawn Jin wrote:
> First thank you for your valuable response.
>
> > > Assumed that the interrupt vectors locate at the low address space
> > > physically and given that there is 2GB SDRAM shared by two ppc440
> > > cores, can one of linux kernels run at the top of 1GB space? This
> > > means the interrupt vectors for this copy need to move to upper 1GB.
> > > Each core runs a copy of linux kernel independently.
> >
> > Yes, you'd have to do something like the APUS code does by settings
> > PPC_MEMSTART appropriately for the second processor. Also, of course
>
> I guess the value set to PPC_MEMSTART should be the offset to the
> physical starting address of 2GB SDRAM not the absolute physical
> address, right?
It would be 0x00000000 for the first processor and 0x40000000 for the
second processor. Note that head_44x.S is a major place where a lot
of "system memory is at zero" assumptions take place that need to
be addressed for the second processor.
> > limiting the memory on the first processor to 1GB. There's probably
>
> Limiting the memory on the first processor to 1GB can be done by
> setting the mem size to 1GB in boot arguments (mem=1024MB)?
Correct, but for a SoC port where this is a static configuration, you
can simply make your "find_end_of_memory()" routine return 1GB.
> > One idea is that if you really don't have to do it, then don't. :)
>
> The SoC is designed in this way that two cores share the DDR but it's
> not SMP. Two kernels have to run independently. Relocating interrupt
> vectors to upper 1GB memory means that another copy of kernel can run
> at upper memory, right. So I'm afraid I have to do that. :(
That's a shame. This sounds identical to a 440-based standard product
that IBM had planned (and cancelled) when they still owned the 4xx
standard product line.
-Matt
^ permalink raw reply
* Re: Relocating interrupt vectors in ppc440?
From: Shawn Jin @ 2005-01-27 20:18 UTC (permalink / raw)
To: linuxppc
In-Reply-To: <20050127111615.A4266@cox.net>
First thank you for your valuable response.
> > Assumed that the interrupt vectors locate at the low address space
> > physically and given that there is 2GB SDRAM shared by two ppc440
> > cores, can one of linux kernels run at the top of 1GB space? This
> > means the interrupt vectors for this copy need to move to upper 1GB.
> > Each core runs a copy of linux kernel independently.
>
> Yes, you'd have to do something like the APUS code does by settings
> PPC_MEMSTART appropriately for the second processor. Also, of course
I guess the value set to PPC_MEMSTART should be the offset to the
physical starting address of 2GB SDRAM not the absolute physical
address, right?
> limiting the memory on the first processor to 1GB. There's probably
Limiting the memory on the first processor to 1GB can be done by
setting the mem size to 1GB in boot arguments (mem=1024MB)?
> One idea is that if you really don't have to do it, then don't. :)
The SoC is designed in this way that two cores share the DDR but it's
not SMP. Two kernels have to run independently. Relocating interrupt
vectors to upper 1GB memory means that another copy of kernel can run
at upper memory, right. So I'm afraid I have to do that. :(
Thanks,
-Shawn.
^ permalink raw reply
* Re: [PATCH] radeonfb: massive update of PM code
From: Colin Leroy @ 2005-01-27 18:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1106012932.4533.46.camel@gaston>
On 18 Jan 2005 at 12h01, Benjamin Herrenschmidt wrote:
Hi Ben,
> This patch is a quite massive update to radeonfb. It adds the ability
> to reboot from scratch the various chip models used on the recent
> powermac laptops, adds a bunch of new chips (including R420 support,
> untested), plus various fixes here or there including LCD & flat panel
> blanking, abuse of stack usage in radeonfb_set_par(), and finally,
> adapts the PM code to the recent powermac changes.
I just upgraded to 2.6.10, applied the 6 other patches you sent and this
one. This one makes some heavy video corruption on my iBook G4
(PowerBook6,3). The patch applies with a 27 lines offset at most hunks,
but does no rejects.
I'm using xorg 6.7.0, and your test sleep patch #7 on 2.6.9 worked fine.
Tell me if I can be of any help...
Thanks!
--
Colin
"Dinner not ready: (A)bort (R)etry (P)izza"
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox