* switching from initrd to initramfs
From: Mikhail Zaturenskiy @ 2009-07-08 19:25 UTC (permalink / raw)
To: linuxppc-dev
Hello, I have a working system with an initrd ramdisk and I'm having
some trouble switching it over to initramfs.
This is for an EP88xc Embedded Planet board, now running U-Boot and
using kernel 2.6.29. I prepare my initrd using:
genext2fs -U -d rootfs -D rootfs_devices.tab -b 9700 -i 380 initrd.img
gzip -v9 initrd.img
mkimage -T ramdisk -C gzip -n 'Test Ramdisk Image' -d initrd.img.gz uInitrd
(instructions are from
http://www.denx.de/wiki/view/DULG/RootFileSystemDesignAndBuilding )
...which seems to work ok and results in the following:
************************************************************************************
U-Boot 2009.03-svn8609 (Jun 30 2009 - 11:32:48)
CPU: MPC885ZPnn at 100 MHz [40.0...133.0 MHz]
8 kB I-Cache 8 kB D-Cache FEC present
Board: EP88xC 1.1 CPLD revision 2
DRAM: 64 MB
FLASH: 32 MB
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET, FEC2 ETHERNET
Hit any key to stop autoboot: 0
=>
=>
=> setenv bootargs console=ttyCPM0,9600n8 root=/dev/ram rw init=/sbin/init
=> tftp 400000 ep88x_uimage_29
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_uimage_29'.
Load address: 0x400000
Loading: #################################################################
##########
done
Bytes transferred = 1089141 (109e75 hex)
=> tftp 750000 ep88x_ramdisk_generated2
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_ramdisk_generated2'.
Load address: 0x750000
Loading: #################################################################
###############################################################
done
Bytes transferred = 1869959 (1c8887 hex)
=> tftp 1000000 ep88x_dtb
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_dtb'.
Load address: 0x1000000
Loading: #
done
Bytes transferred = 7643 (1ddb hex)
=> bootm 400000 750000 1000000
## Booting kernel from Legacy Image at 00400000 ...
Image Name: Linux-2.6.29.6-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1089077 Bytes = 1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00750000 ...
Image Name: Test Ramdisk Image
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1869895 Bytes = 1.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01000000
Booting using the fdt blob at 0x1000000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 03da5000, end 03f6d847 ... OK
Loading Device Tree to 007fb000, end 007ffdda ... OK
Using Embedded Planet EP88xC machine description
Linux version 2.6.29.6-dirty (devone@localhost.localdomain) (gcc version 4.2.2)
#1 Mon Jul 6 12:53:12 CDT 2009
Found initrd at 0xc3da5000:0xc3f6d847
Zone PFN ranges:
DMA 0x00000000 -> 0x00004000
Normal 0x00004000 -> 0x00004000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00004000
MMU: Allocated 72 bytes of context maps for 16 contexts
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: console=ttyCPM0,9600n8 root=/dev/ram rw init=/sbin/init
PID hash table entries: 256 (order: 8, 1024 bytes)
Decrementer Frequency = 0x5f5e10
clocksource: timebase mult[28000000] shift[22] registered
console [ttyCPM0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 60644k/65536k available (2124k kernel code, 4824k reserved, 88k data, 10
6k bss, 124k init)
SLUB: Genslabs=11, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay loop... 12.41 BogoMIPS (lpj=62080)
Mount-cache hash table entries: 512
net_namespace: 296 bytes
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 1826k freed
msgmni has been set to 122
io scheduler noop registered
io scheduler deadline registered (default)
Generic RTC Driver v1.07
f0000a80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq = 19) is a CPM UART
f0000a20.serial: ttyCPM1 at MMIO 0xc5016a20 (irq = 29) is a CPM UART
brd: module loaded
loop: module loaded
eth0 (): not using net_device_ops yet
eth0: fs_enet: 00:00:00:00:00:00
eth1 (): not using net_device_ops yet
eth1: fs_enet: 00:00:00:00:00:00
FEC MII Bus: probed
fe000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
fe000000.flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 124k init
init started: BusyBox v1.7.1 (2008-04-02 09:14:47 MEST)
starting pid 208, tty '': '/etc/rc.sh'
starting pid 213, tty '': '/bin/application'
starting pid 214, tty '': '/bin/sh'
### Application running ...
~ #
*****************************************************************************
Then I tried to make an initramfs from the same root tree using:
find | cpio -ovc | gzip -v9 > ../initramfs.cpio.gz
mkimage -T ramdisk -C gzip -n 'Test Ramdisk Image' -d
../initramfs.cpio.gz ../uCpio
But the result seems to have an issue with init:
****************************************************************************
U-Boot 2009.03-svn8609 (Jun 30 2009 - 11:32:48)
CPU: MPC885ZPnn at 100 MHz [40.0...133.0 MHz]
8 kB I-Cache 8 kB D-Cache FEC present
Board: EP88xC 1.1 CPLD revision 2
DRAM: 64 MB
FLASH: 32 MB
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET, FEC2 ETHERNET
Hit any key to stop autoboot: 0
=>
=>
=> setenv bootargs console=ttyCPM0,9600n8 root=/dev/ram rw init=/sbin/init
=> tftp 400000 ep88x_uimage_29
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_uimage_29'.
Load address: 0x400000
Loading: #################################################################
##########
done
Bytes transferred = 1089141 (109e75 hex)
=> tftp 750000 ep88x_ramfs
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_ramfs'.
Load address: 0x750000
Loading: #################################################################
############################################################
done
Bytes transferred = 1832735 (1bf71f hex)
=> tftp 1000000 ep88x_dtb
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_dtb'.
Load address: 0x1000000
Loading: #
done
Bytes transferred = 7643 (1ddb hex)
=> bootm 400000 750000 1000000
## Booting kernel from Legacy Image at 00400000 ...
Image Name: Linux-2.6.29.6-dirty
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1089077 Bytes = 1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00750000 ...
Image Name: Test Ramdisk Image
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1832671 Bytes = 1.7 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 01000000
Booting using the fdt blob at 0x1000000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 03dae000, end 03f6d6df ... OK
Loading Device Tree to 007fb000, end 007ffdda ... OK
Using Embedded Planet EP88xC machine description
Linux version 2.6.29.6-dirty (devone@localhost.localdomain) (gcc version 4.2.2)
#1 Mon Jul 6 12:53:12 CDT 2009
Found initrd at 0xc3dae000:0xc3f6d6df
Zone PFN ranges:
DMA 0x00000000 -> 0x00004000
Normal 0x00004000 -> 0x00004000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00004000
MMU: Allocated 72 bytes of context maps for 16 contexts
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: console=ttyCPM0,9600n8 root=/dev/ram rw init=/sbin/init
PID hash table entries: 256 (order: 8, 1024 bytes)
Decrementer Frequency = 0x5f5e10
clocksource: timebase mult[28000000] shift[22] registered
console [ttyCPM0] enabled
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 60680k/65536k available (2124k kernel code, 4788k reserved, 88k data, 10
6k bss, 124k init)
SLUB: Genslabs=11, HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Calibrating delay loop... 12.41 BogoMIPS (lpj=62080)
Mount-cache hash table entries: 512
net_namespace: 296 bytes
NET: Registered protocol family 16
bio: create slab <bio-0> at 0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs... it is
Freeing initrd memory: 1789k freed
msgmni has been set to 122
io scheduler noop registered
io scheduler deadline registered (default)
Generic RTC Driver v1.07
f0000a80.serial: ttyCPM0 at MMIO 0xc500ea80 (irq = 19) is a CPM UART
f0000a20.serial: ttyCPM1 at MMIO 0xc5016a20 (irq = 29) is a CPM UART
brd: module loaded
loop: module loaded
eth0 (): not using net_device_ops yet
eth0: fs_enet: 00:00:00:00:00:00
eth1 (): not using net_device_ops yet
eth1: fs_enet: 00:00:00:00:00:00
FEC MII Bus: probed
fe000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
fe000000.flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
List of all partitions:
1f00 32768 mtdblock0 (driver?)
No filesystem could mount root, tried: ext2 cramfs
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Rebooting in 180 seconds..
**********************************************************************
I was hoping to convert this working initrd to initramfs before I try
and create my own initrd, I'm still learning about this process. I got
this to work yesterday morning, but I'm not sure what changed or what
I'm doing differently...
Can somebody help me figure out what's missing?
Thanks,
Mikhail Zaturenskiy
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-08 19:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <3887C2A7-3566-43A9-A863-4670B039E5DA@kernel.crashing.org>
On Wed, Jul 08, 2009 at 01:09:39PM -0500, Kumar Gala wrote:
>
> On Jul 8, 2009, at 11:19 AM, Ira W. Snyder wrote:
>
>> Add support for the Freescale MPC83xx memory controller to the
>> existing
>> driver for the Freescale MPC85xx memory controller. The only
>> difference
>> between the two processors are in the CS_BNDS register parsing code.
>>
>> The L2 cache controller does not exist on the MPC83xx, but the OF
>> subsystem
>> will not use the driver if the device is not present in the OF device
>> tree.
>>
>> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
>> ---
>>
>> This was tested on an MPC8349EMDS-based board.
>>
>> I don't really like how the MCE disable works on mpc85xx (clearing the
>> HID1 register), but this can be revisited when mpc86xx support gets
>> added. It sucks to have this happen before the probe() routine is
>> called
>> and we know what kind of hardware we're actually running on.
>>
>> drivers/edac/Kconfig | 6 +++---
>> drivers/edac/mpc85xx_edac.c | 38 +++++++++++++++++++++++++++
>> +----------
>> drivers/edac/mpc85xx_edac.h | 3 +++
>> 3 files changed, 34 insertions(+), 13 deletions(-)
>
> [snip]
>
>> /************************ MC SYSFS parts
>> ***********************************/
>>
>> @@ -738,7 +740,8 @@ static irqreturn_t mpc85xx_mc_isr(int irq, void
>> *dev_id)
>> return IRQ_HANDLED;
>> }
>>
>> -static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci)
>> +static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci,
>> + const struct of_device_id *match)
>> {
>> struct mpc85xx_mc_pdata *pdata = mci->pvt_info;
>> struct csrow_info *csrow;
>> @@ -784,18 +787,26 @@ static void __devinit mpc85xx_init_csrows(struct
>> mem_ctl_info *mci)
>> }
>>
>> for (index = 0; index < mci->nr_csrows; index++) {
>> - u32 start;
>> - u32 end;
>> + u32 start, end, extra;
>>
>> csrow = &mci->csrows[index];
>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>> (index * MPC85XX_MC_CS_BNDS_OFS));
>> - start = (cs_bnds & 0xfff0000) << 4;
>> - end = ((cs_bnds & 0xfff) << 20);
>> +
>> + if (match->data && match->data == MPC83xx) {
>> + start = (cs_bnds & 0x00ff0000) << 8;
>> + end = (cs_bnds & 0x000000ff) << 24;
>> + extra = 0x00ffffff;
>> + } else {
>> + start = (cs_bnds & 0x0fff0000) << 4;
>> + end = (cs_bnds & 0x00000fff) << 20;
>> + extra = 0x000fffff;
>> + }
>
> I don't understand this at all.. The only difference between 83xx & 85xx
> is that we should have an extra 4-bits for 36-bit physical addresses.
>
> We should be able to write this code in such a way that it works for
> both 83xx & 85xx.
>
> start = (cs_bnds & 0xffff0000) >> 16;
> end = (cs_bnds & 0xffff);
>
> if (start == end)
> continue;
> start <<= (20 - PAGE_SHIFT);
> end <<= (20 - PAGE_SHIFT);
> end |= (1 << (20 - PAGE_SHIFT)) - 1;
>
Sorry, I don't know a thing about PAGE_SHIFT. Looking in
arch/powerpc/platforms/Kconfig.cputype, PPC_85xx doesn't seem to imply a
change in PAGE_SIZE, which changes the PAGE_SHIFT in
arch/powerpc/include/asm/page.h.
Also, are you sure you cannot use 4K pages on an 85xx? If you can use 4K
pages on 85xx, then PAGE_SHIFT == 12, and your solution breaks.
I admit I don't know much about all of the different powerpc platforms.
Ira
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Kumar Gala @ 2009-07-08 20:58 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <20090708193355.GE2827@ovro.caltech.edu>
On Jul 8, 2009, at 2:33 PM, Ira W. Snyder wrote:
> On Wed, Jul 08, 2009 at 01:09:39PM -0500, Kumar Gala wrote:
>>
>> On Jul 8, 2009, at 11:19 AM, Ira W. Snyder wrote:
>>
>>> Add support for the Freescale MPC83xx memory controller to the
>>> existing
>>> driver for the Freescale MPC85xx memory controller. The only
>>> difference
>>> between the two processors are in the CS_BNDS register parsing code.
>>>
>>> The L2 cache controller does not exist on the MPC83xx, but the OF
>>> subsystem
>>> will not use the driver if the device is not present in the OF
>>> device
>>> tree.
>>>
>>> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
>>> ---
>>>
>>> This was tested on an MPC8349EMDS-based board.
>>>
>>> I don't really like how the MCE disable works on mpc85xx (clearing
>>> the
>>> HID1 register), but this can be revisited when mpc86xx support gets
>>> added. It sucks to have this happen before the probe() routine is
>>> called
>>> and we know what kind of hardware we're actually running on.
>>>
>>> drivers/edac/Kconfig | 6 +++---
>>> drivers/edac/mpc85xx_edac.c | 38 +++++++++++++++++++++++++++
>>> +----------
>>> drivers/edac/mpc85xx_edac.h | 3 +++
>>> 3 files changed, 34 insertions(+), 13 deletions(-)
>>
>> [snip]
>>
>>> /************************ MC SYSFS parts
>>> ***********************************/
>>>
>>> @@ -738,7 +740,8 @@ static irqreturn_t mpc85xx_mc_isr(int irq, void
>>> *dev_id)
>>> return IRQ_HANDLED;
>>> }
>>>
>>> -static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci)
>>> +static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci,
>>> + const struct of_device_id *match)
>>> {
>>> struct mpc85xx_mc_pdata *pdata = mci->pvt_info;
>>> struct csrow_info *csrow;
>>> @@ -784,18 +787,26 @@ static void __devinit
>>> mpc85xx_init_csrows(struct
>>> mem_ctl_info *mci)
>>> }
>>>
>>> for (index = 0; index < mci->nr_csrows; index++) {
>>> - u32 start;
>>> - u32 end;
>>> + u32 start, end, extra;
>>>
>>> csrow = &mci->csrows[index];
>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>> - start = (cs_bnds & 0xfff0000) << 4;
>>> - end = ((cs_bnds & 0xfff) << 20);
>>> +
>>> + if (match->data && match->data == MPC83xx) {
>>> + start = (cs_bnds & 0x00ff0000) << 8;
>>> + end = (cs_bnds & 0x000000ff) << 24;
>>> + extra = 0x00ffffff;
>>> + } else {
>>> + start = (cs_bnds & 0x0fff0000) << 4;
>>> + end = (cs_bnds & 0x00000fff) << 20;
>>> + extra = 0x000fffff;
>>> + }
>>
>> I don't understand this at all.. The only difference between 83xx &
>> 85xx
>> is that we should have an extra 4-bits for 36-bit physical addresses.
>>
>> We should be able to write this code in such a way that it works for
>> both 83xx & 85xx.
>>
>> start = (cs_bnds & 0xffff0000) >> 16;
>> end = (cs_bnds & 0xffff);
>>
>> if (start == end)
>> continue;
>> start <<= (20 - PAGE_SHIFT);
>> end <<= (20 - PAGE_SHIFT);
>> end |= (1 << (20 - PAGE_SHIFT)) - 1;
>>
>
> Sorry, I don't know a thing about PAGE_SHIFT. Looking in
> arch/powerpc/platforms/Kconfig.cputype, PPC_85xx doesn't seem to
> imply a
> change in PAGE_SIZE, which changes the PAGE_SHIFT in
> arch/powerpc/include/asm/page.h.
>
> Also, are you sure you cannot use 4K pages on an 85xx? If you can
> use 4K
> pages on 85xx, then PAGE_SHIFT == 12, and your solution breaks.
>
> I admit I don't know much about all of the different powerpc
> platforms.
PAGE_SHIFT is the same.. I was folding in the code from below the diff:
csrow->first_page = start >> PAGE_SHIFT;
csrow->last_page = end >> PAGE_SHIFT;
into the calculation of start/end. I know PAGE_SHIFT is a minimum 12
on any PPC based system (and at this point its always 12 on 85xx/
83xx). The idea is to ensure that when shift start/end up that it
still fits in 32-bits. This is to handle the case of >4G of memory.
- k
^ permalink raw reply
* Re: [PATCH] ehca: use port autodetect mode as default
From: Roland Dreier @ 2009-07-08 22:26 UTC (permalink / raw)
To: Alexander Schmidt
Cc: of-ewg, lkml, linuxppc-dev, Christoph Raisch, of-general,
Hoang-Nam Nguyen, Stefan Roscher
In-Reply-To: <20090707160639.6b45bf4d@BL3D1974.boeblingen.de.ibm.com>
looks good, applied
^ permalink raw reply
* binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-08 22:41 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
Alan,
We are seeing an issue w/ld and kernel linking of 32-bit kernels.
The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not
providing the proper address for _end.
Building stock v2.6.30 w/the mpc85xx_defconfig we get:
00001000 A _end
Using 2.18.50.20080215 we get:
c0680000 A _end
If we modify the linker script:
_end2 = .;
_end3 = ALIGN(4096);
_end4 = ALIGN(PAGE_SIZE);
. = ALIGN(PAGE_SIZE);
_end = . ;
PROVIDE32 (end = .);
and the result is:
00001000 A _end
c067f678 A _end2
c0680000 A _end3
c0680000 A _end4
I used an old version of linker (2.18.50.20080215) and re-linked:
c067f678 A _end2
c0680000 A _end
c0680000 A _end3
c0680000 A _end4
Any ideas?
- k
^ permalink raw reply
* Re: switching from initrd to initramfs
From: Mikhail Zaturenskiy @ 2009-07-08 22:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <97dd5fd20907081225g2dc4a8dep74407ece12223162@mail.gmail.com>
> I was hoping to convert this working initrd to initramfs before I try
> and create my own initrd, I'm still learning about this process. I got
> this to work yesterday morning, but I'm not sure what changed or what
> I'm doing differently...
> Can somebody help me figure out what's missing?
Never mind, got it! :) For reference, here is what I did:
First I made a custom init file called "init_mz" with the following contents:
#!/bin/sh
echo "hello! processing init_mz"
#Create all the symlinks to /bin/busybox
echo "installing busybox links..."
busybox --install -s
echo "done installing busybox links..."
#Mount things needed by this script
echo "mounting proc..."
mount -t proc proc /proc
echo "done mounting proc..."
echo "mounting sysfs..."
mount -t sysfs sysfs /sys
echo "done mounting sysfs..."
#Create device nodes
echo "creating /dev nodes..."
mknod /dev/null c 1 3
mknod /dev/tty c 5 0
mdev -s
echo "done creating /dev nodes..."
echo "exec-ing sh..."
exec /bin/sh
At this point booting with the "rdinit=/init_mz" kernel argument worked.
Then I removed pretty much everything unnecessary from my root tree,
cross-compiled a busybox v1.14.2 with defconfg (except
statically-linked), and created the few necessary links, so my tree
looks like this:
************
|-- bin
| |-- busybox
| |-- echo -> busybox
| |-- mount -> busybox
| `-- sh -> busybox
|-- dev
|-- init_mz
|-- proc
|-- sbin
|-- sys
`-- usr
|-- bin
`-- sbin
**************
I could probably also get rid of /dev /proc /sbin /sys /usr* /bin/echo
and /bin/mount and just create those on the fly in the init_mz file.
I'm building the initramfs ramdisk using:
find | cpio -ovc | gzip -v9 > ../initramfs.cpio.gz
mkimage -T ramdisk -C gzip -n 'Test Ramdisk Image' -d
../initramfs.cpio.gz ../uCpio
For my kernel arguments I'm using "console=ttyCPM0,9600n8
root=/dev/ram rw rdinit=/init_mz" and that is all! I now have a
functional initramfs that's 0.97MB large.
For a while I was confused because "ls" output had file names with
strange symbols such as "1;34mbin0m" for "bin", but I figured out that
it's because supposedly those represent font colors and I'm using
HyperTerminal which doesn't support them.
I hope somebody will find this useful.
Mikhail Zaturenskiy
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Alan Modra @ 2009-07-08 23:39 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <09159ADA-39F9-419E-AE46-4CFAE612AFB9@kernel.crashing.org>
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
> If we modify the linker script:
>
> _end2 = .;
> _end3 = ALIGN(4096);
> _end4 = ALIGN(PAGE_SIZE);
> . = ALIGN(PAGE_SIZE);
> _end = . ;
> PROVIDE32 (end = .);
>
> and the result is:
>
> 00001000 A _end
> c067f678 A _end2
> c0680000 A _end3
> c0680000 A _end4
Possibly some section with a zero vma is being placed before _end.
Generate a link map to see if this is so.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* [PATCH] powerpc: fix booke user_disable_single_step()
From: Dave Kleikamp @ 2009-07-08 23:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev
On booke processors, gdb is seeing spurious SIGTRAPs when setting a
watchpoint.
user_disable_single_step() simply quits when the DAC is non-zero. It should
be clearing the DBCR0_IC and DBCR0_BT bits from the dbcr0 register and
TIF_SINGLESTEP from the thread flag.
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 9fa2c7d..ef14988 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -736,15 +736,16 @@ void user_disable_single_step(struct task_struct *task)
{
struct pt_regs *regs = task->thread.regs;
-
-#if defined(CONFIG_BOOKE)
- /* If DAC then do not single step, skip */
- if (task->thread.dabr)
- return;
-#endif
-
if (regs != NULL) {
-#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+#if defined(CONFIG_BOOKE)
+ /* If DAC don't clear DBCRO_IDM or MSR_DE */
+ if (task->thread.dabr)
+ task->thread.dbcr0 &= ~(DBCR0_IC | DBCR0_BT);
+ else {
+ task->thread.dbcr0 &= ~(DBCR0_IC | DBCR0_BT | DBCR0_IDM);
+ regs->msr &= ~MSR_DE;
+ }
+#elif defined(CONFIG_40x)
task->thread.dbcr0 &= ~(DBCR0_IC | DBCR0_BT | DBCR0_IDM);
regs->msr &= ~MSR_DE;
#else
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply related
* Re: [PATCH] powerpc: fix booke user_disable_single_step()
From: Josh Boyer @ 2009-07-08 23:48 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: ppc-dev
In-Reply-To: <1247096778.22069.1.camel@norville.austin.ibm.com>
On Wed, Jul 08, 2009 at 06:46:18PM -0500, Dave Kleikamp wrote:
>On booke processors, gdb is seeing spurious SIGTRAPs when setting a
>watchpoint.
>
>user_disable_single_step() simply quits when the DAC is non-zero. It should
>be clearing the DBCR0_IC and DBCR0_BT bits from the dbcr0 register and
>TIF_SINGLESTEP from the thread flag.
>
>Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
I'll test this first thing in the morning. At first glance it looks pretty
good.
josh
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-09 2:40 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <20090708233954.GA3181@bubble.grove.modra.org>
On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:
> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>> If we modify the linker script:
>>
>> _end2 = .;
>> _end3 = ALIGN(4096);
>> _end4 = ALIGN(PAGE_SIZE);
>> . = ALIGN(PAGE_SIZE);
>> _end = . ;
>> PROVIDE32 (end = .);
>>
>> and the result is:
>>
>> 00001000 A _end
>> c067f678 A _end2
>> c0680000 A _end3
>> c0680000 A _end4
>
> Possibly some section with a zero vma is being placed before _end.
> Generate a link map to see if this is so.
In the broken (ALIGN) case we have:
.bss 0x00000000c05d3018 0x0 lib/lib.a(klist.o)
.bss 0x00000000c05d3018 0x0 lib/lib.a(sha1.o)
.bss 0x00000000c05d3018 0x0 .tmp_kallsyms3.o
*(COMMON)
0x00000000c05d3018 __bss_stop = .
.PPC.EMB.apuinfo
0x0000000000000000 0x24
.PPC.EMB.apuinfo
0x0000000000000000 0x1c arch/powerpc/kernel/
head_fsl_booke.o
.PPC.EMB.apuinfo
In the non-ALIGN case we have:
0x00000000c05d3018 _end = .
0x00000000c05d3018 PROVIDE (end, .)
LOAD arch/powerpc/kernel/head_fsl_booke.o
LOAD init/built-in.o
START GROUP
LOAD usr/built-in.o
LOAD arch/powerpc/kernel/built-in.o
LOAD arch/powerpc/mm/built-in.o
LOAD arch/powerpc/lib/built-in.o
LOAD arch/powerpc/sysdev/built-in.o
LOAD arch/powerpc/platforms/built-in.o
LOAD arch/powerpc/math-emu/built-in.o
LOAD kernel/built-in.o
LOAD mm/built-in.o
LOAD fs/built-in.o
LOAD ipc/built-in.o
LOAD security/built-in.o
LOAD crypto/built-in.o
LOAD block/built-in.o
LOAD lib/lib.a
LOAD lib/built-in.o
LOAD drivers/built-in.o
LOAD sound/built-in.o
LOAD firmware/built-in.o
LOAD net/built-in.o
END GROUP
LOAD .tmp_kallsyms3.o
OUTPUT(vmlinux elf32-powerpc)
.PPC.EMB.apuinfo
0x0000000000000000 0x24
.PPC.EMB.apuinfo
0x0000000000000000 0x1c arch/powerpc/kernel/
head_fsl_booke.o
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-09 3:39 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <20090708233954.GA3181@bubble.grove.modra.org>
On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:
> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>> If we modify the linker script:
>>
>> _end2 = .;
>> _end3 = ALIGN(4096);
>> _end4 = ALIGN(PAGE_SIZE);
>> . = ALIGN(PAGE_SIZE);
>> _end = . ;
>> PROVIDE32 (end = .);
>>
>> and the result is:
>>
>> 00001000 A _end
>> c067f678 A _end2
>> c0680000 A _end3
>> c0680000 A _end4
>
> Possibly some section with a zero vma is being placed before _end.
> Generate a link map to see if this is so.
Playing with this further I think its related to the -me500 option we
pass and thus wondering if its something with the APU section
handling. If I hack the kernel up a little and pass -m440 instead
things seem to be ok.
- k
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-09 3:52 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, Edmar Wienskoski-RA8797,
Alan Modra, bug-binutils
In-Reply-To: <E6EB8DA7-8B38-4C97-BE3C-4649DFA295C8@kernel.crashing.org>
On Jul 8, 2009, at 10:39 PM, Kumar Gala wrote:
>
> On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:
>
>> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>>> If we modify the linker script:
>>>
>>> _end2 = .;
>>> _end3 = ALIGN(4096);
>>> _end4 = ALIGN(PAGE_SIZE);
>>> . = ALIGN(PAGE_SIZE);
>>> _end = . ;
>>> PROVIDE32 (end = .);
>>>
>>> and the result is:
>>>
>>> 00001000 A _end
>>> c067f678 A _end2
>>> c0680000 A _end3
>>> c0680000 A _end4
>>
>> Possibly some section with a zero vma is being placed before _end.
>> Generate a link map to see if this is so.
>
> Playing with this further I think its related to the -me500 option
> we pass and thus wondering if its something with the APU section
> handling. If I hack the kernel up a little and pass -m440 instead
> things seem to be ok.
To further verify this if I switch the -me500 to -mspe and build
things seem to be ok. This further points at some APU section related
bug.
- k
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Alan Modra @ 2009-07-09 4:40 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <AB02ECF3-9C72-436B-A946-CBCCD3859762@kernel.crashing.org>
On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
> To further verify this if I switch the -me500 to -mspe and build things
> seem to be ok. This further points at some APU section related bug.
Like omitting .PPC.EMB.apuinfo from your kernel link script? See the
ld info doc on orphan sections.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply
* SPI driver on mpc5121
From: Canella Matteo @ 2009-07-09 9:30 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]
Hi,
I'm on a mpc5121 platform, kernel 2.6.24.6, and I'm using the mpc512x_psc_spi driver to communicate with a touch screen controller.
I'm sending commands and reading data from the controller using 24-bit packet (3 bytes).
The speed of the SPI is set to 640 KHz.
I thought that I would need 8/640K = 12,5 us each byte I send, but this is not true.
I'm verifying the time needed by mpc512x_psc_spi_transfer_rxtx function in order to send one byte toggling a digital output when it sets the TX/RX flags (after it copies data in the transmission buffer) and toggling the output again when the empty buffer interrupt is triggered.
I see that the actual 12,5us data transfer is preceded by a 20us delay and followed by another 15,6us delay. So the transfer is done in almost 50 us.
Is this a normal behavior? Does the PSC controller need this overhead in the transfer time?
DSCKI and DTL delays are set to zero.
Another doubt I have:
In mpc512x_psc_spi_transfer_rxtx, Mode Register 2 of the PSC is set to zero. This is done (as manual says) by access to MR1 (by a read) and then write a zero on the same address.:
in_8(&psc->mode);
mdelay(1);
out_8(&psc->mode, 0x0);
mdelay(1);
I don't understand why a 1ms delay is needed. The manual doesn't say anything about this.
I tried to comment out these delays and anyway it seems to work correctly.
Best regards,
Matteo Canella
[-- Attachment #2: Type: text/html, Size: 5097 bytes --]
^ permalink raw reply
* Re: ALSA fixes for non-coherent ppc32 again
From: Gerhard Pircher @ 2009-07-09 11:22 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev
In-Reply-To: <s5hfxd7qn49.wl%tiwai@suse.de>
-------- Original-Nachricht --------
> Datum: Wed, 08 Jul 2009 16:13:10 +0200
> Von: Takashi Iwai <tiwai@suse.de>
> An: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Gerhard Pircher <gerhard_pircher@gmx.net>, linuxppc-dev@ozlabs.org
> Betreff: Re: ALSA fixes for non-coherent ppc32 again
> At Wed, 08 Jul 2009 13:01:50 +1000,
> Benjamin Herrenschmidt wrote:
> >
> > On Mon, 2009-06-22 at 08:34 +1000, Benjamin Herrenschmidt wrote:
> > > On Sun, 2009-06-21 at 20:18 +0200, Gerhard Pircher wrote:
> > > > Hi,
> > > >
> > > > Takashi Iwai posted patches to make ALSA work on non-coherent
> > > > PPC32 systems (almost exactly) a year ago. See here:
> > > >
> > > > http://www.nabble.com/-PATCH-0-3--ALSA-fixes-for-non-coherent-ppc32-to17980027.html#a17980027
> > > >
> > > > As far as I can see these patches never went upstream. Where
> > > > there any objections or did we just forget about them? It would
> > > > be cool, if the patches could be merged now, as at least two
> > > > platforms need this bugfix (namely Sam440 and AmigaOne).
> > >
> > > I definitely forgot about those... But I'm fine with what Takashi
> > > did for now, I can always make the powerpc helper for
> > > dma_mmap_coherent() smarter later on if necessary.
> >
> > BTW. Can you guys send a "final" patch for adding mmap_coherent to
> > powerpc ? Please make so that the dma_mmap_coherent() function doesn't
> > explose if dma_ops->mmap_coherent is NULL though (either fail
> > gracefully or fallback to some standard mmap).
>
> The attached is the revised patch. It falls backs to the standard
> mmap.
>
> The whole patch series are found in test/dma-fix branch of sound git
> tree below:
> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> test/dma-fix
>
> I had no time to play cross-build yet, so it'd be helpful if someone
> can test it...
> (BTW, any good minimal gcc and binutils package for kernel builds for
> PPC32?)
Okay, I cross-build it on a x86 machine and tested it on my AmigaOne with
the VIA686 onboard sound and a Soundblaster 5.1. It worked fine after I
applied the "ALSA: Fix SG-buffer DMA with non-coherent architectures"
patch.
Thanks!
Gerhard
--
Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate
für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02
^ permalink raw reply
* Re: [PATCH]: [MPC5200] Add ATA DMA support
From: Roman Fietze @ 2009-07-09 14:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fa686aa40901050731i3fb3ee2er221af3b174051aa@mail.gmail.com>
Hallo,
On Monday 05 January 2009 16:31:33 Grant Likely wrote:
> DMA support is now in mainline, but it is disabled by
> default ...
I had problems using ATA DMA on an own MPC5200B board, too. This board
has no problems at all using DMA33 with DENX 2.4.25, with all kinds of
automotive disks from 20 to 40GB. I definitively tested all three
listed drives below, but we are using other drives as well
(e.g. Hitachi 20 and 40 GB variants).
On exactly those boards I'm now running the 2.6.30 from DENX. The
following harddisks work well on this board, including network traffic
in parallel (which sometimes was a problem on old kernels or MPC5200's
w/o a 'B'):
=2D Toshiba MK4036GA
=2D Hitachi HEJ423020F9AT00
But an old 20GB Seagate ST940813AM shows the following problem when
booting the system:
PHY: f0003000:00 - Link is Up - 100/Half
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
ata1.00: BMDMA stat 0x5
ata1.00: cmd ca/00:08:1f:10:9c/00:00:00:00:00/e0 tag 0 dma 4096 out
res 51/84:08:1f:10:9c/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { ICRC ABRT }
ata1: soft resetting link
ata1.00: configured for UDMA/33
ata1: EH complete
I think this is similar to the errors reported after the ATA DMA patch
for the MPC5200B was introduced in this mailing list.
I even tried to use some modified timings from the 2.4.25 kernel, but
(of course) w/o success.
Are there any other patches I should try? Anything I could do to help
you to get this problem fixed?
Roman
=2D-=20
Roman Fietze Telemotive AG B=FCro M=FChlhausen
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-09 15:22 UTC (permalink / raw)
To: Alan Modra
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, bug-binutils,
Edmar Wienskoski-RA8797
In-Reply-To: <20090709044007.GB3181@bubble.grove.modra.org>
On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
> On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
>> To further verify this if I switch the -me500 to -mspe and build
>> things
>> seem to be ok. This further points at some APU section related bug.
>
> Like omitting .PPC.EMB.apuinfo from your kernel link script? See the
> ld info doc on orphan sections.
Ok, not terribly enlightening, but why would .PPC.EMB.apuinfo sections
be different than something like .debug sections which we also dont
list in the linker script.
- k
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-09 16:58 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <6CF38C94-45EB-4FD7-B8E0-B9899F4EEF90@kernel.crashing.org>
On Wed, Jul 08, 2009 at 03:58:02PM -0500, Kumar Gala wrote:
>
> On Jul 8, 2009, at 2:33 PM, Ira W. Snyder wrote:
>
>> On Wed, Jul 08, 2009 at 01:09:39PM -0500, Kumar Gala wrote:
>>>
>>> On Jul 8, 2009, at 11:19 AM, Ira W. Snyder wrote:
>>>
>>>> Add support for the Freescale MPC83xx memory controller to the
>>>> existing
>>>> driver for the Freescale MPC85xx memory controller. The only
>>>> difference
>>>> between the two processors are in the CS_BNDS register parsing code.
>>>>
>>>> The L2 cache controller does not exist on the MPC83xx, but the OF
>>>> subsystem
>>>> will not use the driver if the device is not present in the OF
>>>> device
>>>> tree.
>>>>
>>>> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
>>>> ---
>>>>
>>>> This was tested on an MPC8349EMDS-based board.
>>>>
>>>> I don't really like how the MCE disable works on mpc85xx (clearing
>>>> the
>>>> HID1 register), but this can be revisited when mpc86xx support gets
>>>> added. It sucks to have this happen before the probe() routine is
>>>> called
>>>> and we know what kind of hardware we're actually running on.
>>>>
>>>> drivers/edac/Kconfig | 6 +++---
>>>> drivers/edac/mpc85xx_edac.c | 38 +++++++++++++++++++++++++++
>>>> +----------
>>>> drivers/edac/mpc85xx_edac.h | 3 +++
>>>> 3 files changed, 34 insertions(+), 13 deletions(-)
>>>
>>> [snip]
>>>
>>>> /************************ MC SYSFS parts
>>>> ***********************************/
>>>>
>>>> @@ -738,7 +740,8 @@ static irqreturn_t mpc85xx_mc_isr(int irq, void
>>>> *dev_id)
>>>> return IRQ_HANDLED;
>>>> }
>>>>
>>>> -static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci)
>>>> +static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci,
>>>> + const struct of_device_id *match)
>>>> {
>>>> struct mpc85xx_mc_pdata *pdata = mci->pvt_info;
>>>> struct csrow_info *csrow;
>>>> @@ -784,18 +787,26 @@ static void __devinit
>>>> mpc85xx_init_csrows(struct
>>>> mem_ctl_info *mci)
>>>> }
>>>>
>>>> for (index = 0; index < mci->nr_csrows; index++) {
>>>> - u32 start;
>>>> - u32 end;
>>>> + u32 start, end, extra;
>>>>
>>>> csrow = &mci->csrows[index];
>>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>>> - start = (cs_bnds & 0xfff0000) << 4;
>>>> - end = ((cs_bnds & 0xfff) << 20);
>>>> +
>>>> + if (match->data && match->data == MPC83xx) {
>>>> + start = (cs_bnds & 0x00ff0000) << 8;
>>>> + end = (cs_bnds & 0x000000ff) << 24;
>>>> + extra = 0x00ffffff;
>>>> + } else {
>>>> + start = (cs_bnds & 0x0fff0000) << 4;
>>>> + end = (cs_bnds & 0x00000fff) << 20;
>>>> + extra = 0x000fffff;
>>>> + }
>>>
>>> I don't understand this at all.. The only difference between 83xx &
>>> 85xx
>>> is that we should have an extra 4-bits for 36-bit physical addresses.
>>>
>>> We should be able to write this code in such a way that it works for
>>> both 83xx & 85xx.
>>>
>>> start = (cs_bnds & 0xffff0000) >> 16;
>>> end = (cs_bnds & 0xffff);
>>>
>>> if (start == end)
>>> continue;
>>> start <<= (20 - PAGE_SHIFT);
>>> end <<= (20 - PAGE_SHIFT);
>>> end |= (1 << (20 - PAGE_SHIFT)) - 1;
>>>
>>
>> Sorry, I don't know a thing about PAGE_SHIFT. Looking in
>> arch/powerpc/platforms/Kconfig.cputype, PPC_85xx doesn't seem to imply
>> a
>> change in PAGE_SIZE, which changes the PAGE_SHIFT in
>> arch/powerpc/include/asm/page.h.
>>
>> Also, are you sure you cannot use 4K pages on an 85xx? If you can use
>> 4K
>> pages on 85xx, then PAGE_SHIFT == 12, and your solution breaks.
>>
>> I admit I don't know much about all of the different powerpc
>> platforms.
>
> PAGE_SHIFT is the same.. I was folding in the code from below the diff:
>
> csrow->first_page = start >> PAGE_SHIFT;
> csrow->last_page = end >> PAGE_SHIFT;
>
> into the calculation of start/end. I know PAGE_SHIFT is a minimum 12 on
> any PPC based system (and at this point its always 12 on 85xx/83xx). The
> idea is to ensure that when shift start/end up that it still fits in
> 32-bits. This is to handle the case of >4G of memory.
>
Hello Kumar,
I must not understand something going on here. Your proposed code
doesn't work at all on my board. The
/sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
The attached patch DOES work on my board, but I'm confident that it does
NOT work on a system with PAGE_SIZE != 4096. Any idea what I did wrong?
If I'm reading things correctly:
csrow->first_page full address of the first page (NOT pfn)
csrow->last_page full address of the last page (NOT pfn)
csrow->nr_pages number of pages
The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the size_mb
sysfs value.
If csrow->first_page and csrow->last_page ARE supposed to be the pfn,
then I think the original code got it wrong, and the calculation for
csrow->nr_pages needs to be changed.
Thanks,
Ira
>From a442c2e5a1cfbe29ea9d2ea7d45237677ff7899d Mon Sep 17 00:00:00 2001
From: Ira W. Snyder <iws@ovro.caltech.edu>
Date: Wed, 8 Jul 2009 08:59:16 -0700
Subject: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
Add support for the Freescale MPC83xx memory controller to the existing
driver for the Freescale MPC85xx memory controller. The only difference
between the two processors are in the CS_BNDS register parsing code, which
has been changed so it will work on both processors.
The L2 cache controller does not exist on the MPC83xx, but the OF subsystem
will not use the driver if the device is not present in the OF device tree.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
drivers/edac/Kconfig | 6 +++---
drivers/edac/mpc85xx_edac.c | 30 ++++++++++++++++++++----------
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 4339b1a..78303f9 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -176,11 +176,11 @@ config EDAC_I5100
San Clemente MCH.
config EDAC_MPC85XX
- tristate "Freescale MPC85xx"
- depends on EDAC_MM_EDAC && FSL_SOC && MPC85xx
+ tristate "Freescale MPC83xx / MPC85xx"
+ depends on EDAC_MM_EDAC && FSL_SOC && (PPC_83xx || MPC85xx)
help
Support for error detection and correction on the Freescale
- MPC8560, MPC8540, MPC8548
+ MPC8349, MPC8560, MPC8540, MPC8548
config EDAC_MV64X60
tristate "Marvell MV64x60"
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index b4f5c63..e4832b4 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -43,7 +43,9 @@ static u32 orig_pci_err_en;
#endif
static u32 orig_l2_err_disable;
+#ifdef CONFIG_MPC85xx
static u32 orig_hid1[2];
+#endif
/************************ MC SYSFS parts ***********************************/
@@ -790,18 +792,19 @@ static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci)
csrow = &mci->csrows[index];
cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
(index * MPC85XX_MC_CS_BNDS_OFS));
- start = (cs_bnds & 0xfff0000) << 4;
- end = ((cs_bnds & 0xfff) << 20);
- if (start)
- start |= 0xfffff;
- if (end)
- end |= 0xfffff;
+
+ start = (cs_bnds & 0xffff0000) >> 16;
+ end = (cs_bnds & 0x0000ffff);
if (start == end)
continue; /* not populated */
- csrow->first_page = start >> PAGE_SHIFT;
- csrow->last_page = end >> PAGE_SHIFT;
+ start <<= PAGE_SHIFT;
+ end <<= PAGE_SHIFT;
+ end |= (1 << PAGE_SHIFT) - 1;
+
+ csrow->first_page = start;
+ csrow->last_page = end;
csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
csrow->grain = 8;
csrow->mtype = mtype;
@@ -986,6 +989,7 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{ .compatible = "fsl,mpc8560-memory-controller", },
{ .compatible = "fsl,mpc8568-memory-controller", },
{ .compatible = "fsl,mpc8572-memory-controller", },
+ { .compatible = "fsl,mpc8349-memory-controller", },
{},
};
@@ -1001,13 +1005,13 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
},
};
-
+#ifdef CONFIG_MPC85xx
static void __init mpc85xx_mc_clear_rfxe(void *data)
{
orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x20000));
}
-
+#endif
static int __init mpc85xx_mc_init(void)
{
@@ -1040,26 +1044,32 @@ static int __init mpc85xx_mc_init(void)
printk(KERN_WARNING EDAC_MOD_STR "PCI fails to register\n");
#endif
+#ifdef CONFIG_MPC85xx
/*
* need to clear HID1[RFXE] to disable machine check int
* so we can catch it
*/
if (edac_op_state == EDAC_OPSTATE_INT)
on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+#endif
return 0;
}
module_init(mpc85xx_mc_init);
+#ifdef CONFIG_MPC85xx
static void __exit mpc85xx_mc_restore_hid1(void *data)
{
mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
}
+#endif
static void __exit mpc85xx_mc_exit(void)
{
+#ifdef CONFIG_MPC85xx
on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+#endif
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
#endif
--
1.5.4.3
^ permalink raw reply related
* Re: binutils 2.19 issue with kernel link
From: Dale Farnsworth @ 2009-07-09 16:39 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <09159ADA-39F9-419E-AE46-4CFAE612AFB9@kernel.crashing.org>
On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
> We are seeing an issue w/ld and kernel linking of 32-bit kernels.
>
> The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not providing
> the proper address for _end.
>
> Building stock v2.6.30 w/the mpc85xx_defconfig we get:
>
> 00001000 A _end
>
> Using 2.18.50.20080215 we get:
>
> c0680000 A _end
>
> If we modify the linker script:
>
> _end2 = .;
> _end3 = ALIGN(4096);
> _end4 = ALIGN(PAGE_SIZE);
> . = ALIGN(PAGE_SIZE);
> _end = . ;
> PROVIDE32 (end = .);
>
> and the result is:
>
> 00001000 A _end
> c067f678 A _end2
> c0680000 A _end3
> c0680000 A _end4
>
> I used an old version of linker (2.18.50.20080215) and re-linked:
>
> c067f678 A _end2
> c0680000 A _end
> c0680000 A _end3
> c0680000 A _end4
>
> Any ideas?
We have found the following workaround to be useful.
Thanks to Andrew Jenner at Code Sourcery.
-Dale
Dale Farnsworth
MontaVista Software
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index acf237f..34b0181 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -282,4 +282,7 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
_end = . ;
PROVIDE32 (end = .);
+
+#undef PPC
+ .PPC.EMB.apuinfo 0 : { *(.PPC.EMB.apuinfo) }
}
^ permalink raw reply related
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Kumar Gala @ 2009-07-09 17:58 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <20090709165844.GB29383@ovro.caltech.edu>
> Hello Kumar,
>
> I must not understand something going on here. Your proposed code
> doesn't work at all on my board. The
> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
What does it come out as? How much memory do you have in the system?
> The attached patch DOES work on my board, but I'm confident that it
> does
> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
> wrong?
>
> If I'm reading things correctly:
> csrow->first_page full address of the first page (NOT pfn)
> csrow->last_page full address of the last page (NOT pfn)
> csrow->nr_pages number of pages
>
> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the size_mb
> sysfs value.
>
> If csrow->first_page and csrow->last_page ARE supposed to be the pfn,
> then I think the original code got it wrong, and the calculation for
> csrow->nr_pages needs to be changed.
>
> Thanks,
> Ira
[snip]
> /************************ MC SYSFS parts
> ***********************************/
>
> @@ -790,18 +792,19 @@ static void __devinit
> mpc85xx_init_csrows(struct mem_ctl_info *mci)
> csrow = &mci->csrows[index];
> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
> (index * MPC85XX_MC_CS_BNDS_OFS));
> - start = (cs_bnds & 0xfff0000) << 4;
> - end = ((cs_bnds & 0xfff) << 20);
> - if (start)
> - start |= 0xfffff;
> - if (end)
> - end |= 0xfffff;
can you printk what cs_bnds values are in your setup.
> +
> + start = (cs_bnds & 0xffff0000) >> 16;
> + end = (cs_bnds & 0x0000ffff);
>
> if (start == end)
> continue; /* not populated */
>
> - csrow->first_page = start >> PAGE_SHIFT;
> - csrow->last_page = end >> PAGE_SHIFT;
> + start <<= PAGE_SHIFT;
> + end <<= PAGE_SHIFT;
> + end |= (1 << PAGE_SHIFT) - 1;
> +
> + csrow->first_page = start;
> + csrow->last_page = end;
This seems odd to me... I can't believe this is working out properly.
>
> csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
> csrow->grain = 8;
> csrow->mtype = mtype;
>
Lets get some real values on the table for your system so I can get a
sense of what's really going on.
- k
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Kumar Gala @ 2009-07-09 18:14 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev
In-Reply-To: <20090709163900.GA6549@farnsworth.org>
On Jul 9, 2009, at 11:39 AM, Dale Farnsworth wrote:
> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>> We are seeing an issue w/ld and kernel linking of 32-bit kernels.
>>
>> The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not
>> providing
>> the proper address for _end.
>>
>> Building stock v2.6.30 w/the mpc85xx_defconfig we get:
>>
>> 00001000 A _end
>>
>> Using 2.18.50.20080215 we get:
>>
>> c0680000 A _end
>>
>> If we modify the linker script:
>>
>> _end2 = .;
>> _end3 = ALIGN(4096);
>> _end4 = ALIGN(PAGE_SIZE);
>> . = ALIGN(PAGE_SIZE);
>> _end = . ;
>> PROVIDE32 (end = .);
>>
>> and the result is:
>>
>> 00001000 A _end
>> c067f678 A _end2
>> c0680000 A _end3
>> c0680000 A _end4
>>
>> I used an old version of linker (2.18.50.20080215) and re-linked:
>>
>> c067f678 A _end2
>> c0680000 A _end
>> c0680000 A _end3
>> c0680000 A _end4
>>
>> Any ideas?
>
> We have found the following workaround to be useful.
> Thanks to Andrew Jenner at Code Sourcery.
>
> -Dale
>
> Dale Farnsworth
> MontaVista Software
>
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/
> vmlinux.lds.S
> index acf237f..34b0181 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -282,4 +282,7 @@ SECTIONS
> . = ALIGN(PAGE_SIZE);
> _end = . ;
> PROVIDE32 (end = .);
> +
> +#undef PPC
> + .PPC.EMB.apuinfo 0 : { *(.PPC.EMB.apuinfo) }
> }
Is there any plans to fix binutils or is this viewed as not a binutils
regression?
- k
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-09 18:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <FC7C9C56-A1E7-4A02-BDEA-F55E10567313@kernel.crashing.org>
On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>> Hello Kumar,
>>
>> I must not understand something going on here. Your proposed code
>> doesn't work at all on my board. The
>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
>
> What does it come out as? How much memory do you have in the system?
>
The size_mb shows as 0 with your code. See the explanation below. With
my code it shows as 256MB, as expected.
I have 256MB memory in the system.
>> The attached patch DOES work on my board, but I'm confident that it
>> does
>> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
>> wrong?
>>
>> If I'm reading things correctly:
>> csrow->first_page full address of the first page (NOT pfn)
>> csrow->last_page full address of the last page (NOT pfn)
>> csrow->nr_pages number of pages
>>
>> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the size_mb
>> sysfs value.
>>
>> If csrow->first_page and csrow->last_page ARE supposed to be the pfn,
>> then I think the original code got it wrong, and the calculation for
>> csrow->nr_pages needs to be changed.
>>
>> Thanks,
>> Ira
>
> [snip]
>
>> /************************ MC SYSFS parts
>> ***********************************/
>>
>> @@ -790,18 +792,19 @@ static void __devinit mpc85xx_init_csrows(struct
>> mem_ctl_info *mci)
>> csrow = &mci->csrows[index];
>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>> (index * MPC85XX_MC_CS_BNDS_OFS));
>> - start = (cs_bnds & 0xfff0000) << 4;
>> - end = ((cs_bnds & 0xfff) << 20);
>> - if (start)
>> - start |= 0xfffff;
>> - if (end)
>> - end |= 0xfffff;
>
> can you printk what cs_bnds values are in your setup.
>
I am only using a single chip select. CS0_BNDS (register 0xe0002000) is
0x0000000F.
>> +
>> + start = (cs_bnds & 0xffff0000) >> 16;
>> + end = (cs_bnds & 0x0000ffff);
>>
This is the same in both our versions.
start == 0x0
end == 0xF
>> if (start == end)
>> continue; /* not populated */
>>
>> - csrow->first_page = start >> PAGE_SHIFT;
>> - csrow->last_page = end >> PAGE_SHIFT;
>> + start <<= PAGE_SHIFT;
>> + end <<= PAGE_SHIFT;
>> + end |= (1 << PAGE_SHIFT) - 1;
>> +
MY VERSION
start == 0x0
end == 0xffff
first_page == 0x0
last_page == 0xffff
YOUR VERSION (<<= (20 - PAGE_SHIFT), etc.)
start == 0x0
end == 0xfff
first_page == 0x0
last_page == 0x0
>> + csrow->first_page = start;
>> + csrow->last_page = end;
>
> This seems odd to me... I can't believe this is working out properly.
>
>>
>> csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
The calculation is unchanged here from the original code. Due to the
">> PAGE_SHIFT", nr_pages ends up as 1 in your version.
MY VERSION
nr_pages == 0xffff + 1 - 0 == 0x10000
0x10000 * 4096 / 1024 / 1024 == 256 MB
YOUR VERSION
nr_pages == 0x0 + 1 - 0x0 == 1
0x1 * 4096 / 1024 / 1024 == 0MB
>> csrow->grain = 8;
>> csrow->mtype = mtype;
>>
>
> Lets get some real values on the table for your system so I can get a
> sense of what's really going on.
>
Thanks for the help.
Ira
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Kumar Gala @ 2009-07-09 18:25 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <20090709181705.GD29383@ovro.caltech.edu>
On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
> On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>>> Hello Kumar,
>>>
>>> I must not understand something going on here. Your proposed code
>>> doesn't work at all on my board. The
>>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
>>
>> What does it come out as? How much memory do you have in the system?
>>
>
> The size_mb shows as 0 with your code. See the explanation below. With
> my code it shows as 256MB, as expected.
>
> I have 256MB memory in the system.
>
>>> The attached patch DOES work on my board, but I'm confident that it
>>> does
>>> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
>>> wrong?
>>>
>>> If I'm reading things correctly:
>>> csrow->first_page full address of the first page (NOT pfn)
>>> csrow->last_page full address of the last page (NOT pfn)
>>> csrow->nr_pages number of pages
>>>
>>> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the
>>> size_mb
>>> sysfs value.
>>>
>>> If csrow->first_page and csrow->last_page ARE supposed to be the
>>> pfn,
>>> then I think the original code got it wrong, and the calculation for
>>> csrow->nr_pages needs to be changed.
>>>
>>> Thanks,
>>> Ira
>>
>> [snip]
>>
>>> /************************ MC SYSFS parts
>>> ***********************************/
>>>
>>> @@ -790,18 +792,19 @@ static void __devinit
>>> mpc85xx_init_csrows(struct
>>> mem_ctl_info *mci)
>>> csrow = &mci->csrows[index];
>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>> - start = (cs_bnds & 0xfff0000) << 4;
>>> - end = ((cs_bnds & 0xfff) << 20);
>>> - if (start)
>>> - start |= 0xfffff;
>>> - if (end)
>>> - end |= 0xfffff;
>>
>> can you printk what cs_bnds values are in your setup.
>>
>
> I am only using a single chip select. CS0_BNDS (register 0xe0002000)
> is
> 0x0000000F.
>
>>> +
>>> + start = (cs_bnds & 0xffff0000) >> 16;
>>> + end = (cs_bnds & 0x0000ffff);
>>>
>
> This is the same in both our versions.
>
> start == 0x0
> end == 0xF
>
>>> if (start == end)
>>> continue; /* not populated */
>>>
>>> - csrow->first_page = start >> PAGE_SHIFT;
>>> - csrow->last_page = end >> PAGE_SHIFT;
>>> + start <<= PAGE_SHIFT;
>>> + end <<= PAGE_SHIFT;
>>> + end |= (1 << PAGE_SHIFT) - 1;
>>> +
>
> MY VERSION
>
> start == 0x0
> end == 0xffff
>
> first_page == 0x0
> last_page == 0xffff
>
> YOUR VERSION (<<= (20 - PAGE_SHIFT), etc.)
My math was wrong it should be ( <<= (24 - PAGE_SHIFT) )
With that I think things work out.
- k
>
>
> start == 0x0
> end == 0xfff
>
> first_page == 0x0
> last_page == 0x0
>
>>> + csrow->first_page = start;
>>> + csrow->last_page = end;
>>
>> This seems odd to me... I can't believe this is working out properly.
>>
>>>
>>> csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
>
> The calculation is unchanged here from the original code. Due to the
> ">> PAGE_SHIFT", nr_pages ends up as 1 in your version.
>
> MY VERSION
>
> nr_pages == 0xffff + 1 - 0 == 0x10000
>
> 0x10000 * 4096 / 1024 / 1024 == 256 MB
>
>
> YOUR VERSION
>
> nr_pages == 0x0 + 1 - 0x0 == 1
>
> 0x1 * 4096 / 1024 / 1024 == 0MB
>
>>> csrow->grain = 8;
>>> csrow->mtype = mtype;
>>>
>>
>> Lets get some real values on the table for your system so I can get a
>> sense of what's really going on.
>>
>
> Thanks for the help.
> Ira
^ permalink raw reply
* Questions in spi_mpc83xx.c
From: Mark Bishop @ 2009-07-09 18:16 UTC (permalink / raw)
To: spi-devel-general; +Cc: linuxppc-dev
I haven't seen this before - the '##' in the function name. This is ANCII C?
#define MPC83XX_SPI_TX_BUF(type) \
u32 mpc83xx_spi_tx_buf_##type(struct mpc83xx_spi *mpc83xx_spi) \
{ \
u32 data; \
....
Also, I have a SPI chip here that will drive MISO high when it is
ready to accept more data. It acts like a hardware handshake. I was
thinking about making changes to the controller source (spi_mpc83xx.c,
in my case) to support this.
This is the only SPI chip contained on this system so I am not worried
about affecting other SPI devices hooked to the controller.
What are people's opinion on this as far as right place to implement,
and I could use a push as to where in the controller to make mods if
appropriate.
And if it isn't obvious already I am still learning a bit as to how
the SPI sub-system is organized. I have taken apart the
documentation in the kernel Documentation/spi directory and am reading
all the code in drivers/spi.
^ permalink raw reply
* [PATCH] powerpc/85xx: Add support for I2C EEPROMs on MPC8548CDS boards
From: Anton Vorontsov @ 2009-07-09 18:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
This patch simply adds four eeprom nodes to MPC8548CDS' device tree.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8548cds.dts | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts b/arch/powerpc/boot/dts/mpc8548cds.dts
index 475be14..4173af3 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -100,6 +100,21 @@
interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+
+ eeprom@56 {
+ compatible = "atmel,24c64";
+ reg = <0x56>;
+ };
+
+ eeprom@57 {
+ compatible = "atmel,24c64";
+ reg = <0x57>;
+ };
};
i2c@3100 {
@@ -111,6 +126,11 @@
interrupts = <43 2>;
interrupt-parent = <&mpic>;
dfsrr;
+
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
};
dma@21300 {
--
1.6.3.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox