* Kernel build error
From: mcnernbm @ 2005-05-12 22:30 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]
Using the 2.4 kernel tree with a 2.4.26 kernel I am receive the following
error when trying to build for the powerpc 405.
I set the arch: to arch: ppc and set the cross-compile line in the make
file.
Make dep and make modules runs fine.
But when I run make zImage I receive the follwoing error:
mv: can't stat source zvmlinux
make[2]: *** [zImage] Error 1
make[2]: Leaving directory
'/ppclinux/v2.4.26_linuxppc_2_4_devel/linuxppc_2_4_devel/arch/ppc/boot/simple'
make[1]: *** [zImage] Error 2
make[1]: Leaving directory
'/ppclinux/v2.4.26_linuxppc_2_4_devel/linuxppc_2_4_devel/arch/ppc/boot/'
make: *** [zImage] Error 2
I am using the default xilinx_ml300 arch config file so I can at least get
the kernel to build before attempting to build one for my specific virtex
II pro board. Does anyone know what might be causing this?
I am using gcc-3.4.1 and glibc-2.3.5. Not sure if this is part of the
issue or but if so which version should I be using? And is it the 2.4.26
kernel that is the issue? Should i go back to an older one that is used
in alot of the tutorials for the xilinx ml300 board.
Thanks
Brett
[-- Attachment #2: Type: text/html, Size: 1736 bytes --]
^ permalink raw reply
* IDMA
From: Wojciech Kromer @ 2005-05-13 6:12 UTC (permalink / raw)
To: linuxppc-embedded
Do I need any hardware changes in order to use IDMA for PCI transactions
on 8250?
Should it be faster?
Maybe less cpu usage?
I have the same questions about using idma for connecting external
device (ie DSP) on 8xx processors ?
^ permalink raw reply
* Re: [PATCH 03/04] Freescale Ethernet combined driver
From: Pantelis Antoniou @ 2005-05-13 8:51 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: Tom Rini, linuxppc-embedded
In-Reply-To: <428323C9.8070608@intracom.gr>
[-- Attachment #1: Type: text/plain, Size: 66 bytes --]
Hi
Fix compile on 8xx FEC.
Brown bag time.
Regards
Pantelis
[-- Attachment #2: fec-fix.patch --]
[-- Type: text/x-patch, Size: 1296 bytes --]
Index: linux-2.6.11.7-fs_enet/drivers/net/fs_enet/fs_enet.h
===================================================================
--- linux-2.6.11.7-fs_enet.orig/drivers/net/fs_enet/fs_enet.h
+++ linux-2.6.11.7-fs_enet/drivers/net/fs_enet/fs_enet.h
@@ -108,7 +108,7 @@ struct fs_enet_mii_bus {
union {
struct {
unsigned int mii_speed;
- void *fsp;
+ void *fecp;
} fec;
struct {
@@ -172,7 +172,7 @@ struct fs_enet_private {
union {
struct {
int idx; /* FEC1 = 0, FEC2 = 1 */
- void *fsp; /* hw registers */
+ void *fecp; /* hw registers */
__u32 hthi, htlo; /* state for multicast */
} fec;
Index: linux-2.6.11.7-fs_enet/drivers/net/fs_enet/mac-fec.c
===================================================================
--- linux-2.6.11.7-fs_enet.orig/drivers/net/fs_enet/mac-fec.c
+++ linux-2.6.11.7-fs_enet/drivers/net/fs_enet/mac-fec.c
@@ -60,10 +60,10 @@
#endif
/* write */
-#define FW(_fecp, _reg, _v) __fs_out32(&(_fecp)->fs_ ## _reg, (_v))
+#define FW(_fecp, _reg, _v) __fs_out32(&(_fecp)->fec_ ## _reg, (_v))
/* read */
-#define FR(_fecp, _reg) __fs_in32(&(_fecp)->fs_ ## _reg)
+#define FR(_fecp, _reg) __fs_in32(&(_fecp)->fec_ ## _reg)
/* set bits */
#define FS(_fecp, _reg, _v) FW(_fecp, _reg, FR(_fecp, _reg) | (_v))
^ permalink raw reply
* insmod problem
From: Marco Schramel @ 2005-05-13 12:33 UTC (permalink / raw)
To: PPC_LINUX
Hi,
we use a custom mpc8270 system. Everything works fine.
Now i have to handle some float values in a device driver. If i insert the compiled module my target prints out
insmod: unresolved symbol __addsf3
insmod: unresolved symbol __floatsisf
Are there any missing libraries ?
Any other ideas?
Best regards
Marco
--
---------
Marco Schramel
^ permalink raw reply
* Re: insmod problem
From: Pantelis Antoniou @ 2005-05-13 12:46 UTC (permalink / raw)
To: Marco Schramel; +Cc: PPC_LINUX
In-Reply-To: <200505131433.23307.Schramel.Linux@go.bartec.de>
Marco Schramel wrote:
> Hi,
>
> we use a custom mpc8270 system. Everything works fine.
> Now i have to handle some float values in a device driver. If i insert the compiled module my target prints out
>
> insmod: unresolved symbol __addsf3
> insmod: unresolved symbol __floatsisf
>
> Are there any missing libraries ?
>
> Any other ideas?
>
> Best regards
>
> Marco
>
>
You're using floating arithmetic in the kernel.
That's not supported.
Regards
Pantelis
^ permalink raw reply
* Re: insmod problem
From: Mark Chambers @ 2005-05-13 13:14 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: PPC_LINUX
In-Reply-To: <4284A19A.7010901@intracom.gr>
>
>
> You're using floating arithmetic in the kernel.
>
> That's not supported.
>
> Regards
>
> Pantelis
>
Just for my edification: Is floating point itself not supported (floating
point register
corruption or something like that) or just linking to user space libraries?
Mark Chambers
^ permalink raw reply
* Re: insmod problem
From: Kumar Gala @ 2005-05-13 13:46 UTC (permalink / raw)
To: Mark Chambers; +Cc: PPC_LINUX
In-Reply-To: <005b01c557bd$c04e2770$0301a8c0@chuck2>
On May 13, 2005, at 8:14 AM, Mark Chambers wrote:
> >
> >
> > You're using floating arithmetic in the kernel.
> >
> > That's not supported.
> >
> > Regards
> >
> > Pantelis
> >
>
> Just for my edification:=A0 Is floating point itself not supported=20
> (floating
> point register
> corruption or something like that) or just linking to user space=20
> libraries?
Use of floating point registers and instructions. Its possible to use=20=
FP in rare cases inside the kernel buts its extremely discouraged.
- kumar
^ permalink raw reply
* eth0: PHY id 0x00221619 is not supported! HELP
From: Garcia Jérémie @ 2005-05-13 15:15 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody,
We are developping a custom board which uses a ppc405EP and on which one =
we'd like to load a linux hardhat.
During the boot process, we're getting error messages about the ethernet =
PHY. That is really annoying cause we plan to moubnt the file system via =
nfs. So no ethernet no NFS...
Could someone give us a tip and tell us if the messages displayed before =
seem to be normal cause we had to modify some part of the kernel in =
order to get Linux booting.
What those ethernet messages mean? Everythin seems to happen in the =
"ibm_ocp_enet.c" eand "ibm_ocp_phy.c" filesPlease help....
So here we go ---->>>>>>>>>
Linux/PPC load: console=3DttyS0,19200 root=3D/dev/nfs rw ip=3Don
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.20_mvl31-405ep_eval =
(root@sop-dhcp-10-16-5-126.amcc.com) (version gcc 3.3.1 (MontaVista =
3.3.1-3.0.10.0300532 2003-12-24)) #26 ven mai 13 5
AMCC Q80G Board
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=3DttyS0,19200 root=3D/dev/nfs rw ip=3Don
hr_time_init: arch_to_nsec =3D 10485759, nsec_to_arch =3D 858993476
Calibrating delay loop... 199.47 BogoMIPS
Memory: 14416k available (1280k kernel code, 424k data, 64k init, 0k =
highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
OCP uart ver 1.6.2 init complete
LSP Revision 1
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis =
Communications AB.
i2c-core.o: i2c core module version 2.6.2 (20011118)
i2c-dev.o: i2c /dev entries driver module version 2.6.2 (20011118)
i2c-proc.o version 2.6.2 (20011118)
pty: 256 Unix98 ptys configured
eeprom.o version 2.6.2 (20011118)
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0xef600300 (irq =3D 0) is a 16550A
ttyS01 at 0xef600400 (irq =3D 1) is a 16550A
IBM gpio driver version 07.25.02
GPIO #0 at 0xc207d700
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: PHY id 0x00221619 is not supported!
eth0: PHY id 0x00221619 is not supported!
eth0: No PHY device found.
removing net dev
eth0: PHY id 0x00221619 is not supported!
eth0: PHY id 0x00221619 is not supported!
eth0: No PHY device found.
removing net dev
IBM IIC driver v2.0
ibm-iic: using compatibility value for OPB freq, fix your board specific =
setup
ibm-iic0: using standard (100 kHz) mode
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMPIP: routing cache hash table of 512 =
buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
IP-Config: No network devices available.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
kmod: failed to exec /sbin/modprobe -s -k block-major-2, errno =3D 2
VFS: Cannot open root device "nfs" or 02:00
Please append a correct "root=3D" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
<0>Rebooting in 180 seconds..
Tks a lot for your precious help
Dj=E9
^ permalink raw reply
* Re: eth0: PHY id 0x00221619 is not supported! HELP
From: Clemens Koller @ 2005-05-13 15:39 UTC (permalink / raw)
To: Garcia Jérémie, linuxppc-dev
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B2A@exnet.3il.fr>
[-- Attachment #1: Type: text/plain, Size: 4575 bytes --]
Hi, Garcia!
Well, it's usually not a big deal to add your phyid to the driver.
Maybe some generic support is sufficient for your needs.
Check the datasheet of your Board and the PHY.
When you are sure you use an unsupported PHY, read the *phy.c of
your driver and add it. YMMV
Just FYI, I attached a (quick and dirty) patch to add an Intel LXT971 PHY to
the gianfar driver. The LXT981 is a 100Mbit PHY on the gigabit capable TSEC
of a mpc8540 cpu.
Greets,
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
Fax: +49-89-741518-19
Garcia Jérémie wrote:
> Hi everybody,
> We are developping a custom board which uses a ppc405EP and on which one we'd like to load a linux hardhat.
> During the boot process, we're getting error messages about the ethernet PHY. That is really annoying cause we plan to moubnt the file system via nfs. So no ethernet no NFS...
> Could someone give us a tip and tell us if the messages displayed before seem to be normal cause we had to modify some part of the kernel in order to get Linux booting.
> What those ethernet messages mean? Everythin seems to happen in the "ibm_ocp_enet.c" eand "ibm_ocp_phy.c" filesPlease help....
> So here we go ---->>>>>>>>>
>
> Linux/PPC load: console=ttyS0,19200 root=/dev/nfs rw ip=on
> Uncompressing Linux...done.
> Now booting the kernel
> Linux version 2.4.20_mvl31-405ep_eval (root@sop-dhcp-10-16-5-126.amcc.com) (version gcc 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24)) #26 ven mai 13 5
> AMCC Q80G Board
> On node 0 totalpages: 4096
> zone(0): 4096 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> Kernel command line: console=ttyS0,19200 root=/dev/nfs rw ip=on
> hr_time_init: arch_to_nsec = 10485759, nsec_to_arch = 858993476
> Calibrating delay loop... 199.47 BogoMIPS
> Memory: 14416k available (1280k kernel code, 424k data, 64k init, 0k highmem)
> Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
> Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
> POSIX conformance testing by UNIFIX
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> OCP uart ver 1.6.2 init complete
> LSP Revision 1
> ikconfig 0.5 with /proc/ikconfig
> Starting kswapd
> Disabling the Out Of Memory Killer
> JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis Communications AB.
> i2c-core.o: i2c core module version 2.6.2 (20011118)
> i2c-dev.o: i2c /dev entries driver module version 2.6.2 (20011118)
> i2c-proc.o version 2.6.2 (20011118)
> pty: 256 Unix98 ptys configured
> eeprom.o version 2.6.2 (20011118)
> Serial driver version 5.05c (2001-07-08) with no serial options enabled
> ttyS00 at 0xef600300 (irq = 0) is a 16550A
> ttyS01 at 0xef600400 (irq = 1) is a 16550A
> IBM gpio driver version 07.25.02
> GPIO #0 at 0xc207d700
> RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
> loop: loaded (max 8 devices)
> eth0: PHY id 0x00221619 is not supported!
> eth0: PHY id 0x00221619 is not supported!
> eth0: No PHY device found.
> removing net dev
> eth0: PHY id 0x00221619 is not supported!
> eth0: PHY id 0x00221619 is not supported!
> eth0: No PHY device found.
> removing net dev
> IBM IIC driver v2.0
> ibm-iic: using compatibility value for OPB freq, fix your board specific setup
> ibm-iic0: using standard (100 kHz) mode
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMPIP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 1024 bind 2048)
> IP-Config: No network devices available.
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> Root-NFS: No NFS server available, giving up.
> VFS: Unable to mount root fs via NFS, trying floppy.
> kmod: failed to exec /sbin/modprobe -s -k block-major-2, errno = 2
> VFS: Cannot open root device "nfs" or 02:00
> Please append a correct "root=" boot option
> Kernel panic: VFS: Unable to mount root fs on 02:00
> <0>Rebooting in 180 seconds..
>
>
> Tks a lot for your precious help
> Djé
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: gianfar.diff --]
[-- Type: text/x-diff, Size: 1469 bytes --]
diff -Nur --exclude-from=exclude-files linux-2.6.11-clean/drivers/net/gianfar.h linux/drivers/net/gianfar.h
--- linux-2.6.11-clean/drivers/net/gianfar.h 2005-03-02 02:38:25.000000000 -0500
+++ linux/drivers/net/gianfar.h 2005-03-04 19:19:43.000000000 -0500
@@ -131,7 +131,9 @@
#define MACCFG1_SYNCD_TX_EN 0x00000002
#define MACCFG1_TX_EN 0x00000001
-#define MACCFG2_INIT_SETTINGS 0x00007205
+/* #define MACCFG2_INIT_SETTINGS 0x00007205*/
+/* CK--- changed to use MII instead of GMII */
+#define MACCFG2_INIT_SETTINGS 0x00007105
#define MACCFG2_FULL_DUPLEX 0x00000001
#define MACCFG2_IF 0x00000300
#define MACCFG2_MII 0x00000100
diff -Nur --exclude-from=exclude-files linux-2.6.11-clean/drivers/net/gianfar_phy.c linux/drivers/net/gianfar_phy.c
--- linux-2.6.11-clean/drivers/net/gianfar_phy.c 2005-03-02 02:38:09.000000000 -0500
+++ linux/drivers/net/gianfar_phy.c 2005-03-04 18:24:54.000000000 -0500
@@ -580,6 +580,15 @@
.config_intr = &marvell_config_intr,
};
+static struct phy_info phy_info_lxt971 = {
+ .phy_id = 0x001378e0,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Intel LXT971",
+ .features = MII_BASIC_FEATURES,
+ .config_aneg = genmii_config_aneg,
+ .read_status = genmii_read_status,
+};
+
static struct phy_info phy_info_genmii= {
.phy_id = 0x00000000,
.phy_id_mask = 0x00000000,
@@ -593,6 +602,7 @@
&phy_info_cis820x,
&phy_info_marvell,
&phy_info_dm9161,
+ &phy_info_lxt971,
&phy_info_genmii,
NULL
};
^ permalink raw reply
* Re: [2.6.8] OOPS and SIGSEGV on altivec instruction on PowerPC 7540.
From: Kumar Gala @ 2005-05-13 16:03 UTC (permalink / raw)
To: Pawel Sikora; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <200505131749.20752.pluto@agmk.net>
This is odd. the 2.6.8 kernel should have the code that causes a SIGILL=20=
if !CONFIG_ALTIVEC. Can you enable CONFIG_KALLSYMS.
- kumar
On May 13, 2005, at 10:49 AM, Pawel Sikora wrote:
> Hi,
>
> simple runtime altivec detection from userspace causes an oops
> on the `vand` instruction. kernel was built *without* CONFIG_ALTIVEC.
> i think kernel should return a SIGILL instead of an oops ;-)
>
> Oops: kernel access of bad area, sig: 11 [#65]
> NIP: C0008B84 LR: C0007F2C SP: CF373F20 REGS: cf373e70 TRAP: 0300 Not=20=
> tainted
> MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
> DAR: 00000088, DSISR: 40000000
> TASK =3D c81e04f0[12983] 'altivec' THREAD: cf372000Last syscall: 174
> GPR00: C0007F2C CF373F20 C81E04F0 00000004 00000004 00030001 00000000=20=
> 0FEE08D0
> GPR08: 0000F932 C0007F2C 00009032 C0350000 081E0788 00000000 00000000=20=
> 100A37D8
> GPR16: 100A0000 00000000 100A0000 00000000 10070000 100A37C8 100AEF08=20=
> 00000000
> GPR24: 100A1108 00000000 100A59A8 3002AEF8 3002BB80 3002AE60 0FFEA6FC=20=
> 00000004
> Call trace: [c0007f2c]
>
>
>
> processor =A0 =A0 =A0 : 0
> cpu =A0 =A0 =A0 =A0 =A0 =A0 : 7450
> clock =A0 =A0 =A0 =A0 =A0 : 700MHz
> revision =A0 =A0 =A0 =A0: 2.1 (pvr 8000 0201)
> bogomips =A0 =A0 =A0 =A0: 696.32
> machine =A0 =A0 =A0 =A0 : PowerMac4,4
> motherboard =A0 =A0 : PowerMac4,4 MacRISC2 MacRISC Power Macintosh
> detected as =A0 =A0 : 80 (eMac)
> pmac flags =A0 =A0 =A0: 00000001
> L2 cache =A0 =A0 =A0 =A0: 256K unified
> memory =A0 =A0 =A0 =A0 =A0: 384MB
> pmac-generation : NewWorld
>
> --=20
> The only thing necessary for the triumph of evil
> =A0 is for good men to do nothing.
> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - Edmund Burke
> <altivec.c>=
^ permalink raw reply
* [PATCH 2.6.11.7] Swapping OOPS fix for ATA Over Ethernet
From: McMullan, Jason @ 2005-05-13 17:24 UTC (permalink / raw)
To: PPC_LINUX, Linux Kernel
[-- Attachment #1.1: Type: text/plain, Size: 163 bytes --]
This patch fixes swapping for devices that do not need to define an
unplug_io_fn().
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #1.2: swapping-unplug-oops.patch --]
[-- Type: text/x-patch, Size: 456 bytes --]
Description: Fix OOPS when swapping on a device that doesn't have
an unplug_io_fn defined (ie, ATA Over Ethernet)
Signed-Off-By: Jason McMullan <jason.mcmullan@timesys.com>
--- linux-orig/mm/swapfile.c
+++ linux/mm/swapfile.c
@@ -80,7 +80,7 @@
WARN_ON(page_count(page) <= 1);
bdi = bdev->bd_inode->i_mapping->backing_dev_info;
- bdi->unplug_io_fn(bdi, page);
+ blk_run_backing_dev(bdi, page);
}
up_read(&swap_unplug_sem);
}
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2.6.11.7] ATA-Over-Ethernet Root device
From: McMullan, Jason @ 2005-05-13 17:29 UTC (permalink / raw)
To: PPC_LINUX, Linux Kernel
[-- Attachment #1.1: Type: text/plain, Size: 436 bytes --]
This patch allows you to use ATA Over Ethernet as your root device,
with 'root=/dev/etherd/eX.Y/disc'
Limited testing, just for review.
Advantages:
1) Ext3 over AOE caches dirents, so it's faster and less network
traffic than NFS root
2) Smaller than NFS root code (for embedded systems)
3) Proper locking semantics with Ext3, ReiserFS, etc.
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #1.2: aoe-root.patch --]
[-- Type: text/x-patch, Size: 4283 bytes --]
Description: ATA Over Ethernet root device
ie 'root=/dev/etherd/e0.0/disc' on the kernel command line
Signed-Off-By: Jason McMullan <jason.mcmullan@timesys.com>
--- linux-orig/drivers/block/Kconfig
+++ linux/drivers/block/Kconfig
@@ -506,4 +506,19 @@
This driver provides Support for ATA over Ethernet block
devices like the Coraid EtherDrive (R) Storage Blade.
+config ATA_OVER_ETH_ROOT
+ bool "ATA over Ethernet root device"
+ depends on ATA_OVER_ETH=y
+ help
+ If you want to use ATA Over Ethernet as the root device,
+ set this to 'y'
+
+config ATA_OVER_ETH_ROOT_SHELF
+ int "Shelf ID"
+ depends on ATA_OVER_ETH_ROOT
+
+config ATA_OVER_ETH_ROOT_SLOT
+ int "Slot ID"
+ depends on ATA_OVER_ETH_ROOT
+
endmenu
--- linux-orig/drivers/block/aoe/aoe.h
+++ linux/drivers/block/aoe/aoe.h
@@ -153,6 +153,7 @@
int aoedev_init(void);
void aoedev_exit(void);
struct aoedev *aoedev_bymac(unsigned char *);
+struct aoedev *aoedev_bymajor_minor(ulong major, ulong minor);
void aoedev_downdev(struct aoedev *d);
struct aoedev *aoedev_set(ulong, unsigned char *, struct net_device *, ulong);
int aoedev_busy(void);
--- linux-orig/drivers/block/aoe/aoeblk.c
+++ linux/drivers/block/aoe/aoeblk.c
@@ -229,6 +229,7 @@
gd->capacity = d->ssize;
snprintf(gd->disk_name, sizeof gd->disk_name, "etherd/e%ld.%ld",
d->aoemajor, d->aoeminor);
+ strncpy(gd->devfs_name, gd->disk_name, sizeof gd->devfs_name);
gd->queue = &d->blkq;
d->gd = gd;
--- linux-orig/drivers/block/aoe/aoedev.c
+++ linux/drivers/block/aoe/aoedev.c
@@ -28,6 +28,23 @@
return d;
}
+struct aoedev *
+aoedev_bymajor_minor(ulong major, ulong minor)
+{
+ struct aoedev *d;
+ ulong flags;
+
+ spin_lock_irqsave(&devlist_lock, flags);
+
+ for (d=devlist; d; d=d->next)
+ if (d->aoemajor == major && d->aoeminor == minor)
+ break;
+
+ spin_unlock_irqrestore(&devlist_lock, flags);
+ return d;
+}
+
+
/* called with devlist lock held */
static struct aoedev *
aoedev_newdev(ulong nframes)
--- linux-orig/drivers/block/aoe/aoemain.c
+++ linux/drivers/block/aoe/aoemain.c
@@ -7,6 +7,13 @@
#include <linux/hdreg.h>
#include <linux/blkdev.h>
#include <linux/module.h>
+#include <linux/devfs_fs_kernel.h>
+#ifdef CONFIG_ATA_OVER_ETH_ROOT
+#include <linux/delay.h>
+#include <linux/rtnetlink.h>
+#include <linux/netdevice.h>
+#include <net/sock.h>
+#endif
#include "aoe.h"
MODULE_LICENSE("GPL");
@@ -53,6 +60,43 @@
}
}
+#ifdef CONFIG_ATA_OVER_ETH_ROOT
+void aoe_root(unsigned long major, unsigned long minor)
+{
+ struct net_device *dev;
+
+ printk(KERN_INFO
+ "aoe: Waiting for root AOE device e%ld.%ld\n", major, minor);
+
+ /* Give hardware a chance to settle */
+ msleep(500);
+
+ rtnl_shlock();
+ /* bring loopback device up first */
+printk("Bring up loopback...\n");
+ if (dev_change_flags(&loopback_dev, loopback_dev.flags | IFF_UP) < 0)
+ printk(KERN_ERR "AOE Root: Failed to open %s\n", loopback_dev.name);
+
+ /* Setup all network devices */
+ for (dev = dev_base; dev ; dev = dev->next) {
+ if (dev == &loopback_dev)
+ continue;
+printk("Bring up %s...\n",dev->name);
+ dev_change_flags(dev, dev->flags | IFF_UP);
+ }
+ rtnl_shunlock();
+
+ /* Give drivers a chance to settle */
+ ssleep(1);
+
+ do {
+ aoecmd_cfg(major, minor);
+ msleep(1);
+ } while (!aoedev_bymajor_minor(CONFIG_ATA_OVER_ETH_ROOT_SHELF,CONFIG_ATA_OVER_ETH_ROOT_SLOT));
+
+}
+#endif
+
static void
aoe_exit(void)
{
@@ -63,6 +107,7 @@
aoechr_exit();
aoedev_exit();
aoeblk_exit(); /* free cache after de-allocating bufs */
+ devfs_remove("etherd");
}
static int __init
@@ -70,6 +115,8 @@
{
int ret;
+ devfs_mk_dir("etherd");
+
ret = aoedev_init();
if (ret)
return ret;
@@ -91,6 +138,9 @@
printk(KERN_INFO
"aoe: aoe_init: AoE v2.6-%s initialised.\n",
VERSION);
+#ifdef CONFIG_ATA_OVER_ETH_ROOT
+ aoe_root(CONFIG_ATA_OVER_ETH_ROOT_SHELF,CONFIG_ATA_OVER_ETH_ROOT_SLOT);
+#endif
discover_timer(TINIT);
return 0;
@@ -102,6 +152,7 @@
aoechr_exit();
chr_fail:
aoedev_exit();
+ devfs_remove("etherd");
printk(KERN_INFO "aoe: aoe_init: initialisation failure.\n");
return ret;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to the
From: Allen Curtis @ 2005-05-13 17:09 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 98 bytes --]
What is the status of this patch?
Where can I find the kernel tree with this integrated?
TIA
[-- Attachment #2: Type: text/html, Size: 562 bytes --]
^ permalink raw reply
* MPC885 - USB HCI drivers.
From: Guillaume Autran @ 2005-05-13 17:27 UTC (permalink / raw)
To: PPC_LINUX
In-Reply-To: <ed43f07150d50a594be2bc2589e902a0@freescale.com>
Hi,
Is there any driver for the USB host controller interface built-in the
MPC885 processors.
Does anyone have any experience with it ?
Thanks.
Guillaume.
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* Re: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to the
From: Kumar Gala @ 2005-05-13 17:43 UTC (permalink / raw)
To: Allen Curtis; +Cc: linuxppc-embedded
In-Reply-To: <000601c557de$99627550$6601a8c0@D35HH141>
Allen,
On May 13, 2005, at 12:09 PM, Allen Curtis wrote:
> What is the status of this patch?
Still open.
> Where can I find the kernel tree with this integrated?
One doesn't exist.
- kumar
^ permalink raw reply
* RE: eth0: PHY id 0x00221619 is not supported! HELP
From: Nghiem, Tien @ 2005-05-13 18:25 UTC (permalink / raw)
To: Garcia Jérémie, linuxppc-dev
Hi Garcia,
In the ibm_ocp_phy.c file, the function mii_phy_probe(struct mii_phy =
*phy, int mii_id) has not found the ID of your ethernet transceiver, so =
you can bypass it by doing the following:
int rc;
u32 id;
struct mii_phy_def* def;
int i;
=20
phy->autoneg =3D 0;
phy->advertising =3D 0;
phy->mii_id =3D mii_id;
phy->speed =3D 0;
phy->duplex =3D 0;
phy->pause =3D 0;
=20
/* Take PHY out of isloate mode and reset it. */
rc =3D reset_one_mii_phy(phy, mii_id);
//if (rc)
// return -ENODEV;
=20
/* Read ID and find matching entry */ =20
//id =3D (phy_read(phy, MII_PHYSID1) << 16 | phy_read(phy, =
MII_PHYSID2))
& 0xfffffff0;
//for (i=3D0; (def =3D mii_phy_table[i]) !=3D NULL; i++)
// if ((id & def->phy_id_mask) =3D=3D def->phy_id)
// break;
=20
def =3D mii_phy_table[0];
=20
/* Should never be NULL (we have a generic entry), but... */
if (def =3D=3D NULL)
return -ENODEV;
=20
phy->def =3D def;
/* Setup default advertising */
phy->advertising =3D def->features;
=20
return 0;
I don't know the PPC 405EP, but I did it for my custom board (MPC8260). =
It should work.
Tien
-----Original Message-----
From: linuxppc-dev-bounces@ozlabs.org
[mailto:linuxppc-dev-bounces@ozlabs.org]On Behalf Of Garcia J=E9r=E9mie
Sent: Friday, May 13, 2005 11:15 AM
To: linuxppc-dev@ozlabs.org
Subject: eth0: PHY id 0x00221619 is not supported! HELP
Hi everybody,
We are developping a custom board which uses a ppc405EP and on which one =
we'd like to load a linux hardhat.
During the boot process, we're getting error messages about the ethernet =
PHY. That is really annoying cause we plan to moubnt the file system via =
nfs. So no ethernet no NFS...
Could someone give us a tip and tell us if the messages displayed before =
seem to be normal cause we had to modify some part of the kernel in =
order to get Linux booting.
What those ethernet messages mean? Everythin seems to happen in the =
"ibm_ocp_enet.c" eand "ibm_ocp_phy.c" filesPlease help....
So here we go ---->>>>>>>>>
Linux/PPC load: console=3DttyS0,19200 root=3D/dev/nfs rw ip=3Don
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.4.20_mvl31-405ep_eval =
(root@sop-dhcp-10-16-5-126.amcc.com) (version gcc 3.3.1 (MontaVista =
3.3.1-3.0.10.0300532 2003-12-24)) #26 ven mai 13 5
AMCC Q80G Board
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=3DttyS0,19200 root=3D/dev/nfs rw ip=3Don
hr_time_init: arch_to_nsec =3D 10485759, nsec_to_arch =3D 858993476
Calibrating delay loop... 199.47 BogoMIPS
Memory: 14416k available (1280k kernel code, 424k data, 64k init, 0k =
highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
OCP uart ver 1.6.2 init complete
LSP Revision 1
ikconfig 0.5 with /proc/ikconfig
Starting kswapd
Disabling the Out Of Memory Killer
JFFS2 version 2.1. (C) 2001, 2002 Red Hat, Inc., designed by Axis =
Communications AB.
i2c-core.o: i2c core module version 2.6.2 (20011118)
i2c-dev.o: i2c /dev entries driver module version 2.6.2 (20011118)
i2c-proc.o version 2.6.2 (20011118)
pty: 256 Unix98 ptys configured
eeprom.o version 2.6.2 (20011118)
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0xef600300 (irq =3D 0) is a 16550A
ttyS01 at 0xef600400 (irq =3D 1) is a 16550A
IBM gpio driver version 07.25.02
GPIO #0 at 0xc207d700
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
eth0: PHY id 0x00221619 is not supported!
eth0: PHY id 0x00221619 is not supported!
eth0: No PHY device found.
removing net dev
eth0: PHY id 0x00221619 is not supported!
eth0: PHY id 0x00221619 is not supported!
eth0: No PHY device found.
removing net dev
IBM IIC driver v2.0
ibm-iic: using compatibility value for OPB freq, fix your board specific =
setup
ibm-iic0: using standard (100 kHz) mode
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMPIP: routing cache hash table of 512 =
buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
IP-Config: No network devices available.
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
kmod: failed to exec /sbin/modprobe -s -k block-major-2, errno =3D 2
VFS: Cannot open root device "nfs" or 02:00
Please append a correct "root=3D" boot option
Kernel panic: VFS: Unable to mount root fs on 02:00
<0>Rebooting in 180 seconds..
Tks a lot for your precious help
Dj=E9
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH 2.6.11.7] ATA Over Ethernet Root, Mark 2
From: McMullan, Jason @ 2005-05-13 19:17 UTC (permalink / raw)
To: Linux Kernel, PPC_LINUX
[-- Attachment #1.1: Type: text/plain, Size: 230 bytes --]
Second revision of my ATA Over Ethernet root device patch, now with
white space correction and removed debugging crud.
Any more comment, suggestions?
--
Jason McMullan <jason.mcmullan@timesys.com>
TimeSys Corporation
[-- Attachment #1.2: aoe-root.patch --]
[-- Type: text/x-patch, Size: 4608 bytes --]
#### Auto-generated patch ####
Date: Fri, 13 May 2005 15:15:04 -0400
Signed-Off-By: Jason McMullan <jason.mcmullan@timesys.com>
Description: ATA Over Ethernet root device
ie 'root=/dev/etherd/e0.0/disc' on the kernel command line
Depends:
linux-2.6.11.7
###############################
Index of changes:
Kconfig | 15 +++++++++++++++
aoe/aoe.h | 1 +
aoe/aoeblk.c | 1 +
aoe/aoedev.c | 16 ++++++++++++++++
aoe/aoemain.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 83 insertions(+)
--- linux-orig/drivers/block/Kconfig
+++ linux/drivers/block/Kconfig
@@ -506,4 +506,19 @@
This driver provides Support for ATA over Ethernet block
devices like the Coraid EtherDrive (R) Storage Blade.
+config ATA_OVER_ETH_ROOT
+ bool "ATA over Ethernet root device"
+ depends on ATA_OVER_ETH=y
+ help
+ If you want to use ATA Over Ethernet as the root device,
+ set this to 'y'
+
+config ATA_OVER_ETH_ROOT_SHELF
+ int "Shelf ID"
+ depends on ATA_OVER_ETH_ROOT
+
+config ATA_OVER_ETH_ROOT_SLOT
+ int "Slot ID"
+ depends on ATA_OVER_ETH_ROOT
+
endmenu
--- linux-orig/drivers/block/aoe/aoe.h
+++ linux/drivers/block/aoe/aoe.h
@@ -153,6 +153,7 @@
int aoedev_init(void);
void aoedev_exit(void);
struct aoedev *aoedev_bymac(unsigned char *);
+struct aoedev *aoedev_bymajor_minor(ulong major, ulong minor);
void aoedev_downdev(struct aoedev *d);
struct aoedev *aoedev_set(ulong, unsigned char *, struct net_device *, ulong);
int aoedev_busy(void);
--- linux-orig/drivers/block/aoe/aoeblk.c
+++ linux/drivers/block/aoe/aoeblk.c
@@ -229,6 +229,7 @@
gd->capacity = d->ssize;
snprintf(gd->disk_name, sizeof gd->disk_name, "etherd/e%ld.%ld",
d->aoemajor, d->aoeminor);
+ strncpy(gd->devfs_name, gd->disk_name, sizeof gd->devfs_name);
gd->queue = &d->blkq;
d->gd = gd;
--- linux-orig/drivers/block/aoe/aoedev.c
+++ linux/drivers/block/aoe/aoedev.c
@@ -28,6 +28,22 @@
return d;
}
+struct aoedev *aoedev_bymajor_minor(ulong major, ulong minor)
+{
+ struct aoedev *d;
+ ulong flags;
+
+ spin_lock_irqsave(&devlist_lock, flags);
+
+ for (d = devlist; d; d = d->next)
+ if (d->aoemajor == major && d->aoeminor == minor)
+ break;
+
+ spin_unlock_irqrestore(&devlist_lock, flags);
+ return d;
+}
+
+
/* called with devlist lock held */
static struct aoedev *
aoedev_newdev(ulong nframes)
--- linux-orig/drivers/block/aoe/aoemain.c
+++ linux/drivers/block/aoe/aoemain.c
@@ -7,6 +7,14 @@
#include <linux/hdreg.h>
#include <linux/blkdev.h>
#include <linux/module.h>
+#include <linux/devfs_fs_kernel.h>
+
+/* AOE Root device includes */
+#include <linux/delay.h>
+#include <linux/rtnetlink.h>
+#include <linux/netdevice.h>
+#include <net/sock.h>
+
#include "aoe.h"
MODULE_LICENSE("GPL");
@@ -53,6 +61,41 @@
}
}
+#ifdef CONFIG_ATA_OVER_ETH_ROOT
+void aoe_root(unsigned long major, unsigned long minor)
+{
+ struct net_device *dev;
+
+ printk(KERN_INFO
+ "aoe: Waiting for root AOE device e%ld.%ld\n", major, minor);
+
+ /* Give hardware a chance to settle */
+ msleep(500);
+
+ rtnl_shlock();
+ /* bring loopback device up first */
+ if (dev_change_flags(&loopback_dev, loopback_dev.flags | IFF_UP) < 0)
+ printk(KERN_ERR "AOE Root: Failed to open %s\n", loopback_dev.name);
+
+ /* Setup all network devices */
+ for (dev = dev_base; dev ; dev = dev->next) {
+ if (dev == &loopback_dev)
+ continue;
+ dev_change_flags(dev, dev->flags | IFF_UP);
+ }
+ rtnl_shunlock();
+
+ /* Give drivers a chance to settle */
+ ssleep(1);
+
+ do {
+ aoecmd_cfg(major, minor);
+ msleep(1);
+ } while (!aoedev_bymajor_minor(CONFIG_ATA_OVER_ETH_ROOT_SHELF,CONFIG_ATA_OVER_ETH_ROOT_SLOT));
+
+}
+#endif
+
static void
aoe_exit(void)
{
@@ -63,6 +106,7 @@
aoechr_exit();
aoedev_exit();
aoeblk_exit(); /* free cache after de-allocating bufs */
+ devfs_remove("etherd");
}
static int __init
@@ -70,6 +114,8 @@
{
int ret;
+ devfs_mk_dir("etherd");
+
ret = aoedev_init();
if (ret)
return ret;
@@ -91,6 +137,9 @@
printk(KERN_INFO
"aoe: aoe_init: AoE v2.6-%s initialised.\n",
VERSION);
+#ifdef CONFIG_ATA_OVER_ETH_ROOT
+ aoe_root(CONFIG_ATA_OVER_ETH_ROOT_SHELF,CONFIG_ATA_OVER_ETH_ROOT_SLOT);
+#endif
discover_timer(TINIT);
return 0;
@@ -102,6 +151,7 @@
aoechr_exit();
chr_fail:
aoedev_exit();
+ devfs_remove("etherd");
printk(KERN_INFO "aoe: aoe_init: initialisation failure.\n");
return ret;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: eth0: PHY id 0x00221619 is not supported! HELP
From: Colin Leroy @ 2005-05-13 19:30 UTC (permalink / raw)
To: Nghiem, Tien; +Cc: linuxppc-dev, Garcia Jérémie
In-Reply-To: <CCD52035B75A5D4E8A481EFB132C42EA28E5CF@mail.oerlikon.ca>
On 13 May 2005 at 14h05, Nghiem, Tien wrote:
Hi,
> rc = reset_one_mii_phy(phy, mii_id);
> //if (rc)
> // return -ENODEV;
Why disabling such guards?
> //for (i=0; (def = mii_phy_table[i]) != NULL; i++)
> // if ((id & def->phy_id_mask) == def->phy_id)
> // break;
Just an idea, I guess it'd be far more clean to add the phy id to
mii_phy_table[] (and, optionally, send the patch so you won't have to
do it everytime).
You're just asking for breakage there.
--
Colin
^ permalink raw reply
* RE: eth0: PHY id 0x00221619 is not supported! HELP
From: Nghiem, Tien @ 2005-05-13 20:36 UTC (permalink / raw)
To: Colin Leroy; +Cc: linuxppc-dev, Garcia Jérémie
Hi Colin,
I worked on a project 2 years ago, and the hardware supplier decided to
change the tranceiver twice during the course of the project. So =
instead of modifying the mii_phy_table
each time the transeiver was changed, I bypassed the id check. =20
I did this because I doubt that in the future people are going to be =
interested in updating software, and delivering a new s/w version when a =
hardware fix is performed.
It's not clean, but it's easy and convenient.
This is just a suggestion of mine for a quick fix.
Tien
-----Original Message-----
From: Colin Leroy [mailto:colin@colino.net]
Sent: Friday, May 13, 2005 3:31 PM
To: Nghiem, Tien
Cc: Garcia J=E9r=E9mie; linuxppc-dev@ozlabs.org
Subject: Re: eth0: PHY id 0x00221619 is not supported! HELP
On 13 May 2005 at 14h05, Nghiem, Tien wrote:
Hi,=20
> rc =3D reset_one_mii_phy(phy, mii_id);
> //if (rc)
> // return -ENODEV;
Why disabling such guards?
> //for (i=3D0; (def =3D mii_phy_table[i]) !=3D NULL; i++)
> // if ((id & def->phy_id_mask) =3D=3D def->phy_id)
> // break;
Just an idea, I guess it'd be far more clean to add the phy id to
mii_phy_table[] (and, optionally, send the patch so you won't have to
do it everytime).
You're just asking for breakage there.
--=20
Colin
^ permalink raw reply
* Re: [PATCH 2.6.12-rc2] Freescale 8272ADS PCI bridge support to the
From: Allen Curtis @ 2005-05-13 21:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: Ppc Embedded
In-Reply-To: <757b7fc162262dae582e1d85b6f36e62@freescale.com>
Is the patch necessary? In the March archive it appears that people
were using the standard 8260 PCI support. What is the issue? Perhaps I
could provide a patch to m8260_pci.c (as you suggested)
>> Where can I find the kernel tree with this integrated?
>
> One doesn't exist.
>
Is there an embedded 2.5/2.6 tree somewhere? (I know about the
bkbits.net/ppc/linux-2.5 tree
TIA
^ permalink raw reply
* [patch 1/1] ppc/fcc_enet: replace schedule_timeout() with ssleep()
From: domen @ 2005-05-13 22:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, domen, Nishanth Aravamudan
From: Nishanth Aravamudan <nacc@us.ibm.com>
Use ssleep() instead of schedule_timeout() to guarantee the task delays
as expected.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: Domen Puncer <domen@coderock.org>
---
fcc_enet.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
Index: quilt/arch/ppc/8260_io/fcc_enet.c
===================================================================
--- quilt.orig/arch/ppc/8260_io/fcc_enet.c
+++ quilt/arch/ppc/8260_io/fcc_enet.c
@@ -1305,12 +1305,11 @@ static void mii_parse_dm9161_scsr(uint m
static void mii_dm9161_wait(uint mii_reg, struct net_device *dev)
{
- int timeout = HZ;
+ int timeout_secs = 1;
/* Davicom takes a bit to come up after a reset,
* so wait here for a bit */
- set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(timeout);
+ ssleep(timeout_secs);
}
static phy_info_t phy_info_dm9161 = {
--
^ permalink raw reply
* MPC860 CP / CPM Misbehaving
From: Martin, Tim @ 2005-05-13 22:11 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Not so much a linux question, as a general MPC860 question, but maybe
someone out there can help.
I'm using a custom MPC860 based embedded board and having problems with SCC1
and SMC1 reception. I have SCC1 setup in ethernet mode, and SMC1 setup in
UART mode. The general problem manifests itself as getting receive buffer
descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD
status/control field, "Overrun. Set when a receiver overrun occurs during
reception").
For example, when receiving an ICMP ping over SCC1, I typically get the
first 40-64 bytes of the standard 78 byte ICMP message.
For another example, with no activity on SCC1, receive activity on SMC1 can
also result in receive RxBDs with the OV bit set.
There is also some weirdness where activity on SCC1 results in CPM
interrupts (and RxBDs filled) for SMC1.
I am testing my code by running from a BDM/JTAG debugger. To throw a wrench
in things, the above weirdness does not occur if the core processor is
halted at a breakpoint (e.g. if the core is halted at a breakpoint, the CPM
continues to run and the entire 78 byte ICMP message shows up in an SCC1
RxBD).
This isn't a board hardware problem, the board runs fine with other software
(different operating system, etc). It's most likely a configuration problem
on my end.
I have verified that:
* Clocks are setup for correct frequency and routing (SCC1 getting
CLK1/CLK2, SMC1 getting BRG1).
* Low power mode (MSR[POW] and PLPRCR[LPM]) is not being entered.
* I/O ports (PA, PB, PC, PD) configured correctly.
* I'm using the Motorola/Frescale microcode patch (MPC860MC05.zip) that
allows SMC1 and SCC3 to be used at the same time. SMC1 dual port ram
parameter area is remapped correctly. Not that this matters in this
configuration, since I'm not even enabling SCC3 for this test. I've also
tried it without the microcode patch and get the same results.
My thoughts are that it's almost as if the CP (CPM RISC processor) or SDMA
is being occasionally frozen out while the core PowerPC MPC860 processor is
running. The FIFO internal to the CPM between SCC1 and the CP is 32 bytes,
so the fact that I'm getting a little more than 32 bytes makes me think that
the CP is being kicked off, and someone gets slowed down/stopped, then the
FIFO overflows. So I'm getting however many bytes the CP can process at the
start of a transmissions plus the 32 bytes in the FIFO before the overflow
occurs. So if this is true, what could stop the CP from running?
Tim
^ permalink raw reply
* Re: MPC860 CP / CPM Misbehaving
From: Wolfgang Denk @ 2005-05-13 23:42 UTC (permalink / raw)
To: Martin, Tim; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <846BA3AF7C8A2048937F1801FD3129C902DB5942@messenger.viasat.com>
In message <846BA3AF7C8A2048937F1801FD3129C902DB5942@messenger.viasat.com> you wrote:
>
> I'm using a custom MPC860 based embedded board and having problems with SCC1
> and SMC1 reception. I have SCC1 setup in ethernet mode, and SMC1 setup in
> UART mode. The general problem manifests itself as getting receive buffer
> descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD
> status/control field, "Overrun. Set when a receiver overrun occurs during
> reception").
...
> This isn't a board hardware problem, the board runs fine with other software
> (different operating system, etc). It's most likely a configuration problem
> on my end.
<speculation>
Are you 100% sure that your SDRAM is working fine when stressed with
burst mode accesses?
See http://www.denx.de/twiki/bin/view/DULG/UBootCrashAfterRelocation
</speculation>
> My thoughts are that it's almost as if the CP (CPM RISC processor) or SDMA
> is being occasionally frozen out while the core PowerPC MPC860 processor is
You may see "funny" problems when your SDRAM is not working right.
And yes, this may happen especially on DMA transfers which will use
burst mode.
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
... Hiroshima 45 ... Chernobyl 86 ... Windows 95 ...
^ permalink raw reply
* RE: MPC860 CP / CPM Misbehaving
From: Martin, Tim @ 2005-05-13 23:57 UTC (permalink / raw)
To: 'wd@denx.de'; +Cc: 'linuxppc-embedded@ozlabs.org'
Wolfgang,
The SDRAM timings (UPM registers) are setup by a BDM/JTAG debugger script.
The same script is run when I download the other software, which works.
That being said, I wasn't the one who wrote the UPM portion of the script
and it is one of the few things I haven't verified, so it does sound like a
likely candidate. Thanks for the tip.
Tim
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]
Sent: Friday, May 13, 2005 4:42 PM
To: Martin, Tim
Cc: 'linuxppc-embedded@ozlabs.org'
Subject: Re: MPC860 CP / CPM Misbehaving
In message <846BA3AF7C8A2048937F1801FD3129C902DB5942@messenger.viasat.com>
you wrote:
>
> I'm using a custom MPC860 based embedded board and having problems with
SCC1
> and SMC1 reception. I have SCC1 setup in ethernet mode, and SMC1 setup in
> UART mode. The general problem manifests itself as getting receive buffer
> descriptors (BDs) from the CPM with the OV bit set (bit 14 of the RxBD
> status/control field, "Overrun. Set when a receiver overrun occurs during
> reception").
...
> This isn't a board hardware problem, the board runs fine with other
software
> (different operating system, etc). It's most likely a configuration
problem
> on my end.
<speculation>
Are you 100% sure that your SDRAM is working fine when stressed with
burst mode accesses?
See http://www.denx.de/twiki/bin/view/DULG/UBootCrashAfterRelocation
</speculation>
> My thoughts are that it's almost as if the CP (CPM RISC processor) or SDMA
> is being occasionally frozen out while the core PowerPC MPC860 processor
is
You may see "funny" problems when your SDRAM is not working right.
And yes, this may happen especially on DMA transfers which will use
burst mode.
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
... Hiroshima 45 ... Chernobyl 86 ... Windows 95 ...
^ permalink raw reply
* problems with ppc405 on 2.6.11.8.
From: Michael Richardson @ 2005-05-13 23:37 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
-----BEGIN PGP SIGNED MESSAGE-----
A customer of mine has a PPC405 system, which was based upon the
Embedded Planet design. It runs U-boot 0.4.0, and the system currently
ships with a kernel based upon Timesys 2.4.18.
We are in the process of upgrading to 2.6.11. (linus, not timesys. We
see no value add from timesys)
The major stumbling block was using boot/simple/{head,relocate}.S,
and the inftrees.c. For reasons we do not understand, the system would
fail in huft_build() when (setting up for) decompressing. We traced
through this using our bdi2000, after failing with puts() additions.
My gut instinct was originally that we were blowing our stack, or
overwriting running code while decompressing.
Kyle McMartin tried (I'm not sure why yet) replacing the head.S with
the one from 2.4.18-timesys. It seemed to solve the problem.
I'm posting this in two hopes:
a) that someone else not hit the same problem.
b) that someone else might have a suggestion on
what might be different between head.S+relocate.S and head.S(2.4.18).
- --
] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [
] mcr @ xelerance.com Now doing IPsec training, see |net architect[
] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQoU6E4qHRg3pndX9AQEtswP5AXD3+gxobRZWfZUGU7MqzoJSJFCLcrYc
0yqfGHBL79g3zbkJUONnE30qBBdEyYkH5ghmg6Xqxt4YjgPId3ZOWHBtrRrp+PCA
lBm8WzsgBBBT5SCKNDe6kOy2rSKUjunxv4GXJ0lSQpZMvuceAOmD73no4tWIM/I8
2iETSMLkr9Q=
=2Tlk
-----END PGP SIGNATURE-----
^ 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