* [PATCH] Remove flush_dcache_all export
From: Matt Porter @ 2006-08-04 16:41 UTC (permalink / raw)
To: linuxppc-dev
Removes the flush_dcache_all export for non coherent platforms.
We removed the last in-kernel user of this years ago in arch/ppc
so it no longer serves a purpose. Plus, it breaks the build
at the moment.
Signed-off-by: Matt Porter <mporter@embeddedalley.com>
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index 4b052ae..0e18342 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -127,10 +127,6 @@ EXPORT_SYMBOL(pci_bus_mem_base_phys);
EXPORT_SYMBOL(pci_bus_to_hose);
#endif /* CONFIG_PCI */
-#ifdef CONFIG_NOT_COHERENT_CACHE
-EXPORT_SYMBOL(flush_dcache_all);
-#endif
-
EXPORT_SYMBOL(start_thread);
EXPORT_SYMBOL(kernel_thread);
^ permalink raw reply related
* Re: MTD Flash Howto ?
From: David H. Lynch Jr. @ 2006-08-04 15:52 UTC (permalink / raw)
To: Ned W. Rhodes, jonandia; +Cc: linuxppc-embedded
In-Reply-To: <001a01c6b7d1$17dd6130$6201eed0@ssgpoweredge>
Thanks;
I looked at the Denx stuff that was a good start. But raised
some questions:
I have a single device. I presume that means it is 8 bits
wide, and constitutes a single Bank.
I guess I have to query the Hardware people, on that.
What exactly drives CONFIG_MTD_I? and CONFIG_MTD_B?
A hard disk partition is usually reflected by data structures
(a partition table) written to the Disk.
Am I correct in assuming that these are in drivers/mtd/maps.
In my instance all the flash belongs to a single file system
There is a single reserved block at the begining,
but it is reflected in the filesystem structure not the
partitioning.
So as I understand things I have a single partition.
When I ran menuconfig, I indicated that I did not need/had a
single partitions - would that be the correct choice ?
There is a platform ram "map" that seems to allow defining the
flash region in a platform data structure - is that a viable alternative
to a machine specific map file ?
Is it limited to just RAM.
Prior to loading a filesystem driver shouldn;'t I get some
message indicating that mtd detected my specific type of flash ? or Is
that queriable inside /proc ?
Ned W. Rhodes wrote:
> The book Building Embedded Linux Systems has a good section on the use of
> flash file systems.
>
> When you boot, you will see something like this, depending on the type of
> flash driver you have. Make sure you have defined your mtd map in
> kernel/drivers/mtd/map.
>
> JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
> JFS: nTxBlock = 965, nTxLock = 7720
>
> Then if you have the MTD partitions correctly identified, the kernel will
> show you something like:
>
> CBG flash bank 0: Found 1 x16 devices at 0x0 in 16-bit bank
> Intel/Sharp Extended Query Table at 0x0031
> Using buffer write method
> cfi_cmdset_0001: Erase suspend on write enabled
> Creating 2 MTD partitions on "CBG flash bank 0":
> 0x00000000-0x01800000 : "ffw1"
> 0x01800000-0x02000000 : "filesystem1"
>
> Once booted you can look at /proc/mtd and you should see the partitions
> something like:
>
> [root@lbg ]# cat /proc/mtd
> dev: size erasesize name
> mtd0: 01800000 00020000 "ffw1"
> mtd1: 00800000 00020000 "filesystem1"
>
> Your mileage may vary depending on the type of flash you have and all the
> configuration options, but that is basically how to tell that things are
> mapped and ready for use.
>
> Ned W. Rhodes
> Software System Group
> 703.812.5072 x100
>
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: XUPV2P, Kernel 2.6.17 boot problem
From: David H. Lynch Jr. @ 2006-08-04 15:35 UTC (permalink / raw)
To: Peter Korsgaard, linuxppc-embedded
In-Reply-To: <87irl8zjl7.fsf@sleipner.barco.com>
[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]
Peter Korsgaard wrote:
>>>>>> "DHL" == David H Lynch <dhlii@dlasys.net> writes:
>>>>>>
>
>
>>> Linux/PPC load: console=ttyS0,9600.....
>>>
>>> Uncompressing Linux...inflate returned FFFFFFFB exit
>>>
>>>
>
> DHL> Zlib was upgraded with 2.6.17. The updated Zlib is broken on
> DHL> ppc32. I am pretty certain it is fixed in 2.6.18-rc3
>
> No, that was ony added in 2.6.18-rc1 (and the fix was only added
> post-rc3), so that can't be it..
>
I am not sure of the details, but I had the exact same problem, I
used "git bisect" to isolate it.
and it bisected down to the Zlib patch I backed that out and I was
able to go from 2.6.16.21. all the way to 2.6.18-rc2.
I beleive there is another problem of some kind that effects Xilinx
ppc's that went in and got fixed between 2.6.16.21 and 2.6.18-rcx.
Though my symptoms were different for that one, and I was never able
to isolate it because even though I could not get 2.6.17 to work,
The stuff in the 2.6 git tree did.
Have you tried 2.6.18.x to see if your stuff works with it ?
--
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: 2675 bytes --]
^ permalink raw reply
* RE: MTD Flash Howto ?
From: Ned W. Rhodes @ 2006-08-04 14:20 UTC (permalink / raw)
To: 'David H. Lynch Jr.'; +Cc: linuxppc-embedded
In-Reply-To: <mailman.2056.1154699657.11183.linuxppc-embedded@ozlabs.org>
The book Building Embedded Linux Systems has a good section on the use of
flash file systems.
When you boot, you will see something like this, depending on the type of
flash driver you have. Make sure you have defined your mtd map in
kernel/drivers/mtd/map.
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
JFS: nTxBlock = 965, nTxLock = 7720
Then if you have the MTD partitions correctly identified, the kernel will
show you something like:
CBG flash bank 0: Found 1 x16 devices at 0x0 in 16-bit bank
Intel/Sharp Extended Query Table at 0x0031
Using buffer write method
cfi_cmdset_0001: Erase suspend on write enabled
Creating 2 MTD partitions on "CBG flash bank 0":
0x00000000-0x01800000 : "ffw1"
0x01800000-0x02000000 : "filesystem1"
Once booted you can look at /proc/mtd and you should see the partitions
something like:
[root@lbg ]# cat /proc/mtd
dev: size erasesize name
mtd0: 01800000 00020000 "ffw1"
mtd1: 00800000 00020000 "filesystem1"
Your mileage may vary depending on the type of flash you have and all the
configuration options, but that is basically how to tell that things are
mapped and ready for use.
Ned W. Rhodes
Software System Group
703.812.5072 x100
^ permalink raw reply
* Re: XUPV2P, Kernel 2.6.17 boot problem
From: Peter Korsgaard @ 2006-08-04 14:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <44D1021C.5080602@dlasys.net>
>>>>> "DHL" == David H Lynch <dhlii@dlasys.net> writes:
>> Linux/PPC load: console=ttyS0,9600.....
>>
>> Uncompressing Linux...inflate returned FFFFFFFB exit
>>
DHL> Zlib was upgraded with 2.6.17. The updated Zlib is broken on
DHL> ppc32. I am pretty certain it is fixed in 2.6.18-rc3
No, that was ony added in 2.6.18-rc1 (and the fix was only added
post-rc3), so that can't be it..
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: invalidate_dcache_range Kernel 2.6.14
From: Alex Zeffertt @ 2006-08-04 14:01 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: GSM909, linuxppc-embedded
In-Reply-To: <44D352DE.9060007@cambridgebroadband.com>
Alex Zeffertt wrote:
> 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.
>
Oh, and obviously add it to a header file.
Alex
^ permalink raw reply
* 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
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