* Re: No ttyS device at I/O port 0xfe004500 for console
From: Kumar Gala @ 2006-06-13 19:55 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <448EEC59.2010201@cambridgebroadband.com>
On Jun 13, 2006, at 11:48 AM, Alex Zeffertt wrote:
> Hi list,
>
> I'm trying to boot a linux-2.6.11 kernel on a MPC83xx based board.
> Through
> some experimentation I have found I need "console=uart,io,0xfe004500"
> in the kernel command line in order to get any output over the serial
> port.
>
> Half way through initialisation the kernel appears to swap from its
> "early"
> 8250 serial driver to a "full" 8250 serial driver. At this point
> it prints
> "No ttyS device at I/O port 0xfe004500 for console" and there is no
> further output.
>
> Does anyone have any idea what I may be doing wrong?
>
> BTW, here's the output that I do get.
Alex, where did you get this 2.6.11 kernel? The public tree didn't
have support for 83xx in 2.6.11. I'd suggest looking at using
something newer like 2.6.16 and see if you have the same issue.
- k
>
> -------------------/snip--------------------------
> U-Boot 1.1.3 (FSL Development) (Jun 13 2006 - 14:01:25) MPC83XX
>
> Clock configuration:
> Coherent System Bus: 132 MHz
> Core: 264 MHz
> QE: 198 MHz
> Local Bus Controller: 132 MHz
> Local Bus: 66 MHz
> DDR: 264 MHz
> SEC: 132 MHz
> I2C1: 132 MHz
> CPU: MPC8323E, Rev: 10 at 264 MHz
> Board: Freescale MPC832XEPB
> I2C: ready
> DRAM:
> DDR RAM: 128 MB
> FLASH: 16 MB
> In: serial
> Out: serial
> Err: serial
> Net: FSL GETH0
> Hit any key to stop autoboot: 0
> geth: PHY is Davicom DM9161A (181b8a0)
> FSL GETH0: Full Duplex
> FSL GETH0: Speed 100BT
> FSL GETH0: Link is up
> Using FSL GETH0 device
> TFTP from server 10.0.0.107; our IP address is 10.0.6.65
> Filename 'uImage'.
> Load address: 0x200000
> Loading:
> #################################################################
>
> #################################################################
>
> #################################################################
> ##########
> done
> Bytes transferred = 1046491 (ff7db hex)
> ## Booting image at 00200000 ...
> Image Name: Linux-2.6.11
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1046427 Bytes = 1021.9 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Linux version 2.6.11 (ajz@zambia) (gcc version 3.4.3) #5 Tue Jun 13
> 17:36:46 BST 2006
> Built 1 zonelists
> Kernel command line: root=/dev/nfs rw nfsroot=10.0.0.107:/opt/eldk/
> ppc_6xx ip=10.0.6.65:10.0.0.107:10.0.0.1:255.255.0.0:eth0:off
> console=uart,io,0xfe004500
> IPIC (128 IRQ sources, 8 External IRQs) at fe000700
> QE IC (64 IRQ sources) at fe100080
> PID hash table entries: 1024 (order: 10, 16384 bytes)
> Early serial console at I/O port 0xfe004500 (options '134')
> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
> Memory: 127488k available (1724k kernel code, 432k data, 100k init,
> 0k highmem)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> NET: Registered protocol family 16
> SCSI subsystem initialized
> JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
> Generic RTC Driver v1.07
> Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing
> disabled
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> RAMDISK driver initialized: 16 RAM disks of 32768K size 1024 blocksize
> loop: loaded (max 8 devices)
> MPC832XE MDS flash device: 1000000 at ff000000 Partition number 5
> MPC832XE PB Flash Map Info: Found 1 x16 devices at 0x0 in 16-bit bank
> Intel/Sharp Extended Query Table at 0x0031
> Using buffer write method
> cfi_cmdset_0001: Erase suspend on write enabled
> Creating 5 MTD partitions on "MPC832XE PB Flash Map Info":
> 0x00000000-0x00020000 : "HRCW"
> 0x00020000-0x00900000 : "JFFS2"
> 0x00900000-0x00d00000 : "Ramdisk"
> 0x00d00000-0x00f00000 : "Kernel"
> 0x00f00000-0x01000000 : "U-Boot"
> MPC832XE MDS flash device initialized
> i2c /dev entries driver
> NET: Registered protocol family 2
> IP: routing cache hash table of 1024 buckets, 8Kbytes
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> No ttyS device at I/O port 0xfe004500 for console
>
> -------------------/snip--------------------------
>
>
>
> TIA,
>
> Alex
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: No ttyS device at I/O port 0xfe004500 for console
From: Joakim Tjernlund @ 2006-06-13 20:46 UTC (permalink / raw)
To: 'Kumar Gala', 'Alex Zeffertt'; +Cc: linuxppc-embedded
In-Reply-To: <2CFF4933-A9D2-4981-BD11-C38537CE193B@kernel.crashing.org>
> On Jun 13, 2006, at 11:48 AM, Alex Zeffertt wrote:
>
> > Hi list,
> >
> > I'm trying to boot a linux-2.6.11 kernel on a MPC83xx based
> board.
> > Through
> > some experimentation I have found I need
> "console=uart,io,0xfe004500"
> > in the kernel command line in order to get any output over
> the serial
> > port.
> >
> > Half way through initialisation the kernel appears to swap from its
> > "early"
> > 8250 serial driver to a "full" 8250 serial driver. At this
> point it
> > prints "No ttyS device at I/O port 0xfe004500 for console"
> and there
> > is no further output.
> >
> > Does anyone have any idea what I may be doing wrong?
> >
> > BTW, here's the output that I do get.
>
> Alex, where did you get this 2.6.11 kernel? The public tree
> didn't have support for 83xx in 2.6.11. I'd suggest looking
> at using something newer like 2.6.16 and see if you have the
> same issue.
I suspect he got from the same place I did, freescales LTIB dev. env.
which has been patched to support 832x. I am having the same problem as he
has, any info on what the problem might be would be great.
Also, if anyone has any info on when these patches will be sent upstream, I
sure would like to hear about it.
Jocke
^ permalink raw reply
* Re: help with inittab
From: David H. Lynch Jr. @ 2006-06-13 21:07 UTC (permalink / raw)
To: Anantharaman Chetan-W16155; +Cc: linuxppc-embedded
In-Reply-To: <EDF27F298D4B03498AE0C249A941DFF803D70E@de01exm68.ds.mot.com>
My specific problem turned out to be that the serial driver I had
written was still using the physical IO address that I had temporarily
mapped (virtual=physical) during very early boot, and when that
temporary mapping went away I instantly became deaf and dump and it just
happend to go away while starting init.
But for a long time I though I had other problems, so things I tried
included:
Writing a simple "hello world" program and running that from
where the kernel starts init.
I think where the kernel starts init is the first place that
Linux actually starts making use of virtual memory.
I beleive that the way the kernel loads a program involves actually
forcing pagefaults, so alot of things can work, but if paging is not
working perfectly
you will not be able to start another process.
Another thing you should watch out for is that there are two
places Linux looks to start an "init" process.
The first uses whatever might be specified as a commandline
argument (or in your .config, or hardcoded in some BSP's)
If that fails then it starts through a list of potential init
processes until one starts.
I recently had a problem where I wanted to start "/bin/sh" as my
init so I commented out everything else, but left the command line
argument option in and still did not get /bin/sh because it was picking
up the argument from elsewhere.
Anantharaman Chetan-W16155 wrote:
> I've tried what you've mentioned below, i.e removing the /sbin/init and
> just having the /bin/sh in the init/main.c file and I don't get a
> standalone shell. I am having a Linux 2.4 Kernel (Montavista 3.1)
> running on a PPC405 in a Xilinx Virtex4 FX100 FPGA.
>
> You mentioned it could be a hardware problem. Are there any errata which
> could explain the h/w bug?
>
>
> Thanks,
> Chetan Anantharaman
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 11 Jun 2006 22:02:02 -0400
> From: "David H. Lynch Jr." <dhlii@dlasys.net>
> Subject: Re: help with inittab
> Cc: Chris Dumoulin <cdumoulin@ics-ltd.com>,
> linuxppc-embedded@ozlabs.org
> Message-ID: <448CCB1A.409@dlasys.net>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
> For debugging or single user purposes you do not need to run init or
> have an inittab.
> There have been several sugestions that there may be a hardware
> problem - there are a number that are possible.
>
> I was stalled here for some time because my UartDriver was
> accidentally using the physical IO address instead of the virtual one
> and I had created a temporary phys=virtual entry in the tbl that was
> conveniently getting blow away just here.
>
> You can try to isolate your problem by changing your boot ramdisk
> (inramfs or initrd)
>
> Eliminate or rename /init /sbin/init /linuxrc and any of the other
> permutations that linux tries to execute in init/main.c they are all
> listed very near where you stopped.
> make sure you have /bin/sh
>
> reboot on that ramdisk if you have an "init" related problem then
> you should get a standalone shell.
> If you have a hardware problem you will likely still stop at the
> same place.
>
>
>
>
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Init dies with unhandled signal 4
From: David H. Lynch Jr. @ 2006-06-13 21:16 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <528646bc0606121303p35d4955dn60b82dc5fa6c9566@mail.gmail.com>
I am trying to move my Pico E-12 port from 2.6.15 to the current 2.6
from Linus's git tree.
Most everything moved fine, but now "/init" dies with an unhandled
signal 4 which I beleive is an invalid CPU instruction.
I do not have this with 2.6.15 and Linus's tree is obviously more
bleeding edge.
I am just asking whether I should be trying to track down a problem with
my code or if this might be a problem in the git tree.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* RE: MPC5200B SPI PSC3 Problem
From: Trueskew @ 2006-06-13 21:11 UTC (permalink / raw)
To: linuxppc-embedded
Ok, I'm slightly less confused, and since I may have caused confusion I'll
clarify a little here. Sorry if some of you knew this already.
The MPC5200B has an SPI interface described in Chapter 17 of the MPC5200B
Users Guide. It uses either lines PSC3_6 - PSC3_9, or some of the Timer
pins. The MPC5200B also has an SPI available through the PSCs that use the
codec lines (PSC3_0 - PSC3_3). Depending on what rev of the user's guide
you have, there's a table in Chapter 15 that suggests you can set up PSC3
for Codec and SPI. Unfortunately, the SPI they're talking about is the
8-bit SPI, not the PSC3 SPI.
That was the basic source for my confusion. Hints here and in other places
and some parts of the manual suggested, but it was the scope that really
drove that home for me. I won't elaborate anymore here since for all I know
I'm the only person who just figured that out, but if anyone is struggling
like I just did and has any questions, I'm not a guru but I'll try to help.
Good luck.
^ permalink raw reply
* RE: No ttyS device at I/O port 0xfe004500 for console
From: Joakim Tjernlund @ 2006-06-13 21:20 UTC (permalink / raw)
To: 'Alex Zeffertt', linuxppc-embedded
In-Reply-To: <448EEC59.2010201@cambridgebroadband.com>
> -----Original Message-----
> From:
> linuxppc-embedded-bounces+joakim.tjernlund=lumentis.se@ozlabs.
> org
> [mailto:linuxppc-embedded-bounces+joakim.tjernlund=lumentis.se
> @ozlabs.org] On Behalf Of Alex Zeffertt
> Sent: den 13 juni 2006 18:48
> To: linuxppc-embedded@ozlabs.org
> Subject: No ttyS device at I/O port 0xfe004500 for console
>
> Hi list,
>
> I'm trying to boot a linux-2.6.11 kernel on a MPC83xx based
> board. Through some experimentation I have found I need
> "console=uart,io,0xfe004500"
> in the kernel command line in order to get any output over
> the serial port.
Alex, can you post your complete u-boot env(printenv). I am trying to do
the same as you but I havn't gotten any output yet. I managed to wipe my
u-boot & u-boot env and the docs arent that great :(
Jocke
^ permalink raw reply
* Re: OpenFirmware framebuffer
From: David Woodhouse @ 2006-06-13 21:33 UTC (permalink / raw)
To: matt; +Cc: linuxppc-dev
In-Reply-To: <021501c68efd$bc311080$99dfdfdf@bakuhatsu.net>
On Tue, 2006-06-13 at 10:26 -0500, Matt Sealey wrote:
> I just booted up my Pegasos and tried the offb driver for display and was
> rather disappointed. It just displays 4 lines about HID0 and stuff and then
> waits around.
I didn't think the Pegasos firmware supported framebuffer?
--
dwmw2
^ permalink raw reply
* RE: No ttyS device at I/O port 0xfe004500 for console
From: Joakim Tjernlund @ 2006-06-13 21:39 UTC (permalink / raw)
To: 'Chuck Meade', 'Kumar Gala',
'Alex Zeffertt'
Cc: linuxppc-embedded
In-Reply-To: <IIEEICKJLNEPBBDJICNGKEFDLDAA.chuckmeade@mindspring.com>
> >
> > I suspect he got from the same place I did, freescales LTIB
> dev. env.
> > which has been patched to support 832x. I am having the
> same problem
> > as he has, any info on what the problem might be would be great.
> >
> > Also, if anyone has any info on when these patches will be sent
> > upstream, I sure would like to hear about it.
> >
> > Jocke
>
> Hi Joakim,
>
> Same here -- go into arch/ppc/platforms/83xx and edit file
> mpc83xx_sys.c.
> If you are using the 8323e cpu, then you need to make sure
Yes, got one of those.
> that file has code to support the 8323E. Mine didn't, so I
> got no platform devices initialized (no serial port, no Eth
> devs). I added a block of code to support the 8323E (set
> mask to 0xffff0000 and "value" to 0x80620000, then the device
> list for the 8323E). Use existing code there as a guide, it
> was not difficult once I figured out that this was the problem.
hmm, you don't have a patch handy?
>
> If you are using a newer LTIB release than me, perhaps yours is fixed.
> The one I have is from 3/15/06.
Me too, I have requested that freescale release a new LTIB with proper support,
but who knows when the will be.
>
> Anyway, this works fine for me and addresses the problem of
> the platform devs not getting initialized.
>
> Chuck
>
>
>
^ permalink raw reply
* RE: No ttyS device at I/O port 0xfe004500 for console
From: Chuck Meade @ 2006-06-13 21:25 UTC (permalink / raw)
To: Joakim Tjernlund, 'Kumar Gala', 'Alex Zeffertt'
Cc: linuxppc-embedded
In-Reply-To: <000f01c68f2a$68b83960$0e67a8c0@Jocke>
> > On Jun 13, 2006, at 11:48 AM, Alex Zeffertt wrote:
> >
> > > Hi list,
> > >
> > > I'm trying to boot a linux-2.6.11 kernel on a MPC83xx based
> > board.
> > > Through
> > > some experimentation I have found I need
> > "console=uart,io,0xfe004500"
> > > in the kernel command line in order to get any output over
> > the serial
> > > port.
> > >
> > > Half way through initialisation the kernel appears to swap from its
> > > "early"
> > > 8250 serial driver to a "full" 8250 serial driver. At this
> > point it
> > > prints "No ttyS device at I/O port 0xfe004500 for console"
> > and there
> > > is no further output.
> > >
> > > Does anyone have any idea what I may be doing wrong?
> > >
> > > BTW, here's the output that I do get.
> >
> > Alex, where did you get this 2.6.11 kernel? The public tree
> > didn't have support for 83xx in 2.6.11. I'd suggest looking
> > at using something newer like 2.6.16 and see if you have the
> > same issue.
>
> I suspect he got from the same place I did, freescales LTIB dev. env.
> which has been patched to support 832x. I am having the same problem as he
> has, any info on what the problem might be would be great.
>
> Also, if anyone has any info on when these patches will be sent upstream, I
> sure would like to hear about it.
>
> Jocke
Hi Joakim,
Same here -- go into arch/ppc/platforms/83xx and edit file mpc83xx_sys.c.
If you are using the 8323e cpu, then you need to make sure that file has
code to support the 8323E. Mine didn't, so I got no platform devices
initialized (no serial port, no Eth devs). I added a block of code to support
the 8323E (set mask to 0xffff0000 and "value" to 0x80620000, then the
device list for the 8323E). Use existing code there as a guide, it was not
difficult once I figured out that this was the problem.
If you are using a newer LTIB release than me, perhaps yours is fixed.
The one I have is from 3/15/06.
Anyway, this works fine for me and addresses the problem of the platform
devs not getting initialized.
Chuck
^ permalink raw reply
* RE: No ttyS device at I/O port 0xfe004500 for console
From: Chuck Meade @ 2006-06-13 22:01 UTC (permalink / raw)
To: Joakim Tjernlund, 'Kumar Gala', 'Alex Zeffertt'
Cc: linuxppc-embedded
In-Reply-To: <001101c68f31$d89aa220$0e67a8c0@Jocke>
> > Hi Joakim,
> >
> > Same here -- go into arch/ppc/platforms/83xx and edit file
> > mpc83xx_sys.c.
> > If you are using the 8323e cpu, then you need to make sure
>
> Yes, got one of those.
>
> > that file has code to support the 8323E. Mine didn't, so I
> > got no platform devices initialized (no serial port, no Eth
> > devs). I added a block of code to support the 8323E (set
> > mask to 0xffff0000 and "value" to 0x80620000, then the device
> > list for the 8323E). Use existing code there as a guide, it
> > was not difficult once I figured out that this was the problem.
>
> hmm, you don't have a patch handy?
Here you go:
--- mpc83xx_sys.c-ORIG 2006-06-13 17:54:36.577339832 -0400
+++ mpc83xx_sys.c 2006-06-13 17:56:02.394293672 -0400
@@ -136,6 +136,23 @@ struct ppc_sys_spec ppc_sys_specs[] = {
#endif
},
},
+ {
+ .ppc_sys_name = "8323E",
+ .mask = 0xFFFF0000,
+ .value = 0x80620000,
+#ifdef CONFIG_QE
+ .num_devices = 4,
+#else
+ .num_devices = 2,
+#endif
+ .device_list = (enum ppc_sys_devices[])
+ {
+ MPC83xx_IIC1, MPC83xx_DUART,
+#ifdef CONFIG_QE
+ MPC83xx_QE_UCC3, MPC83xx_QE_UCC4,
+#endif
+ },
+ },
{ /* default match */
.ppc_sys_name = "",
.mask = 0x00000000,
Regards,
Chuck
^ permalink raw reply
* Suspend-to-RAM?
From: Guennadi Liakhovetski @ 2006-06-13 22:02 UTC (permalink / raw)
To: Linuxppc-embedded
Hi
Do I understand it right that in the stock 2.6.17-rc... kernels
suspend-to-RAM is not available to any embedded ppc processors / boards?
Only for powermac? Is it for a reason (which one?) or just nobody has done
/ submitted to mainline this?
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: No ttyS device at I/O port 0xfe004500 for console
From: Kumar Gala @ 2006-06-13 22:32 UTC (permalink / raw)
To: Chuck Meade; +Cc: linuxppc-embedded, Joakim Tjernlund
In-Reply-To: <IIEEICKJLNEPBBDJICNGCEFHLDAA.chuckmeade@mindspring.com>
> Here you go:
Let me know if this fixes the issues you guys are seeing with your
83xx boards. If so, I'll clean up this patch and push it upstream.
- k
> --- mpc83xx_sys.c-ORIG 2006-06-13 17:54:36.577339832 -0400
> +++ mpc83xx_sys.c 2006-06-13 17:56:02.394293672 -0400
> @@ -136,6 +136,23 @@ struct ppc_sys_spec ppc_sys_specs[] = {
> #endif
> },
> },
> + {
> + .ppc_sys_name = "8323E",
> + .mask = 0xFFFF0000,
> + .value = 0x80620000,
> +#ifdef CONFIG_QE
> + .num_devices = 4,
> +#else
> + .num_devices = 2,
> +#endif
> + .device_list = (enum ppc_sys_devices[])
> + {
> + MPC83xx_IIC1, MPC83xx_DUART,
> +#ifdef CONFIG_QE
> + MPC83xx_QE_UCC3, MPC83xx_QE_UCC4,
> +#endif
> + },
> + },
> { /* default match */
> .ppc_sys_name = "",
> .mask = 0x00000000,
>
>
> Regards,
> Chuck
>
^ permalink raw reply
* USB flashdrive on Motorola MPC5200 (IceCube) board, linux kernel 2.4.20
From: Furxhi, Orges @ 2006-06-13 22:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 10999 bytes --]
Hi all,
I have been trying for days now to get my usb flashdrive to work on my
Motorola MPC5200 (IceCube) board running on the 2.4.20 linux kernel. I have
followed the instruction in this Flash Memory HOWTO article
(http://www.tldp.org/HOWTO/Flash-Memory-HOWTO/index.html
<http://www.tldp.org/HOWTO/Flash-Memory-HOWTO/index.html> ), but I have had
no success.
When I mount the usbfs filesystem (mount -t usbfs none /proc/bus/usb/) the
following 3 items are created in the /proc/bus/usb/ directory:
dr-xr-xr-x 1 root root 0 Jan 1 00:12 001
-r--r--r-- 1 root root 0 Jan 1 00:12 devices
-r--r--r-- 1 root root 0 Jan 1 00:12 drivers
# cat devices shows:
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2
B: Alloc= 0/900 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 1.10 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 0.00
S: Product=USB OHCI Root Hub
S: SerialNumber=f0001000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=255ms
# cat drivers shows
usbdevfs
hub
usb-storage
In the this Flash Memory-HOWTO it is mentioned that the usb-storage-x
directory will be created in the /proc/scsi/ directory, but I do not see it
on my system. Also the contents of /proc/scsi/scsi are "Attached devices:
none".
Following are my boot up messages:
U-Boot 1.1.4 (Mar 21 2006 - 15:07:57)
CPU: MPC5200 v1.2 at 462 MHz
Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
Board: Motorola MPC5200 (IceCube)
I2C: 85 kHz, ready
DRAM: 64 MB
FLASH: 8 MB
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET
Type "run flash_nfs" to mount root filesystem over NFS
Hit any key to stop autoboot: 0
## Booting image at ff900000 ...
Image Name: Linux-2.4.20_mvl31-lite5200
Created: 2006-06-13 21:40:05 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 989480 Bytes = 966.3 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.20_mvl31-lite5200 (ofurxhi@mdc58503) (gcc version 3.3.1
(Monta
Vista 3.3.1-7.0.13.0500039 2005-01-12)) #11 Tue Jun 13 16:32:09 CDT 2006
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock2 rw rootfstype=jffs2
ip=192.168.0.7:192.
168.0.2:192.168.0.2:255.255.255.0:cpua::off
frequencies: cpu=461995100, bus=131998608, ipb=65999304, pci=32999652
Calibrating delay loop... 307.20 BogoMIPS
Memory: 62460k available (1540k kernel code, 524k data, 240k init, 0k
highmem)
Dentry cache hash table entries: 8192 (order: 4, 65536 bytes)
Inode cache hash table entries: 4096 (order: 3, 32768 bytes)
Mount-cache hash table entries: 1024 (order: 1, 8192 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
POSIX conformance testing by UNIFIX
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 1 of device 00:00.0
PCI: Cannot allocate resource region 1 of device 00:01.0
PCI: Cannot allocate resource region 1 of device 00:02.0
PCI: Cannot allocate resource region 1 of device 00:03.0
PCI: Cannot allocate resource region 1 of device 00:04.0
PCI: Cannot allocate resource region 1 of device 00:05.0
PCI: Cannot allocate resource region 1 of device 00:06.0
PCI: Cannot allocate resource region 1 of device 00:07.0
PCI: Cannot allocate resource region 1 of device 00:08.0
PCI: Cannot allocate resource region 1 of device 00:09.0
PCI: Cannot allocate resource region 1 of device 00:0a.0
PCI: Cannot allocate resource region 1 of device 00:0b.0
PCI: Cannot allocate resource region 1 of device 00:0c.0
PCI: Cannot allocate resource region 1 of device 00:0d.0
PCI: Cannot allocate resource region 1 of device 00:0e.0
PCI: Cannot allocate resource region 1 of device 00:0f.0
PCI: Cannot allocate resource region 1 of device 00:10.0
PCI: Cannot allocate resource region 1 of device 00:11.0
PCI: Cannot allocate resource region 1 of device 00:12.0
PCI: Cannot allocate resource region 1 of device 00:13.0
PCI: Cannot allocate resource region 1 of device 00:14.0
PCI: Cannot allocate resource region 1 of device 00:15.0
PCI: Cannot allocate resource region 1 of device 00:16.0
PCI: Cannot allocate resource region 1 of device 00:17.0
PCI: Cannot allocate resource region 1 of device 00:18.0
PCI: Cannot allocate resource region 1 of device 00:19.0
PCI: Cannot allocate resource region 1 of device 00:1a.0
PCI: Cannot allocate resource region 1 of device 00:1b.0
PCI: Cannot allocate resource region 1 of device 00:1c.0
PCI: Cannot allocate resource region 1 of device 00:1d.0
PCI: Cannot allocate resource region 1 of device 00:1e.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
LSP Revision 52
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
Journalled Block Device driver loaded
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
JFFS version 1.0, (C) 1999, 2000 Axis Communications AB
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis
Communications
AB.
pty: 256 Unix98 ptys configured
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
NO QRY response
cfi_cmdset_0001: Erase suspend on write enabled
Using buffer write method
Icecube flash bank 0: Using static image partition definition
Creating 3 MTD partitions on "Icecube Bank 0":
0x00000000-0x00100000 : "u-boot"
0x00100000-0x00200000 : "kernel"
0x00200000-0x00800000 : "jffs2"
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci.c: USB OHCI at membase 0xf0001000, IRQ 44
usb.c: new USB bus registered, assigned bus number 1
Product: USB OHCI Root Hub
SerialNumber: f0001000
hub.c: USB hub found
hub.c: 2 ports detected
Initializing USB Mass Storage driver...
usb.c: registered new driver usb-storage
USB Mass Storage support registered.
eth0: Phy @ 0x0, type LXT971 (0x001378e2)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
eth0: config: auto-negotiation off, 100HDX, 10HDX.
IP-Config: Complete:
device=eth0, addr=192.168.0.7, mask=255.255.255.0, gw=192.168.0.2,
host=cpua, domain=, nis-domain=(none),
bootserver=192.168.0.2, rootserver=192.168.0.2, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Empty flash at 0x0000fffc ends at 0x00010000
CLEANMARKER node found at 0x00010000, not first node in block (0x00000000)
Empty flash at 0x0002fffc ends at 0x00030000
CLEANMARKER node found at 0x00030000, not first node in block (0x00020000)
Empty flash at 0x0004fffc ends at 0x00050000
CLEANMARKER node found at 0x00050000, not first node in block (0x00040000)
Empty flash at 0x0006fffc ends at 0x00070000
CLEANMARKER node found at 0x00070000, not first node in block (0x00060000)
Empty flash at 0x0008fffc ends at 0x00090000
CLEANMARKER node found at 0x00090000, not first node in block (0x00080000)
Empty flash at 0x000afffc ends at 0x000b0000
CLEANMARKER node found at 0x000b0000, not first node in block (0x000a0000)
Empty flash at 0x000cfffc ends at 0x000d0000
CLEANMARKER node found at 0x000d0000, not first node in block (0x000c0000)
Empty flash at 0x000efffc ends at 0x000f0000
CLEANMARKER node found at 0x000f0000, not first node in block (0x000e0000)
Empty flash at 0x0010fffc ends at 0x00110000
CLEANMARKER node found at 0x00110000, not first node in block (0x00100000)
Empty flash at 0x0012fffc ends at 0x00130000
CLEANMARKER node found at 0x00130000, not first node in block (0x00120000)
Empty flash at 0x0014fffc ends at 0x00150000
CLEANMARKER node found at 0x00150000, not first node in block (0x00140000)
Empty flash at 0x0016fffc ends at 0x00170000
CLEANMARKER node found at 0x00170000, not first node in block (0x00160000)
Empty flash at 0x0018fffc ends at 0x00190000
CLEANMARKER node found at 0x00190000, not first node in block (0x00180000)
Empty flash at 0x001afffc ends at 0x001b0000
CLEANMARKER node found at 0x001b0000, not first node in block (0x001a0000)
Empty flash at 0x001cfffc ends at 0x001d0000
CLEANMARKER node found at 0x001d0000, not first node in block (0x001c0000)
Empty flash at 0x001efffc ends at 0x001f0000
CLEANMARKER node found at 0x001f0000, not first node in block (0x001e0000)
Empty flash at 0x0020fffc ends at 0x00210000
CLEANMARKER node found at 0x00210000, not first node in block (0x00200000)
Empty flash at 0x0022fffc ends at 0x00230000
CLEANMARKER node found at 0x00230000, not first node in block (0x00220000)
Empty flash at 0x0024fffc ends at 0x00250000
CLEANMARKER node found at 0x00250000, not first node in block (0x00240000)
Empty flash at 0x0026fffc ends at 0x00270000
CLEANMARKER node found at 0x00270000, not first node in block (0x00260000)
VFS: Mounted root (jffs2 filesystem).
Mounted devfs on /dev
Freeing unused kernel memory: 240k init
serial console detected. Disabling virtual terminals.
init started: BusyBox v0.60.3 (2004.01.09-22:53+0000) multi-call binary
Initializing iocspi
Warning: loading /lib/modules/iocspim.o will taint the kernel: no license
See http://www.tux.org/lkml/#export-tainted for information about tainted
modu
les
iocspi: release_20060418
iocspi: major 254.
Module iocspim loaded, with warnings
Initializing canspi
Warning: loading /lib/modules/canspim.o will taint the kernel: no license
See http://www.tux.org/lkml/#export-tainted for information about tainted
modu
les
canspi: init_module()
canspi: init_module(): sema_init
canspi: init_module(): register_chrdev
canspi: major 253.
canspi: micro_config()
canspi: micro_config: PSC request_irq failed (0)
canspi: micro_config psc=f0002400 cdm=f0000200 gpio=f0000b00
portcfg=10051004
Module canspim loaded, with warnings
Initializing iocdrv
Warning: loading /lib/modules/iocdrvm.o will taint the kernel: no license
See http://www.tux.org/lkml/#export-tainted for information about tainted
modu
les
iocdrv: release_20060502
iocdrv: major 252.
Module iocdrvm loaded, with warnings
System initialized
MontaVista(R) Linux(R) Professional Edition 3.1
cpua login:
Any help would be highly appreciated.
Thank you,
Orges Furxhi
[-- Attachment #2: Type: text/html, Size: 43615 bytes --]
^ permalink raw reply
* Re: 32 bit userland on G5
From: Paul Mackerras @ 2006-06-13 22:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1150194348.9208.33.camel@johannes>
Johannes Berg writes:
> Since apparently the G5 honours no-execute permissions, shouldn't the 64
> bit kernel set the READ_IMPLIES_EXEC personality flag for 32-bit
> userland?
The elf_read_implies_exec() macro in include/asm-powerpc/elf.h
achieves the same effect, I believe.
Paul.
^ permalink raw reply
* Re: 32 bit userland on G5
From: Paul Mackerras @ 2006-06-13 22:52 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list, Johannes Berg
In-Reply-To: <1150202709.12423.21.camel@hades.cambridge.redhat.com>
David Woodhouse writes:
> Why? Just because older hardware wasn't capable of enforcing the
> permissions, that doesn't mean that we shouldn't enforce them now.
Historically the PPC32 ELF ABI has used an executable PLT, containing
instructions constructed at runtime, located next to the BSS, and
without the corresponding program header entry indicating execute
permission. Alan Modra devised a new way of doing the PLT which
doesn't require it to be executable, but of course it is only used in
programs that have been built since the new method went into the
toolchain (in fact all of the .o files being linked have to have been
compiled with the new method in order for it to be used).
So if you are absolutely sure that every program you will ever want to
run on your kernel has been built with an up-to-date toolchain, you
can turn on enforcement of execute permissions for 32-bit processes.
It would be a "courageous" step (in the Yes Minister sense :) for a
distro to do it, IMHO.
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc-genirq: Use generic_handle_irq()
From: Benjamin Herrenschmidt @ 2006-06-13 23:18 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev list, Ingo Molnar, Thomas Gleixner
In-Reply-To: <1150195883.5618.6.camel@vader.jdub.homelinux.org>
On Tue, 2006-06-13 at 05:51 -0500, Josh Boyer wrote:
> On Tue, 2006-06-13 at 13:47 +1000, Benjamin Herrenschmidt wrote:
> > This patch updates the ppc and powerpc architectures to use the new
> > generic_handle_irq() so that interrupt controllers can be ported to the
> > new genirq layer.
>
> It does? I only see arch/powerpc in the patch. Is arch/ppc hiding
> somewhere else?
>
> And yes, arch/ppc still exists. We can debate that later ;).
arch/ppc uses arch/powerpc/kernel/irq.c
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc-genirq: Use generic_handle_irq()
From: Benjamin Herrenschmidt @ 2006-06-13 23:20 UTC (permalink / raw)
To: Josh Boyer
Cc: linuxppc-dev list, Ingo Molnar, David Woodhouse, Thomas Gleixner
In-Reply-To: <1150202794.29294.5.camel@weaponx.rchland.ibm.com>
On Tue, 2006-06-13 at 07:46 -0500, Josh Boyer wrote:
> On Tue, 2006-06-13 at 13:39 +0100, David Woodhouse wrote:
> > On Tue, 2006-06-13 at 05:51 -0500, Josh Boyer wrote:
> > > It does? I only see arch/powerpc in the patch. Is arch/ppc hiding
> > > somewhere else?
> > >
> > > And yes, arch/ppc still exists. We can debate that later ;).
> >
> > Did a maintainer step forward for it yet?
>
> For arch/ppc? Not that I'm aware of. But that wasn't particularly my
> point. The email says "This patch updates the ppc and powerpc
> architectures..." when it doesn't.
It does, check again :)
Ben.
^ permalink raw reply
* Re: 32 bit userland on G5
From: David Woodhouse @ 2006-06-13 23:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Johannes Berg
In-Reply-To: <17551.16830.186314.247458@cargo.ozlabs.ibm.com>
On Wed, 2006-06-14 at 08:52 +1000, Paul Mackerras wrote:
> Historically the PPC32 ELF ABI has used an executable PLT, containing
> instructions constructed at runtime, located next to the BSS, and
> without the corresponding program header entry indicating execute
> permission. Alan Modra devised a new way of doing the PLT which
> doesn't require it to be executable, but of course it is only used in
> programs that have been built since the new method went into the
> toolchain (in fact all of the .o files being linked have to have been
> compiled with the new method in order for it to be used).
'Historical' being until about 4 years ago, around the time of
http://ecos.sourceware.org/ml/binutils/2002-05/msg00097.html ?
> So if you are absolutely sure that every program you will ever want to
> run on your kernel has been built with an up-to-date toolchain, you
> can turn on enforcement of execute permissions for 32-bit processes.
> It would be a "courageous" step (in the Yes Minister sense :) for a
> distro to do it, IMHO.
We already did it in Fedora. We don't default to READ_IMPLIES_EXEC for
32-bit processes on the 64-bit kernel.
--
dwmw2
^ permalink raw reply
* Re: 32 bit userland on G5
From: Paul Mackerras @ 2006-06-13 23:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list, Johannes Berg
In-Reply-To: <1150241510.11159.159.camel@shinybook.infradead.org>
David Woodhouse writes:
> 'Historical' being until about 4 years ago, around the time of
> http://ecos.sourceware.org/ml/binutils/2002-05/msg00097.html ?
That's not the one I was talking about; that appears to be about
marking the GOT and PLT as executable in the ELF file. That may be
enough in fact to allow us to turn off read-implies-exec, though.
> We already did it in Fedora. We don't default to READ_IMPLIES_EXEC for
> 32-bit processes on the 64-bit kernel.
By patching include/asm-powerpc/elf.h?
Paul.
^ permalink raw reply
* RE: No ttyS device at I/O port 0xfe004500 for console
From: Joakim Tjernlund @ 2006-06-13 23:53 UTC (permalink / raw)
To: 'Chuck Meade', 'Kumar Gala',
'Alex Zeffertt'
Cc: linuxppc-embedded
In-Reply-To: <IIEEICKJLNEPBBDJICNGCEFHLDAA.chuckmeade@mindspring.com>
Hi Chuck
>
> > > Hi Joakim,
> > >
> > > Same here -- go into arch/ppc/platforms/83xx and edit file
> > > mpc83xx_sys.c.
> > > If you are using the 8323e cpu, then you need to make sure
> >
> > Yes, got one of those.
> >
> > > that file has code to support the 8323E. Mine didn't, so
> I got no
> > > platform devices initialized (no serial port, no Eth
> devs). I added
> > > a block of code to support the 8323E (set mask to 0xffff0000 and
> > > "value" to 0x80620000, then the device list for the 8323E). Use
> > > existing code there as a guide, it was not difficult once
> I figured
> > > out that this was the problem.
> >
> > hmm, you don't have a patch handy?
>
> Here you go:
Thanks, now it boot into the ramdisk and a get a login prompt and all, but I don't
see any output during kernel startup(only a few garbage chars).
Tried the console params Alex sent but makes no difference. How does
your cmdline look like?
^ permalink raw reply
* RE: OpenFirmware framebuffer
From: Benjamin Herrenschmidt @ 2006-06-13 23:53 UTC (permalink / raw)
To: matt; +Cc: linuxppc-dev, 'Nathan Lynch'
In-Reply-To: <024901c68f06$4aa71f00$99dfdfdf@bakuhatsu.net>
On Tue, 2006-06-13 at 11:27 -0500, Matt Sealey wrote:
> Gentoo 2.6.15-r5 from the 2006.0 install CD.
>
> It says "Welcome to Linux gentoo-2.6.15-r5" and then I see four
> lines, MSR, HID0 and hex printout of each.
>
> That's it.
>
> I get the usual messages spooled to the serial console. My args are;
>
> boot cd /boot/pegasos console=ttyS1,115200,8n1 console=tty0 init=/linuxrc looptype=squashfs loop=/image.squashfs udev nodevfs cdroot
> root=/dev/ram0 video=ofonly
Send us a copy of your dmesg log. Also, does the pegasos firmware
creates a "display" node in OF with the right type and properties ?
Ben.
^ permalink raw reply
* Re: 32 bit userland on G5
From: David Woodhouse @ 2006-06-14 0:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Johannes Berg
In-Reply-To: <17551.20066.365036.256580@cargo.ozlabs.ibm.com>
On Wed, 2006-06-14 at 09:46 +1000, Paul Mackerras wrote:
> > We already did it in Fedora. We don't default to READ_IMPLIES_EXEC
> > for 32-bit processes on the 64-bit kernel.
>
> By patching include/asm-powerpc/elf.h?
By patching fs/binfmt_elf.c -- it's part of the exec-shield patch.
http://cvs.fedora.redhat.com/viewcvs/devel/kernel/linux-2.6-execshield.patch?rev=1.20&view=auto
shinybook /home/dwmw2 $ cat foo.c
int foo[2] = { 0x3860005a, 0x4e800020 };
int main(void)
{
int (*foofn)(void) = (void *)foo;
int f = foofn();
printf("%x\n", f);
}
shinybook /home/dwmw2 $ ./foo
5a
shinybook /home/dwmw2 $ scp foo pmac: ; ssh pmac
foo 100% 9996 9.8KB/s
00:00
Last login: Wed Jun 14 00:58:26 2006 from shinybook-bcm.infradead.org
pmac /home/dwmw2 $ ./foo
Segmentation fault
pmac /home/dwmw2 $ setarch ppc -X ./foo
5a
--
dwmw2
^ permalink raw reply
* RE: No ttyS device at I/O port 0xfe004500 for console
From: Joakim Tjernlund @ 2006-06-14 0:19 UTC (permalink / raw)
To: 'Chuck Meade', 'Kumar Gala',
'Alex Zeffertt'
Cc: linuxppc-embedded
In-Reply-To: <001201c68f44$962c1fa0$0e67a8c0@Jocke>
>
> Hi Chuck
>
> >
> > > > Hi Joakim,
> > > >
> > > > Same here -- go into arch/ppc/platforms/83xx and edit file
> > > > mpc83xx_sys.c.
> > > > If you are using the 8323e cpu, then you need to make sure
> > >
> > > Yes, got one of those.
> > >
> > > > that file has code to support the 8323E. Mine didn't, so
> > I got no
> > > > platform devices initialized (no serial port, no Eth
> > devs). I added
> > > > a block of code to support the 8323E (set mask to
> 0xffff0000 and
> > > > "value" to 0x80620000, then the device list for the
> 8323E). Use
> > > > existing code there as a guide, it was not difficult once
> > I figured
> > > > out that this was the problem.
> > >
> > > hmm, you don't have a patch handy?
> >
> > Here you go:
>
> Thanks, now it boot into the ramdisk and a get a login prompt
> and all, but I don't see any output during kernel
> startup(only a few garbage chars).
> Tried the console params Alex sent but makes no difference.
> How does your cmdline look like?
ahem, I forgot the obvious console=ttyS0. Now it works, thanks a lot
Jocke
^ permalink raw reply
* Re: [PATCH] powerpc-genirq: Use generic_handle_irq()
From: Josh Boyer @ 2006-06-14 0:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Ingo Molnar, David Woodhouse, Thomas Gleixner
In-Reply-To: <1150240803.13958.66.camel@localhost.localdomain>
On Wed, 2006-06-14 at 09:20 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2006-06-13 at 07:46 -0500, Josh Boyer wrote:
> > On Tue, 2006-06-13 at 13:39 +0100, David Woodhouse wrote:
> > > On Tue, 2006-06-13 at 05:51 -0500, Josh Boyer wrote:
> > > > It does? I only see arch/powerpc in the patch. Is arch/ppc hiding
> > > > somewhere else?
> > > >
> > > > And yes, arch/ppc still exists. We can debate that later ;).
> > >
> > > Did a maintainer step forward for it yet?
> >
> > For arch/ppc? Not that I'm aware of. But that wasn't particularly my
> > point. The email says "This patch updates the ppc and powerpc
> > architectures..." when it doesn't.
>
> It does, check again :)
Ugh. Today is not my day apparently. Sorry for the noise.
josh
^ permalink raw reply
* [PATCH] powerpc: Adding the use of the firmware soft-reset-nmi to kdump.
From: David Wilder @ 2006-06-14 1:58 UTC (permalink / raw)
To: linuxppc-dev, fastboot, paulus, akpm, Haren Myneni
[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]
-I am reposting this patch based on comments from Paul Mackerras and
Michael Ellerman requesting updated documentation.
-This patch is build against 2.6.17-rc6-git5 with the following patch
applied first.
http://lists.osdl.org/pipermail/fastboot/2006-May/002947.html
The above patch must be applied first to prevent a collision in
include/linux/kexec.h
-My patch includes mostly powerpc specific changes plus a small generic
change in kernel/kexec.h
- Patch Description
With this patch, kdump uses the firmware soft-rest NMI for two purposes:
1) Initiate the kdump (take a crash dump) by issuing a soft-reset.
2) Break a CPU out of a deadlock condition that is detected during kdump
processing.
When a soft-reset is initiated each CPU will enter
system_reset_exception() and set its corresponding bit in the global
bit-array cpus_in_sr then call die(). When die() finds the CPU’s bit set
in cpu_in_sr crash_kexec() is called to initiate a crash dump. The first
CPU to enter crash_kexec() is called the “crashing CPU”. All other CPUs
are “secondary CPUs”. The secondary CPU’s pass through to
crash_kexec_secondary() and sleep. The crashing CPU waits for all CPUs
to enter via soft-reset then boots the kdump kernel (see
crash_soft_reset_check())
When the system crashes due to a panic or exception, crash_kexec() is
called by panic() or die(). The crashing CPU sends an IPI to all other
CPUs to notify them of the pending shutdown. If a CPU is in a deadlock
or hung state with interrupts disabled, the IPI will not be delivered.
The result being, that the kdump kernel is not booted. This problem is
solved with the use of a firmware generated soft-reset. After the
crashing_cpu has issued the IPI, it waits for 10 sec for all CPUs to
enter crash_ipi_callback(). A CPU signifies its entry to
crash_ipi_callback() by setting its corresponding bit in the
cpus_in_crash bit array. After 10 sec, if one or more CPUs have not set
their bit in cpus_in_crash we assume that the CPU(s) is deadlocked. The
operator is then prompted to generate a soft-reset to break the
deadlock. Each CPU enters the soft reset handler as described above.
Two conditions must be handled at this point:
1) The system crashed because the operator generated a soft-reset. See
#1 above.
2) The system had crashed before the soft-reset was generated ( in the
case of a Panic or oops…).
The first CPU to enter crash_kexec() uses the state of the kexec_lock to
determine this state. If kexec_lock is already held then condition 2 is
true and crash_kexec_secondary() is called, else; this CPU is flagged as
the crashing CPU, the kexec_lock is acquired and crash_kexec() proceeds
as described above.
Each additional CPUs responding to the soft-reset will pass through
crash_kexec() to kexec_secondary(). All secondary CPUs call
crash_ipi_callback() readying them self's for the shutdown. When ready
they clear their bit in cpus_in_sr. The crashing CPU waits in
kexec_secondary() until all other CPUs have cleared their bits in
cpus_in_sr. The kexec kernel boot is then started.
Signed-off-by: Haren Myneni <haren@us.ibm.com>
Signed-off-by: David Wilder <dwilder@us.ibm.com>
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
[-- Attachment #2: ppc64-softreset-in-k-dump-2.6.17-rc6-git5.patch --]
[-- Type: text/x-patch, Size: 10352 bytes --]
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 778f22f..d84ca6b 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -23,9 +23,11 @@
#include <linux/elfcore.h>
#include <linux/init.h>
#include <linux/types.h>
+#include <linux/irq.h>
#include <asm/processor.h>
#include <asm/machdep.h>
+#include <asm/kexec.h>
#include <asm/kdump.h>
#include <asm/lmb.h>
#include <asm/firmware.h>
@@ -40,6 +42,7 @@
/* This keeps a track of which one is crashing cpu. */
int crashing_cpu = -1;
+static cpumask_t cpus_in_crash = CPU_MASK_NONE;
static u32 *append_elf_note(u32 *buf, char *name, unsigned type, void *data,
size_t data_len)
@@ -97,34 +100,66 @@ static void crash_save_this_cpu(struct p
}
#ifdef CONFIG_SMP
-static atomic_t waiting_for_crash_ipi;
+static atomic_t enter_on_soft_reset = ATOMIC_INIT(0);
void crash_ipi_callback(struct pt_regs *regs)
{
int cpu = smp_processor_id();
- if (cpu == crashing_cpu)
- return;
-
if (!cpu_online(cpu))
return;
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(1, 1);
-
local_irq_disable();
+ if (!cpu_isset(cpu, cpus_in_crash))
+ crash_save_this_cpu(regs, cpu);
+ cpu_set(cpu, cpus_in_crash);
- crash_save_this_cpu(regs, cpu);
- atomic_dec(&waiting_for_crash_ipi);
+ /*
+ * Entered via soft-reset - could be the kdump
+ * process is invoked using soft-reset or user activated
+ * it if some CPU did not respond to an IPI.
+ * For soft-reset, the secondary CPU can enter this func
+ * twice. 1 - using IPI, and 2. soft-reset.
+ * Tell the kexec CPU that entered via soft-reset and ready
+ * to go down.
+ */
+ if (cpu_isset(cpu, cpus_in_sr)) {
+ cpu_clear(cpu, cpus_in_sr);
+ atomic_inc(&enter_on_soft_reset);
+ }
+
+ /*
+ * Starting the kdump boot.
+ * This barrier is needed to make sure that all CPUs are stopped.
+ * If not, soft-reset will be invoked to bring other CPUs.
+ */
+ while (!cpu_isset(crashing_cpu, cpus_in_crash))
+ cpu_relax();
+
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 1);
kexec_smp_wait();
/* NOTREACHED */
}
-static void crash_kexec_prepare_cpus(void)
+/*
+ * Wait until all CPUs are entered via soft-reset.
+ */
+static void crash_soft_reset_check(int cpu)
+{
+ unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
+
+ cpu_clear(cpu, cpus_in_sr);
+ while (atomic_read(&enter_on_soft_reset) != ncpus)
+ cpu_relax();
+}
+
+
+static void crash_kexec_prepare_cpus(int cpu)
{
unsigned int msecs;
- atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
+ unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
crash_send_ipi(crash_ipi_callback);
smp_wmb();
@@ -132,14 +167,13 @@ static void crash_kexec_prepare_cpus(voi
/*
* FIXME: Until we will have the way to stop other CPUSs reliabally,
* the crash CPU will send an IPI and wait for other CPUs to
- * respond. If not, proceed the kexec boot even though we failed to
- * capture other CPU states.
+ * respond.
* Delay of at least 10 seconds.
*/
- printk(KERN_ALERT "Sending IPI to other cpus...\n");
+ printk(KERN_EMERG "Sending IPI to other cpus...\n");
msecs = 10000;
- while ((atomic_read(&waiting_for_crash_ipi) > 0) && (--msecs > 0)) {
- barrier();
+ while ((cpus_weight(cpus_in_crash) < ncpus) && (--msecs > 0)) {
+ cpu_relax();
mdelay(1);
}
@@ -148,18 +182,71 @@ static void crash_kexec_prepare_cpus(voi
/*
* FIXME: In case if we do not get all CPUs, one possibility: ask the
* user to do soft reset such that we get all.
- * IPI handler is already set by the panic cpu initially. Therefore,
- * all cpus could invoke this handler from die() and the panic CPU
- * will call machine_kexec() directly from this handler to do
- * kexec boot.
- */
- if (atomic_read(&waiting_for_crash_ipi))
- printk(KERN_ALERT "done waiting: %d cpus not responding\n",
- atomic_read(&waiting_for_crash_ipi));
+ * Soft-reset will be used until better mechanism is implemented.
+ */
+ if (cpus_weight(cpus_in_crash) < ncpus) {
+ printk(KERN_EMERG "done waiting: %d cpu(s) not responding\n",
+ ncpus - cpus_weight(cpus_in_crash));
+ printk(KERN_EMERG "Activate soft-reset to stop other cpu(s)\n");
+ cpus_in_sr = CPU_MASK_NONE;
+ atomic_set(&enter_on_soft_reset, 0);
+ while (cpus_weight(cpus_in_crash) < ncpus)
+ cpu_relax();
+ }
+ /*
+ * Make sure all CPUs are entered via soft-reset if the kdump is
+ * invoked using soft-reset.
+ */
+ if (cpu_isset(cpu, cpus_in_sr))
+ crash_soft_reset_check(cpu);
/* Leave the IPI callback set */
}
+
+/*
+ * This function will be called by secondary cpus or by kexec cpu
+ * if soft-reset is activated to stop some CPUs.
+ */
+void crash_kexec_secondary(struct pt_regs *regs)
+{
+ int cpu = smp_processor_id();
+ unsigned long flags;
+ int msecs = 5;
+
+ local_irq_save(flags);
+ /* Wait 5ms if the kexec CPU is not entered yet. */
+ while (crashing_cpu < 0) {
+ if (--msecs < 0) {
+ /*
+ * Either kdump image is not loaded or
+ * kdump process is not started - Probably xmon
+ * exited using 'x'(exit and recover) or
+ * kexec_should_crash() failed for all running tasks.
+ */
+ cpu_clear(cpu, cpus_in_sr);
+ local_irq_restore(flags);
+ return;
+ }
+ mdelay(1);
+ cpu_relax();
+ }
+ if (cpu == crashing_cpu) {
+ /*
+ * Panic CPU will enter this func only via soft-reset.
+ * Wait until all secondary CPUs entered and
+ * then start kexec boot.
+ */
+ crash_soft_reset_check(cpu);
+ cpu_set(crashing_cpu, cpus_in_crash);
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 0);
+ machine_kexec(kexec_crash_image);
+ /* NOTREACHED */
+ }
+ crash_ipi_callback(regs);
+}
+
#else
-static void crash_kexec_prepare_cpus(void)
+static void crash_kexec_prepare_cpus(int cpu)
{
/*
* move the secondarys to us so that we can copy
@@ -170,6 +257,10 @@ static void crash_kexec_prepare_cpus(voi
smp_release_cpus();
}
+void crash_kexec_secondary(struct pt_regs *regs)
+{
+ cpus_in_sr = CPU_MASK_NONE;
+}
#endif
void default_machine_crash_shutdown(struct pt_regs *regs)
@@ -186,14 +277,14 @@ void default_machine_crash_shutdown(stru
*/
local_irq_disable();
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(1, 0);
-
/*
* Make a note of crashing cpu. Will be used in machine_kexec
* such that another IPI will not be sent.
*/
crashing_cpu = smp_processor_id();
- crash_kexec_prepare_cpus();
crash_save_this_cpu(regs, crashing_cpu);
+ crash_kexec_prepare_cpus(crashing_cpu);
+ cpu_set(crashing_cpu, cpus_in_crash);
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(1, 0);
}
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 064a525..d3c6402 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -51,9 +51,13 @@
#include <asm/firmware.h>
#include <asm/processor.h>
#endif
+#include <asm/kexec.h>
#ifdef CONFIG_PPC64 /* XXX */
#define _IO_BASE pci_io_base
+#ifdef CONFIG_KEXEC
+cpumask_t cpus_in_sr = CPU_MASK_NONE;
+#endif
#endif
#ifdef CONFIG_DEBUGGER
@@ -96,7 +100,7 @@ static DEFINE_SPINLOCK(die_lock);
int die(const char *str, struct pt_regs *regs, long err)
{
- static int die_counter, crash_dump_start = 0;
+ static int die_counter;
if (debugger(regs))
return 1;
@@ -128,22 +132,13 @@ int die(const char *str, struct pt_regs
print_modules();
show_regs(regs);
bust_spinlocks(0);
-
- if (!crash_dump_start && kexec_should_crash(current)) {
- crash_dump_start = 1;
- spin_unlock_irq(&die_lock);
- crash_kexec(regs);
- /* NOTREACHED */
- }
spin_unlock_irq(&die_lock);
- if (crash_dump_start)
- /*
- * Only for soft-reset: Other CPUs will be responded to an IPI
- * sent by first kexec CPU.
- */
- for(;;)
- ;
+ if (kexec_should_crash(current) ||
+ kexec_sr_activated(smp_processor_id()))
+ crash_kexec(regs);
+ crash_kexec_secondary(regs);
+
if (in_interrupt())
panic("Fatal exception in interrupt");
@@ -205,6 +200,10 @@ void system_reset_exception(struct pt_re
if (ppc_md.system_reset_exception(regs))
return;
}
+
+#ifdef CONFIG_KEXEC
+ cpu_set(smp_processor_id(), cpus_in_sr);
+#endif
die("System Reset", regs, SIGABRT);
diff --git a/include/asm-powerpc/kexec.h b/include/asm-powerpc/kexec.h
index 6a2af2f..2a35215 100644
--- a/include/asm-powerpc/kexec.h
+++ b/include/asm-powerpc/kexec.h
@@ -31,9 +31,9 @@
#define KEXEC_ARCH KEXEC_ARCH_PPC
#endif
+#ifndef __ASSEMBLY__
#ifdef CONFIG_KEXEC
-#ifndef __ASSEMBLY__
#ifdef __powerpc64__
/*
* This function is responsible for capturing register states if coming
@@ -114,6 +114,11 @@ extern void kexec_smp_wait(void); /* get
extern void __init kexec_setup(void);
extern int crashing_cpu;
extern void crash_send_ipi(void (*crash_ipi_callback)(struct pt_regs *));
+extern cpumask_t cpus_in_sr;
+static inline int kexec_sr_activated(int cpu)
+{
+ return cpu_isset(cpu,cpus_in_sr);
+}
#endif /* __powerpc64 __ */
struct kimage;
@@ -123,8 +128,15 @@ extern int default_machine_kexec_prepare
extern void default_machine_crash_shutdown(struct pt_regs *regs);
extern void machine_kexec_simple(struct kimage *image);
+extern void crash_kexec_secondary(struct pt_regs *regs);
+extern int overlaps_crashkernel(unsigned long start, unsigned long size);
+extern void reserve_crashkernel(void);
+
+#else /* !CONFIG_KEXEC */
+static inline int kexec_sr_activated(int cpu) { return 0; }
+static inline void crash_kexec_secondary(struct pt_regs *regs) { }
-#endif /* ! __ASSEMBLY__ */
#endif /* CONFIG_KEXEC */
+#endif /* ! __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_KEXEC_H */
diff --git a/kernel/kexec.c b/kernel/kexec.c
index f99d69c..950559d 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1042,7 +1042,6 @@ asmlinkage long compat_sys_kexec_load(un
void crash_kexec(struct pt_regs *regs)
{
- struct kimage *image;
int locked;
@@ -1056,12 +1055,11 @@ void crash_kexec(struct pt_regs *regs)
*/
locked = xchg(&kexec_lock, 1);
if (!locked) {
- image = xchg(&kexec_crash_image, NULL);
- if (image) {
+ if (kexec_crash_image) {
struct pt_regs fixed_regs;
crash_setup_regs(&fixed_regs, regs);
machine_crash_shutdown(&fixed_regs);
- machine_kexec(image);
+ machine_kexec(kexec_crash_image);
}
xchg(&kexec_lock, 0);
}
^ permalink raw reply related
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