* 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: 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
* 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: 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
* 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: 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
* smc2 without hw handshake
From: Antonio Di Bacco @ 2006-06-13 19:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I'm using the SMC2 serial device of MPC880 without using hardware handshake. I
use only tx and rx at a speed of 9600. Could it work? The driver I use is
included in linux 2.4.25 from denx.
Bye,
Antonio.
^ permalink raw reply
* No ttyS device at I/O port 0xfe004500 for console
From: Alex Zeffertt @ 2006-06-13 16:48 UTC (permalink / raw)
To: linuxppc-embedded
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.
-------------------/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
^ permalink raw reply
* Re: [PATCH] Compile failure fix for ppc on 2.6.17-rc4-mm3 (2nd attempt)
From: Mel Gorman @ 2006-06-13 16:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Andrew Morton, linuxppc-dev, vgoyal, linux-kernel
In-Reply-To: <17545.16696.195276.334774@cargo.ozlabs.ibm.com>
On (09/06/06 19:36), Paul Mackerras didst pronounce:
> Mel Gorman writes:
>
> > + res->end = -(-res->end & ~(unsigned long)mask); \
> > + res->end += mask; \
>
> I think this is equivalent to
>
> res->end = (res->end + mask) | mask;
>
> and I have to say the latter seems more understandable to me (and
> doesn't need a cast) ...
>
Makes sense. The patch on top of the latest -mm is below if you want to push
it. It has not been boot tested as building with the latest -mm is broken
at the moment for older powerpcs because of the git-powerpc.patch patch .
That patch assumes that mm_context_t is a struct with a vdso_base which is
not always the case (it's an unsigned long in include/asm-ppc/mmu.h).
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.17-rc6-mm2-clean/arch/powerpc/kernel/pci_32.c linux-2.6.17-rc6-mm2-resources/arch/powerpc/kernel/pci_32.c
--- linux-2.6.17-rc6-mm2-clean/arch/powerpc/kernel/pci_32.c 2006-06-13 17:25:39.000000000 +0100
+++ linux-2.6.17-rc6-mm2-resources/arch/powerpc/kernel/pci_32.c 2006-06-13 17:30:20.000000000 +0100
@@ -1121,9 +1121,8 @@ check_for_io_childs(struct pci_bus *bus,
* e.g. res->end of 0x1fff moves to 0x2fff
*/
#define push_end(res, mask) do { \
- BUG_ON(((mask+1) & mask) != 0); \
- res->end = -(-res->end & ~(unsigned long)mask); \
- res->end += mask; \
+ BUG_ON(((mask+1) & mask) != 0); \
+ res->end = (res->end + mask) | mask; \
} while (0)
list_for_each_entry(dev, &bus->devices, bus_list) {
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* RE: OpenFirmware framebuffer
From: Matt Sealey @ 2006-06-13 16:27 UTC (permalink / raw)
To: 'Nathan Lynch'; +Cc: linuxppc-dev
In-Reply-To: <20060613161115.GB26750@localdomain>
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
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
> -----Original Message-----
> From: Nathan Lynch [mailto:ntl@pobox.com]
> Sent: Tuesday, June 13, 2006 11:11 AM
> To: Matt Sealey
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: OpenFirmware framebuffer
>
> 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.
> >
> > Is this all there is? Is there nothing more? Can't I get a
> scrolling
> > kernel output, and a penguin logo or am I missing the point? :)
>
> Maybe someone can help if you give more details, e.g. the
> kernel version, and exactly what messages are displayed
> before it hangs.
>
>
^ permalink raw reply
* Re: help with inittab
From: Anantharaman Chetan-W16155 @ 2006-06-13 16:26 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <mailman.9.1150164003.18626.linuxppc-embedded@ozlabs.org>
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?=20
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=3DISO-8859-1
=20
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=3Dvirtual 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.
=20
--=20
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: 32 bit userland on G5
From: Johannes Berg @ 2006-06-13 16:18 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list
In-Reply-To: <1150215340.2844.33.camel@hades.cambridge.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 278 bytes --]
On Tue, 2006-06-13 at 17:15 +0100, David Woodhouse wrote:
> Nah. It isn't a valid assumption; just as it isn't valid to assume that
> your stack will _always_ be at about 0xbfffffff.
Ok.
Just curious though: Why does READ_IMPLIES_EXEC exist at all then?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: 32 bit userland on G5
From: David Woodhouse @ 2006-06-13 16:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1150214746.6305.3.camel@johannes>
On Tue, 2006-06-13 at 18:05 +0200, Johannes Berg wrote:
> Yeah, I was just thinking that there are programs relying on that and if
> they run in the 32-bit compat mode they might rightfully do so... Dunno.
Nah. It isn't a valid assumption; just as it isn't valid to assume that
your stack will _always_ be at about 0xbfffffff.
--
dwmw2
^ permalink raw reply
* Re: OpenFirmware framebuffer
From: Nathan Lynch @ 2006-06-13 16:11 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev
In-Reply-To: <021501c68efd$bc311080$99dfdfdf@bakuhatsu.net>
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.
>
> Is this all there is? Is there nothing more? Can't I get a scrolling kernel
> output, and a penguin logo or am I missing the point? :)
Maybe someone can help if you give more details, e.g. the kernel
version, and exactly what messages are displayed before it hangs.
^ permalink raw reply
* OpenFirmware framebuffer
From: Matt Sealey @ 2006-06-13 15:26 UTC (permalink / raw)
To: linuxppc-dev
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.
Is this all there is? Is there nothing more? Can't I get a scrolling kernel
output, and a penguin logo or am I missing the point? :)
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* [PATCH] make pmf irq_client functions safe against pmf interrupts coming in
From: Johannes Berg @ 2006-06-13 15:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Andrew Morton, linuxppc-dev list
In-Reply-To: <1150192713.13958.52.camel@localhost.localdomain>
This fixes the pmf irq_client functions to be safe against pmf interrupts coming
in while a client is registered/unregistered.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
--- linux-2.6-git.orig/arch/powerpc/platforms/powermac/pfunc_core.c 2006-06-13 17:37:35.791076087 +0200
+++ linux-2.6-git/arch/powerpc/platforms/powermac/pfunc_core.c 2006-06-13 17:40:16.213632271 +0200
@@ -871,10 +871,17 @@ int pmf_register_irq_client(struct devic
spin_unlock_irqrestore(&pmf_lock, flags);
if (func == NULL)
return -ENODEV;
+
+ /* guard against manipulations of list */
mutex_lock(&pmf_irq_mutex);
if (list_empty(&func->irq_clients))
func->dev->handlers->irq_enable(func);
+
+ /* guard against pmf_do_irq while changing list */
+ spin_lock_irqsave(&pmf_lock, flags);
list_add(&client->link, &func->irq_clients);
+ spin_unlock_irqrestore(&pmf_lock, flags);
+
client->func = func;
mutex_unlock(&pmf_irq_mutex);
@@ -885,12 +892,19 @@ EXPORT_SYMBOL_GPL(pmf_register_irq_clien
void pmf_unregister_irq_client(struct pmf_irq_client *client)
{
struct pmf_function *func = client->func;
+ unsigned long flags;
BUG_ON(func == NULL);
+ /* guard against manipulations of list */
mutex_lock(&pmf_irq_mutex);
client->func = NULL;
+
+ /* guard against pmf_do_irq while changing list */
+ spin_lock_irqsave(&pmf_lock, flags);
list_del(&client->link);
+ spin_unlock_irqrestore(&pmf_lock, flags);
+
if (list_empty(&func->irq_clients))
func->dev->handlers->irq_disable(func);
mutex_unlock(&pmf_irq_mutex);
^ permalink raw reply
* Re: 32 bit userland on G5
From: Johannes Berg @ 2006-06-13 16:05 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev list
In-Reply-To: <1150202709.12423.21.camel@hades.cambridge.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]
On Tue, 2006-06-13 at 13:45 +0100, David Woodhouse wrote:
> Why? Just because older hardware wasn't capable of enforcing the
> permissions, that doesn't mean that we shouldn't enforce them now.
Yeah, I was just thinking that there are programs relying on that and if
they run in the 32-bit compat mode they might rightfully do so... Dunno.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc-genirq: Use generic_handle_irq()
From: Josh Boyer @ 2006-06-13 12:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: Ingo Molnar, Thomas Gleixner, linuxppc-dev list
In-Reply-To: <1150202394.12423.16.camel@hades.cambridge.redhat.com>
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.
I think most agree that arch/ppc needs to die via a complete migration
to arch/powerpc. But patches shouldn't claim to do something they
don't :).
josh
^ permalink raw reply
* Re: windfarm for PM72/PM73/RM31
From: Étienne Bersac @ 2006-06-13 12:46 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: linuxppc-dev
In-Reply-To: <20060502001306.GA9589@curie-int.vc.shawcable.net>
Hello,
> The PID params portion will come together a bit later, please bug me by
> Wednesday next week if I haven't posted anything.
I'll get back my iMac G5 rev C in the next hours. So i'll be able to
test code. Have done some work about windfarm ?
Regards.
Étienne.
--
Verso l'Alto !
^ permalink raw reply
* Re: 32 bit userland on G5
From: David Woodhouse @ 2006-06-13 12:45 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev list
In-Reply-To: <1150194348.9208.33.camel@johannes>
On Tue, 2006-06-13 at 12:25 +0200, Johannes Berg wrote:
> 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?
Why? Just because older hardware wasn't capable of enforcing the
permissions, that doesn't mean that we shouldn't enforce them now.
--
dwmw2
^ permalink raw reply
* Re: [PATCH] powerpc-genirq: Use generic_handle_irq()
From: David Woodhouse @ 2006-06-13 12:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: Ingo Molnar, Thomas Gleixner, linuxppc-dev list
In-Reply-To: <1150195883.5618.6.camel@vader.jdub.homelinux.org>
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?
--
dwmw2
^ permalink raw reply
* Re: [PATCH] powerpc-genirq: Use generic_handle_irq()
From: Josh Boyer @ 2006-06-13 10:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Ingo Molnar, Thomas Gleixner
In-Reply-To: <1150170472.13958.13.camel@localhost.localdomain>
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 ;).
josh
^ permalink raw reply
* Re: [PATCH] Fix builtin command line interaction with firmware
From: Segher Boessenkool @ 2006-06-13 10:45 UTC (permalink / raw)
To: Amos Waterland; +Cc: linuxppc-dev
In-Reply-To: <20060613034502.GA15130@kvasir.watson.ibm.com>
> It seems that prom_init's early_cmdline_parse is broken on at least
> Apple 970 xserves and IBM JS20 blades with SLOF. The firmware of
> these
> machines returns -1 and 1 respectively when getprop is called for the
> bootargs property of /chosen, causing Linux to ignore its builtin
> command line in favor of a null string. This patch makes Linux use
> its
> builtin command line if getprop returns an error or a null string.
If the user gave no boot arguments on the boot command, -1 and 1
are the only two valid return values even, and -1 is only valid
if no "boot" or "load" command was used to load the kernel.
Makes me wonder what those XServe's do ;-)
(0 isn't valid as the property is encoded with encode-string, which
puts a trailing 0 byte on the empty string. Doesn't hurt to check
for it anyway of course ;-) ).
> Signed-off-by: Amos Waterland <apw@us.ibm.com>
Looks good, thanks!
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
>
> ---
>
> arch/powerpc/kernel/prom_init.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> 0f0caf0342f39b4437dcb3e9f2f1d62bfb4e3e7d
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/
> prom_init.c
> index f70bd09..2e63a90 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -574,7 +574,7 @@ static void __init early_cmdline_parse(v
> if ((long)_prom->chosen > 0)
> l = prom_getprop(_prom->chosen, "bootargs", p,
> COMMAND_LINE_SIZE-1);
> #ifdef CONFIG_CMDLINE
> - if (l == 0) /* dbl check */
> + if (l <= 0 || p[0] == '\0') /* dbl check */
> strlcpy(RELOC(prom_cmd_line),
> RELOC(CONFIG_CMDLINE), sizeof(prom_cmd_line));
> #endif /* CONFIG_CMDLINE */
> --
> 1.0.4
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* 32 bit userland on G5
From: Johannes Berg @ 2006-06-13 10:25 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
Hi,
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 memory being execute-protected is causing a mono bug
(http://bugzilla.ximian.com/show_bug.cgi?id=77028) but I'm not sure
where the correct fix would be, currently the kernel doesn't seem to be
behaving exactly the same on G4 and G5.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]
^ permalink raw reply
* Re: pmf_register_irq_client gives sleep with locks held warning
From: Benjamin Herrenschmidt @ 2006-06-13 9:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: Andrew Morton, linuxppc-dev list
In-Reply-To: <1150188199.9208.7.camel@johannes>
> I see your patch is in, I'll make a patch that fixes it then instead of
> replacing it, I guess.
Please do, thanks.
Ben.
^ 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