* Re: invalidate_dcache_range Kernel 2.6.14
From: Alex Zeffertt @ 2006-08-04 13:59 UTC (permalink / raw)
To: GSM909; +Cc: linuxppc-embedded
In-Reply-To: <20060804130938.78980@gmx.net>
GSM909@gmx.de wrote:
> I have an old driver that need the funktion invalidate_dcache_range but when I compile the driver : Unknown symbol invalidate_dcache_range.
>
> Whats the name of this funktion now ???
>
The same. You just need to add EXPORT_SYMBOL(invalidate_dcache_range) to
ppc_ksys.c for your module to see it.
> Regards
> Ted
Alex
^ permalink raw reply
* Re: Trouble booting Kernel 2.6.12 on powerpc 8540
From: Kumar Gala @ 2006-08-04 13:57 UTC (permalink / raw)
To: Prashant Yendigeri; +Cc: linuxppc-embedded
In-Reply-To: <OFCF3F7A59.180DAB88-ON652571C0.004C2A03-652571C0.004C5E3A@lntinfotech.com>
On Aug 4, 2006, at 8:54 AM, Prashant Yendigeri wrote:
>
> Hi,
>
> I am able to boot linux kernel 2.6.12 on ppc 8540, and also able to =20=
> login too. But then i am unable to see any output when i say ls, =20
> mount,ifconfig etc. Only pwd and env seem to work
> Whereas if i boot with kernel 2.4.20 and with the same ramdisk =20
> which i used to boot 2.6.12, i am able to see eveything, ls, mount =20
> outputs etc.
Do you have console=3DttyS0 on the command line to the kernel?
- kumar
>
> I built the ramdisk image using busybox 1.2
>
> This is the boot messages of 2.6.12 :
> ## Booting image at 01000000 ...
> Image Name: Linux-2.6.12
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1177413 Bytes =3D 1.1 MB
> Load Address: 00000000
> Entry Point: 000000000
> Verifying ksum ... OK
> Uncompressing Kernel Image ... OK
> ## Loading RAMDisk Image at 01200000 ...
> Image Name: MPC85xx ramdisk
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 5887861 Bytes =3D 5.6 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Loading Ramdisk to 0fa16000, end 0ffb3775 ... OK
> mpc8540ads_init(): exit
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> mpc8540ads_setup_arch()
> arch: exit
> openpic: enter
> r ...?.?....=C9=A5?..)55?....?.?..???)5?
> ] class_hotplug - name =3D ttyw8
> [ 2.126538] Generic RTC Driver v1.07
> [ 2.127108] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, =20=
> IRQ sharind[ 2.130813] ttyS0 at MMIO 0xe0004500 (irq =3D 26) is a =20=
> 16550A
> [ 2.152265] ttyS1 at MMIO 0xe0004600 (irq =3D 26) is a 16550A
> [ 2.158526] io scheduler noop registered
> [ 2.162574] io scheduler anticipatory registered
> [ 2.167318] io scheduler deadline registered
> [ 2.171730] io scheduler cfq registered
> [ 2.182339] RAMDISK driver initialized: 16 RAM disks of 32768K =20
> size 1024 ble[ 2.193524] loop: loaded (max 8 devices)
> [ 2.198105] Equalizer2002: Simon Janes (simon@ncm.com) and David =20=
> S. Miller )[ 2.207423] tun: Universal TUN/TAP device driver, 1.6
> [ 2.212597] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
> [ 2.219737] mice: PS/2 mouse device common for all mice
> [ 2.225711] i2c /dev entries driver
> [ 2.230856] NET: Registered protocol family 2
> [ 2.245261] IP: routing cache hash table of 2048 buckets, 16Kbytes
> [ 2.252570] TCP established hash table entries: 16384 (order: 5, =20=
> 131072 byt)[ 2.260355] TCP bind hash table entries: 16384 =20
> (order: 4, 65536 bytes)
> [ 2.267366] TCP: Hash tables configured (established 16384 bind =20
> 16384)
> [ 2.274459] NET: Registered protocol family 1
> [ 2.278943] NET: Registered protocol family 17
> [ 2.284791] RAMDISK: Compressed image found at block 0
> [ 4.435668] VFS: Mounted root (ext2 filesystem).
> [ 4.440693] Freeing unused kernel memory: 84k init
> [ 4.445614] Reached here
> [ 4.448201] Reached here 2
> [ 4.451423] Reached here 3
> [ 4.454196] going to Exec /sbin/init
> init started: BusyBox v1.2.0 (2006.08.02-10:51+0000) multi-call =20
> binary
> Starting pid 682, console /dev/ttyS0: '/etc/init.d/rcS'
> Starting pid 690, console /dev/ttyS0: '/sbin/ge
> Welcome to Linux on MPC85xxSK board!
> MPC85xxSK login:
>
>
> -> After this i login as root and type ls but no output on the =20
> screen, pwd and env throw output.
> -> I also see that in 2.4 booting messages :"Freeing initrd =20
> memory........" is displayed" but not in 2.6.12, eventhough i have =20
> enabled CONFIG_BLK_DEV_INITRD
> -> Should i enter something for CONFIG_INITRAMFS_SOURCE as of now =20
> it is blank ?
>
> Thanks and Regards,
> Prashant
>
>
>
> ______________________________________________________________________
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Trouble booting Kernel 2.6.12 on powerpc 8540
From: Prashant Yendigeri @ 2006-08-04 13:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3644 bytes --]
Hi,
I am able to boot linux kernel 2.6.12 on ppc 8540, and also able to login
too. But then i am unable to see any output when i say ls, mount,ifconfig
etc. Only pwd and env seem to work
Whereas if i boot with kernel 2.4.20 and with the same ramdisk which i
used to boot 2.6.12, i am able to see eveything, ls, mount outputs etc.
I built the ramdisk image using busybox 1.2
This is the boot messages of 2.6.12 :
## Booting image at 01000000 ...
Image Name: Linux-2.6.12
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1177413 Bytes = 1.1 MB
Load Address: 00000000
Entry Point: 000000000
Verifying ksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 01200000 ...
Image Name: MPC85xx ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 5887861 Bytes = 5.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fa16000, end 0ffb3775 ... OK
mpc8540ads_init(): exit
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
mpc8540ads_setup_arch()
arch: exit
openpic: enter
r ...?.?....É¥?..)55?....?.?..???)5?
] class_hotplug - name = ttyw8
[ 2.126538] Generic RTC Driver v1.07
[ 2.127108] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
sharind[ 2.130813] ttyS0 at MMIO 0xe0004500 (irq = 26) is a 16550A
[ 2.152265] ttyS1 at MMIO 0xe0004600 (irq = 26) is a 16550A
[ 2.158526] io scheduler noop registered
[ 2.162574] io scheduler anticipatory registered
[ 2.167318] io scheduler deadline registered
[ 2.171730] io scheduler cfq registered
[ 2.182339] RAMDISK driver initialized: 16 RAM disks of 32768K size
1024 ble[ 2.193524] loop: loaded (max 8 devices)
[ 2.198105] Equalizer2002: Simon Janes (simon@ncm.com) and David S.
Miller )[ 2.207423] tun: Universal TUN/TAP device driver, 1.6
[ 2.212597] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 2.219737] mice: PS/2 mouse device common for all mice
[ 2.225711] i2c /dev entries driver
[ 2.230856] NET: Registered protocol family 2
[ 2.245261] IP: routing cache hash table of 2048 buckets, 16Kbytes
[ 2.252570] TCP established hash table entries: 16384 (order: 5, 131072
byt)[ 2.260355] TCP bind hash table entries: 16384 (order: 4, 65536
bytes)
[ 2.267366] TCP: Hash tables configured (established 16384 bind 16384)
[ 2.274459] NET: Registered protocol family 1
[ 2.278943] NET: Registered protocol family 17
[ 2.284791] RAMDISK: Compressed image found at block 0
[ 4.435668] VFS: Mounted root (ext2 filesystem).
[ 4.440693] Freeing unused kernel memory: 84k init
[ 4.445614] Reached here
[ 4.448201] Reached here 2
[ 4.451423] Reached here 3
[ 4.454196] going to Exec /sbin/init
init started: BusyBox v1.2.0 (2006.08.02-10:51+0000) multi-call binary
Starting pid 682, console /dev/ttyS0: '/etc/init.d/rcS'
Starting pid 690, console /dev/ttyS0: '/sbin/ge
Welcome to Linux on MPC85xxSK board!
MPC85xxSK login:
-> After this i login as root and type ls but no output on the screen, pwd
and env throw output.
-> I also see that in 2.4 booting messages :"Freeing initrd
memory........" is displayed" but not in 2.6.12, eventhough i have enabled
CONFIG_BLK_DEV_INITRD
-> Should i enter something for CONFIG_INITRAMFS_SOURCE as of now it is
blank ?
Thanks and Regards,
Prashant
______________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 7248 bytes --]
^ permalink raw reply
* invalidate_dcache_range Kernel 2.6.14
From: GSM909 @ 2006-08-04 13:09 UTC (permalink / raw)
To: linuxppc-embedded
I have an old driver that need the funktion invalidate_dcache_range but when I compile the driver : Unknown symbol invalidate_dcache_range.
Whats the name of this funktion now ???
Regards
Ted
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit!
"Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl
^ permalink raw reply
* Problem in __get_dma_page and __pa
From: Behre, Frederik - LT @ 2006-08-04 11:04 UTC (permalink / raw)
To: linuxppc-embedded
Hi
Did someone know if there are known problems in __get_dma_pages and __pa
in linux version 2.6.14 ?=20
Regards=20
Freddy
^ permalink raw reply
* Trouble booting Kernel 2.6.12 on powerpc 8540
From: Prashant Yendigeri @ 2006-08-04 11:02 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3402 bytes --]
Hi,
I am able to boot linux kernel 2.6.12 on ppc 8540, and also able to login
too. But then i am unable to see any output when i say ls, mount,ifconfig
etc. Only pwd and env seem to work
Whereas if i boot with kernel 2.4.20 and with the same ramdisk which i
used to boot 2.6.12, i am able to see eveything, ls, mount outputs etc.
I built the ramdisk image using busybox 1.2
This is the boot messages of 2.6.12 :
## Booting image at 01000000 ...
Image Name: Linux-2.6.12
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1177413 Bytes = 1.1 MB
Load Address: 00000000
Entry Point: 000000000
Verifying ksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 01200000 ...
Image Name: MPC85xx ramdisk
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 5887861 Bytes = 5.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fa16000, end 0ffb3775 ... OK
mpc8540ads_init(): exit
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
mpc8540ads_setup_arch()
arch: exit
openpic: enter
r ...?.?....É¥?..)55?....?.?..???)5?
] class_hotplug - name = ttyw8
[ 2.126538] Generic RTC Driver v1.07
[ 2.127108] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
sharind[ 2.130813] ttyS0 at MMIO 0xe0004500 (irq = 26) is a 16550A
[ 2.152265] ttyS1 at MMIO 0xe0004600 (irq = 26) is a 16550A
[ 2.158526] io scheduler noop registered
[ 2.162574] io scheduler anticipatory registered
[ 2.167318] io scheduler deadline registered
[ 2.171730] io scheduler cfq registered
[ 2.182339] RAMDISK driver initialized: 16 RAM disks of 32768K size
1024 ble[ 2.193524] loop: loaded (max 8 devices)
[ 2.198105] Equalizer2002: Simon Janes (simon@ncm.com) and David S.
Miller )[ 2.207423] tun: Universal TUN/TAP device driver, 1.6
[ 2.212597] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 2.219737] mice: PS/2 mouse device common for all mice
[ 2.225711] i2c /dev entries driver
[ 2.230856] NET: Registered protocol family 2
[ 2.245261] IP: routing cache hash table of 2048 buckets, 16Kbytes
[ 2.252570] TCP established hash table entries: 16384 (order: 5, 131072
byt)[ 2.260355] TCP bind hash table entries: 16384 (order: 4, 65536
bytes)
[ 2.267366] TCP: Hash tables configured (established 16384 bind 16384)
[ 2.274459] NET: Registered protocol family 1
[ 2.278943] NET: Registered protocol family 17
[ 2.284791] RAMDISK: Compressed image found at block 0
[ 4.435668] VFS: Mounted root (ext2 filesystem).
[ 4.440693] Freeing unused kernel memory: 84k init
[ 4.445614] Reached here
[ 4.448201] Reached here 2
[ 4.451423] Reached here 3
[ 4.454196] going to Exec /sbin/init
init started: BusyBox v1.2.0 (2006.08.02-10:51+0000) multi-call binary
Starting pid 682, console /dev/ttyS0: '/etc/init.d/rcS'
Starting pid 690, console /dev/ttyS0: '/sbin/ge
Welcome to Linux on MPC85xxSK board!
MPC85xxSK login:
-> After this i login as root and type ls but no output on the screen, pwd
and env throw output.
Thanks and Regards,
Prashant
______________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 6912 bytes --]
^ permalink raw reply
* ioctl() hangs in Lite5200b FEC driver?
From: Parav Pandit @ 2006-08-04 10:17 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
1. Is drivers/net/fec.c is the correct driver for the
Lite5200B board in 2.6.x?
2. If yes, it doesn't have any implementation for
do_ioctl() call.
In my case ifconfig tries to set the IFF_RUNNING |
IFF_UP flag using SIOCGIFFLAGS ioctl cmd, but my
ifconfig utility hangs in the ioctl().
Can some one tell me why does it hang?
Can some one tell me, when do_ioctl() is not
implemented by the driver, than which default function
gets called by the system?
Regards,
Parav Pandit
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: AOA and Toonie (Mac Mini) : nothing happens
From: Johannes Berg @ 2006-08-04 9:56 UTC (permalink / raw)
To: Francois Barre; +Cc: linuxppc-dev
In-Reply-To: <fd8d0180608040253h11ebf168p8656b370857f1647@mail.gmail.com>
Hi,
The mac mini isn't quite supported yet, the relevant patches are in the
alsa mercurial repo.
However, it should auto-load snd-aoa-fabric-layout (and then crash). Can
you privately send me a tarball of /proc/device-tree?
johannes
^ permalink raw reply
* AOA and Toonie (Mac Mini) : nothing happens
From: Francois Barre @ 2006-08-04 9:53 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I am now trying the AOA driver on a Mac Mini 1.2Ghz, using 2.6.18-rc3
linux/kernel/git/linville/wireless-dev.git kernel.
At startup, no module is loaded. When I try to manually modprobe
snd-aoa-*.ko and snd-aoa-codec-toonie.ko, no error is shown in dmesg,
but no device is binded to modules. Finally, nothing happens.
I know I shall provide more data but I lost connection to the machine right now.
Did I miss something ?
What is the process for loading modules in AOA ?
Do I have to alter my alsa config files ?
Regards,
^ permalink raw reply
* Help for USB host driver for MPC8xx
From: Josef Angermeier @ 2006-08-04 8:02 UTC (permalink / raw)
To: linuxppc-embedded
Hello Wei,
i ported Brad Parkers mpc8xx usb driver for linux 2.4 to linux 2.6 and merged it with the cpm2usb project's m82xx usb driver. Using it i can mount an usb-stick with linux 2.6.18 running on a m8xx. But for sure, there have to get some more bugs fixed, and i have to validate that the included cpm2usb code for m82xx still works, before i can send a patch for an official linux release.
So if you like i will send you my code and you tell me if it also works for your needs!
Josef
Hi All,
Dose anyone use USB host drivers for MPC875 with Linux 2.4.25? I just
found these notes from http://www.heeltoe.com/software/usb/usb.html,
but I have no idea about how to use it, any advice? Thanks.
Wei
^ permalink raw reply
* RE: MTD Flash Howto ?
From: Josu Onandia @ 2006-08-04 7:10 UTC (permalink / raw)
To: dhlii, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]
Hi,
Even if you dont't use U-Boot as bootloader, I'm sure that the documentation in http://www.denx.de/wiki/DULG/Manual will interest you.
Best regards
Josu Onandia
-----Mensaje original-----
De: linuxppc-embedded-bounces+jonandia=aotek.es@ozlabs.org [mailto:linuxppc-embedded-bounces+jonandia=aotek.es@ozlabs.org]En nombre de David H. Lynch Jr.
Enviado el: viernes, 04 de agosto de 2006 6:04
Para: linuxppc-embedded
Asunto: MTD Flash Howto ?
I need to put together a filesystem driver for the flash in the Pico E-12.
I think I have a pretty good grasp of what I need of the FileSystem end of things.
But I am less certain of the peices needed to get from the flash to the block driver that I assume underly's the FileSystem.
I have enabled MTD, and configured a starting address and size.
I got a signon banner. How can I tell if it has really found my flash and if it actually knows the type of flash it found - in my
instance Spansion S29GL512N.
I have found some documentation covering details, I think I am more interested in something that gives a more zoomed out view.
Is anyone aware of a relevant howto ? Maybe some web pages on the end-end process of going from flash devices to filesystems over flash ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 3403 bytes --]
^ permalink raw reply
* [PATCH] SLB shadow buffer
From: Michael Neuling @ 2006-08-04 5:53 UTC (permalink / raw)
To: linuxppc-dev, paulus; +Cc: sfr, anton
This adds a shadow buffer for the SLBs and regsiters it with PHYP.
Only the bolted SLB entries (first 3) are saved.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Thanks to sfr and mpe for their help.
arch/powerpc/kernel/asm-offsets.c | 2 +
arch/powerpc/kernel/entry_64.S | 12 ++++++++++
arch/powerpc/kernel/paca.c | 15 ++++++++++++-
arch/powerpc/mm/slb.c | 27 ++++++++++++++++++++++++
arch/powerpc/platforms/pseries/lpar.c | 18 ++++++++++++++--
arch/powerpc/platforms/pseries/plpar_wrappers.h | 10 ++++++++
arch/powerpc/platforms/pseries/setup.c | 10 ++++++++
include/asm-powerpc/lppaca.h | 15 +++++++++++++
include/asm-powerpc/paca.h | 4 +++
9 files changed, 109 insertions(+), 4 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/asm-offsets.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/asm-offsets.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/asm-offsets.c
@@ -135,11 +135,13 @@ int main(void)
DEFINE(PACA_STARTPURR, offsetof(struct paca_struct, startpurr));
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
DEFINE(PACA_SYSTEM_TIME, offsetof(struct paca_struct, system_time));
+ DEFINE(PACA_SLBSHADOWPTR, offsetof(struct paca_struct, slb_shadow_buffer_ptr));
DEFINE(LPPACASRR0, offsetof(struct lppaca, saved_srr0));
DEFINE(LPPACASRR1, offsetof(struct lppaca, saved_srr1));
DEFINE(LPPACAANYINT, offsetof(struct lppaca, int_dword.any_int));
DEFINE(LPPACADECRINT, offsetof(struct lppaca, int_dword.fields.decr_int));
+ DEFINE(SLBSHADOW_SAVEAREA, offsetof(struct slb_shadow_buffer, save_area));
#endif /* CONFIG_PPC64 */
/* RTAS */
Index: linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/entry_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
@@ -323,6 +323,10 @@ _GLOBAL(ret_from_fork)
* The code which creates the new task context is in 'copy_thread'
* in arch/powerpc/kernel/process.c
*/
+#define SHADOW_SLB_BOLTED_LAST_ESID \
+ (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1))
+#define SHADOW_SLB_BOLTED_LAST_VSID \
+ (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1) + 8)
.align 7
_GLOBAL(_switch)
mflr r0
@@ -375,6 +379,14 @@ BEGIN_FTR_SECTION
ld r7,KSP_VSID(r4) /* Get new stack's VSID */
oris r0,r6,(SLB_ESID_V)@h
ori r0,r0,(SLB_NUM_BOLTED-1)@l
+
+ /* Update the last bolted SLB */
+ ld r9,PACA_SLBSHADOWPTR(r13)
+ li r12,0
+ std r12,SHADOW_SLB_BOLTED_LAST_ESID(r9) /* Clear ESID */
+ std r7,SHADOW_SLB_BOLTED_LAST_VSID(r9) /* Save VSID */
+ std r0,SHADOW_SLB_BOLTED_LAST_ESID(r9) /* Save ESID */
+
slbie r6
slbie r6 /* Workaround POWER5 < DD2.1 issue */
slbmte r7,r0
Index: linux-2.6-ozlabs/arch/powerpc/kernel/paca.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/paca.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/paca.c
@@ -17,6 +17,7 @@
#include <asm/lppaca.h>
#include <asm/iseries/it_lp_reg_save.h>
#include <asm/paca.h>
+#include <asm/mmu.h>
/* This symbol is provided by the linker - let it fill in the paca
@@ -45,6 +46,17 @@ struct lppaca lppaca[] = {
},
};
+/*
+ * 3 persistent SLBs are registered here. The buffer will be zero
+ * initially, hence will all be invaild until we actually write them.
+ */
+struct slb_shadow_buffer slb_shadow_buffer[] = {
+ [0 ... (NR_CPUS-1)] = {
+ .persistent = SLB_NUM_BOLTED,
+ .buffer_length = sizeof(struct slb_shadow_buffer),
+ },
+};
+
/* The Paca is an array with one entry per processor. Each contains an
* lppaca, which contains the information shared between the
* hypervisor and Linux.
@@ -59,7 +71,8 @@ struct lppaca lppaca[] = {
.lock_token = 0x8000, \
.paca_index = (number), /* Paca Index */ \
.kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL, \
- .hw_cpu_id = 0xffff,
+ .hw_cpu_id = 0xffff, \
+ .slb_shadow_buffer_ptr = &slb_shadow_buffer[number]
#ifdef CONFIG_PPC_ISERIES
#define PACA_INIT_ISERIES(number) \
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -22,6 +22,8 @@
#include <asm/paca.h>
#include <asm/cputable.h>
#include <asm/cacheflush.h>
+#include <asm/smp.h>
+#include <linux/compiler.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
@@ -50,9 +52,29 @@ static inline unsigned long mk_vsid_data
return (get_kernel_vsid(ea) << SLB_VSID_SHIFT) | flags;
}
+static inline void slb_shadow_update(unsigned long esid, unsigned long vsid,
+ unsigned long entry)
+{
+ /* Clear the ESID first so the entry is not valid while we are
+ * updating it. Then write the VSID before the real ESID. */
+ get_slb_shadow_buffer()->save_area[2*entry] = 0;
+ barrier();
+ get_slb_shadow_buffer()->save_area[2*entry+1] = vsid;
+ barrier();
+ get_slb_shadow_buffer()->save_area[2*entry] = esid;
+
+}
+
static inline void create_slbe(unsigned long ea, unsigned long flags,
unsigned long entry)
{
+ /* Updating the shadow buffer before writing the SLB ensures
+ * we don't get a stale entry here if we get preempted by PHYP
+ * between these two statements. */
+ slb_shadow_update(mk_esid_data(ea, entry),
+ mk_vsid_data(ea, flags),
+ entry);
+
asm volatile("slbmte %0,%1" :
: "r" (mk_vsid_data(ea, flags)),
"r" (mk_esid_data(ea, entry))
@@ -77,6 +99,11 @@ void slb_flush_and_rebolt(void)
if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET)
ksp_esid_data &= ~SLB_ESID_V;
+ /* Only second entry may change here so only resave that */
+ slb_shadow_update(ksp_esid_data,
+ mk_vsid_data(ksp_esid_data, lflags),
+ 2);
+
/* We need to do this all in asm, so we're sure we don't touch
* the stack between the slbia and rebolting it. */
asm volatile("isync\n"
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
@@ -254,18 +254,32 @@ out:
void vpa_init(int cpu)
{
int hwcpu = get_hard_smp_processor_id(cpu);
- unsigned long vpa = __pa(&lppaca[cpu]);
+ unsigned long vpa;
long ret;
if (cpu_has_feature(CPU_FTR_ALTIVEC))
lppaca[cpu].vmxregs_in_use = 1;
+ vpa = __pa(&lppaca[cpu]);
ret = register_vpa(hwcpu, vpa);
- if (ret)
+ if (ret) {
printk(KERN_ERR "WARNING: vpa_init: VPA registration for "
"cpu %d (hw %d) of area %lx returns %ld\n",
cpu, hwcpu, vpa, ret);
+ return;
+ }
+ /* PAPR says this feature is SLB-Buffer but firmware never
+ * reports that. All SPLPAR support SLB shadow buffer. */
+ vpa = __pa(&slb_shadow_buffer[cpu]);
+ if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+ ret = register_slb_shadow(hwcpu, vpa);
+ if (ret)
+ printk(KERN_ERR
+ "WARNING: vpa_init: SLB shadow buffer "
+ "registration for cpu %d (hw %d) of area %lx "
+ "returns %ld\n", cpu, hwcpu, vpa, ret);
+ }
}
long pSeries_lpar_hpte_insert(unsigned long hpte_group,
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/plpar_wrappers.h
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -40,6 +40,16 @@ static inline long register_vpa(unsigned
return vpa_call(0x1, cpu, vpa);
}
+static inline long unregister_slb_shadow(unsigned long cpu, unsigned long vpa)
+{
+ return vpa_call(0x7, cpu, vpa);
+}
+
+static inline long register_slb_shadow(unsigned long cpu, unsigned long vpa)
+{
+ return vpa_call(0x3, cpu, vpa);
+}
+
extern void vpa_init(int cpu);
static inline long plpar_pte_remove(unsigned long flags, unsigned long ptex,
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/setup.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/setup.c
@@ -234,8 +234,16 @@ static void pseries_kexec_cpu_down_xics(
{
/* Don't risk a hypervisor call if we're crashing */
if (firmware_has_feature(FW_FEATURE_SPLPAR) && !crash_shutdown) {
- unsigned long vpa = __pa(get_lppaca());
+ unsigned long vpa;
+ vpa = __pa(get_slb_shadow_buffer());
+ if (unregister_slb_shadow(hard_smp_processor_id(), vpa))
+ printk("SLB shadow buffer deregistration of "
+ "cpu %u (hw_cpu_id %d) failed\n",
+ smp_processor_id(),
+ hard_smp_processor_id());
+
+ vpa = __pa(get_lppaca());
if (unregister_vpa(hard_smp_processor_id(), vpa)) {
printk("VPA deregistration of cpu %u (hw_cpu_id %d) "
"failed\n", smp_processor_id(),
Index: linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/lppaca.h
+++ linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
@@ -28,6 +28,7 @@
//
//----------------------------------------------------------------------------
#include <asm/types.h>
+#include <asm/mmu.h>
/* The Hypervisor barfs if the lppaca crosses a page boundary. A 1k
* alignment is sufficient to prevent this */
@@ -133,5 +134,19 @@ struct lppaca {
extern struct lppaca lppaca[];
+/* SLB shadow buffer structure as defined in the PAPR. The save_area
+ * contains adjacent ESID and VSID pairs for each shadowed SLB. The
+ * ESID is stored in the lower 64bits, then the VSID. NOTE: This
+ * structure is 0x40 bytes long (with 3 bolted SLBs), but PHYP
+ * complaints if we're not 0x80 (cache line?) aligned. */
+struct slb_shadow_buffer {
+ u32 persistent; // Number of persistent SLBs x00-x03
+ u32 buffer_length; // Total shadow buffer length x04-x07
+ u64 reserved; // Alignment x08-x0f
+ u64 save_area[SLB_NUM_BOLTED * 2]; // x10-x40
+} __attribute__((__aligned__(0x80)));
+
+extern struct slb_shadow_buffer slb_shadow_buffer[];
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_LPPACA_H */
Index: linux-2.6-ozlabs/include/asm-powerpc/paca.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/paca.h
+++ linux-2.6-ozlabs/include/asm-powerpc/paca.h
@@ -23,6 +23,7 @@
register struct paca_struct *local_paca asm("r13");
#define get_paca() local_paca
#define get_lppaca() (get_paca()->lppaca_ptr)
+#define get_slb_shadow_buffer() (get_paca()->slb_shadow_buffer_ptr)
struct task_struct;
@@ -98,6 +99,9 @@ struct paca_struct {
u64 user_time; /* accumulated usermode TB ticks */
u64 system_time; /* accumulated system TB ticks */
u64 startpurr; /* PURR/TB value snapshot */
+
+ /* Pointer to SLB shadow buffer */
+ struct slb_shadow_buffer *slb_shadow_buffer_ptr;
};
extern struct paca_struct paca[];
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Paul Mackerras @ 2006-08-04 4:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154464346.19994.4.camel@cashmere.sps.mot.com>
Jon Loeliger writes:
> One semi-obvious place would be to co-locate them with
> their corresponding Linux arch/powerpc/platform directory.
> Another would be to have a new directory full of them
> under, say, arch/powerpc/devtrees or so.
Either of those would work.
I think we should have the dts for all of the reference boards we
support in the kernel tree. We don't have to have every single dts in
the kernel tree, but it is useful to have at least a representative
sample there. They're not very big and they are useful as a reference
for people who are reading drivers or platform code.
Paul.
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Paul Mackerras @ 2006-08-04 4:49 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, g.liakhovetski, Milton Miller
In-Reply-To: <20060803135440.GB3075@smtp.west.cox.net>
Tom Rini writes:
> But "content requirements change" isn't the same as "left things out of
> their tree". It sounds, and I haven't seen the changes, so I'm not
> certain that the meaning behind a field changed. Something like that
> should change the dt version.
I disagree. Strongly. The dt version relates to the representation
of the tree, not its content.
If we *have* to change the meaning of a property value in a particular
node in an incompatible way, then we can do something such as adding
another property to indicate what the interpretation of the first
property value should be. Usually it's possible to find a way around
the problem without resorting to that, though.
> New fields aren't a problem. Changing
> existing fields meaning in incompatible ways is a problem.
Only a minor, localized problem. Nothing worth changing the whole dt
version number for.
Paul.
^ permalink raw reply
* MTD Flash Howto ?
From: David H. Lynch Jr. @ 2006-08-04 4:04 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]
I need to put together a filesystem driver for the flash in the Pico
E-12.
I think I have a pretty good grasp of what I need of the FileSystem
end of things.
But I am less certain of the peices needed to get from the flash to
the block driver that I assume underly's the FileSystem.
I have enabled MTD, and configured a starting address and size.
I got a signon banner. How can I tell if it has really found my
flash and if it actually knows the type of flash it found - in my
instance Spansion S29GL512N.
I have found some documentation covering details, I think I am more
interested in something that gives a more zoomed out view.
Is anyone aware of a relevant howto ? Maybe some web pages on the
end-end process of going from flash devices to filesystems over flash ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
[-- Attachment #2: Type: text/html, Size: 1873 bytes --]
^ permalink raw reply
* ELDK 3.1.1 support for x86_64 host architecture
From: Michael Carey @ 2006-08-04 0:11 UTC (permalink / raw)
To: linuxppc-embedded
I found the subject "ELDK 3.1.1 support for x86_64 host architecture" in =
the archives (Apr 15 2005) which describes my problem, however there was =
never any posting of a resolution.
When I attempt to run: "./install -d /opt/eldk" I get the following =
output:
Do you really want to install into /opt/eldk directory[y/n]?: y
Creating directories
Done
Installing cross RPMs
Preparing... ########################################### =
[100%]
package rpm-4.1.1-1.8xa_10 is intended for a i386 architecture
can't change dir: No such file or directory
The details on my system are:
mcarey@mmtdev:~> cat /etc/issue
Welcome to SUSE LINUX 10.1 (X86-64) - Kernel \r (\l).
mcarey@mmtdev:~> uname -a
Linux mmtdev 2.6.16.13-4-default #1 Wed May 3 04:53:23 UTC 2006 x86_64 =
x86_64 x86_64 GNU/Linux
mcarey@mmtdev:~> cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.06GHz
stepping : 1
cpu MHz : 3065.612
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca =
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm =
constant_tsc pni monitor ds_cpl tm2 cid cx16 xtpr
bogomips : 6140.72
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
//
Thanks for any help you could provide,
Michael Carey
^ permalink raw reply
* Re: [RFC] asm code for Hypervisor Call Instrumentation
From: Mike Kravetz @ 2006-08-04 0:08 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20060804092552.41f00701.sfr@canb.auug.org.au>
On Fri, Aug 04, 2006 at 09:25:52AM +1000, Stephen Rothwell wrote:
> I would have thought that
>
> #define HCALL_INST_PRECALL
>
> would work.
It does work. That was too obvious for me. :)
--
Mike
^ permalink raw reply
* Re: [RFC] asm code for Hypervisor Call Instrumentation
From: Stephen Rothwell @ 2006-08-03 23:25 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev
In-Reply-To: <20060803174058.GA3179@w-mikek2.ibm.com>
Hi Mike,
On Thu, 3 Aug 2006 10:40:58 -0700 Mike Kravetz <kravetz@us.ibm.com> wrote:
>
> What is the preferred method to 'leave it blank'?
>
> #define HCALL_INST_PRECALL /* nop */
> #define HCALL_INST_PRECALL ;
> something else?
I would have thought that
#define HCALL_INST_PRECALL
would work.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* Re: DMA Driver on MPC8260
From: Manish Joshi @ 2006-08-03 23:09 UTC (permalink / raw)
To: jimmy liu, linuxppc-embedded
In-Reply-To: <20060803213507.93830.qmail@web53109.mail.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 1891 bytes --]
No idea about sample code.
But I think programming DMA itself is straightforward as mentioned below.
Just ensure to use uncached physical memory for src/dest addresses.
Then you can program your interrupt to receive the DMA completion notification.
There are couple of registers like ESR, DMASR etc which you can check in case you see any issues after programming your DMA config registers which are little endian.
jimmy liu <jimmyzhmliu@yahoo.com> wrote:
You are 100% right. MPC8260 has 4 DMA channels which
can be programmed independently. Could I find some
sample code from some place?
--- Manish Joshi wrote:
> What kind of information you are looking for?
> Specific questions always help.
> General details you can find in the user manual
> itself.
>
> Not sure, but I think MPC8260 has 4 DMA channels
> which can be programmed independently. You need to
> set the mode registers and then the src/dest addr
> registers and byte count and finally turn on the
> start bit.
>
>
> jimmy liu wrote:
> I am working on PCI transactions between MPC8260
> and
> FPGA. Could somebody give me some information about
> the PCI DMA Driver on MPC8260?
>
> Thanks.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> ---------------------------------
> Want to be your own boss? Learn how on Yahoo! Small
> Business.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------
Want to be your own boss? Learn how on Yahoo! Small Business.
[-- Attachment #2: Type: text/html, Size: 2474 bytes --]
^ permalink raw reply
* tool for editing builtin command line
From: Amos Waterland @ 2006-08-03 22:22 UTC (permalink / raw)
To: linuxppc-dev
The following is a tool for reading and editing the builtin command line
arguments in Linux zImage files and other bootable files that follow the
same format. It is useful in a cluster context in which one is booting
the same kernel on many machines with the only difference being their
network autoconfiguration values. Inspired by a script that Michal
Ostrowski posted earlier.
To see the existing arguments in a bootable image:
$ ./builtin-cmdline zImage
console=ttyS0,19200
To put new arguments in the image:
$ ./builtin-cmdline zImage "ro root=/dev/nfs nfsroot=192.168.0.3:/nfsroot \
ip=192.168.0.4::192.168.0.2:255.255.255.0:cluster001:eth0:off"
Signed-off-by: Amos Waterland <apw@us.ibm.com>
---
#!/bin/bash
#
# Copyright (C) 2006 Amos Waterland <apw@us.ibm.com>, IBM Corp.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
function help()
{
local name=$1;
local version=$2;
echo -e "\`$name' manipulates builtin command line arguments\n" \
"\n" \
"Usage: $name FILE [ARGS]\n" \
" -?, --help Show this help statement.\n" \
" --version Show version statement.\n" \
"\n" \
"Examples: $name zImage\n" \
" $name zImage 'console=ttyS0'";
}
function work()
{
local file=$1;
local args=$2;
local off; local siz; local out;
off=$(objdump -h $file |
gawk -- '{if($2=="__builtin_cmdline") {print strtonum("0x"$6);}}';)
if [ -z $off ]; then
echo "error: cannot find command line section in: $file"; return 1;
fi
siz=$(objdump -h $file |
gawk -- '{if($2=="__builtin_cmdline") {print strtonum("0x"$3);}}';)
if [ -z $siz ]; then return 1; fi
if [ -z "$args" ]; then
out=$(dd bs=1 if=$file skip=$off count=$siz 2>/dev/null);
if [ $? -ne 0 ]; then return 1; fi
echo $out;
else
dd if=/dev/zero of=$file bs=1 \
seek=$off conv=notrunc count=$siz 2>/dev/null
if [ $? -ne 0 ]; then return 1; fi
echo -n "$args" | dd \
of=$file bs=1 seek=$off conv=notrunc count=$siz 2>/dev/null
if [ $? -ne 0 ]; then return 1; fi
fi
return 0;
}
function main()
{
local args;
local file;
local name=builtin-cmdline;
local version=0.1.0;
while [ $# -gt 0 ]; do
case $1 in
-\? | --help)
help $name $version; return 1;
;;
--version)
echo "$name $version"; return 1;
;;
*)
if [ -z "$file" ]; then
file="$1"; shift;
elif [ -z "$args" ]; then
args="$1"; shift;
else
help $name $version; return 1;
fi
;;
esac
done
[ -z "$file" ] && {
help $name $version; return 1;
}
work "$file" "$args" || {
echo "bailing out because of errors"; return 1;
}
return 0;
}
main "$@";
exit $?;
^ permalink raw reply
* Re: [PATCH] Convert to mac-address for ethernet MAC address data.
From: Jon Loeliger @ 2006-08-03 21:55 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <0D9BEF4A-F8A5-42C5-9962-8C88322C9F50@kernel.crashing.org>
On Thu, 2006-08-03 at 16:49, Kumar Gala wrote:
> >
> > - mac_addr = get_property(np, "address", NULL);
> > - memcpy(gfar_data.mac_addr, mac_addr, 6);
> > + mac_addr = get_property(np, "local-mac-address", NULL);
>
> If "mac-address" the preferred mechanism, why dont we check for it
> first?
It's not. "local-mac-address" is. But that is HW specific.
SW version comes in as "mac-address". Here's what was said
earlier by Paul Nasrat:
Well I'm biased and say we shouldn't reinvent the wheel
with dtc if we don't need to. I've sent Jon a patch to
start validating this for dtc and am waiting feedback
before I add additional device_types. So we should have
local-mac-address be preassiged hwaddr and mac-address last
used. For some setups this would be the same persistently,
but I can envisage some non OF setups populating mac-address
from the card.
Paul
Which I interpreted to mean the order: local-mac-address first,
mac-address next, and the obsolete one, "address" last.
jdl
^ permalink raw reply
* Re: USB problem on MPC8349 (MPH0-ULPI)
From: Kumar Gala @ 2006-08-03 21:50 UTC (permalink / raw)
To: Srinivasa Hebbar; +Cc: linuxppc-embedded
In-Reply-To: <200608032101.23547.sshebbar@gmail.com>
On Aug 3, 2006, at 10:31 AM, Srinivasa Hebbar wrote:
>
> Hello,
>
> On MPC8349 sys board, I am getting following error when
> I connect the USB mass storage device.
>
> I am using MPH0 in ULPI mode.
>
> The driver doesn't detect any USB device.
>
> Any help to solve this problem is appreciated.
>
> The configuration and details of the board is given at
> the end of this mail.
[snip]
>> Operating System: Linux 2.6.11 (Freescale BSP downloaded from
>> metrowerks/freescale website).
I'd suggest using a stock 2.6.17 kernel or take the issue up with
Freescale since you are running a kernel from them.
- kumar
^ permalink raw reply
* Re: [PATCH] Convert to mac-address for ethernet MAC address data.
From: Kumar Gala @ 2006-08-03 21:49 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154640338.26770.34.camel@cashmere.sps.mot.com>
On Aug 3, 2006, at 4:25 PM, Jon Loeliger wrote:
> onvert to mac-address for ethernet MAC address data.
>
> Also accept "local-mac-address". However the old "address"
> is now obsolete, but accepted for backwards compatibility.
> It should be removed after all device trees have been
> converted to use "mac-address".
>
> Signed-off-by: Jon Loeliger <jdl@freescale.com>
> ---
> Documentation/powerpc/booting-without-of.txt | 10 +++++-----
> arch/powerpc/sysdev/fsl_soc.c | 12 ++++++++++--
> 2 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt b/
> Documentation/powerpc/booting-without-of.txt
> index 3c62e66..8c48b8a 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -1196,7 +1196,7 @@ platforms are moved over to use the flat
> - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC"
> - compatible : Should be "gianfar"
> - reg : Offset and length of the register set for the device
> - - address : List of bytes representing the ethernet address of
> + - mac-address : List of bytes representing the ethernet
> address of
> this controller
> - interrupts : <a b> where a is the interrupt number and b is a
> field that represents an encoding of the sense and level
> @@ -1216,7 +1216,7 @@ platforms are moved over to use the flat
> model = "TSEC";
> compatible = "gianfar";
> reg = <24000 1000>;
> - address = [ 00 E0 0C 00 73 00 ];
> + mac-address = [ 00 E0 0C 00 73 00 ];
> interrupts = <d 3 e 3 12 3>;
> interrupt-parent = <40000>;
> phy-handle = <2452000>
> @@ -1498,7 +1498,7 @@ not necessary as they are usually the sa
> model = "TSEC";
> compatible = "gianfar";
> reg = <24000 1000>;
> - address = [ 00 E0 0C 00 73 00 ];
> + mac-address = [ 00 E0 0C 00 73 00 ];
> interrupts = <d 3 e 3 12 3>;
> interrupt-parent = <40000>;
> phy-handle = <2452000>;
> @@ -1511,7 +1511,7 @@ not necessary as they are usually the sa
> model = "TSEC";
> compatible = "gianfar";
> reg = <25000 1000>;
> - address = [ 00 E0 0C 00 73 01 ];
> + mac-address = [ 00 E0 0C 00 73 01 ];
> interrupts = <13 3 14 3 18 3>;
> interrupt-parent = <40000>;
> phy-handle = <2452001>;
> @@ -1524,7 +1524,7 @@ not necessary as they are usually the sa
> model = "FEC";
> compatible = "gianfar";
> reg = <26000 1000>;
> - address = [ 00 E0 0C 00 73 02 ];
> + mac-address = [ 00 E0 0C 00 73 02 ];
> interrupts = <19 3>;
> interrupt-parent = <40000>;
> phy-handle = <2452002>;
> diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/
> fsl_soc.c
> index 4a6aa64..92ba378 100644
> --- a/arch/powerpc/sysdev/fsl_soc.c
> +++ b/arch/powerpc/sysdev/fsl_soc.c
> @@ -166,8 +166,16 @@ static int __init gfar_of_init(void)
> goto err;
> }
>
> - mac_addr = get_property(np, "address", NULL);
> - memcpy(gfar_data.mac_addr, mac_addr, 6);
> + mac_addr = get_property(np, "local-mac-address", NULL);
If "mac-address" the preferred mechanism, why dont we check for it
first?
> + if (mac_addr == NULL)
> + mac_addr = get_property(np, "mac-address", NULL);
> + if (mac_addr == NULL) {
> + /* Obsolete */
> + mac_addr = get_property(np, "address", NULL);
> + }
> +
> + if (mac_addr)
> + memcpy(gfar_data.mac_addr, mac_addr, 6);
>
> if (model && !strcasecmp(model, "TSEC"))
> gfar_data.device_flags =
> --
> 2006_06_07.01.gittree_pull-dirty
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: DMA Driver on MPC8260
From: jimmy liu @ 2006-08-03 21:35 UTC (permalink / raw)
To: Manish Joshi, linuxppc-embedded
In-Reply-To: <20060803201848.45985.qmail@web34715.mail.mud.yahoo.com>
You are 100% right. MPC8260 has 4 DMA channels which
can be programmed independently. Could I find some
sample code from some place?
--- Manish Joshi <mjoshi_blr@yahoo.com> wrote:
> What kind of information you are looking for?
> Specific questions always help.
> General details you can find in the user manual
> itself.
>
> Not sure, but I think MPC8260 has 4 DMA channels
> which can be programmed independently. You need to
> set the mode registers and then the src/dest addr
> registers and byte count and finally turn on the
> start bit.
>
>
> jimmy liu <jimmyzhmliu@yahoo.com> wrote:
> I am working on PCI transactions between MPC8260
> and
> FPGA. Could somebody give me some information about
> the PCI DMA Driver on MPC8260?
>
> Thanks.
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
> ---------------------------------
> Want to be your own boss? Learn how on Yahoo! Small
> Business.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* [PATCH Ver 2] Add MPC8641 HPCN Device Tree Source file.
From: Jon Loeliger @ 2006-08-03 21:27 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Subject: [PATCH] Add MPC8641 HPCN Device Tree Source file.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Uses "mac-address" instead of "address" in ethernet nodes.
Ignore my previous version of this patch.
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 338 ++++++++++++++++++++++++++++++++
1 files changed, 338 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
new file mode 100644
index 0000000..e832a88
--- /dev/null
+++ b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
@@ -0,0 +1,338 @@
+/*
+ * MPC8641 HPCN Device Tree Source
+ *
+ * Copyright 2006 Freescale Semiconductor Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+
+/ {
+ model = "MPC8641HPCN";
+ compatible = "mpc86xx";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #cpus = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8641@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>; // 33 MHz, from uboot
+ bus-frequency = <0>; // From uboot
+ clock-frequency = <0>; // From uboot
+ 32-bit;
+ linux,boot-cpu;
+ };
+ PowerPC,8641@1 {
+ device_type = "cpu";
+ reg = <1>;
+ d-cache-line-size = <20>; // 32 bytes
+ i-cache-line-size = <20>; // 32 bytes
+ d-cache-size = <8000>; // L1, 32K
+ i-cache-size = <8000>; // L1, 32K
+ timebase-frequency = <0>; // 33 MHz, from uboot
+ bus-frequency = <0>; // From uboot
+ clock-frequency = <0>; // From uboot
+ 32-bit;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <00000000 40000000>; // 1G at 0x0
+ };
+
+ soc8641@f8000000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "soc";
+ ranges = <0 f8000000 00100000>;
+ reg = <f8000000 00100000>; // CCSRBAR 1M
+ bus-frequency = <0>;
+
+ i2c@3000 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3000 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <40000>;
+ dfsrr;
+ };
+
+ i2c@3100 {
+ device_type = "i2c";
+ compatible = "fsl-i2c";
+ reg = <3100 100>;
+ interrupts = <2b 2>;
+ interrupt-parent = <40000>;
+ dfsrr;
+ };
+
+ mdio@24520 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "mdio";
+ compatible = "gianfar";
+ reg = <24520 20>;
+ linux,phandle = <24520>;
+ ethernet-phy@0 {
+ linux,phandle = <2452000>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <0>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@1 {
+ linux,phandle = <2452001>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <1>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@2 {
+ linux,phandle = <2452002>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <2>;
+ device_type = "ethernet-phy";
+ };
+ ethernet-phy@3 {
+ linux,phandle = <2452003>;
+ interrupt-parent = <40000>;
+ interrupts = <4a 1>;
+ reg = <3>;
+ device_type = "ethernet-phy";
+ };
+ };
+
+ ethernet@24000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <24000 1000>;
+ mac-address = [ 00 E0 0C 00 73 00 ];
+ interrupts = <1d 2 1e 2 22 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452000>;
+ };
+
+ ethernet@25000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <25000 1000>;
+ mac-address = [ 00 E0 0C 00 73 01 ];
+ interrupts = <23 2 24 2 28 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452001>;
+ };
+
+ ethernet@26000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <26000 1000>;
+ mac-address = [ 00 E0 0C 00 02 FD ];
+ interrupts = <1F 2 20 2 21 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452002>;
+ };
+
+ ethernet@27000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ device_type = "network";
+ model = "TSEC";
+ compatible = "gianfar";
+ reg = <27000 1000>;
+ mac-address = [ 00 E0 0C 00 03 FD ];
+ interrupts = <25 2 26 2 27 2>;
+ interrupt-parent = <40000>;
+ phy-handle = <2452003>;
+ };
+ serial@4500 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4500 100>;
+ clock-frequency = <0>;
+ interrupts = <2a 2>;
+ interrupt-parent = <40000>;
+ };
+
+ serial@4600 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <4600 100>;
+ clock-frequency = <0>;
+ interrupts = <1c 2>;
+ interrupt-parent = <40000>;
+ };
+
+ pci@8000 {
+ compatible = "86xx";
+ device_type = "pci";
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ reg = <8000 1000>;
+ bus-range = <0 fe>;
+ ranges = <02000000 0 80000000 80000000 0 20000000
+ 01000000 0 00000000 e2000000 0 00100000>;
+ clock-frequency = <1fca055>;
+ interrupt-parent = <40000>;
+ interrupts = <18 2>;
+ interrupt-map-mask = <f800 0 0 7>;
+ interrupt-map = <
+ /* IDSEL 0x11 */
+ 8800 0 0 1 4d0 3 2
+ 8800 0 0 2 4d0 4 2
+ 8800 0 0 3 4d0 5 2
+ 8800 0 0 4 4d0 6 2
+
+ /* IDSEL 0x12 */
+ 9000 0 0 1 4d0 4 2
+ 9000 0 0 2 4d0 5 2
+ 9000 0 0 3 4d0 6 2
+ 9000 0 0 4 4d0 3 2
+
+ /* IDSEL 0x13 */
+ 9800 0 0 1 4d0 0 0
+ 9800 0 0 2 4d0 0 0
+ 9800 0 0 3 4d0 0 0
+ 9800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x14 */
+ a000 0 0 1 4d0 0 0
+ a000 0 0 2 4d0 0 0
+ a000 0 0 3 4d0 0 0
+ a000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x15 */
+ a800 0 0 1 4d0 0 0
+ a800 0 0 2 4d0 0 0
+ a800 0 0 3 4d0 0 0
+ a800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x16 */
+ b000 0 0 1 4d0 0 0
+ b000 0 0 2 4d0 0 0
+ b000 0 0 3 4d0 0 0
+ b000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x17 */
+ b800 0 0 1 4d0 0 0
+ b800 0 0 2 4d0 0 0
+ b800 0 0 3 4d0 0 0
+ b800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x18 */
+ c000 0 0 1 4d0 0 0
+ c000 0 0 2 4d0 0 0
+ c000 0 0 3 4d0 0 0
+ c000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x19 */
+ c800 0 0 1 4d0 0 0
+ c800 0 0 2 4d0 0 0
+ c800 0 0 3 4d0 0 0
+ c800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1a */
+ d000 0 0 1 4d0 6 2
+ d000 0 0 2 4d0 3 2
+ d000 0 0 3 4d0 4 2
+ d000 0 0 4 4d0 5 2
+
+
+ /* IDSEL 0x1b */
+ d800 0 0 1 4d0 5 2
+ d800 0 0 2 4d0 0 0
+ d800 0 0 3 4d0 0 0
+ d800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1c */
+ e000 0 0 1 4d0 9 2
+ e000 0 0 2 4d0 a 2
+ e000 0 0 3 4d0 c 2
+ e000 0 0 4 4d0 7 2
+
+ /* IDSEL 0x1d */
+ e800 0 0 1 4d0 9 2
+ e800 0 0 2 4d0 a 2
+ e800 0 0 3 4d0 b 2
+ e800 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1e */
+ f000 0 0 1 4d0 c 2
+ f000 0 0 2 4d0 0 0
+ f000 0 0 3 4d0 0 0
+ f000 0 0 4 4d0 0 0
+
+ /* IDSEL 0x1f */
+ f800 0 0 1 4d0 6 2
+ f800 0 0 2 4d0 0 0
+ f800 0 0 3 4d0 0 0
+ f800 0 0 4 4d0 0 0
+ >;
+ i8259@4d0 {
+ clock-frequency = <0>;
+ interrupt-controller;
+ device_type = "interrupt-controller";
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ built-in;
+ compatible = "chrp,iic";
+ big-endian;
+ interrupts = <49 2>;
+ interrupt-parent = <40000>;
+ };
+
+ };
+ pic@40000 {
+ linux,phandle = <40000>;
+ clock-frequency = <0>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ reg = <40000 40000>;
+ built-in;
+ compatible = "chrp,open-pic";
+ device_type = "open-pic";
+ big-endian;
+ interrupts = <
+ 10 2 11 2 12 2 13 2
+ 14 2 15 2 16 2 17 2
+ 18 2 19 2 1a 2 1b 2
+ 1c 2 1d 2 1e 2 1f 2
+ 20 2 21 2 22 2 23 2
+ 24 2 25 2 26 2 27 2
+ 28 2 29 2 2a 2 2b 2
+ 2c 2 2d 2 2e 2 2f 2
+ 30 2 31 2 32 2 33 2
+ 34 2 35 2 36 2 37 2
+ 38 2 39 2 2a 2 3b 2
+ 3c 2 3d 2 3e 2 3f 2
+ 48 1 49 2 4a 1
+ >;
+ interrupt-parent = <40000>;
+ };
+ };
+};
--
2006_06_07.01.gittree_pull-dirty
^ 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