* Re: [PATCH] 1/2 Start header file merger (Was: Re: Beginning Merger Patch)
From: Michael Ellerman @ 2005-08-05 9:08 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20050805174705.731ffa05.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1525 bytes --]
And for the faint of heart there's a patch at:
http://michael.ellerman.id.au/files/misc/header-merge.patch
cheers
On Fri, 5 Aug 2005 17:47, Stephen Rothwell wrote:
> On Tue, 2 Aug 2005 19:10:56 -0400 Dan Malek <dan@embeddededge.com> wrote:
> > On Aug 2, 2005, at 6:59 PM, Jon Loeliger wrote:
> > > ..... A stub is left
> > > in asm-ppc and asm-ppc64 pointing to the unified files.
> >
> > Why bother? You may as well change all of the source
> > files, too, or else that will never get done :-)
>
> You actually don't need to modify (m)any source files.
>
> Here is an alternative approach. These patches depend on Olaf's
> boot code cleanup for ppc64 (or similar). Do the following:
>
> cd linux/include
> mkdir asm-powerpc
> cd asm-ppc
> for i in *
> do
> [ -e ../asm-ppc64/$i ] || mv $i ../asm-powerpc/$i
> done
> cd ../asm-ppc64
> for i in *
> do
> [ -e ../asm-ppc/$i ] || mv $i ../asm-powerpc/$i
> done
> for i in *
> do
> [ -f ../asm-ppc64/$i ] && cmp -s $i ../asm-ppc64/$i &&
> mv $i ../asm-powerpc/$i && rm ../asm-ppc64/$i
> done
>
> Then apply the patch below and the patch in the following email.
>
> I have built this kernel for ppc (defconfig), ppc64 (iSeries, pSeries and
> pmac).
--
Michael Ellerman
IBM OzLabs
email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: The kernel halt after "transferring control to linux(0x000000)..." on HD860(MPC860SR) board kernel 2.4.25, and 2.6.12
From: Wolfgang Denk @ 2005-08-05 9:16 UTC (permalink / raw)
To: FCG WANG Baohua; +Cc: linuxppc-dev, linuxppc-embedded
In-Reply-To: <A9DE2BAF233E444FA9C5E77A5825A01E865055@ydmail.sbell.com.cn>
In message <A9DE2BAF233E444FA9C5E77A5825A01E865055@ydmail.sbell.com.cn> you wrote:
>
> I meet a problem when porting kernel 2.4.25,and 2.6.12 to a HD860
> board: Whatever your config, or whatever you patch, set ppcboot
> enviroment,
> whether use ramdisk or nfs, the kernel all display a message then
> halt.
How do you define "halt"? There is no "halt" instruction in the CPU,
so it must be doing "something".
> The log_buf in Memory display that the kernel has problem at :
>
> 1. /init/main.c calibrate_delay() ;
> 2. /init/main.c do_initcalls() do while dead loop!!
> 3. /init/do_mounts.c mount_root()
Locate the problems and fix them.
> Does it need any patches? thanks!
> The kernel 2.4.25 is from ELDK 3.1.1, 2.6.12.3 is from kernel.org
this kernel works fine on many, many other boards. It's extremely
likely that the problems are caused by your port only.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A person who is more than casually interested in computers should be
well schooled in machine language, since it is a fundamental part of
a computer. -- Donald Knuth
^ permalink raw reply
* Does ELDK 3.1 ppc-linux-x86 support target mpc862 ?
From: hegs @ 2005-08-05 10:22 UTC (permalink / raw)
To: linuxppc-embedded
RG9lcyBFTERLIDMuMSBwcGMtbGludXgteDg2IHN1cHBvcnQgdGFyZ2V0IG1wYzg2MiA/DQoNCg0K
DQpUaGFua3MhDQpTWkgNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K
^ permalink raw reply
* Problem related to root filesystem
From: apoorv sangal @ 2005-08-05 10:38 UTC (permalink / raw)
To: linuxppc-embedded
Cc: sibi_mathew, vikrant_basotra, nishant_galange, apoorv sangal
Hi All,
=09I am porting Linux on the custom board PMC8266 (having MPC8266
microprocessor) based on the ADS8260 board.I am using ELDK1.1.1 and
Linux2.4.24.
I am trying to load JFFS2 filesystem , the JFFS2 filesystem image is
at address 0xFC160000 and the flash size is 32mb
I am getting the following messages:-
physmap flash device: 2000000 at fc160000
CFI: Found no Physically mapped flash device at location zero
kmod: failed to exec /sbin/modprobe -s -k jedec_probe, errno =3D 2
kmod: failed to exec /sbin/modprobe -s -k map_rom, errno =3D 2
pmc8260 flash map (size->0x2000000 mem->0xFC160000)
CFI: Found no pmc8260 flash memory device at location zero
Can anyone please tell me what is happening and how can i set it right??
***************************************************************************=
**
The whole of captured output is as following:-
***************************************************************************=
**
Image Name: 2.4.24 ADS8260
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 302270 Bytes =3D 295.2 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ...=20
Linux version 2.4.24-pre2 (satyam@pmcserver) (gcc version 3.2.2
20030217 (Yellow Dog Linux 3.0 3.2.2-2a_1)) #20 Fri Aug 5 15:22:28 IST
2005
On node 0 totalpages: 32768
zone(0): 32768 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=3DttyS0,115200 root=3DFC160000 rw rootfstype=
=3Djffs2
Warning: real time clock seems stuck!
Calibrating delay loop... 131.89 BogoMIPS
Memory: 128712k available (512k kernel code, 260k data, 36k init, 0k highme=
m)
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 8192 (order: 3, 32768 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd
Inside Chr_dev_init
CPM UART driver version 0.01
ttyS0 on SMC1 at 0x0000, BRG7
ttyS1 on SMC2 at 0x0040, BRG8
ttyS2 on SCC1 at 0x8000, BRG1
ttyS3 on SCC2 at 0x8100, BRG2
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
physmap flash device: 2000000 at fc160000
CFI: Found no Physically mapped flash device at location zero
kmod: failed to exec /sbin/modprobe -s -k jedec_probe, errno =3D 2
kmod: failed to exec /sbin/modprobe -s -k map_rom, errno =3D 2
pmc8260 flash map (size->0x2000000 mem->0xFC160000)
CFI: Found no pmc8260 flash memory device at location zero
*****
VFS:test name =3D /dev/root
VFS:fs_name =3D jffs2=20
VFS:root name =3D 00:00
****=20
kmod: failed to exec /sbin/modprobe -s -k jffs2, errno =3D 2
VFS:tried fs_name =3D jffs2 err =3D -19
VFS: Cannot open root device "FC160000" or 00:00
Please append a correct "root=3D" boot option
Kernel panic: VFS: Unable to mount root fs on 00:00
<0>Rebooting in 180 seconds..
Response awaited from the list.
Regards,
Apoorv Sangal
^ permalink raw reply
* what to use to connect to JTAG/BDM port on PPC405EP
From: Igor Marnat @ 2005-08-05 11:11 UTC (permalink / raw)
To: linuxppc-embedded
Hello List!
Hope, it's not offtopic.
I have EVB based on PPC 405 EP (PPChameleon EVB). It has JTAG port.
What JTAG device can I use to connect to the board? I've found BDI2000
device, for example, but it costs as N times as the EVB does
(approximately). It seems unreasonable for me. Is it possible to make such a device or to find
find the cheaper one? We found several schemes of how to make connector BDM-parallel
port. Is it possible to do such a thing for PPC 405EP?
Regards,
Igor Marnat
mailto:marny@rambler.ru
^ permalink raw reply
* FW: Mpc5200 and ISP1106/1107 USB transceivers
From: Dieter Schneider @ 2005-08-05 11:00 UTC (permalink / raw)
To: 'linux embedded forum'
[-- Attachment #1: Type: text/plain, Size: 263 bytes --]
Mit freundlichen Grüßen
Berghof Automationstechnik GmbH
i.A. Dieter Schneider
- Entwicklungsingenieur -
http://www.berghof.com
mailto:dieter.schneider@berghof.com
Phone: +49 7121 894-129
Fax: +49 7121 894-100
Adresse:
Harretstr.1 72800 Eningen
Deutschland
[-- Attachment #2: Type: message/rfc822, Size: 1580 bytes --]
From: "Dieter Schneider" <dieter.schneider@berghof.com>
To: <Martin.Krause@tqs.de>
Subject: Mpc5200 and ISP1106/1107 USB transceivers
Date: Thu, 4 Aug 2005 17:14:44 +0200
Hello Mr.Krause,
i made an investigation with Philips 1106/1107 USB transceivers not working
with low speed devices and mpc5200:
-usb 1.1 specification gives a rise/fall time for low speed devices in range
75ns to 300ns.
-"working" devices like Philips PDIUSBP11 have a rise/fall time of aprox.
120ns
-isp1106 / 1107 are in range of 180ns, that's inside usb 1.1 spec, but not
working with mpc5200
So its a problem of mpc5200, not philips 1106/1107 transceivers, who are
inside usb 1.1 spec. Setting transceiver speed pin konstant to High(=high
speed device) let the isp1106/1107 work also with low speed devices, but of
course with high speed rise/fall times (7..20ns). By the way, Phillips
PDIUSBP11 is obsolet. Giving the USB D+/D- an additional capacitive load
(for example 120pF, thats inside usb 1.1 spec ) makes an working Phillips
PDIUSBP11 not working.
Mit freundlichen Grüßen
Berghof Automationstechnik GmbH
i.A. Dieter Schneider
- Entwicklungsingenieur -
http://www.berghof.com
mailto:dieter.schneider@berghof.com
Phone: +49 7121 894-129
Fax: +49 7121 894-100
Adresse:
Harretstr.1 72800 Eningen
Deutschland
^ permalink raw reply
* Re: [PATCH] 1/2 Start header file merger (Was: Re: Beginning Merger Patch)
From: Arnd Bergmann @ 2005-08-05 11:53 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20050805174705.731ffa05.sfr@canb.auug.org.au>
On Freedag 05 August 2005 09:47, Stephen Rothwell wrote:
> cd linux/include
> mkdir asm-powerpc
> cd asm-ppc
> for i in *
> do
> =A0=A0=A0=A0=A0=A0=A0=A0[ -e ../asm-ppc64/$i ] || mv $i ../asm-powerpc/$i
> done
> cd ../asm-ppc64
> for i in *
> do
> =A0=A0=A0=A0=A0=A0=A0=A0[ -e ../asm-ppc/$i ] || mv $i ../asm-powerpc/$i
> done
While I really like your approach in general (I've done it the
same way when merging asm-s390{,x]), I think we should take
a little care to move only the files that we really want in
asm/powerpc.
E.g, most of the files that are in asm-ppc but not in asm-ppc64
seem so be board-specific or cpu-specific, so I'd not move them
around before (unless) moving the platform code for those as well.
Also, for everything below include/asm-ppc64/iSeries, it would
make sense to rename the files to lowercase in the same
step and change all their users.
> for i in *
> do
> =A0=A0=A0=A0=A0=A0=A0=A0[ -f ../asm-ppc64/$i ] && cmp -s $i ../asm-ppc64/=
$i &&
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0mv $i ../asm-powerpc/$i &=
& rm ../asm-ppc64/$i
> done
Another help for merging further is to do=20
for i in `ls include/asm-ppc` ; do=20
if [ -e include/asm-ppc64/$i ] ; then
diff --ifdef __powerpc64__ include/asm-{ppc,ppc64}/$i > \
include/asm-generic/$i ;
fi
done
Note that you need to hand-edit practically every file that you get from
this, but many of them become trivial to merge.
Another interesting point about it is which define to use. For s390, we
decided to '#ifdef __s390x__' rather than '#ifdef CONFIG_ARCH_S390X' or
'ifdef CONFIG_64BIT', because CONFIG_* does not work when including the
headers from user space.
Using CONFIG_64BIT instead of __powerpc64__ only within #ifdef __KERNEL__
would be correct but less consistant.
Arnd <><
^ permalink raw reply
* Re: Problem related to root filesystem
From: Tore Martin Hagen @ 2005-08-05 11:35 UTC (permalink / raw)
To: apoorv sangal
Cc: apoorv sangal, vikrant_basotra, nishant_galange, sibi_mathew,
linuxppc-embedded
In-Reply-To: <a796693605080503383ce43419@mail.gmail.com>
Hi Apoorv.
Is the Flash CFI complient?
The sharp flash that commes with the ADS8260 board is not.
/Tore
apoorv sangal wrote:
>Hi All,
> I am porting Linux on the custom board PMC8266 (having MPC8266
>microprocessor) based on the ADS8260 board.I am using ELDK1.1.1 and
>Linux2.4.24.
>
>I am trying to load JFFS2 filesystem , the JFFS2 filesystem image is
>at address 0xFC160000 and the flash size is 32mb
>
>I am getting the following messages:-
>physmap flash device: 2000000 at fc160000
>
>CFI: Found no Physically mapped flash device at location zero
>
>kmod: failed to exec /sbin/modprobe -s -k jedec_probe, errno = 2
>
>kmod: failed to exec /sbin/modprobe -s -k map_rom, errno = 2
>
>pmc8260 flash map (size->0x2000000 mem->0xFC160000)
>
>CFI: Found no pmc8260 flash memory device at location zero
>
>Can anyone please tell me what is happening and how can i set it right??
>
>*****************************************************************************
>The whole of captured output is as following:-
>*****************************************************************************
>Image Name: 2.4.24 ADS8260
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 302270 Bytes = 295.2 kB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ...
>
>Linux version 2.4.24-pre2 (satyam@pmcserver) (gcc version 3.2.2
>20030217 (Yellow Dog Linux 3.0 3.2.2-2a_1)) #20 Fri Aug 5 15:22:28 IST
>2005
>
>On node 0 totalpages: 32768
>
>zone(0): 32768 pages.
>
>zone(1): 0 pages.
>
>zone(2): 0 pages.
>
>Kernel command line: console=ttyS0,115200 root=FC160000 rw rootfstype=jffs2
>
>Warning: real time clock seems stuck!
>
>Calibrating delay loop... 131.89 BogoMIPS
>
>Memory: 128712k available (512k kernel code, 260k data, 36k init, 0k highmem)
>
>Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
>
>Inode cache hash table entries: 8192 (order: 4, 65536 bytes)
>
>Mount cache hash table entries: 512 (order: 0, 4096 bytes)
>
>Buffer cache hash table entries: 8192 (order: 3, 32768 bytes)
>
>Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
>
>POSIX conformance testing by UNIFIX
>
>Linux NET4.0 for Linux 2.4
>
>Based upon Swansea University Computer Society NET3.039
>
>Starting kswapd
>
>Inside Chr_dev_init
>
>CPM UART driver version 0.01
>
>ttyS0 on SMC1 at 0x0000, BRG7
>
>ttyS1 on SMC2 at 0x0040, BRG8
>
>ttyS2 on SCC1 at 0x8000, BRG1
>
>ttyS3 on SCC2 at 0x8100, BRG2
>
>RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
>
>physmap flash device: 2000000 at fc160000
>
>CFI: Found no Physically mapped flash device at location zero
>
>kmod: failed to exec /sbin/modprobe -s -k jedec_probe, errno = 2
>
>kmod: failed to exec /sbin/modprobe -s -k map_rom, errno = 2
>
>pmc8260 flash map (size->0x2000000 mem->0xFC160000)
>
>CFI: Found no pmc8260 flash memory device at location zero
>
>*****
>
>VFS:test name = /dev/root
>
>VFS:fs_name = jffs2
>
>VFS:root name = 00:00
>
> ****
>
>kmod: failed to exec /sbin/modprobe -s -k jffs2, errno = 2
>
>VFS:tried fs_name = jffs2 err = -19
>
>VFS: Cannot open root device "FC160000" or 00:00
>
>Please append a correct "root=" boot option
>
>Kernel panic: VFS: Unable to mount root fs on 00:00
>
> <0>Rebooting in 180 seconds..
>
>Response awaited from the list.
>
>Regards,
>Apoorv Sangal
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: Problem related to root filesystem
From: apoorv sangal @ 2005-08-05 12:04 UTC (permalink / raw)
To: Tore Martin Hagen, linuxppc-embedded
Cc: apoorv sangal, vikrant_basotra, nishant_galange, sibi_mathew
In-Reply-To: <42F34F05.2080508@oslo.westerngeco.slb.com>
Hi Tore,
Thanks for replying.
I am using Intel StrataFlash Memory (28F2563) and I have checked in
the data sheet it is CFI compliant.
So the problem lies somewhere else.
Regards,
Apoorv Sangal
On 8/5/05, Tore Martin Hagen <THagen@oslo.westerngeco.slb.com> wrote:
> Hi Apoorv.
>=20
> Is the Flash CFI complient?
>=20
> The sharp flash that commes with the ADS8260 board is not.
>=20
> /Tore
>=20
> apoorv sangal wrote:
>=20
> >Hi All,
> > I am porting Linux on the custom board PMC8266 (having MPC8266
> >microprocessor) based on the ADS8260 board.I am using ELDK1.1.1 and
> >Linux2.4.24.
> >
> >I am trying to load JFFS2 filesystem , the JFFS2 filesystem image is
> >at address 0xFC160000 and the flash size is 32mb
> >
> >I am getting the following messages:-
> >physmap flash device: 2000000 at fc160000
> >
> >CFI: Found no Physically mapped flash device at location zero
> >
> >kmod: failed to exec /sbin/modprobe -s -k jedec_probe, errno =3D 2
> >
> >kmod: failed to exec /sbin/modprobe -s -k map_rom, errno =3D 2
> >
> >pmc8260 flash map (size->0x2000000 mem->0xFC160000)
> >
> >CFI: Found no pmc8260 flash memory device at location zero
> >
> >Can anyone please tell me what is happening and how can i set it right??
> >
> >************************************************************************=
*****
> >The whole of captured output is as following:-
> >************************************************************************=
*****
> >Image Name: 2.4.24 ADS8260
> > Image Type: PowerPC Linux Kernel Image (gzip compressed)
> > Data Size: 302270 Bytes =3D 295.2 kB
> > Load Address: 00000000
> > Entry Point: 00000000
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ...
> >
> >Linux version 2.4.24-pre2 (satyam@pmcserver) (gcc version 3.2.2
> >20030217 (Yellow Dog Linux 3.0 3.2.2-2a_1)) #20 Fri Aug 5 15:22:28 IST
> >2005
> >
> >On node 0 totalpages: 32768
> >
> >zone(0): 32768 pages.
> >
> >zone(1): 0 pages.
> >
> >zone(2): 0 pages.
> >
> >Kernel command line: console=3DttyS0,115200 root=3DFC160000 rw rootfstyp=
e=3Djffs2
> >
> >Warning: real time clock seems stuck!
> >
> >Calibrating delay loop... 131.89 BogoMIPS
> >
> >Memory: 128712k available (512k kernel code, 260k data, 36k init, 0k hig=
hmem)
> >
> >Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
> >
> >Inode cache hash table entries: 8192 (order: 4, 65536 bytes)
> >
> >Mount cache hash table entries: 512 (order: 0, 4096 bytes)
> >
> >Buffer cache hash table entries: 8192 (order: 3, 32768 bytes)
> >
> >Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
> >
> >POSIX conformance testing by UNIFIX
> >
> >Linux NET4.0 for Linux 2.4
> >
> >Based upon Swansea University Computer Society NET3.039
> >
> >Starting kswapd
> >
> >Inside Chr_dev_init
> >
> >CPM UART driver version 0.01
> >
> >ttyS0 on SMC1 at 0x0000, BRG7
> >
> >ttyS1 on SMC2 at 0x0040, BRG8
> >
> >ttyS2 on SCC1 at 0x8000, BRG1
> >
> >ttyS3 on SCC2 at 0x8100, BRG2
> >
> >RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> >
> >physmap flash device: 2000000 at fc160000
> >
> >CFI: Found no Physically mapped flash device at location zero
> >
> >kmod: failed to exec /sbin/modprobe -s -k jedec_probe, errno =3D 2
> >
> >kmod: failed to exec /sbin/modprobe -s -k map_rom, errno =3D 2
> >
> >pmc8260 flash map (size->0x2000000 mem->0xFC160000)
> >
> >CFI: Found no pmc8260 flash memory device at location zero
> >
> >*****
> >
> >VFS:test name =3D /dev/root
> >
> >VFS:fs_name =3D jffs2
> >
> >VFS:root name =3D 00:00
> >
> > ****
> >
> >kmod: failed to exec /sbin/modprobe -s -k jffs2, errno =3D 2
> >
> >VFS:tried fs_name =3D jffs2 err =3D -19
> >
> >VFS: Cannot open root device "FC160000" or 00:00
> >
> >Please append a correct "root=3D" boot option
> >
> >Kernel panic: VFS: Unable to mount root fs on 00:00
> >
> > <0>Rebooting in 180 seconds..
> >
> >Response awaited from the list.
> >
> >Regards,
> >Apoorv Sangal
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>=20
>
^ permalink raw reply
* Re: Problem related to root filesystem
From: Vitaly Bordug @ 2005-08-05 12:10 UTC (permalink / raw)
To: apoorv sangal
Cc: apoorv sangal, vikrant_basotra, nishant_galange, sibi_mathew,
linuxppc-embedded
In-Reply-To: <a796693605080503383ce43419@mail.gmail.com>
apoorv sangal wrote:
>Hi All,
> I am porting Linux on the custom board PMC8266 (having MPC8266
>microprocessor) based on the ADS8260 board.I am using ELDK1.1.1 and
>Linux2.4.24.
>
>I am trying to load JFFS2 filesystem , the JFFS2 filesystem image is
>at address 0xFC160000 and the flash size is 32mb
>
>I am getting the following messages:-
>physmap flash device: 2000000 at fc160000
>
>CFI: Found no Physically mapped flash device at location zero
>
>
>
Check if flash-relative buswidth and interleave has been configured
within CONFIG_MTD_CFI_GEOMETRY.
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] 1/2 Start header file merger (Was: Re: Beginning Merger Patch)
From: Stephen Rothwell @ 2005-08-05 14:59 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <200508051353.23750.arnd@arndb.de>
Hi Arnd,
On Fri, 5 Aug 2005 13:53:22 +0200 Arnd Bergmann <arnd@arndb.de> wrote:
>
> While I really like your approach in general (I've done it the
> same way when merging asm-s390{,x]), I think we should take
> a little care to move only the files that we really want in
> asm/powerpc.
Sure, this was just a first pass - really to demonstrate that we
can remove header files from their original directories as we go.
> E.g, most of the files that are in asm-ppc but not in asm-ppc64
> seem so be board-specific or cpu-specific, so I'd not move them
> around before (unless) moving the platform code for those as well.
Indeed.
> Also, for everything below include/asm-ppc64/iSeries, it would
> make sense to rename the files to lowercase in the same
> step and change all their users.
That would definitely be a separate set of patches (those include
files are referenced in 47 different files).
> Another help for merging further is to do
>
> for i in `ls include/asm-ppc` ; do
> if [ -e include/asm-ppc64/$i ] ; then
> diff --ifdef __powerpc64__ include/asm-{ppc,ppc64}/$i > \
> include/asm-generic/$i ;
^^^^^^^
(I assume you meant powerpc as we are not the generic architecture, yet :-))
> fi
> done
>
> Note that you need to hand-edit practically every file that you get from
> this, but many of them become trivial to merge.
I'll have a go and see what happens.
> Another interesting point about it is which define to use. For s390, we
> decided to '#ifdef __s390x__' rather than '#ifdef CONFIG_ARCH_S390X' or
> 'ifdef CONFIG_64BIT', because CONFIG_* does not work when including the
> headers from user space.
Well noone should even include kernel headers from user space :-) and my
understanding is that glibc "sanitizes" its version of the kernel headers
anyway.
> Using CONFIG_64BIT instead of __powerpc64__ only within #ifdef __KERNEL__
> would be correct but less consistant.
The advantage of using CONFIG_64BIT as much as possible is that it shows
us places that can be consolidated across the various architectures
(which is a bit of a passion of mine :-)). And more consolidation should
make life easier for the glibc folks in the long run.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply
* RE: MPC885ADS and 2.6.13-rc5 - nogo ?
From: Schaefer-Hutter, Peter @ 2005-08-05 16:00 UTC (permalink / raw)
To: linuxppc-embedded list
Hello!=20
Replying to myself: I'm able to see bootup messages on ttyCPM0 now=20
after i applied the "Made non-console uart work"-patch that i skipped
until now because, well, it was "non-console" ...
However, output on ttyCPM0 stops soon:
Linux version 2.6.13-rc5 (ashaepe@rcf02) (gcc version 3.3.2) #20 Fri
Aug 5 17:48:42 CEST 2005
Built 1 zonelists
Kernel command line: console=3DttyCPM0,38400n8 root=3D/dev/nfs
nfsroot=3D/home/ashaepe/nfs rw ip=3D10.135.2.133:10.135.0.22:1
0.135.0.1:255.255.252.0::eth0:off
PID hash table entries: 64 (order: 6, 1024 bytes)
Decrementer Frequency =3D 375000000/60
Dentry cache hash table entries: 2048 (order: 1, 8192 bytes)
Inode-cache hash table entries: 1024 (order: 0, 4096 bytes)
Memory: 6272k available (1352k kernel code, 404k data, 68k init, 0k
highmem)
Mount-cache hash table entries: 512
Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:348
Call trace:
[c0005b10] dump_stack+0x18/0x28
[c0003c60] check_bug_trap+0x84/0xac
[c0003de8] ProgramCheckException+0x160/0x1a0
[c0003260] ret_from_except_full+0x0/0x4c
[c01a9f84] dma_alloc_init+0x44/0xa0
[c01a66a4] do_initcalls+0x54/0xfc
[c0002260] init+0x2c/0xf4
[c000533c] kernel_thread+0x44/0x60
NET: Registered protocol family 16
JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
Serial: CPM driver $Revision: 0.01 $
ttyCPM0 at MMIO 0xff000a80 (irq =3D 20) is a CPM UART
ttyCPM1 at MMIO 0xff000a90 (irq =3D 19) is a CPM UART
io scheduler noop registered
And that's all output for now...
Can anybody explain the "dma_alloc_init"-error ?
Best regards,
Peter
-----Original Message-----
Hello!
I gave the MPC885ADS support recently added by Andrei Konovalov=20
a try - but no luck: booting 2.6.13-rc5 with u-boot 1.1.2=20
(tftpboot & bootm) hangs after uncompressing.
Did anybody succeed with this?
Applied were the following patches from patchwork.ozlabs.org:
* 8xx_cpm_hostalloc
* all fixes to fec.c
The board boots an 2.4-Kernel just fine. Did i miss some patches=20
for U-Boot?
Best regards,
Peter
^ permalink raw reply
* Re: MPC885ADS and 2.6.13-rc5 - nogo ?
From: aris @ 2005-08-05 16:26 UTC (permalink / raw)
To: Schaefer-Hutter, Peter; +Cc: linuxppc-embedded list
In-Reply-To: <8E342283C2100540AAC5D103097054776F87A9@rcexc.racoms.loc>
> Badness in dma_alloc_init at arch/ppc/kernel/dma-mapping.c:348
> Call trace:
> [c0005b10] dump_stack+0x18/0x28
> [c0003c60] check_bug_trap+0x84/0xac
> [c0003de8] ProgramCheckException+0x160/0x1a0
> [c0003260] ret_from_except_full+0x0/0x4c
> [c01a9f84] dma_alloc_init+0x44/0xa0
> [c01a66a4] do_initcalls+0x54/0xfc
> [c0002260] init+0x2c/0xf4
> [c000533c] kernel_thread+0x44/0x60
> NET: Registered protocol family 16
> JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
> Serial: CPM driver $Revision: 0.01 $
> ttyCPM0 at MMIO 0xff000a80 (irq = 20) is a CPM UART
> ttyCPM1 at MMIO 0xff000a90 (irq = 19) is a CPM UART
just out of curiosity, try changing CONSISTENT_START to 0xe0000000
--
Aristeu
^ permalink raw reply
* [PATCH] 85xx platform support for PHY Abstraction Layer
From: Andy Fleming @ 2005-08-05 17:33 UTC (permalink / raw)
To: linuxppc-embedded, kumar.gala
This patch adds necessary platform code to bring up PHYs for gianfar using
the new PHY Abstraction Layer. It is codependent with the gianfar patch I
sent to the netdev list earlier this week (i.e. either both or neither
need to be applied for the driver to even build).
Signed-off-by: Andy Fleming <afleming@freescale.com>
diff --git a/arch/ppc/platforms/85xx/mpc8540_ads.c b/arch/ppc/platforms/85xx/mpc8540_ads.c
--- a/arch/ppc/platforms/85xx/mpc8540_ads.c
+++ b/arch/ppc/platforms/85xx/mpc8540_ads.c
@@ -53,6 +53,10 @@
#include <syslib/ppc85xx_setup.h>
+static const char *GFAR_PHY_0 = "phy0:0";
+static const char *GFAR_PHY_1 = "phy0:1";
+static const char *GFAR_PHY_3 = "phy0:3";
+
/* ************************************************************************
*
* Setup the architecture
@@ -64,6 +68,7 @@ mpc8540ads_setup_arch(void)
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
struct gianfar_platform_data *pdata;
+ struct gianfar_mdio_data *mdata;
/* get the core frequency */
freq = binfo->bi_intfreq;
@@ -90,34 +95,35 @@ mpc8540ads_setup_arch(void)
invalidate_tlbcam_entry(num_tlbcam_entries - 1);
#endif
+ /* setup the board related info for the MDIO bus */
+ mdata = (struct gianfar_mdio_data *) ppc_sys_get_pdata(MPC85xx_MDIO);
+
+ mdata->irq[0] = MPC85xx_IRQ_EXT5;
+ mdata->irq[1] = MPC85xx_IRQ_EXT5;
+ mdata->irq[2] = -1;
+ mdata->irq[3] = MPC85xx_IRQ_EXT5;
+ mdata->irq[31] = -1;
+ mdata->paddr += binfo->bi_immr_base;
+
/* setup the board related information for the enet controllers */
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC1);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 0;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_0;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC2);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 1;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_1;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_FEC);
if (pdata) {
pdata->board_flags = 0;
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 3;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_3;
memcpy(pdata->mac_addr, binfo->bi_enet2addr, 6);
}
diff --git a/arch/ppc/platforms/85xx/mpc8560_ads.c b/arch/ppc/platforms/85xx/mpc8560_ads.c
--- a/arch/ppc/platforms/85xx/mpc8560_ads.c
+++ b/arch/ppc/platforms/85xx/mpc8560_ads.c
@@ -58,6 +58,10 @@
extern void cpm2_reset(void);
+static const char *GFAR_PHY_0 = "phy0:0";
+static const char *GFAR_PHY_1 = "phy0:1";
+static const char *GFAR_PHY_3 = "phy0:3";
+
/* ************************************************************************
*
* Setup the architecture
@@ -70,6 +74,7 @@ mpc8560ads_setup_arch(void)
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
struct gianfar_platform_data *pdata;
+ struct gianfar_mdio_data *mdata;
cpm2_reset();
@@ -88,24 +93,28 @@ mpc8560ads_setup_arch(void)
mpc85xx_setup_hose();
#endif
+ /* setup the board related info for the MDIO bus */
+ mdata = (struct gianfar_mdio_data *) ppc_sys_get_pdata(MPC85xx_MDIO);
+
+ mdata->irq[0] = MPC85xx_IRQ_EXT5;
+ mdata->irq[1] = MPC85xx_IRQ_EXT5;
+ mdata->irq[2] = -1;
+ mdata->irq[3] = MPC85xx_IRQ_EXT5;
+ mdata->irq[31] = -1;
+ mdata->paddr += binfo->bi_immr_base;
+
/* setup the board related information for the enet controllers */
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC1);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 0;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_0;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC2);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 1;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_1;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
diff --git a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
--- a/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
+++ b/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
@@ -395,6 +395,9 @@ mpc85xx_cds_pcibios_fixup(void)
TODC_ALLOC();
+static const char *GFAR_PHY_0 = "phy0:0";
+static const char *GFAR_PHY_1 = "phy0:1";
+
/* ************************************************************************
*
* Setup the architecture
@@ -406,6 +409,7 @@ mpc85xx_cds_setup_arch(void)
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
struct gianfar_platform_data *pdata;
+ struct gianfar_mdio_data *mdata;
/* get the core frequency */
freq = binfo->bi_intfreq;
@@ -449,44 +453,42 @@ mpc85xx_cds_setup_arch(void)
invalidate_tlbcam_entry(num_tlbcam_entries - 1);
#endif
+ /* setup the board related info for the MDIO bus */
+ mdata = (struct gianfar_mdio_data *) ppc_sys_get_pdata(MPC85xx_MDIO);
+
+ mdata->irq[0] = MPC85xx_IRQ_EXT5;
+ mdata->irq[1] = MPC85xx_IRQ_EXT5;
+ mdata->irq[2] = -1;
+ mdata->irq[3] = -1;
+ mdata->irq[31] = -1;
+ mdata->paddr += binfo->bi_immr_base;
+
/* setup the board related information for the enet controllers */
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC1);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 0;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_0;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC2);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 1;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_1;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_eTSEC1);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 0;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_0;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_eTSEC2);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 1;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_1;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
diff --git a/arch/ppc/platforms/85xx/sbc8560.c b/arch/ppc/platforms/85xx/sbc8560.c
--- a/arch/ppc/platforms/85xx/sbc8560.c
+++ b/arch/ppc/platforms/85xx/sbc8560.c
@@ -92,6 +92,9 @@ sbc8560_early_serial_map(void)
}
#endif
+static const char *GFAR_PHY_25 = "phy0:25";
+static const char *GFAR_PHY_26 = "phy0:26";
+
/* ************************************************************************
*
* Setup the architecture
@@ -103,6 +106,7 @@ sbc8560_setup_arch(void)
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
struct gianfar_platform_data *pdata;
+ struct gianfar_mdio_data *mdata;
/* get the core frequency */
freq = binfo->bi_intfreq;
@@ -127,24 +131,26 @@ sbc8560_setup_arch(void)
invalidate_tlbcam_entry(num_tlbcam_entries - 1);
#endif
+ /* setup the board related info for the MDIO bus */
+ mdata = (struct gianfar_mdio_data *) ppc_sys_get_pdata(MPC85xx_MDIO);
+
+ mdata->irq[25] = MPC85xx_IRQ_EXT6;
+ mdata->irq[26] = MPC85xx_IRQ_EXT7;
+ mdata->irq[31] = -1;
+ mdata->paddr += binfo->bi_immr_base;
+
/* setup the board related information for the enet controllers */
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC1);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC85xx_IRQ_EXT6;
- pdata->phyid = 25;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_25;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC2);
if (pdata) {
pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR;
- pdata->interruptPHY = MPC85xx_IRQ_EXT7;
- pdata->phyid = 26;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_26;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
diff --git a/arch/ppc/platforms/85xx/stx_gp3.c b/arch/ppc/platforms/85xx/stx_gp3.c
--- a/arch/ppc/platforms/85xx/stx_gp3.c
+++ b/arch/ppc/platforms/85xx/stx_gp3.c
@@ -93,6 +93,9 @@ static u8 gp3_openpic_initsenses[] __ini
0x0, /* External 11: */
};
+static const char *GFAR_PHY_2 = "phy0:2";
+static const char *GFAR_PHY_4 = "phy0:4";
+
/*
* Setup the architecture
*/
@@ -102,6 +105,7 @@ gp3_setup_arch(void)
bd_t *binfo = (bd_t *) __res;
unsigned int freq;
struct gianfar_platform_data *pdata;
+ struct gianfar_mdio_data *mdata;
cpm2_reset();
@@ -120,23 +124,26 @@ gp3_setup_arch(void)
mpc85xx_setup_hose();
#endif
+ /* setup the board related info for the MDIO bus */
+ mdata = (struct gianfar_mdio_data *) ppc_sys_get_pdata(MPC85xx_MDIO);
+
+ mdata->irq[2] = MPC85xx_IRQ_EXT5;
+ mdata->irq[4] = MPC85xx_IRQ_EXT5;
+ mdata->irq[31] = -1;
+ mdata->paddr += binfo->bi_immr_base;
+
/* setup the board related information for the enet controllers */
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC1);
if (pdata) {
/* pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR; */
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 2;
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_2;
memcpy(pdata->mac_addr, binfo->bi_enetaddr, 6);
}
pdata = (struct gianfar_platform_data *) ppc_sys_get_pdata(MPC85xx_TSEC2);
if (pdata) {
/* pdata->board_flags = FSL_GIANFAR_BRD_HAS_PHY_INTR; */
- pdata->interruptPHY = MPC85xx_IRQ_EXT5;
- pdata->phyid = 4;
- /* fixup phy address */
- pdata->phy_reg_addr += binfo->bi_immr_base;
+ pdata->bus_id = GFAR_PHY_4;
memcpy(pdata->mac_addr, binfo->bi_enet1addr, 6);
}
diff --git a/arch/ppc/syslib/mpc85xx_devices.c b/arch/ppc/syslib/mpc85xx_devices.c
--- a/arch/ppc/syslib/mpc85xx_devices.c
+++ b/arch/ppc/syslib/mpc85xx_devices.c
@@ -25,19 +25,20 @@
/* We use offsets for IORESOURCE_MEM since we do not know at compile time
* what CCSRBAR is, will get fixed up by mach_mpc85xx_fixup
*/
+struct gianfar_mdio_data mpc85xx_mdio_pdata = {
+ .paddr = MPC85xx_MIIM_OFFSET,
+};
static struct gianfar_platform_data mpc85xx_tsec1_pdata = {
.device_flags = FSL_GIANFAR_DEV_HAS_GIGABIT |
FSL_GIANFAR_DEV_HAS_COALESCE | FSL_GIANFAR_DEV_HAS_RMON |
FSL_GIANFAR_DEV_HAS_MULTI_INTR,
- .phy_reg_addr = MPC85xx_ENET1_OFFSET,
};
static struct gianfar_platform_data mpc85xx_tsec2_pdata = {
.device_flags = FSL_GIANFAR_DEV_HAS_GIGABIT |
FSL_GIANFAR_DEV_HAS_COALESCE | FSL_GIANFAR_DEV_HAS_RMON |
FSL_GIANFAR_DEV_HAS_MULTI_INTR,
- .phy_reg_addr = MPC85xx_ENET1_OFFSET,
};
static struct gianfar_platform_data mpc85xx_etsec1_pdata = {
@@ -46,7 +47,6 @@ static struct gianfar_platform_data mpc8
FSL_GIANFAR_DEV_HAS_MULTI_INTR |
FSL_GIANFAR_DEV_HAS_CSUM | FSL_GIANFAR_DEV_HAS_VLAN |
FSL_GIANFAR_DEV_HAS_EXTENDED_HASH,
- .phy_reg_addr = MPC85xx_ENET1_OFFSET,
};
static struct gianfar_platform_data mpc85xx_etsec2_pdata = {
@@ -55,7 +55,6 @@ static struct gianfar_platform_data mpc8
FSL_GIANFAR_DEV_HAS_MULTI_INTR |
FSL_GIANFAR_DEV_HAS_CSUM | FSL_GIANFAR_DEV_HAS_VLAN |
FSL_GIANFAR_DEV_HAS_EXTENDED_HASH,
- .phy_reg_addr = MPC85xx_ENET1_OFFSET,
};
static struct gianfar_platform_data mpc85xx_etsec3_pdata = {
@@ -64,7 +63,6 @@ static struct gianfar_platform_data mpc8
FSL_GIANFAR_DEV_HAS_MULTI_INTR |
FSL_GIANFAR_DEV_HAS_CSUM | FSL_GIANFAR_DEV_HAS_VLAN |
FSL_GIANFAR_DEV_HAS_EXTENDED_HASH,
- .phy_reg_addr = MPC85xx_ENET1_OFFSET,
};
static struct gianfar_platform_data mpc85xx_etsec4_pdata = {
@@ -73,11 +71,10 @@ static struct gianfar_platform_data mpc8
FSL_GIANFAR_DEV_HAS_MULTI_INTR |
FSL_GIANFAR_DEV_HAS_CSUM | FSL_GIANFAR_DEV_HAS_VLAN |
FSL_GIANFAR_DEV_HAS_EXTENDED_HASH,
- .phy_reg_addr = MPC85xx_ENET1_OFFSET,
};
static struct gianfar_platform_data mpc85xx_fec_pdata = {
- .phy_reg_addr = MPC85xx_ENET1_OFFSET,
+ .device_flags = 0,
};
static struct fsl_i2c_platform_data mpc85xx_fsl_i2c_pdata = {
@@ -718,6 +715,12 @@ struct platform_device ppc_sys_platform_
.flags = IORESOURCE_IRQ,
},
},
+ },
+ [MPC85xx_MDIO] = {
+ .name = "fsl-gianfar_mdio",
+ .id = 0,
+ .dev.platform_data = &mpc85xx_mdio_pdata,
+ .num_resources = 0,
},
};
diff --git a/arch/ppc/syslib/mpc85xx_sys.c b/arch/ppc/syslib/mpc85xx_sys.c
--- a/arch/ppc/syslib/mpc85xx_sys.c
+++ b/arch/ppc/syslib/mpc85xx_sys.c
@@ -24,19 +24,19 @@ struct ppc_sys_spec ppc_sys_specs[] = {
.ppc_sys_name = "8540",
.mask = 0xFFFF0000,
.value = 0x80300000,
- .num_devices = 10,
+ .num_devices = 11,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_FEC, MPC85xx_IIC1,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
- MPC85xx_PERFMON, MPC85xx_DUART,
+ MPC85xx_PERFMON, MPC85xx_DUART, MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8560",
.mask = 0xFFFF0000,
.value = 0x80700000,
- .num_devices = 19,
+ .num_devices = 20,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
@@ -45,14 +45,14 @@ struct ppc_sys_spec ppc_sys_specs[] = {
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C, MPC85xx_CPM_SCC1,
MPC85xx_CPM_SCC2, MPC85xx_CPM_SCC3, MPC85xx_CPM_SCC4,
MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2, MPC85xx_CPM_FCC3,
- MPC85xx_CPM_MCC1, MPC85xx_CPM_MCC2,
+ MPC85xx_CPM_MCC1, MPC85xx_CPM_MCC2, MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8541",
.mask = 0xFFFF0000,
.value = 0x80720000,
- .num_devices = 13,
+ .num_devices = 14,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
@@ -60,13 +60,14 @@ struct ppc_sys_spec ppc_sys_specs[] = {
MPC85xx_PERFMON, MPC85xx_DUART,
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C,
MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
+ MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8541E",
.mask = 0xFFFF0000,
.value = 0x807A0000,
- .num_devices = 14,
+ .num_devices = 15,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
@@ -74,13 +75,14 @@ struct ppc_sys_spec ppc_sys_specs[] = {
MPC85xx_PERFMON, MPC85xx_DUART, MPC85xx_SEC2,
MPC85xx_CPM_SPI, MPC85xx_CPM_I2C,
MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
+ MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8555",
.mask = 0xFFFF0000,
.value = 0x80710000,
- .num_devices = 19,
+ .num_devices = 20,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
@@ -91,13 +93,14 @@ struct ppc_sys_spec ppc_sys_specs[] = {
MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
MPC85xx_CPM_SMC1, MPC85xx_CPM_SMC2,
MPC85xx_CPM_USB,
+ MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8555E",
.mask = 0xFFFF0000,
.value = 0x80790000,
- .num_devices = 20,
+ .num_devices = 21,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_TSEC1, MPC85xx_TSEC2, MPC85xx_IIC1,
@@ -108,6 +111,7 @@ struct ppc_sys_spec ppc_sys_specs[] = {
MPC85xx_CPM_FCC1, MPC85xx_CPM_FCC2,
MPC85xx_CPM_SMC1, MPC85xx_CPM_SMC2,
MPC85xx_CPM_USB,
+ MPC85xx_MDIO,
},
},
/* SVRs on 8548 rev1.0 matches for 8548/8547/8545 */
@@ -115,104 +119,112 @@ struct ppc_sys_spec ppc_sys_specs[] = {
.ppc_sys_name = "8548E",
.mask = 0xFFFF00F0,
.value = 0x80390010,
- .num_devices = 13,
+ .num_devices = 14,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_eTSEC1, MPC85xx_eTSEC2, MPC85xx_eTSEC3,
MPC85xx_eTSEC4, MPC85xx_IIC1, MPC85xx_IIC2,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
MPC85xx_PERFMON, MPC85xx_DUART, MPC85xx_SEC2,
+ MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8548",
.mask = 0xFFFF00F0,
.value = 0x80310010,
- .num_devices = 12,
+ .num_devices = 13,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_eTSEC1, MPC85xx_eTSEC2, MPC85xx_eTSEC3,
MPC85xx_eTSEC4, MPC85xx_IIC1, MPC85xx_IIC2,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
MPC85xx_PERFMON, MPC85xx_DUART,
+ MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8547E",
.mask = 0xFFFF00F0,
.value = 0x80390010,
- .num_devices = 13,
+ .num_devices = 14,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_eTSEC1, MPC85xx_eTSEC2, MPC85xx_eTSEC3,
MPC85xx_eTSEC4, MPC85xx_IIC1, MPC85xx_IIC2,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
MPC85xx_PERFMON, MPC85xx_DUART, MPC85xx_SEC2,
+ MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8547",
.mask = 0xFFFF00F0,
.value = 0x80310010,
- .num_devices = 12,
+ .num_devices = 13,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_eTSEC1, MPC85xx_eTSEC2, MPC85xx_eTSEC3,
MPC85xx_eTSEC4, MPC85xx_IIC1, MPC85xx_IIC2,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
MPC85xx_PERFMON, MPC85xx_DUART,
+ MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8545E",
.mask = 0xFFFF00F0,
.value = 0x80390010,
- .num_devices = 11,
+ .num_devices = 12,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_eTSEC1, MPC85xx_eTSEC2,
MPC85xx_IIC1, MPC85xx_IIC2,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
MPC85xx_PERFMON, MPC85xx_DUART, MPC85xx_SEC2,
+ MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8545",
.mask = 0xFFFF00F0,
.value = 0x80310010,
- .num_devices = 10,
+ .num_devices = 11,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_eTSEC1, MPC85xx_eTSEC2,
MPC85xx_IIC1, MPC85xx_IIC2,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
MPC85xx_PERFMON, MPC85xx_DUART,
+ MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8543E",
.mask = 0xFFFF00F0,
.value = 0x803A0010,
- .num_devices = 11,
+ .num_devices = 12,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_eTSEC1, MPC85xx_eTSEC2,
MPC85xx_IIC1, MPC85xx_IIC2,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
MPC85xx_PERFMON, MPC85xx_DUART, MPC85xx_SEC2,
+ MPC85xx_MDIO,
},
},
{
.ppc_sys_name = "8543",
.mask = 0xFFFF00F0,
.value = 0x80320010,
- .num_devices = 10,
+ .num_devices = 11,
.device_list = (enum ppc_sys_devices[])
{
MPC85xx_eTSEC1, MPC85xx_eTSEC2,
MPC85xx_IIC1, MPC85xx_IIC2,
MPC85xx_DMA0, MPC85xx_DMA1, MPC85xx_DMA2, MPC85xx_DMA3,
MPC85xx_PERFMON, MPC85xx_DUART,
+ MPC85xx_MDIO,
},
},
{ /* default match */
diff --git a/include/asm-ppc/mpc85xx.h b/include/asm-ppc/mpc85xx.h
--- a/include/asm-ppc/mpc85xx.h
+++ b/include/asm-ppc/mpc85xx.h
@@ -67,6 +67,8 @@ extern unsigned char __res[];
#define MPC85xx_DMA3_SIZE (0x00080)
#define MPC85xx_ENET1_OFFSET (0x24000)
#define MPC85xx_ENET1_SIZE (0x01000)
+#define MPC85xx_MIIM_OFFSET (0x24520)
+#define MPC85xx_MIIM_SIZE (0x00018)
#define MPC85xx_ENET2_OFFSET (0x25000)
#define MPC85xx_ENET2_SIZE (0x01000)
#define MPC85xx_ENET3_OFFSET (0x26000)
@@ -132,6 +134,7 @@ enum ppc_sys_devices {
MPC85xx_eTSEC3,
MPC85xx_eTSEC4,
MPC85xx_IIC2,
+ MPC85xx_MDIO,
};
/* Internal interrupts are all Level Sensitive, and Positive Polarity */
diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -47,14 +47,19 @@
struct gianfar_platform_data {
/* device specific information */
u32 device_flags;
- u32 phy_reg_addr;
/* board specific information */
u32 board_flags;
- u32 phy_flags;
- u32 phyid;
- u32 interruptPHY;
+ const char *bus_id;
u8 mac_addr[6];
+};
+
+struct gianfar_mdio_data {
+ /* device specific information */
+ u32 paddr;
+
+ /* board specific information */
+ int irq[32];
};
/* Flags related to gianfar device features */
^ permalink raw reply
* Re: [PATCH] 1/2 Start header file merger (Was: Re: Beginning Merger Patch)
From: Arnd Bergmann @ 2005-08-05 16:24 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <20050806005941.5d1fe432.sfr@canb.auug.org.au>
On Freedag 05 August 2005 16:59, Stephen Rothwell wrote:
> Well noone should even include kernel headers from user space :-) and my
> understanding is that glibc "sanitizes" its version of the kernel headers
> anyway.
Glibc doesn't change the header files too much, most of that is done in
the linux-libc-headers package, which is maintained separately from the
kernel and from glibc. There is some effort being put into keeping the
difference between that package and the kernel headers small.
Also, while using kernel headers directly from user space should be
considered a bug, Linus has stated before that he wants source code
that is broken in that way to keep working instead of breaking it
even more.
There is also klibc, which heavily relies on kernel headers by design.
> > Using CONFIG_64BIT instead of __powerpc64__ only within #ifdef __KERNEL=
__
> > would be correct but less consistant.
>=20
> The advantage of using CONFIG_64BIT as much as possible is that it shows
> us places that can be consolidated across the various architectures
> (which is a bit of a passion of mine :-)). =A0And more consolidation shou=
ld
> make life easier for the glibc folks in the long run.
AFAIK, in linux-libc-headers every usage of CONFIG_* outside of __KERNEL__
is a bug that needs to be fixed by the maintainer, so we really should not
do that.
I think it might be ok to use CONFIG_64BIT for files that are completely
inside #ifdef __KERNEL__, but I'd like to avoid stuff like:
#ifndef __powerpc64__
#define __NR_sendfile64=AD=AD 226 /* only for 32 bit */
#endif /* __powerpc64__ */
=2E..
#ifdef __KERNEL__
#ifndef CONFIG_64BIT
#define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall")
#else /* CONFIG_64BIT */
#define cond_syscall(x) asm(".weak\t." #x "\n\t.set\t." #x ",.sys_ni_syscal=
l")
#endif /* CONFIG_64BIT */
#endif /* __KERNEL__ */
in a single file. Using __powerpc64__ consistantly has the advantage that
the casual reader can easily find all places that rely on 32/64 bit
definitions without having to understand why there are two different ways
to do the same thing.
Perhaps it works out better if this is combined with the split into
include/asm-powerpc/ and include/asm-powerpc/user, as mentioned in the
thread around http://www.ussg.iu.edu/hypermail/linux/kernel/0411.3/1663.htm=
l.
Then we could have CONFIG_64BIT everywhere in the real kernel headers and
__powerpc64__ in the user interface headers.
Arnd <><
^ permalink raw reply
* Re: swap_dup: Bad swap file entry 00480020
From: Bogdan Antonovici @ 2005-08-05 19:12 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev, ppckernel, linuxppc-embedded
In-Reply-To: <1a928a85f53f5dcd972161356611a312@embeddededge.com>
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
Dan,
It hasn't crashed since i corrected that pointer initialization in driver. You were right.
Thank you.
Bogdan
----- Original Message -----
From: Dan Malek
To: bogdan antonovici
Cc: linuxppc-dev ; linuxppc-embedded@ozlabs.org ; ppckernel
Sent: Thursday, July 21, 2005 12:59 PM
Subject: Re: swap_dup: Bad swap file entry 00480020
On Jul 21, 2005, at 11:29 AM, bogdan antonovici wrote:
> At the time of swap messages i was running a proprietary driver, my
> application and few daemons.
Looks like your driver may have written over some of the page
tables in the kernel space.
> I look on the net for some clues but it's quite confusing, i noticed
> many emails on swap_dup/swap_free error messages but i couldn't figure
> out what should i search for.
Those messages are likely due to a bug with swapping to disk
that has been in some 2.4 kernels, but I don't believe that is
the case here, since you don't have a disk or swapping enabled.
-- Dan
[-- Attachment #2: Type: text/html, Size: 2462 bytes --]
^ permalink raw reply
* Re: swap_dup: Bad swap file entry 00480020
From: Dan Malek @ 2005-08-05 19:29 UTC (permalink / raw)
To: Bogdan Antonovici; +Cc: linuxppc-dev, linuxppc-embedded, ppckernel
In-Reply-To: <00ca01c599f1$a2411730$cd01a8c0@DESIGNLAB>
On Aug 5, 2005, at 3:12 PM, Bogdan Antonovici wrote:
> It hasn't crashed since i corrected that pointer initialization in
> driver. You were right.
> Thank you.
Glad to hear it. I wasn't looking forward to debugging such a problem
in the VM subsystem at this time :-)
Have fun!
-- Dan
^ permalink raw reply
* Re: [PATCH] cpm_uart: make dpram allocation actually work
From: Marcelo Tosatti @ 2005-08-05 20:34 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <200508021909.45729.pantelis.antoniou@gmail.com>
On Tue, Aug 02, 2005 at 07:09:45PM +0300, Pantelis Antoniou wrote:
> Hi Marcelo
>
> While the idea of allocating console buffers from dpram is sound,
> the initial implementation didn't actually work :)
>
> The following patch fixes it (tested and booted on 2.6.13-rc4).
OK thanks Panto.
Despite my limited knowledge here, Vitaly's merged patch looks fine.
I suppose someone (Kumar?) is going to send it upstream now?
^ permalink raw reply
* Re: swap_dup: Bad swap file entry 00480020
From: Geoff Levand @ 2005-08-05 21:12 UTC (permalink / raw)
To: Bogdan Antonovici; +Cc: linuxppc-dev, linuxppc-embedded, ppckernel
In-Reply-To: <00ca01c599f1$a2411730$cd01a8c0@DESIGNLAB>
BTW, I posted a fix for a bug in the 2.6 page table attribute
settings for PPC440 that cause corruption when swapping. I
don't know if is the same for 2.4.
http://patchwork.ozlabs.org/linuxppc/patch?id=1458
-Geoff
Bogdan Antonovici wrote:
> Dan,
>
> It hasn't crashed since i corrected that pointer initialization in
> driver. You were right.
> Thank you.
> Bogdan
>
> ----- Original Message -----
> From: Dan Malek <mailto:dan@embeddededge.com>
> To: bogdan antonovici <mailto:bantonovici@priority.mb.ca>
> Cc: linuxppc-dev <mailto:linuxppc-dev@ozlabs.org> ;
> linuxppc-embedded@ozlabs.org <mailto:linuxppc-embedded@ozlabs.org> ;
> ppckernel <mailto:ppckernel@ppckernel.org>
> Sent: Thursday, July 21, 2005 12:59 PM
> Subject: Re: swap_dup: Bad swap file entry 00480020
>
>
> On Jul 21, 2005, at 11:29 AM, bogdan antonovici wrote:
>
>
>>At the time of swap messages i was running a proprietary driver, my
>>application and few daemons.
>
>
> Looks like your driver may have written over some of the page
> tables in the kernel space.
>
>
>>I look on the net for some clues but it's quite confusing, i noticed
>>many emails on swap_dup/swap_free error messages but i couldn't figure
>>out what should i search for.
>
>
> Those messages are likely due to a bug with swapping to disk
> that has been in some 2.4 kernels, but I don't believe that is
> the case here, since you don't have a disk or swapping enabled.
>
>
> -- Dan
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: what to use to connect to JTAG/BDM port on PPC405EP
From: Wolfgang Denk @ 2005-08-05 21:19 UTC (permalink / raw)
To: Igor Marnat; +Cc: linuxppc-embedded
In-Reply-To: <19013128171.20050805151105@rambler.ru>
In message <19013128171.20050805151105@rambler.ru> you wrote:
>
> I have EVB based on PPC 405 EP (PPChameleon EVB). It has JTAG port.
> What JTAG device can I use to connect to the board? I've found BDI2000
You found The Right Thing (TM). Use a BDI2000.
> device, for example, but it costs as N times as the EVB does
It's worth the price.
> (approximately). It seems unreasonable for me. Is it possible to make such a device or to find
> find the cheaper one? We found several schemes of how to make connector BDM-parallel
> port. Is it possible to do such a thing for PPC 405EP?
It's simple to rig up the required electrical interface and attach it
- say - to the parallel port of a standard PC. However, to make any
use of it, you have to understand which data to send and how to
interpret the results. This requires signing a NDA with IBM / AMCC /
Freescale. Assuming you get the required information, it then means
quite a lot of hacking to get some working code that interfaces with
a standard debugger like GDB. And you will not be able to share your
code with others, as the NDA explicitely prevents you from
implementing it in any form of open source software. You will
completely on your own there.
In the meantime the BDI user has completed 5 more real projects.
Go for a BDI.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
SW engineering is a race between programmers trying to make better
idiot-proof programs and the universe producing greater idiots.
^ permalink raw reply
* [PATCH] ppc32: fix ppc440 pagetable attributes
From: Matt Porter @ 2005-08-05 22:45 UTC (permalink / raw)
To: akpm; +Cc: linuxppc-embedded
This patch fixes a bug in the PPC440 pagetable attributes that breaks
swap support. It also adds some notes on the PPC440 attribute fields.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> for CELF
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
Index: linux-2.6.12-bhpm/include/asm-ppc/pgtable.h
===================================================================
--- linux-2.6.12-bhpm.orig/include/asm-ppc/pgtable.h 2005-06-02 15:09:24.000000000 -0700
+++ linux-2.6.12-bhpm/include/asm-ppc/pgtable.h 2005-06-02 15:47:53.000000000 -0700
@@ -202,18 +202,64 @@
*
* Note that these bits preclude future use of a page size
* less than 4KB.
+ *
+ *
+ * PPC 440 core has following TLB attribute fields;
+ *
+ * TLB1:
+ * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
+ * RPN................................. - - - - - - ERPN.......
+ *
+ * TLB2:
+ * 0 1 2 3 4 ... 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
+ * - - - - - - U0 U1 U2 U3 W I M G E - UX UW UR SX SW SR
+ *
+ * There are some constrains and options, to decide mapping software bits
+ * into TLB entry.
+ *
+ * - PRESENT *must* be in the bottom three bits because swap cache
+ * entries use the top 29 bits for TLB2.
+ *
+ * - FILE *must* be in the bottom three bits because swap cache
+ * entries use the top 29 bits for TLB2.
+ *
+ * - CACHE COHERENT bit (M) has no effect on PPC440 core, because it
+ * doesn't support SMP. So we can use this as software bit, like
+ * DIRTY.
+ *
+ * PPC Book-E Linux implementation uses PPC HW PTE bit field definition,
+ * even it doesn't have HW PTE. 0-11th LSB of PTE stand for memory
+ * protection-related function. (See PTE structure in include/asm-ppc/mmu.h)
+ * Definition of _PAGE_XXX in "include/asm-ppc/pagetable.h" stands for
+ * above bits. Note that those bits values are CPU dependent, not
+ * architecture.
+ *
+ * Kernel PTE entry holds arch-dependent swp_entry structure under certain
+ * situation. In other words, in such situation, some portion of PTE bits
+ * are used as swp_entry. In PPC implementation, 3-24th LSB are shared with
+ * swp_entry, however 0-2nd three LSB still hold protection values.
+ * That means three protection bits are reserved for both PTE and SWAP
+ * entry at the most three LSBs.
+ *
+ * There are three protection bits available for SWAP entry;
+ * _PAGE_PRESENT
+ * _PAGE_FILE
+ * _PAGE_HASHPTE (if HW has)
+ *
+ * So those three bits have to be inside of 0-2nd LSB of PTE.
+ *
*/
+
#define _PAGE_PRESENT 0x00000001 /* S: PTE valid */
#define _PAGE_RW 0x00000002 /* S: Write permission */
-#define _PAGE_DIRTY 0x00000004 /* S: Page dirty */
+#define _PAGE_FILE 0x00000004 /* S: nonlinear file mapping */
#define _PAGE_ACCESSED 0x00000008 /* S: Page referenced */
#define _PAGE_HWWRITE 0x00000010 /* H: Dirty & RW */
#define _PAGE_HWEXEC 0x00000020 /* H: Execute permission */
#define _PAGE_USER 0x00000040 /* S: User page */
#define _PAGE_ENDIAN 0x00000080 /* H: E bit */
#define _PAGE_GUARDED 0x00000100 /* H: G bit */
-#define _PAGE_COHERENT 0x00000200 /* H: M bit */
-#define _PAGE_FILE 0x00000400 /* S: nonlinear file mapping */
+#define _PAGE_DIRTY 0x00000200 /* S: Page dirty */
#define _PAGE_NO_CACHE 0x00000400 /* H: I bit */
#define _PAGE_WRITETHRU 0x00000800 /* H: W bit */
^ permalink raw reply
* Re: [PATCH] ppc32: fix ppc440 pagetable attributes
From: Andrew Morton @ 2005-08-05 22:54 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050805154505.A10842@cox.net>
Matt Porter <mporter@kernel.crashing.org> wrote:
>
> This patch fixes a bug in the PPC440 pagetable attributes that breaks
> swap support. It also adds some notes on the PPC440 attribute fields.
hm, that looks pretty serious, but it affects all ppc's, yes?
Is this needed for 2.6.13? Are you super-sure it's safe?
^ permalink raw reply
* Re: [PATCH] ppc32: fix ppc440 pagetable attributes
From: Matt Porter @ 2005-08-05 23:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-embedded
In-Reply-To: <20050805155442.4e3dbf8f.akpm@osdl.org>
On Fri, Aug 05, 2005 at 03:54:42PM -0700, Andrew Morton wrote:
> Matt Porter <mporter@kernel.crashing.org> wrote:
> >
> > This patch fixes a bug in the PPC440 pagetable attributes that breaks
> > swap support. It also adds some notes on the PPC440 attribute fields.
>
> hm, that looks pretty serious, but it affects all ppc's, yes?
Just PPC440. I originally organized the attributes incorrectly.
> Is this needed for 2.6.13? Are you super-sure it's safe?
This should go into 2.6.13. I doublechecked it by inspection and
ran numerous tests. It's only existed this long (years) due to the
fact that few people run a disk-based PPC440 system. I would have
sent it up sooner except I wanted to be very sure of my testing
since I don't always trust my own inspection. :)
-Matt
^ permalink raw reply
* [PATCH] add field to struct ocp_func_emac_data for platform-specific unsupported PHY features
From: Wade Farnsworth @ 2005-08-05 23:26 UTC (permalink / raw)
To: linuxppc-embedded, Matt Porter
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
Hello all,
This patch adds a field to struct ocp_func_emac_data that allows
platform-specific unsupported PHY features to be passed in to the
ibm_emac ethernet driver.
This patch also adds some logic for the Bamboo eval board to populate
this field based on the dip switches on the board. This is a workaround
for the improperly biased RJ-45 sockets on the Rev. 0 Bamboo. See the
comments in bamboo.c for more information on this bug.
-Wade Farnsworth
Signed-off by: Wade Farnsworth <wfarnsworth@mvista.com>
[-- Attachment #2: ibm-emac-phy-feat-unsupp-ppc.patch --]
[-- Type: text/plain, Size: 3116 bytes --]
--- linux-2.6/arch/ppc/platforms/4xx/bamboo.c 2005-08-03 13:33:41.000000000 -0700
+++ linux-2.6-dev/arch/ppc/platforms/4xx/bamboo.c 2005-08-02 10:51:00.000000000 -0700
@@ -123,33 +123,69 @@ bamboo_map_irq(struct pci_dev *dev, unsi
static void __init bamboo_set_emacdata(void)
{
- unsigned char * selection1_base;
+ u8 * base_addr;
struct ocp_def *def;
struct ocp_func_emac_data *emacdata;
- u8 selection1_val;
+ u8 val;
int mode;
+ u32 unsupported = 0;
- selection1_base = ioremap64(BAMBOO_FPGA_SELECTION1_REG_ADDR, 16);
- selection1_val = readb(selection1_base);
- iounmap((void *) selection1_base);
- if (BAMBOO_SEL_MII(selection1_val))
+ base_addr = ioremap64(BAMBOO_FPGA_SELECTION1_REG_ADDR, 16);
+ val = readb(base_addr);
+ iounmap((void *) base_addr);
+ if (BAMBOO_SEL_MII(val))
mode = PHY_MODE_MII;
- else if (BAMBOO_SEL_RMII(selection1_val))
+ else if (BAMBOO_SEL_RMII(val))
mode = PHY_MODE_RMII;
else
mode = PHY_MODE_SMII;
- /* Set mac_addr and phy mode for each EMAC */
+ /*
+ * SW2 on the Bamboo is used for ethernet configuration and is accessed
+ * via the CONFIG2 register in the FPGA. If the ANEG pin is set,
+ * overwrite the supported features with the settings in SW2.
+ *
+ * This is used as a workaround for the improperly biased RJ-45 sockets
+ * on the Rev. 0 Bamboo. By default only 10baseT is functional.
+ * Removing inductors L17 and L18 from the board allows 100baseT, but
+ * disables 10baseT. The Rev. 1 has no such limitations.
+ */
+
+ base_addr = ioremap64(BAMBOO_FPGA_CONFIG2_REG_ADDR, 8);
+ val = readb(base_addr);
+ iounmap((void *) base_addr);
+ if (!BAMBOO_AUTONEGOTIATE(val)) {
+ unsupported |= SUPPORTED_Autoneg;
+ if (BAMBOO_FORCE_100Mbps(val)) {
+ unsupported |= SUPPORTED_10baseT_Full;
+ unsupported |= SUPPORTED_10baseT_Half;
+ if (BAMBOO_FULL_DUPLEX_EN(val))
+ unsupported |= SUPPORTED_100baseT_Half;
+ else
+ unsupported |= SUPPORTED_100baseT_Full;
+ } else {
+ unsupported |= SUPPORTED_100baseT_Full;
+ unsupported |= SUPPORTED_100baseT_Half;
+ if (BAMBOO_FULL_DUPLEX_EN(val))
+ unsupported |= SUPPORTED_10baseT_Half;
+ else
+ unsupported |= SUPPORTED_10baseT_Full;
+ }
+ }
+
+ /* Set mac_addr, phy mode and unsupported phy features for each EMAC */
def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 0);
emacdata = def->additions;
memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
emacdata->phy_mode = mode;
+ emacdata->feat_unsupp = unsupported;
def = ocp_get_one_device(OCP_VENDOR_IBM, OCP_FUNC_EMAC, 1);
emacdata = def->additions;
memcpy(emacdata->mac_addr, __res.bi_enet1addr, 6);
emacdata->phy_mode = mode;
+ emacdata->feat_unsupp = unsupported;
}
static int
--- linux-2.6/include/asm-ppc/ibm_ocp.h 2005-08-03 13:34:08.000000000 -0700
+++ linux-2.6-dev/include/asm-ppc/ibm_ocp.h 2005-08-02 10:49:42.000000000 -0700
@@ -67,6 +67,7 @@ struct ocp_func_emac_data {
int phy_mode; /* PHY type or configurable mode */
u8 mac_addr[6]; /* EMAC mac address */
u32 phy_map; /* EMAC phy map */
+ u32 feat_unsupp; /* Unsupported phy features */
};
/* Sysfs support */
^ permalink raw reply
* Re: [PATCH] cpm_uart: make dpram allocation actually work
From: Kumar Gala @ 2005-08-06 3:11 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linuxppc-embedded, Pantelis Antoniou
In-Reply-To: <20050805203456.GD14338@dmt.cnet>
On Aug 5, 2005, at 3:34 PM, Marcelo Tosatti wrote:
> On Tue, Aug 02, 2005 at 07:09:45PM +0300, Pantelis Antoniou wrote:
>
>> Hi Marcelo
>>
>> While the idea of allocating console buffers from dpram is sound,
>> the initial implementation didn't actually work :)
>>
>> The following patch fixes it (tested and booted on 2.6.13-rc4).
>>
>
> OK thanks Panto.
>
> Despite my limited knowledge here, Vitaly's merged patch looks fine.
>
> I suppose someone (Kumar?) is going to send it upstream now?
I plan on this, after we test it on 8560.
- kumar
^ 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