* Re: CPM2 USB host driver
From: Vitaly Bordug @ 2007-11-30 13:00 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, mike
In-Reply-To: <20071130124801.GA13141@localhost.localdomain>
On Fri, 30 Nov 2007 15:48:01 +0300
Anton Vorontsov wrote:
> On Fri, Nov 30, 2007 at 01:30:18PM +0100, Laurent Pinchart wrote:
> > On Friday 30 November 2007 12:16, Vitaly Bordug wrote:
> > > On Fri, 30 Nov 2007 11:45:49 +0100
> > >
> > > Laurent Pinchart wrote:
> > > > Hi everybody,
> > > >
> > > > Linux USB host support for the CPM, CPM2 and CPM2 pro is far
> > > > from complete. Many people showed interest on this list (and on
> > > > linuxppc-embedded) in the past, but nobody managed to complete a
> > > > driver and get it merged.
> > >
> > > that is mainly because of its semi-software nature. However, any
> > > approach would be helpful I beleive.
> >=20
> > The CPM/CPM2 USB host controller does indeed put some pressure on
> > the CPU. The PowerQuick III family is much better in that respect
> > as its USB host controller is EHCI compliant.
>=20
> I didn't yet compare with CPM/CPM2, but I wonder if PQIIPro (MPC8360E)
> USB controller is similar to cpms?..
>
=46rom what I recall, it is similar, but ucc usb should work fine,
at least according to RM it does all the necessary things in hw
so the cpu isn't hogged with say SOF generation.
> I tried to forward-port FHCI from Freescale 2.6.11 kernels. Twice.
> But these efforts always stumbled over more important tasks.
>=20
--=20
Sincerely, Vitaly
^ permalink raw reply
* Re: CPM2 USB host driver
From: Vitaly Bordug @ 2007-11-30 13:02 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev, mike
In-Reply-To: <200711301330.25100.laurentp@cse-semaphore.com>
On Fri, 30 Nov 2007 13:30:18 +0100
Laurent Pinchart wrote:
> On Friday 30 November 2007 12:16, Vitaly Bordug wrote:
> > On Fri, 30 Nov 2007 11:45:49 +0100
> >
> > Laurent Pinchart wrote:
> > > Hi everybody,
> > >
> > > Linux USB host support for the CPM, CPM2 and CPM2 pro is far from
> > > complete. Many people showed interest on this list (and on
> > > linuxppc-embedded) in the past, but nobody managed to complete a
> > > driver and get it merged.
> >
> > that is mainly because of its semi-software nature. However, any
> > approach would be helpful I beleive.
>
> The CPM/CPM2 USB host controller does indeed put some pressure on the
> CPU. The PowerQuick III family is much better in that respect as its
> USB host controller is EHCI compliant.
>
> We plan to use an external USB host controller when we will redesign
> the hardware. My goal in writting a CPM2 USB host driver is mainly to
> enable the hardware team to perform EMC testing on the USB interface.
> I don't expect it to be shipped to any client, but I'd still like to
> get it merged (if I complete the project) as I don't like throwing
> away useful code.
>
> > > As I need USB host support on my MPC8248 (CPM2), I decided to
> > > scratch the itch and try to get a working driver that could be
> > > merged upstream. This mail describes my plans to make sure the
> > > code I write will be useful for other people.
> > >
> > > The driver will be based on the cpm2usb project
> > > (http://cpm2usb.sf.net/). As I don't own any CPM1-based platform,
> > > I will convert the driver to use the CPM2 transaction-level
> > > interface, thus making it incompatible with the CPM1. CPM1
> > > support could be added back later. There is no planned release
> > > date, and more urgent projects could put this development on hold.
> > >
> > > Comments are welcome (and contributions too, especially in the
> > > form of a working driver :-)).
> >
> > I may have some WIP material left, will try to dig it out...
>
> Should I wait ?
>
Dunno. It was about 3 years ago so the chance is small.
--
Sincerely, Vitaly
^ permalink raw reply
* ppcboot and powerpc branch question
From: fabien @ 2007-11-30 13:33 UTC (permalink / raw)
To: linuxppc-embedded
hi all,
After some problem with my custom board and kernel 2.6.19 about the
init process, i've moved
on 2.6.23 and that had fixed my problems. (related to this post :
http://marc.info/?l=linuxppc-embedded&m=119609022221017&w=2)
Apparently it was a problem with cpm_uart on SMC1.
(http://lkml.org/lkml/2007/9/23/99)
the patch have been integrated in 2.6.23. Now i use this kernel and
busybox works.
I want to migrated my board in powerpc branch instead of ppc (i plan
to use xenomai but in 2.6.23
there is only an adeos patch for piowerpc branch), but i see the use
of a device tree
instead of bd_t struct. I'm a bit disappointed because i also see that
older u-boot (in my case
ppcboot 1.1.5) aren't capable to pass dts to kernel.
Is there a way to keep my old bootloader to boot a powerpc branch kernel ?
Best regards
Fab
^ permalink raw reply
* Re: ppcboot and powerpc branch question
From: Grant Likely @ 2007-11-30 13:43 UTC (permalink / raw)
To: fabien; +Cc: linuxppc-embedded
In-Reply-To: <f8f856500711300533t3bad1c1dxb4ff137534acbccb@mail.gmail.com>
On 11/30/07, fabien <fabien.fb@gmail.com> wrote:
> hi all,
>
> After some problem with my custom board and kernel 2.6.19 about the
> init process, i've moved
> on 2.6.23 and that had fixed my problems. (related to this post :
> http://marc.info/?l=linuxppc-embedded&m=119609022221017&w=2)
> Apparently it was a problem with cpm_uart on SMC1.
> (http://lkml.org/lkml/2007/9/23/99)
> the patch have been integrated in 2.6.23. Now i use this kernel and
> busybox works.
> I want to migrated my board in powerpc branch instead of ppc (i plan
> to use xenomai but in 2.6.23
> there is only an adeos patch for piowerpc branch), but i see the use
> of a device tree
> instead of bd_t struct. I'm a bit disappointed because i also see that
> older u-boot (in my case
> ppcboot 1.1.5) aren't capable to pass dts to kernel.
> Is there a way to keep my old bootloader to boot a powerpc branch kernel ?
Yes, you can build a 'cuImage' in arch/powerpc which wraps the kernel
image with a device tree and copies the bd_t data into the tree before
booting.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
From: Olof Johansson @ 2007-11-30 14:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1196403038.569525.367459803520.qpush@grosgo>
On Fri, Nov 30, 2007 at 05:10:38PM +1100, Benjamin Herrenschmidt wrote:
> There will be further cleanups and fixes before 2.6.25 opens
May I suggest running them through checkpatch.pl? It finds stuff in over
half of the ones I tried it on :)
-Olof
^ permalink raw reply
* Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-30 14:12 UTC (permalink / raw)
To: Alessandro Zummo; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <20071130122055.729dd3f8@i1501.lan.towertech.it>
[-- Attachment #1: Type: text/plain, Size: 24971 bytes --]
Hello, Alessandro!
Alessandro Zummo schrieb:
> It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc.
> it should work anyway, but who knows...
Here comes more debugging output:
Please note that I have now _two_ almost identical systems up and running with the
latest kernel. One machine (ecam) with an pcf8563 RTC on I2C and another one (fox_1)
with an DS1337. Both RTCs work, but the kernel doesn't get the time right.
I have now the SENSORS_*=n as you said and the (new) RTC configured.
The kernel configuration (attached) is identical for both machines. Can you please
check that again?!
Which CONFIG do I have to enable that I get /dev/rtc and/or /dev/rtc0 devices?
Note that I don't get any /dev/rtc* entry right now despite RTC_INTF_DRV=Y
Here are the outputs of the two hosts:
====================================================
HOST ECAM
root@ecam:~$ dmesg
Using MPC85xx ADS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.24-rc3-g09f345da (clemens@ecam) (gcc version 4.2.2 (ckcore)) #2 Fri Nov 30 13:06:38 CET 2007
Found legacy serial port 0 for /soc8540@e0000000/serial@4500
mem=e0004500, taddr=e0004500, irq=0, clk=330000000, speed=0
Found legacy serial port 1 for /soc8540@e0000000/serial@4600
mem=e0004600, taddr=e0004600, irq=0, clk=330000000, speed=0
Entering add_active_range(0, 0, 65536) 0 entries of 256 used
Found FSL PCI host bridge at 0x00000000e0008000.Firmware bus number: 0->0
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
On node 0 totalpages: 65536
DMA zone: 512 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 65024 pages, LIFO batch:15
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/sdb3 ro console=ttyS0,115200
mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max 1 CPUs
mpic: ISU size: 56, shift: 6, mask: 3f
mpic: Initializing for 56 sources
PID hash table entries: 1024 (order: 10, 4096 bytes)
time_init: decrementer frequency = 41.250000 MHz
time_init: processor frequency = 825.000000 MHz
clocksource: timebase mult[60f83e1] shift[22] registered
clockevent: decrementer mult[a8f] shift[16] cpu[0]
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256000k/262144k available (3296k kernel code, 5840k reserved, 144k data, 92k bss, 124k init)
SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay loop... 82.43 BogoMIPS (lpj=164864)
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
rstcr compatible register does not exist!
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:12.0
PCI: Cannot allocate resource region 1 of device 0000:00:12.0
PCI: Cannot allocate resource region 2 of device 0000:00:12.0
PCI: Cannot allocate resource region 3 of device 0000:00:12.0
PCI: Cannot allocate resource region 4 of device 0000:00:12.0
PCI: Cannot allocate resource region 0 of device 0000:00:14.0
PCI: Cannot allocate resource region 2 of device 0000:00:14.0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
Time: timebase clocksource has been installed.
Switched to high resolution mode on CPU 0
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
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)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A
loop: module loaded
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:00
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:01
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
eth2: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:02
eth2: Running with NAPI enabled
eth2: 256/256 RX/TX BD ring size
sata_promise 0000:00:14.0: version 2.11
scsi0 : sata_promise
scsi1 : sata_promise
scsi2 : sata_promise
ata1: SATA max UDMA/133 mmio m4096@0x80004000 port 0x80004200 irq 19
ata2: SATA max UDMA/133 mmio m4096@0x80004000 port 0x80004280 irq 19
ata3: PATA max UDMA/133 mmio m4096@0x80004000 port 0x80004300 irq 19
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: FUJITSU MHW2100BH, 00000012, max UDMA/100
ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access ATA FUJITSU MHW2100B 0000 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
pata_pdc2027x 0000:00:12.0: version 1.0
pata_pdc2027x 0000:00:12.0: PLL input clock 32997 kHz
scsi3 : pata_pdc2027x
scsi4 : pata_pdc2027x
ata4: PATA max UDMA/133 mmio m16384@0x80000000 cmd 0x800017c0 irq 18
ata5: PATA max UDMA/133 mmio m16384@0x80000000 cmd 0x800015c0 irq 18
ata4.00: ATA-7: Maxtor 6B120P0, BAH41BM0, max UDMA/133
ata4.00: 240121728 sectors, multi 0: LBA
ata4.00: limited to UDMA/33 due to 40-wire cable
ata4.00: configured for UDMA/33
scsi 3:0:0:0: Direct-Access ATA Maxtor 6B120P0 BAH4 PQ: 0 ANSI: 5
sd 3:0:0:0: [sdb] 240121728 512-byte hardware sectors (122942 MB)
sd 3:0:0:0: [sdb] Write Protect is off
sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 3:0:0:0: [sdb] 240121728 512-byte hardware sectors (122942 MB)
sd 3:0:0:0: [sdb] Write Protect is off
sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 >
sd 3:0:0:0: [sdb] Attached SCSI disk
usbmon: debugfs is not available
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver ftdi_sio
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
usbcore: registered new interface driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
mice: PS/2 mouse device common for all mice
usbcore: registered new interface driver usbtouchscreen
i2c-core: driver [rtc-ds1307] registered
i2c-core: driver [pcf8563] registered
i2c /dev entries driver
i2c-core: driver [dev_driver] registered
i2c-adapter i2c-0: adapter [MPC adapter] registered
i2c-dev: adapter [MPC adapter] registered as minor 0
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 124k init
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sdb3, internal journal
ReiserFS: sdb6: found reiserfs format "3.6" with standard journal
ReiserFS: sdb6: using ordered data mode
ReiserFS: sdb6: journal params: device sdb6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdb6: checking transaction log (sdb6)
ReiserFS: sdb6: Using r5 hash to sort names
Adding 500432k swap on /dev/sdb5. Priority:-1 extents:1 across:500432k
PHY: e0024520:00 - Link is Up - 100/Half
eth0: no IPv6 routers present
root@ecam:~$ i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- 51 -- -- -- -- -- -- 58 59 5a 5b 5c 5d 5e 5f
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@ecam:~$ i2cdump 0 0x51 b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x51, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
10: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
20: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
30: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
40: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
50: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
60: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
70: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
80: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
90: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
a0: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00 ..3@?05??w????3.
b0: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b4 37 00 ..3@?05??w????7.
c0: 00 00 34 40 13 30 35 b1 07 77 c0 c0 c0 b4 37 00 ..4@?05??w????7.
d0: 00 00 34 40 13 30 35 b1 07 77 c0 c0 c0 b4 37 00 ..4@?05??w????7.
e0: 00 00 34 40 13 30 35 b1 07 77 c0 c0 c0 b4 37 00 ..4@?05??w????7.
f0: 00 00 34 40 13 30 35 b1 07 77 c0 c0 c0 b4 37 00 ..4@?05??w????7.
root@ecam:~$ i2cdump 0 0x51 b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x51, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
10: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
20: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
30: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
40: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
50: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
60: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
70: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
80: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
90: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
a0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
b0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
c0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
d0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
e0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
f0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00 .@D@SpE??w????G.
root@ecam:~$
PCF8563 is ticking...
====================================================
HOST FOX_1
root@fox_1:~$ dmesg
Using MPC85xx ADS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.24-rc3-g09f345da (clemens@fox_1) (gcc version 4.2.2 (ckcore)) #2 Fri Nov 30 13:06:37 CET 2007
Found legacy serial port 0 for /soc8540@e0000000/serial@4500
mem=e0004500, taddr=e0004500, irq=0, clk=333333330, speed=0
Found legacy serial port 1 for /soc8540@e0000000/serial@4600
mem=e0004600, taddr=e0004600, irq=0, clk=333333330, speed=0
Entering add_active_range(0, 0, 65536) 0 entries of 256 used
Found FSL PCI host bridge at 0x00000000e0008000.Firmware bus number: 0->0
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 65536
On node 0 totalpages: 65536
DMA zone: 512 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 65024 pages, LIFO batch:15
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
Kernel command line: root=/dev/sda1 ro console=ttyS0,115200
mpic: Setting up MPIC " OpenPIC " version 1.2 at e0040000, max 1 CPUs
mpic: ISU size: 56, shift: 6, mask: 3f
mpic: Initializing for 56 sources
PID hash table entries: 1024 (order: 10, 4096 bytes)
time_init: decrementer frequency = 41.666666 MHz
time_init: processor frequency = 833.333325 MHz
clocksource: timebase mult[6000002] shift[22] registered
clockevent: decrementer mult[aaa] shift[16] cpu[0]
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256000k/262144k available (3296k kernel code, 5840k reserved, 144k data, 92k bss, 124k init)
SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1
Calibrating delay loop... 83.20 BogoMIPS (lpj=166400)
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
rstcr compatible register does not exist!
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 0000:00:12.0
PCI: Cannot allocate resource region 2 of device 0000:00:12.0
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
Time: timebase clocksource has been installed.
Switched to high resolution mode on CPU 0
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
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)
TCP reno registered
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A
loop: module loaded
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c4
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c5
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
eth2: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c6
eth2: Running with NAPI enabled
eth2: 256/256 RX/TX BD ring size
sata_promise 0000:00:12.0: version 2.11
scsi0 : sata_promise
scsi1 : sata_promise
scsi2 : sata_promise
ata1: SATA max UDMA/133 mmio m4096@0x80000000 port 0x80000200 irq 18
ata2: SATA max UDMA/133 mmio m4096@0x80000000 port 0x80000280 irq 18
ata3: PATA max UDMA/133 mmio m4096@0x80000000 port 0x80000300 irq 18
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: FUJITSU MHW2100BH, 00000012, max UDMA/100
ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access ATA FUJITSU MHW2100B 0000 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
usbmon: debugfs is not available
ehci_hcd 0000:00:14.2: EHCI Host Controller
ehci_hcd 0000:00:14.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:14.2: irq 20, io mem 0x81202000
ehci_hcd 0000:00:14.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:14.0: OHCI Host Controller
ohci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:14.0: irq 20, io mem 0x81200000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ohci_hcd 0000:00:14.1: OHCI Host Controller
ohci_hcd 0000:00:14.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:14.1: irq 20, io mem 0x81201000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usb 3-2: new low speed USB device using ohci_hcd and address 2
usb 3-2: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver ftdi_sio
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
usbcore: registered new interface driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
mice: PS/2 mouse device common for all mice
input: TSC-10 DM as /devices/pci0000:00/0000:00:14.1/usb3/3-2/3-2:1.0/input/input0
usbcore: registered new interface driver usbtouchscreen
i2c-core: driver [rtc-ds1307] registered
i2c-core: driver [pcf8563] registered
i2c /dev entries driver
i2c-core: driver [dev_driver] registered
i2c-adapter i2c-0: adapter [MPC adapter] registered
i2c-dev: adapter [MPC adapter] registered as minor 0
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 124k init
EXT3 FS on sda1, internal journal
Adding 2939884k swap on /dev/sda2. Priority:-1 extents:1 across:2939884k
PHY: e0024520:00 - Link is Up - 100/Half
eth0: no IPv6 routers present
root@fox_1:~$ i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@fox_1:~$ i2cdump 0 0x68 b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x68, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 55 00 15 06 30 11 07 00 00 00 00 00 00 00 00 00 U.??0??.........
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
root@fox_1:~$ i2cdump 0 0x68 b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x68, mode byte
Continue? [Y/n] y
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 03 01 15 06 30 11 07 00 00 00 00 00 00 00 00 00 ????0??.........
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
root@fox_1:~$
DS1337 is also working.
=====================================================
Alessandro, if you cannot help me here right now, can you please
give me some pointers to documentation and to the desired calling
tree of the kernel's new RTC stuff to get me started with
debugging?
My next step is to try it all modular... hence that won't be
a solution for me. (I don't wan't modules at all.)
Thank you a lot,
best regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 6919 bytes --]
^ permalink raw reply
* Re: [PATCH 1/11] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
From: Olof Johansson @ 2007-11-30 14:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071130054126.39BDCDDE0A@ozlabs.org>
Hi,
On Fri, Nov 30, 2007 at 04:40:23PM +1100, Benjamin Herrenschmidt wrote:
> +static int m88e1111_init(struct mii_phy *phy)
> +{
> + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
KERN_ level?
-Olof
^ permalink raw reply
* Re: [PATCH 2/11] ibm_newemac: Add ET1011c PHY support
From: Olof Johansson @ 2007-11-30 14:29 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071130054126.E3EFADDE0C@ozlabs.org>
Hi,
On Fri, Nov 30, 2007 at 04:40:24PM +1100, Benjamin Herrenschmidt wrote:
> This adds support for the Agere ET1011c PHY as found on the AMCC Taishan
> board.
The whole patch has whitespace messed up (tabs vs spaces).
-Olof
^ permalink raw reply
* Re: [PATCH 1/11] ibm_newemac: Add BCM5248 and Marvell 88E1111 PHY support
From: Geert Uytterhoeven @ 2007-11-30 14:30 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <20071130142736.GB3117@lixom.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 865 bytes --]
On Fri, 30 Nov 2007, Olof Johansson wrote:
> On Fri, Nov 30, 2007 at 04:40:23PM +1100, Benjamin Herrenschmidt wrote:
>
> > +static int m88e1111_init(struct mii_phy *phy)
> > +{
> > + printk("%s: Marvell 88E1111 Ethernet\n", __FUNCTION__);
>
> KERN_ level?
pr_
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: ppcboot and powerpc branch question
From: fabien @ 2007-11-30 14:45 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40711300543i47991fa6m9812231625205026@mail.gmail.com>
2007/11/30, Grant Likely <grant.likely@secretlab.ca>:
> On 11/30/07, fabien <fabien.fb@gmail.com> wrote:
> > hi all,
> >
> > After some problem with my custom board and kernel 2.6.19 about the
> > init process, i've moved
> > on 2.6.23 and that had fixed my problems. (related to this post :
> > http://marc.info/?l=linuxppc-embedded&m=119609022221017&w=2)
> > Apparently it was a problem with cpm_uart on SMC1.
> > (http://lkml.org/lkml/2007/9/23/99)
> > the patch have been integrated in 2.6.23. Now i use this kernel and
> > busybox works.
> > I want to migrated my board in powerpc branch instead of ppc (i plan
> > to use xenomai but in 2.6.23
> > there is only an adeos patch for piowerpc branch), but i see the use
> > of a device tree
> > instead of bd_t struct. I'm a bit disappointed because i also see that
> > older u-boot (in my case
> > ppcboot 1.1.5) aren't capable to pass dts to kernel.
> > Is there a way to keep my old bootloader to boot a powerpc branch kernel ?
>
> Yes, you can build a 'cuImage' in arch/powerpc which wraps the kernel
> image with a device tree and copies the bd_t data into the tree before
> booting.
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
Ok, thanks
So do I need to define a dts file or the bd_t struct only will be
sufficient to boot with cuImage ?
Best regards
Fab
^ permalink raw reply
* Re: [PATCH v7 7/9] ipic: clean up unsupported ack operations
From: Kumar Gala @ 2007-11-30 14:48 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <989B956029373F45A0B8AF029708189001A1CE7B@zch01exm26.fsl.freescale.net>
On Nov 30, 2007, at 4:03 AM, Li Yang wrote:
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Friday, November 30, 2007 8:36 AM
>> To: Li Yang
>> Cc: linuxppc-dev@ozlabs.org
>> Subject: Re: [PATCH v7 7/9] ipic: clean up unsupported ack operations
>>
>>
>> On Oct 19, 2007, at 6:38 AM, Li Yang wrote:
>>
>>> IPIC controller doesn't support ack operations. The
>> pending registers
>>> are read-only. The patch removes ack operations which are
>> not needed.
>>>
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> ---
>>> arch/powerpc/sysdev/ipic.c | 40 +
>>> +--------------------------------------
>>> 1 files changed, 2 insertions(+), 38 deletions(-)
>>
>> applied.
>
> Hi Kumar,
>
> Please hold on this one. Actually external interrupts in edge mode
> need
> this ack operation. But in most cases (level triggered) ack is not
> needed. I will provide an updated patch later on to take care both
> trigger modes. Thanks.
Ok, I'll drop this patch.
- k
^ permalink raw reply
* Re: [PATCH 24/24] powerpc: Base support for 440SPe "Katmai" eval board
From: Olof Johansson @ 2007-11-30 14:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20071130061209.497F3DE03A@ozlabs.org>
Hi,
On Fri, Nov 30, 2007 at 05:11:06PM +1100, Benjamin Herrenschmidt wrote:
> This adds base support for the Katmai board, including PCI-X and
> PCI-Express (but no RTC, nvram, etc... yet).
>
> Index: linux-work/arch/powerpc/boot/dts/katmai.dts
> ===================================================================
> --- /dev/null 1970-01-01 00:00:00.000000000 +0000
> +++ linux-work/arch/powerpc/boot/dts/katmai.dts 2007-11-30 14:46:02.000000000 +1100
> @@ -0,0 +1,392 @@
> +/*
> + * Device Tree Source for AMCC Bamboo
No it's not :)
-Olof
^ permalink raw reply
* Re: [PATCH] Add MPC837xEMDS PCIE RC mode support
From: Kumar Gala @ 2007-11-30 14:57 UTC (permalink / raw)
To: Li Li; +Cc: linuxppc-dev, Li Tony
In-Reply-To: <1196415470.2371.28.camel@Guyver>
On Nov 30, 2007, at 3:37 AM, Li Li wrote:
> On Fri, 2007-11-30 at 17:05 +0800, Gala Kumar wrote:
>>>>> +
>>>>> + pci2@e0009000 {
>>>>
>>>> I agree w/Olof. This should be pcie@e0009000
>>>>>
>>>>> + interrupt-map-mask = <f800 0 0 7>;
>>>>> + msi-available-ranges = <43 4 51 52 56 57 58 59>;
>>>>> + interrupt-map = <
>>>>> + 0000 0 0 1 &ipic 1 8
>>>>> + 0000 0 0 2 &ipic 1 8
>>>>> + 0000 0 0 3 &ipic 1 8
>>>>> + 0000 0 0 4 &ipic 1 8
>>>>> + >;
>>>>> + interrupt-parent = < &ipic >;
>>>>> + interrupts = <1 8>;
>>>>> + bus-range = <0 0>;
>>>>> + ranges = <02000000 0 A8000000 A8000000 0 10000000
>>>>> + 01000000 0 00000000 B8000000 0 00800000>;
>>>>> + clock-frequency = <0>;
>>>>> + #interrupt-cells = <1>;
>>>>> + #size-cells = <2>;
>>>>> + #address-cells = <3>;
>>>>> + reg = <e0009000 00001000
>>>>> + a0000000 08000000>;
>>>>
>>>> Shouldn't the reg size for the cfg space be 256M?
>>>
>>> 256M is a little too big for kernel.
>>
>> what do you mean too big? Aren't you losing access to some
>> bus/dev/fn
>> than?
>
> If do it standard, a 256M config space, at least 256M mem space and
> 16M
> io space are needed for each PCIE controller.
> To allocate PCIE window, the window size only can be 512M or 1G.
> If we choose 1G space, two PCIE controller needs 2G space.
> We do not have 2G free physical space now. Usually, we use upper 128M
> configure space. So, we have to cut down the config space.
We'll cutting config space is problematic in that its a bug since you
might not be able to talk to a given device.
Is it possible to make the outbound window for cfg space 4k and change
the region of config space its looking at?
>>>>> diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/
>>>>> platforms/83xx/Kconfig
>>>>> index 0c61e7a..00154c5 100644
>>>>> --- a/arch/powerpc/platforms/83xx/Kconfig
>>>>> +++ b/arch/powerpc/platforms/83xx/Kconfig
>>>>> @@ -87,3 +87,10 @@ config PPC_MPC837x
>>>>> select PPC_INDIRECT_PCI
>>>>> select FSL_SERDES
>>>>> default y if MPC837x_MDS
>>>>> +
>>>>> +config PPC_MPC83XX_PCIE
>>>>> + bool "MPC837X PCI Express support"
>>>>> + depends on PCIEPORTBUS && PPC_MPC837x
>>>>> + default n
>>>>> + help
>>>>> + Enables MPC837x PCI express RC mode
>>>>
>>>> This should be a hidden config that is just selected by
>> PPC_MPC837x
>>>> instead of a choice. Also drop the depends on.
>>>>
>>>
>>> In the dts file, the PCIE is default enabled. So, we should provide
>>> another way to disable the PCIE.
>>> Modify and recompile the dts is a little unkind to user.
>>
>> Why do you something beyond CONFIG_PCI. if you don't want PCIe but
>> do
>> want PCI the extra code for PCIe isn't going to kill you.
>>
>
> Here is a little complex. The MPC837xE board needs a carrier board to
> extend PCIE slot. If user does not populate carrier board onto
> MPC837xE
> board and do PCIE scan, the system will halt.
> I just want to provide a easy way to disable the PCIe other than
> modify
> and recompile the dts.
So I have to recompile the kernel for this case, that seems even more
painful to the user. Can we not detect if this board isn't there and
not hang?
>>>>> diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h
>> b/arch/powerpc/
>>>>> platforms/83xx/mpc83xx.h
>>>>> index b778cb4..2078da7 100644
>>>>> --- a/arch/powerpc/platforms/83xx/mpc83xx.h
>>>>> +++ b/arch/powerpc/platforms/83xx/mpc83xx.h
>>>>> @@ -43,12 +43,18 @@
>>>>> #define PORTSCX_PTS_UTMI 0x00000000
>>>>> #define PORTSCX_PTS_ULPI 0x80000000
>>>>>
>>>>> +/* PCIE Registers */
>>>>> +#define PEX_LTSSM_STAT 0x404
>>>>> +#define PEX_LTSSM_STAT_L0 0x16
>>>>> +#define PEX_GCLK_RATIO 0x440
>>>>> +
>>>>
>>>> just move these into the .c file.
>
> ok.
>
>>>>
>>>>>
>>>>> /*
>>>>> * Declaration for the various functions exported by the
>>>>> * mpc83xx_* files. Mostly for use by mpc83xx_setup
>>>>> */
>>>>> -
>>>>> -extern int mpc83xx_add_bridge(struct device_node *dev);
>>>>> +#define PPC_83XX_PCI 0x1
>>>>> +#define PPC_83XX_PCIE 0x2
>>>>> +extern int mpc83xx_add_bridge(struct device_node *dev, int
>> flags);
>>>>> extern void mpc83xx_restart(char *cmd);
>>>>> extern long mpc83xx_time_init(void);
>>>>> extern int mpc834x_usb_cfg(void);
>>>>> diff --git a/arch/powerpc/platforms/83xx/pci.c b/arch/powerpc/
>>>>> platforms/83xx/pci.c
>>>>> index 80425d7..0b52b2e 100644
>>>>> --- a/arch/powerpc/platforms/83xx/pci.c
>>>>> +++ b/arch/powerpc/platforms/83xx/pci.c
>>>>> @@ -25,6 +25,8 @@
>>>>> #include <asm/prom.h>
>>>>> #include <sysdev/fsl_soc.h>
>>>>>
>>>>> +#include "mpc83xx.h"
>>>>> +
>>>>> #undef DEBUG
>>>>>
>>>>> #ifdef DEBUG
>>>>> @@ -33,13 +35,157 @@
>>>>> #define DBG(x...)
>>>>> #endif
>>>>>
>>>>> -int __init mpc83xx_add_bridge(struct device_node *dev)
>>>>> +#if defined(CONFIG_PPC_MPC83XX_PCIE)
>>>>> +
>>>>> +/* PCIE config space Read/Write routines */
>>>>
>>>> should really be called something like mpc83xx_pciex_read_config
>>>>>
>>>>> +static int direct_read_config_pcie(struct pci_bus *bus,
>>>>> + uint devfn, int offset, int len, u32 *val)
>>>>> +{
>>>>> + struct pci_controller *hose = bus->sysdata;
>>>>> + void __iomem *cfg_addr;
>>>>> + u32 bus_no;
>>>>> +
>>>>> + if (hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK)
>>>>> + return PCIBIOS_DEVICE_NOT_FOUND;
>>>>> +
>>>>> + if (ppc_md.pci_exclude_device)
>>>>> + if (ppc_md.pci_exclude_device(hose, bus->number,
>>>> devfn))
>>>>> + return PCIBIOS_DEVICE_NOT_FOUND;
>>>>> +
>>>>> + switch (len) {
>>>>> + case 2:
>>>>> + if (offset & 1)
>>>>> + return -EINVAL;
>>>>> + break;
>>>>> + case 4:
>>>>> + if (offset & 3)
>>>>> + return -EINVAL;
>>>>> + break;
>>>>> + }
>>>>
>>>> fix formatting.
>>>>
>>>>>
>>>>> +
>>>>> + pr_debug("_read_cfg_pcie: bus=%d devfn=%x off=%x len=%x\n",
>>>>> + bus->number, devfn, offset, len);
>>>>> +
>>>>> + if (bus->number == hose->first_busno) {
>>>>> + if (devfn & 0xf8)
>>>>> + return PCIBIOS_DEVICE_NOT_FOUND;
>>>>
>>>> what is the 0xf8 all about?
>>>>
>>>
>>> The pcie only have one link, so the dev number only can be 0, as
>> well
>>> the function number can be 0 ~ 7.
>>
>> I don't follow what the number of links has to do with dev number.
>
> The PCIE only have one link that mean one PCIE bus only can have one
> device populate on it. The dev number of this device must be 0. If the
> device number is not 0, we consider it is a error.
we should add a comment about that.
>>>>> + addr = mbase + (cfg_addr & ~PAGE_MASK);
>>>>> + hose->cfg_addr = addr;
>>>>> + hose->ops = &direct_pcie_ops;
>>>>
>>>> what's the point of this function, why not just fold it into
>>>> mpc83xx_setup_pcie
>>>>
>>>>>
>>>>> +}
>>>>> +
>>>>> +static void __init mpc83xx_setup_pcie(struct pci_controller
>> *hose,
>>>>> + struct resource *reg, struct resource
>>>> *cfg_space)
>>>>> +{
>>>>> + void __iomem *hose_cfg_base;
>>>>> + u32 val;
>>>>> +
>>>>> + hose_cfg_base = ioremap(reg->start, reg->end - reg->start +
>>>> 1);
>>>>> +
>>>>> + val = in_le32(hose_cfg_base + PEX_LTSSM_STAT);
>>>>> + if (val < PEX_LTSSM_STAT_L0)
>>>>> + hose->indirect_type |=
>>>> PPC_INDIRECT_TYPE_NO_PCIE_LINK;
>>>>> +
>>>>> + setup_direct_pcie(hose, cfg_space->start,
>>>>> + cfg_space->end - cfg_space->start + 1);
>>>>> +}
>>>>> +#endif /* CONFIG_PPC_MPC83XX_PCIE */
>>>>> +
>>>>
>>>> We should do the same think fsl_pci does for primary, its passed
>>>> into
>>>> _add_bridge. Also, can we not do what fsl_pci does and use PCI
>>>> capabilities to determine we are a PCIe controller (and drop
>> passing
>>>> it in via flags).
>>>>
>>>
>>> The mpc837x PCIE controller is a little different from mpc85xx.
>>> It can not be access via PCI configure read/write. It only can be
>>> accessed via memory-mapped read/write from core.
>>
>> You don't have access to your own config space?
>>
>
> I can access it but can not via standard pci configure routine.
> So, we use different way to access PCI and PCIE. If we want access PCI
> capabilities, we must know it is PCI controller or PCIE controller
> first.
Duh, your right.. we should than expand flags to also have a
PPC_83XX_PCI_IS_PRIMARY and let that get set by the caller.
- k
^ permalink raw reply
* Re: ppcboot and powerpc branch question
From: Scott Wood @ 2007-11-30 15:04 UTC (permalink / raw)
To: fabien; +Cc: linuxppc-embedded
In-Reply-To: <f8f856500711300645p13dc4cb7m10d3361e1393632b@mail.gmail.com>
fabien wrote:
> Ok, thanks
> So do I need to define a dts file or the bd_t struct only will be
> sufficient to boot with cuImage ?
You need to define a dts file (see the existing ones in
arch/powerpc/boot/dts for examples), and set CONFIG_DEVICE_TREE to tell
the wrapper which one to include.
Note that this dts must have linux,network-index properties in the
network nodes for the MAC addresses to be filled in, and must have
/chosen/linux,stdout-path if you want output from the wrapper (useful if
something goes wrong (such as insufficient memory to relocate the
kernel) or if you want to edit the command line).
You also need to do make zImage rather than make uImage for cuImage to
be built.
-Scott
^ permalink raw reply
* Re: ppcboot and powerpc branch question
From: Clemens Koller @ 2007-11-30 15:09 UTC (permalink / raw)
To: fabien; +Cc: linuxppc-embedded
In-Reply-To: <f8f856500711300533t3bad1c1dxb4ff137534acbccb@mail.gmail.com>
fabien schrieb:
> hi all,
>
> After some problem with my custom board and kernel 2.6.19 about the
> init process, i've moved
> on 2.6.23 and that had fixed my problems. (related to this post :
> http://marc.info/?l=linuxppc-embedded&m=119609022221017&w=2)
> Apparently it was a problem with cpm_uart on SMC1.
> (http://lkml.org/lkml/2007/9/23/99)
> the patch have been integrated in 2.6.23. Now i use this kernel and
> busybox works.
> I want to migrated my board in powerpc branch instead of ppc (i plan
> to use xenomai but in 2.6.23
> there is only an adeos patch for piowerpc branch), but i see the use
> of a device tree
> instead of bd_t struct. I'm a bit disappointed because i also see that
> older u-boot (in my case
> ppcboot 1.1.5) aren't capable to pass dts to kernel.
> Is there a way to keep my old bootloader to boot a powerpc branch kernel ?
please read linux/Documentation/powerpc/booting-without-of.txt
To get a cuImage, you
- need to adjust your <platform>.dts and configure your kernel to use it.
- need the latest dtc (device tree compiler),
- need the latest mkimage (from the latest u-boot tree)
- and build your cuImage by building the target zImage (make zImage)
-> your cuImage then rests in i.e. arch/powerpc/boot/cuImage.<platform>
Aside of no good documentation, I ran into the problem that the
embedded device tree doesn't get updated by the bd_t struct properly
(the mac addresses) in the latest versions of the kernel. This might be
a bug or a configuration error on my side. I didn't check yet.
U-Boot with full device tree support will hopfully fix that, when it's
out.
Regards,
--
Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
^ permalink raw reply
* Re: [PATCH] Add MPC837xEMDS PCIE RC mode support
From: Scott Wood @ 2007-11-30 15:12 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Kumar Gala, Li Li
In-Reply-To: <20071130041404.GB26982@lixom.net>
On Thu, Nov 29, 2007 at 10:14:04PM -0600, Olof Johansson wrote:
> On Fri, Nov 30, 2007 at 11:45:34AM +0800, Li Li wrote:
> > + help
> > + Enables MPC837x PCI express RC mode
>
> Why have a separate config option for this?
To save code size when it isn't needed?
> For systems where you don't want PCI-e configured, it should be left
> out of the device tree instead.
The dts should represent what exists on the hardware, not what you want to
use.
-Scott
^ permalink raw reply
* Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
From: Kumar Gala @ 2007-11-30 15:12 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071130141540.GA3117@lixom.net>
On Nov 30, 2007, at 8:15 AM, Olof Johansson wrote:
> On Fri, Nov 30, 2007 at 05:10:38PM +1100, Benjamin Herrenschmidt
> wrote:
>
>> There will be further cleanups and fixes before 2.6.25 opens
>
> May I suggest running them through checkpatch.pl? It finds stuff in
> over
> half of the ones I tried it on :)
You know of anyone that's integrated checkpatch.pl w/a git commit or
git-add? (effective run checkpatch.pl on the index before you commit
it).
- k
^ permalink raw reply
* Re: [PATCH] Add MPC837xEMDS PCIE RC mode support
From: Scott Wood @ 2007-11-30 15:19 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Li Li, Li Tony
In-Reply-To: <6FF36777-D91C-4B80-968B-CAEF11BC98ED@freescale.com>
On Fri, Nov 30, 2007 at 08:57:33AM -0600, Kumar Gala wrote:
> On Nov 30, 2007, at 3:37 AM, Li Li wrote:
> > If do it standard, a 256M config space, at least 256M mem space and
> > 16M
> > io space are needed for each PCIE controller.
> > To allocate PCIE window, the window size only can be 512M or 1G.
> > If we choose 1G space, two PCIE controller needs 2G space.
> > We do not have 2G free physical space now. Usually, we use upper 128M
> > configure space. So, we have to cut down the config space.
That decision should be made in the kernel, not the dts.
> Is it possible to make the outbound window for cfg space 4k and change
> the region of config space its looking at?
Yes, that'd be best.
> > Here is a little complex. The MPC837xE board needs a carrier board to
> > extend PCIE slot. If user does not populate carrier board onto MPC837xE
> > board and do PCIE scan, the system will halt. I just want to provide a
> > easy way to disable the PCIe other than modify and recompile the dts.
>
> So I have to recompile the kernel for this case, that seems even more
> painful to the user. Can we not detect if this board isn't there and
> not hang?
Assuming it's similar to PCI on other 83xxMDS, yes -- there's a bit in the
reset control words that can be checked.
We don't currently do it on any 83xx that I'm aware of, though. :-P
-Scott
^ permalink raw reply
* Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
From: Olof Johansson @ 2007-11-30 15:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <51DE5987-D0DD-4E62-A99A-3D23ECFA9908@kernel.crashing.org>
On Fri, Nov 30, 2007 at 09:12:34AM -0600, Kumar Gala wrote:
>
> On Nov 30, 2007, at 8:15 AM, Olof Johansson wrote:
>
> > On Fri, Nov 30, 2007 at 05:10:38PM +1100, Benjamin Herrenschmidt
> > wrote:
> >
> >> There will be further cleanups and fixes before 2.6.25 opens
> >
> > May I suggest running them through checkpatch.pl? It finds stuff in
> > over
> > half of the ones I tried it on :)
>
> You know of anyone that's integrated checkpatch.pl w/a git commit or
> git-add? (effective run checkpatch.pl on the index before you commit
> it).
I normally do "quilt diff | checkpatch.pl -" when use quilt. You could
similarly do "git diff HEAD | checkpatch.pl -". You'd always get the
warning about missing signed-off-by though.
-Olof
^ permalink raw reply
* Re: CPM2 USB host driver
From: Laurent Pinchart @ 2007-11-30 15:28 UTC (permalink / raw)
To: avorontsov; +Cc: mike, linuxppc-dev
In-Reply-To: <20071130124801.GA13141@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]
On Friday 30 November 2007 13:48, Anton Vorontsov wrote:
> On Fri, Nov 30, 2007 at 01:30:18PM +0100, Laurent Pinchart wrote:
> > On Friday 30 November 2007 12:16, Vitaly Bordug wrote:
> > > On Fri, 30 Nov 2007 11:45:49 +0100
> > >
> > > Laurent Pinchart wrote:
> > > > Hi everybody,
> > > >
> > > > Linux USB host support for the CPM, CPM2 and CPM2 pro is far from
> > > > complete. Many people showed interest on this list (and on
> > > > linuxppc-embedded) in the past, but nobody managed to complete a
> > > > driver and get it merged.
> > >
> > > that is mainly because of its semi-software nature. However, any
> > > approach would be helpful I beleive.
> >
> > The CPM/CPM2 USB host controller does indeed put some pressure on the
> > CPU. The PowerQuick III family is much better in that respect as its USB
> > host controller is EHCI compliant.
>
> I didn't yet compare with CPM/CPM2, but I wonder if PQIIPro (MPC8360E)
> USB controller is similar to cpms?..
If I'm not mistaken it is very similar to the CPM2 USB host controller, with
the added ability to generate SOF packets automatically.
The CPM has a packet-level USB host controller. CPM2 introduced a
transaction-level mode (it still supports packet-level mode). CPM2 pro fixes
the SOF packets generation issue that wakes the CPU once per millisecond with
CPM and CPM2.
Some members of the PQ2 and PQ2 pro families don't have a CPM but include a
USB EHCI controller. I suppose those processors are less versatile (as the
communication controllers are hardware-based instead of software-based) but
offer more communication performance.
If I'm not mistaken, the only processor to support USB in the PQ3 family is
the MPC8555E. Its USB host controller is similar to the CPM2 as it supports
both packet-level and transaction-level modes, but doesn't generate SOF
packets automatically. I assume the PQ3 integrates a CPM2 and not a CPM2 pro.
To summarize the issue (and I'd appreciate if someone could confirm this), a
packet-level FHCI driver would work with CPM, CPM2 and CPM2 pro based
processors. A transaction-level FHCI driver would work with the CPM2 and CPM2
pro based processors. For CPM2 pro based processors, SOF packet generation
can be handled by the CPM.
> I tried to forward-port FHCI from Freescale 2.6.11 kernels. Twice.
> But these efforts always stumbled over more important tasks.
Do you think I start from the FHCI driver provided by Freescale for 2.6.11,
from the cpm2usb driver or from scratch ?
Both the cpm2usb and FHCI drivers seem to use the packet-level interface. Is
there any reason not to use the transaction-level interface ?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ppcboot and powerpc branch question
From: fabien @ 2007-11-30 15:57 UTC (permalink / raw)
To: Clemens Koller; +Cc: linuxppc-embedded
In-Reply-To: <475027B9.4060804@anagramm.de>
Thanks for yours advices Scott and Clemens i'll read the docs given
Best regards
2007/11/30, Clemens Koller <clemens.koller@anagramm.de>:
> fabien schrieb:
> > hi all,
> >
> > After some problem with my custom board and kernel 2.6.19 about the
> > init process, i've moved
> > on 2.6.23 and that had fixed my problems. (related to this post :
> > http://marc.info/?l=3Dlinuxppc-embedded&m=3D119609022221017&w=3D2)
> > Apparently it was a problem with cpm_uart on SMC1.
> > (http://lkml.org/lkml/2007/9/23/99)
> > the patch have been integrated in 2.6.23. Now i use this kernel and
> > busybox works.
> > I want to migrated my board in powerpc branch instead of ppc (i plan
> > to use xenomai but in 2.6.23
> > there is only an adeos patch for piowerpc branch), but i see the use
> > of a device tree
> > instead of bd_t struct. I'm a bit disappointed because i also see that
> > older u-boot (in my case
> > ppcboot 1.1.5) aren't capable to pass dts to kernel.
> > Is there a way to keep my old bootloader to boot a powerpc branch kerne=
l ?
>
> please read linux/Documentation/powerpc/booting-without-of.txt
>
> To get a cuImage, you
> - need to adjust your <platform>.dts and configure your kernel to use it.
> - need the latest dtc (device tree compiler),
> - need the latest mkimage (from the latest u-boot tree)
> - and build your cuImage by building the target zImage (make zImage)
> -> your cuImage then rests in i.e. arch/powerpc/boot/cuImage.<platform>
>
> Aside of no good documentation, I ran into the problem that the
> embedded device tree doesn't get updated by the bd_t struct properly
> (the mac addresses) in the latest versions of the kernel. This might be
> a bug or a configuration error on my side. I didn't check yet.
> U-Boot with full device tree support will hopfully fix that, when it's
> out.
>
> Regards,
>
> --
> Clemens Koller
> __________________________________
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Stra=DFe 45/1
> Linhof Werksgel=E4nde
> D-81379 M=FCnchen
> Tel.089-741518-50
> Fax 089-741518-19
> http://www.anagramm-technology.com
>
>
^ permalink raw reply
* Re: CPM2 USB host driver
From: Anton Vorontsov @ 2007-11-30 16:11 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: mike, linuxppc-dev
In-Reply-To: <200711301628.33526.laurentp@cse-semaphore.com>
On Fri, Nov 30, 2007 at 04:28:27PM +0100, Laurent Pinchart wrote:
[...]
> > I tried to forward-port FHCI from Freescale 2.6.11 kernels. Twice.
> > But these efforts always stumbled over more important tasks.
>
> Do you think I start from the FHCI driver provided by Freescale for 2.6.11,
> from the cpm2usb driver or from scratch ?
Well, the same question I asked myself when I was looking at
FHCI driver back then. USB subsystem changed drastically, powerpc
bits changed too. Forward porting or doing from scratch.. hm.
Unfortunately I didn't look into cpm2usb, thus I can't tell
whether it will be easier to reuse.
As for FHCI driver, it's not that big (6100 lines host patch + 3516
lines usbgadget patch), but since usb subsystem changed: you have to
know all the changes (or to look them up) and blindly follow them. Or
start from scratch with FHCI/cpm2usb as the reference, thus evolve
into Linux USB expert one day.
I've tried first option -- it's boring to death (that is, you're
doing job USB maintainers done years ago for in-tree drivers ;-).
Today, I think I would choose the second option. Definitely more
fun, and most probably quicker to progress. Though, I repeat,
I didn't look into cpm2usb project.
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 0/24] powerpc: 4xx PCI, PCI-X and PCI-Express support among others
From: Jon Loeliger @ 2007-11-30 16:11 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071130152742.GB4196@lixom.net>
Olof Johansson wrote:
> I normally do "quilt diff | checkpatch.pl -" when use quilt. You could
> similarly do "git diff HEAD | checkpatch.pl -". You'd always get the
> warning about missing signed-off-by though.
So do a "git log -p | checkpatch.pl -" instead? :-)
jdl
^ permalink raw reply
* Re: [PATCH] powerpc: fix os-term usage on kernel panic
From: Will Schmidt @ 2007-11-30 16:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071130165651.b1b7c16c.sfr@canb.auug.org.au>
On Fri, 2007-11-30 at 16:56 +1100, Stephen Rothwell wrote:
> On Tue, 27 Nov 2007 18:15:59 -0600 Will Schmidt <will_schmidt@vnet.ibm.com> wrote:
> >
> > (resending with the proper "from" addr this time).
> >
> >
> > I'm seeing some funky behavior on power5/power6 partitions with this
> > patch. A "/sbin/reboot" is now behaving much more like a
> > "/sbin/halt".
> >
> > Anybody else seeing this, or is it time for me to call an exorcist for
> > my boxes?
>
> On my Power5+ box, I get an error (code B200A101) logged every time I
> reboot and about half the time, the machine does not reboot but need to
> be power cycled. Removing the cited patch makes the error not by logged
> and reboots work fine.
>
> Paul and I have been having a look at this and Paul has asked the
> architects for clarification of when os-term should be used.
The architects will have the correct answer of course.
>From my reading of the papr, I've got the impression that there are two
possibilities.
First, the os-term never returns, and it's up to the service processor
to do whatever it's going to do. (call home, dump, something else).
Nothing we can do there.
Second, os-term returns, and it's up to the OS to call into power-off or
system-reboot.
I think this is more likely. I havn't followed the path back from
machine_restart to see exactly how we got there, but probably means a
bit more logic to decide whether to call into rtas_restart() or
pSeries_power_off() after the call to machine_shutdown.
^ permalink raw reply
* Semaphores in eldk4.1
From: Stuart Hodgson @ 2007-11-30 16:33 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have been suing the eldk4.1 tool chain for a few months now and have
not not encountered any problems with building until now. I build for
two slightly different archs, ppc_85xx and ppx_82xx.
The problem I have come up against is related to some of the semaphore
functions in semaphore.h, namely sem_wait, sem_post. This was originally
noticed in a third party driver I am porting from one board to another
but a small test program has shown the same results.
Calls to these functions on the ppc_82xx platform return -1 with an
error code of 38, in this case meaning ENOSYS (not implemented). On the
ppc_85xx the same program executes fine, thus I conclude that it is
specific to the libc-2.3.5 for ppc_82xx. Has anyone else come across
this problem, I did find one thread but there was no conclusion listed.
I also can not find anything stating that these functions are not
implemented for the 82xx arch compared with others for the eldk4.1
Thanks
Stuart
^ 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