* Re: [PATCH][PPC32] PPC4xx ocp ide rewrite/cleanup
From: Matt Porter @ 2005-02-16 23:14 UTC (permalink / raw)
To: Andre' Draszik; +Cc: linuxppc-embedded
In-Reply-To: <4206ED97.2060506@gmx.net>
On Mon, Feb 07, 2005 at 05:24:55AM +0100, Andre' Draszik wrote:
> Hi,
>
> this is a rewrite of the ibm4xx ocp ide driver. In its current state it
> doesn't compile with current 2.6 and is completely broken in many other
> aspects anyway.
> Please consider applying (or tell me how the patch should be changed to
> qualify for applying :)
>
> Signed-off-by: Andre' Draszik <andid@gmx.net>
>
> diff -urN -X dontdiff linuxppc-2.5.orig/drivers/ide/Kconfig linuxppc-2.5/drivers/ide/Kconfig
I tried applying this to current linuxppc-2.5. All hunks are rejected.
Can you double check this patch and resend?
-Matt
^ permalink raw reply
* RE: How to set a custom baud rate using 2.6 linux distro on MPC5200 based board?
From: Caruso, Nick @ 2005-02-16 21:39 UTC (permalink / raw)
To: Eric N. Johnson (ACD), linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org on behalf of Eric N. Johnson (ACD)
Sent: Tue 2/15/2005 6:55 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: How to set a custom baud rate using 2.6 linux distro on MPC5200 based board?
>I'm trying to set a custom baud rate (500KBaud, in case anyone cares) on
>one of the PSCs on a MPC5200 board.
[snip]
> serial_info.flags = ASYNC_SPD_CUST | ASYNC_LOW_LATENCY;
> serial_info.custom_divisor = 48; // clock on FTDI chip / 48 == 500KB
>
> if ( ioctl(tty_fd, TIOCSSERIAL, &serial_info ) < 0) {
> perror("config_serial_port: ioctl TIOCSSERIAL");
> return(-1);
> }
>
>This compiled fine under the ppc cross-dev tools we have but it fails with
>an "invalid argument" error when run on the ppc board.
It looks like this code was written for an FTDI serial port. The FTDI is a
USB to Serial converter that handles baud rate generation very differently
from a standard UART.
_______________________________________________
Yes, it was originally written for a USB-to-serial adapter. However it is my belief that the clock divisor thing works with any serial device, including so-called 16550 devices.
I think there may be a problem where TIOCSSERIAL doesn't work for the MPC5200 PSC uart code. It seems that if I get the ports' attributes with TIOCGSERIAL and immediately set the same values on the same port I get an error return from the ioctl call. I'm talking with our BSP vendor about this.
best regards,
Nick Caruso
[-- Attachment #2: Type: text/html, Size: 2346 bytes --]
^ permalink raw reply
* Re: Support for Adder875 in Linux 2.4
From: Markus Westergren @ 2005-02-16 21:32 UTC (permalink / raw)
To: Jan Damborsky; +Cc: linuxppc-embedded
In-Reply-To: <421324EC.5000104@devcom.cz>
On Wed, 16 Feb 2005, Jan Damborsky wrote:
> Markus Westergren wrote:
>
> >I got my board working with both ethernet ports today. I'm interested in your
> >patch so that I can see if we made the same ugly hack and if I have overlocked
> >something :)
> >
> >/Markus
> >
> >
> The patch is here. I am sorry it has not been done against current denk
> source tree,
> I used the one from 19th January. But I hope it might satisfy for
> understanding the way
> the hack is done.
>
>
Thank you.
/Markus
^ permalink raw reply
* Re: bdi2000 debugging
From: Matej Kupljen @ 2005-02-16 21:21 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
In-Reply-To: <4213B356.3060901@246tNt.com>
Hi
> The good news : I can explain you BDI2000 problem :)
Thank you for the explanation.
> The bad news : AFAIK you can't fix it :(
>
> There is a bug in the rev <= 1.2 of the silicon of MPC5200 : When there
> is another XLB Master active (like USB or any bestcomm activity), the XLB
> arbiter can get confused during debugging and you can resume nor
> can you access memory or do anything ... you can just reboot.
Hmm, this is not good. :(
How can I determine the silicon rev.?
I'll look it up in the docs.
> It's VERY frustrating since the BDI2000 is then kind of useless for debug
> in the cases when you need those activated ...
So I have to disable USB (can live without it for debugging), bestcomm
(hmm, how can I use console on serial port then?) and what else?
Thanks again for the explanation, I'd spent one more week on this.
Now I know I have to use a different approach :-(
BR,
Matej
^ permalink raw reply
* Re: bdi2000 debugging
From: Sylvain Munaut @ 2005-02-16 20:55 UTC (permalink / raw)
To: Matej Kupljen, linuxppc-embedded
In-Reply-To: <1108547431.30212.37.camel@mbmatejdebian.ultra.si>
Hi
>Something is overwriting memory in kernel space I guess.
>Now, I have the BDI 2000 and I am trying to debug this, but until
>now I was unsuccessful :-(
>
>When I debug the kernel, the BDI prints this out in the telnet
>interface:
>- Target MBAR is 0xF0000000
>- Target XLBA is 0x8000A366
>
>I know what MBAR is, but what the XLBA is?
>The problem is that while this value remains the same everything
>is fine. But sometimes it is set to 0x00000000 and then I cannot
>use debugger anymore. I can make a few steps when this value
>is set to 0x0, but the "stepping" is done in completely unrelated
>code. I first noticed this while stepping trough hc_found_ohci
>function when the return 0 is executed. When I disabled the USB
>support in my kernel I could use debugger to debug a kernel.
>But is still does not work all the time, because the XLBA still
>gets set to 0!
>
>
The good news : I can explain you BDI2000 problem :)
The bad news : AFAIK you can't fix it :(
There is a bug in the rev <= 1.2 of the silicon of MPC5200 : When there
is another XLB Master active (like USB or any bestcomm activity), the XLB
arbiter can get confused during debugging and you can resume nor
can you access memory or do anything ... you can just reboot.
It's VERY frustrating since the BDI2000 is then kind of useless for debug
in the cases when you need those activated ...
Sylvain
^ permalink raw reply
* Re: Lite5200 full duplex support
From: Sylvain Munaut @ 2005-02-16 20:46 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc05021515486bd9f926@mail.gmail.com>
Grant Likely wrote:
>I'm using Sylvain's http://bkbits.246tnt.com:14690/linux-2.5-mpc52xx
>bk tree on a lite5200 evb. I noticed that the FEC driver is hard
>coded to only support half duplex 10/100 auto-negotiation. Is that
>intentional? Are there any known problems with running full duplex?
>
>I modified the code to allow full duplex and I haven't observed any
>problems yet. (w/ nfsroot and compiling apps on the target natively)
>
>Cheers,
>g.
>
>BTW, here's what I changed:
>drivers/net/fec_mpc52xx/fec_phy.c line 294 (phy_info_lxt971)
>from:
> { mk_mii_write(MII_REG_ANAR, 0x0A1), NULL }, /* 10/100, HD */
>to:
> { mk_mii_write(MII_REG_ANAR, 0x1E1), NULL }, /* 10/100, HD */
>
>
>
I'm not sure actually. I also wondered and forgot to ask the author. I guess
I always tought there was a problem with it without checking.
Good to know it's working. Thanks
Sylvain
^ permalink raw reply
* iBook G4: first wakeup has black screen
From: Olof Johansson @ 2005-02-16 18:14 UTC (permalink / raw)
To: linuxppc-dev
Hi,
With 2.6.11-rc4, sleep seems to work pretty well. There's still problems
with disconnecting USB devices while the machine is asleep, but that's
nothing new.
I've noticed one thing though: The very first time I wake the machine up
after sleeping the screen is dark (backlight off?). If I put it to sleep
and wake it up again everything goes back to normal.
The machine is an iBook G4 1.2GHz:
0000:00:10.0 VGA compatible controller: ATI Technologies Inc RV250 5c63
[Radeon Mobility 9200 M9+] (rev 01)
Has anyone else seen this before?
-Olof
^ permalink raw reply
* RE: sched while atomic
From: Rune Torgersen @ 2005-02-16 20:13 UTC (permalink / raw)
To: linuxppc-dev
2.6.11rc2 and rc4 gives roughly the same message on an MPC8266
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
scheduling while atomic: swapper/0x00000002/0
Call trace:
[c0006c30] dump_stack+0x18/0x28
[c01ba970] schedule+0x670/0x674
[c0003f20] syscall_exit_work+0x108/0x10c
[c0244fc4] proc_root_init+0x144/0x150
[00000000] 0x0
[c023a5fc] start_kernel+0x138/0x164
[000035fc] 0x35fc
NET: Registered protocol family 16
Kernel boots normally after this, and everything seems to work
> -----Original Message-----
> From: linuxppc-dev-bounces@ozlabs.org=20
> [mailto:linuxppc-dev-bounces@ozlabs.org] On Behalf Of=20
> danny@mailmij.org
> Sent: Thursday, February 03, 2005 17:15
> To: linuxppc-dev@ozlabs.org
> Subject: sched while atomic
>=20
>=20
> Latest 2.6.11rc* give me this interesting message at boot:
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> scheduling while atomic: swapper/0x00000002/0
> Call trace:
> [c01c7580] schedule+0x640/0x6bc
> [c0004698] syscall_exit_work+0x120/0x124
> [c00a5414] proc_device_tree_init+0x7c/0x98
> [c02be9b4] proc_root_init+0x14c/0x158
> [c02a660c] start_kernel+0x178/0x1b0
> [00003a5c] 0x3a5c
>=20
> Since it doesn't happen on x86, I first thought it was=20
> because of the ppc=20
> specific init of the device_tree, but commenting this out=20
> just lets it=20
> happen somewhere else. It seems schedule is called when it=20
> returns from a=20
> syscall, which seems normal behaviour to me, but the recent=20
> preempt_disable() in start_kernel makes the scheduler give=20
> these warnings.
> So what's happening?=20
>=20
> Also, I think this is already know for a while:
> /lib/modules/2.6.11-rc3/kernel/drivers/video/vga16fb.ko needs unknown=20
> symbol vgacon_remap_base
>=20
> regards,
>=20
> danny
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>=20
>=20
^ permalink raw reply
* Re: Mounta Vista Linux prompt on serial console
From: Wolfgang Denk @ 2005-02-16 20:00 UTC (permalink / raw)
To: srinivas.surabhi; +Cc: linuxppc-embedded
In-Reply-To: <EF9B29C78F41FA488927FCBC7750AF0E011DA5D1@hyd-mdp-msg.wipro.com>
In message <EF9B29C78F41FA488927FCBC7750AF0E011DA5D1@hyd-mdp-msg.wipro.com> you wrote:
>
> cramfs is 2.7MB where as the RAM size is 32MB. While building ofcourse
> the RAMDISK size was told as 8MB. This I mentioned in the devrocket
What has the ramdisk to do here? Either you are using a cramfs
filesystem, or a ramdisk (probably with an ext2 filesystem in it).
Putting cramfs filesystem in a ramdisk image is a pretty bad idea.
> Here I have one doubt while building the uBoot image using mkImage with
> multi option where was the FileSystem image getting downloaded ? and how
A multi-file image in U-Boot indeed requires a ramdisk image. Then
you should not use a cramfs filesystem. The method for loading tha
ramdisk image is described in the U-Boot "README" file; search for
"positioning of initrd images".
> the downloaded location was known to the kernel Image for pointing out
> the File System image location. The options -a and -e are applicable
> only for first image, isn't it? First image I mean the kernel Image. I
Yes. Only the kernel is executable code and has an entry point.
> YES. You are right I am building the image on x86 (Windows platform).
> But I checked the build log it used the -r option. The default build was
> cpio format and after that using fstool converting to CRAMS and the
> option -r was present .I believe that devrocket of MountaVista has
> makefiles specific to OS i.e for Windows, because while installation it
> asks for what type of OS do you want to have the Image Development
> environment.
Maybe you should ask MV support, then.
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 22 - 24, Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is clear that the individual who persecutes a man, his brother,
because he is not of the same opinion, is a monster. - Voltaire
^ permalink raw reply
* Re: Incomplete network configuration information when booting from NFS root on Ebony
From: Eugene Surovegin @ 2005-02-16 17:35 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b05021608591692a460@mail.gmail.com>
On Wed, Feb 16, 2005 at 08:59:02AM -0800, Shawn Jin wrote:
> > > Is anybody using linux-2.6.10 from kernel.org for testing IBM Ebony board?
> >
> > Yes, with stock boot loader and great success (bootp + NFS root). I
> > just use "ip=on root=/dev/nfs" and let my bootp server tell the kernel
> > about all other parameters.
>
> What's your boot loader?
Default IBM one (OpenBIOS).
>
> > Did you try looking at net/ipv4/ipconfig.c? This is file responsible
> > for this message.
>
> Yes. I did find the comment you pointed and thought it might be a
> problem. But another issue I don't understand is why it cannot fetch
> MAC addresses from VPD? Without my hack the MAC addresses fetched from
> VPD are all FF:FF:FF:FF:FF:FF. The Rom Monitor can detect the
> addresses, which I guess are from VPD.
I'd suggest using standard IBM bootloader which is what Ebony comes
with and make it work first, and only after this you should try to put
non-standard one like u-boot. This is just common sense. If you need
help with u-boot, there is a mail list for it. Ask quiestions there.
>
> > /*
> > * If the config information is insufficient (e.g., our IP address or
> > * IP address of the boot server is missing or we have multiple network
> > * interfaces and no default was set), use BOOTP or RARP to get the
> > * missing values.
> > */
> >
> > Probably your case - multiple ethernet devices (440GX has 4) and
> > you haven't specified which device should be assigned IP.
>
> Do you know how to set a default active device?
Doh, please, spend some time and read this ipconfig.c yourself. It has
a big comment describing format of "ip=...":
<client-ip>:<server-ip>:<gw-ip>:<netmask>:<host name>:<device>:<PROTO>
--
Eugene.
^ permalink raw reply
* Re: Incomplete network configuration information when booting fro m NFS root on Ebony
From: Shawn Jin @ 2005-02-16 17:01 UTC (permalink / raw)
To: Demke Torsten-atd012; +Cc: ppcembed
In-Reply-To: <43395BE65409D911B9FF00110A9BFFDCDF4EF4@zwg57exm01.ea.mot.com>
> Why does your kernel uses the IP address 130.27.84.47
> (where comes this address from?), but not the IP address from u-boot?
Thanks for reading so carefully. ;) I tried to shield the real address
and obviously I made some mistakes.
-Shawn.
^ permalink raw reply
* Re: Incomplete network configuration information when booting from NFS root on Ebony
From: Shawn Jin @ 2005-02-16 16:59 UTC (permalink / raw)
To: ppcembed
In-Reply-To: <20050216025921.GA25838@gate.ebshome.net>
> > Is anybody using linux-2.6.10 from kernel.org for testing IBM Ebony board?
>
> Yes, with stock boot loader and great success (bootp + NFS root). I
> just use "ip=on root=/dev/nfs" and let my bootp server tell the kernel
> about all other parameters.
What's your boot loader? I should ask if anybody has successful story
on using uboot to boot 2.6.10 to test Ebony board.
> Did you try looking at net/ipv4/ipconfig.c? This is file responsible
> for this message.
Yes. I did find the comment you pointed and thought it might be a
problem. But another issue I don't understand is why it cannot fetch
MAC addresses from VPD? Without my hack the MAC addresses fetched from
VPD are all FF:FF:FF:FF:FF:FF. The Rom Monitor can detect the
addresses, which I guess are from VPD.
> /*
> * If the config information is insufficient (e.g., our IP address or
> * IP address of the boot server is missing or we have multiple network
> * interfaces and no default was set), use BOOTP or RARP to get the
> * missing values.
> */
>
> Probably your case - multiple ethernet devices (440GX has 4) and
> you haven't specified which device should be assigned IP.
Do you know how to set a default active device?
Thanks,
-Shawn.
^ permalink raw reply
* [PATCH] Fixup of previous PCI9 patch
From: Rune Torgersen @ 2005-02-16 16:38 UTC (permalink / raw)
To: linuxppc-embedded, Tom Rini
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
Previous PCI9 patch had a #endif placed wrong for some unknown reason
(was correct in local tree)
This fixes it.
Signed-off-by: Rune Torgersen <runet@innovsys.com>
Rune Torgersen
System Developer
Innovative Systems LLC
1000 Innovative Drive
Mitchell, SD 57301
Ph: 605-995-6120
www.innovsys.com
[-- Attachment #2: patch_pci9patch_fixup --]
[-- Type: application/octet-stream, Size: 627 bytes --]
--- linux-2.5/include/asm-ppc/io.h 2005-02-16 10:13:07.846116320 -0600
+++ linux-innsys-2.6.9/include/asm-ppc/io.h 2005-02-16 10:32:07.000000000 -0600
@@ -360,6 +360,7 @@ static inline void memcpy_toio(volatile
{
memcpy((void __force *) dst, src, count);
}
+#endif
#define eth_io_copy_and_sum(a,b,c,d) eth_copy_and_sum((a),(void __force *)(void __iomem *)(b),(c),(d))
@@ -408,7 +409,7 @@ extern inline void * bus_to_virt(unsigne
return (void*) mm_ptov (address);
#endif
}
-#endif
+
/*
* Change virtual addresses to physical addresses and vv, for
* addresses in the area where the kernel has the RAM mapped.
^ permalink raw reply
* Re: make -j12 all fails in uImage target
From: Tom Rini @ 2005-02-16 15:54 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Sam Ravnborg
In-Reply-To: <20050207082948.GB29823@suse.de>
On Mon, Feb 07, 2005 at 09:29:48AM +0100, Olaf Hering wrote:
> On Sun, Feb 06, Sam Ravnborg wrote:
>
> > Something like this may do the trick:
> >
> > $(obj)/images: $(addprefix $(obj)/,$(subdir-y) $(bootdir-y))
> > $(Q)$(MAKE) $(build)=$@
> >
> > And then delete the assignment of images to subdir-y
>
> That still doesnt work right, I touched one .c file which lead to a new
> vmlinux, now zImage.rs6k is too small:
Is it possible that the dependency is being met by the file being there,
but not done? If so, would perhaps depending on System.map as well for
vmlinux.bin fix the problem?
This doesn't make sense to me, but taking a quick look over things,
zImage.chrp (/etc) do have dependncies on vmlinux.gz which has deps on
vmlinux.bin, which deps on vmlinux.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH][PPC32] Adds mcc parameter structures and definitions
From: morten.banzon @ 2005-02-16 12:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 250 bytes --]
This patch adds mcc parameter structures and definitions to the
include/asm-ppc/cpm2.h file in the 2.6.10 kernel.
There is currently no MPC82xx mcc driver in the kernel that use this.
Signed-off-by: Morten Banzon <morten.banzon at axxessit.no>
[-- Attachment #2: linux-2.6.10-cpm2.patch --]
[-- Type: application/octet-stream, Size: 7461 bytes --]
--- linux-2.6.10.orig/include/asm-ppc/cpm2.h 2004-12-24 22:34:44.000000000 +0100
+++ linux-2.6.10/include/asm-ppc/cpm2.h 2005-02-16 12:34:54.000000000 +0100
@@ -543,6 +543,186 @@
#define BD_SCC_TX_LAST ((ushort)0x0800)
+
+/* Global MCC Parameters.
+ * These parameters are stored in Parameter RAM, i.e. DPRAM2.
+ * MCC1 global parameters are stored in the first 128 bytes of page 8.
+ * MCC2 global parameters are stored in the first 128 bytes of page 9.
+ */
+typedef struct mcc_param {
+ uint mccbase; /* Multi-channel controller base pointer */
+ ushort mccstate; /* Multi-channel controller state */
+ ushort mrblr; /* Max. receive buffer length */
+ ushort grfthr; /* Global receive frame threshold */
+ ushort grfcnt; /* Global receive frame count */
+ uint rinttmp; /* Temp. location for holding the receive */
+ /* interrupt queue entry */
+ uint data0; /* Temp. location for holding data */
+ uint data1; /* Temp. location for holding data */
+ uint tintbase; /* Multi-channel transmitter circular */
+ /* interrupt table base address */
+ uint tintptr; /* Pointer to the transmitter circular */
+ /* interrupt table. */
+ uint tinttmp; /* Temp. location for holding the transmit */
+ /* interrrupt queue entry */
+ ushort sctpbase; /* Internal pointer for the super channel */
+ /* transmit table */
+ ushort reserved;
+ uint c_mask32; /* CRC constant */
+ ushort xtrabase; /* Pointer to the beginning of the extra */
+ /* parameters information */
+ ushort c_mask16; /* CRC constant */
+ uint rinttmp0; /* Temp. location for holding a receive */
+ uint rinttmp1; /* circular interrupt table entry for */
+ uint rinttmp2; /* tables 0-3 */
+ uint rinttmp3;
+ uint rintbase0; /* Multi-channel receiver circular interrupt */
+ /* table base address */
+ uint rintptr0; /* Pointer to the receiver circular table. */
+ uint rintbase1;
+ uint rintptr1;
+ uint rintbase2;
+ uint rintptr2;
+ uint rintbase3;
+ uint rintptr3;
+ uint ts_tmp; /* Temp. place for time stamp */
+} mcc_param_t;
+
+
+/* MCC Channel Extra Parameters.
+ */
+typedef struct mcc_chan_xtra {
+ ushort tbase; /* TxBD base address */
+ ushort tbptr; /* TxBD pointer */
+ ushort rbase; /* RxBD base address */
+ ushort rbptr; /* RxBD pointer */
+} mcc_chan_xtra_t;
+
+
+/* MCC Channel-Specific HDLC Parameters.
+ * MCC Internal Transmitter State (TSTATE)
+ */
+#define MCC_TSTATE_GBL ((uint)0x20000000) /* Activates snooping */
+#define MCC_TSTATE_BO_BIG ((uint)0x18000000) /* Byte ordering */
+#define MCC_TSTATE_BO_LITTLE ((uint)0x08000000)
+#define MCC_TSTATE_TC2 ((uint)0x04000000) /* Transfer code */
+#define MCC_TSTATE_DTB ((uint)0x02000000) /* Data bus indicator */
+#define MCC_TSTATE_BDB ((uint)0x01000000) /* BD bus */
+
+
+/* MCC Channel Mode Register (CHAMR)
+ */
+#define MCC_CHAMR_MODE ((ushort)0x8000) /* Channel mode */
+#define MCC_CHAMR_POL ((ushort)0x4000) /* Polling */
+#define MCC_CHAMR_MBS ((ushort)0x2000) /* Must be set */
+#define MCC_CHAMR_IDLM ((ushort)0x1000) /* Idle mode */
+#define MCC_CHAMR_CRC ((ushort)0x0080) /* CRC mode */
+#define MCC_CHAMR_TS ((ushort)0x0020) /* Time stamp */
+#define MCC_CHAMR_RQN3 ((ushort)0x0018) /* Receive queue number 3 */
+#define MCC_CHAMR_RQN2 ((ushort)0x0010) /* Receive queue number 2 */
+#define MCC_CHAMR_RQN1 ((ushort)0x0008) /* Receive queue number 1 */
+#define MCC_CHAMR_RQN0 ((ushort)0x0000) /* Receive queue number 0 */
+
+
+/* MCC Internal Receiver State (RSTATE)
+ */
+#define MCC_RSTATE_GBL ((uint)0x20000000) /* Activates snooping */
+#define MCC_RSTATE_BO_BIG ((uint)0x18000000) /* Byte ordering */
+#define MCC_RSTATE_BO_LITTLE ((uint)0x08000000)
+#define MCC_RSTATE_TC2 ((uint)0x04000000) /* Transfer code */
+#define MCC_RSTATE_DTB ((uint)0x02000000) /* Data bus indicator */
+#define MCC_RSTATE_BDB ((uint)0x01000000) /* BD bus */
+
+
+typedef struct mcc_chan_hdlc {
+ uint tstate; /* Tx internal state */
+ uint zistate; /* Zero-insertion machine state */
+ uint zidata0; /* Zero-insertion high word data buffer */
+ uint zidata1; /* Zero-insertion low word data buffer */
+ ushort tbdflags; /* TxBD flags */
+ ushort tbdcnt; /* Tx internal byte count */
+ uint tbdptr; /* Tx internal data pointer */
+ ushort intmsk; /* Channel's interrupt mask */
+ ushort chamr; /* Channel mode register */
+ uint tcrc; /* Temp transmit CRC */
+ uint rstate; /* Rx internal state */
+ uint zdstate; /* Zero-deletion machine state */
+ uint zddata0; /* Zero-deletion high word data buffer */
+ uint zddata1; /* Zero-deletion low word data buffer */
+ ushort rbdflags; /* RxBD flags */
+ ushort rbdcnt; /* Rx internal byte count */
+ uint rbdptr; /* Rx internal data pointer */
+ ushort mflr; /* Max. frame length register */
+ ushort max_cnt; /* Max_length counter */
+ uint rcrc; /* Temp. receive CRC */
+} mcc_chan_hdlc_t;
+
+
+/* MCC Configuration Register (MCCFx)
+ */
+#define MCC_MCCF_TDM_D ((u_char)0x03)
+#define MCC_MCCF_TDM_C ((u_char)0x02)
+#define MCC_MCCF_TDM_B ((u_char)0x01)
+#define MCC_MCCF_TDM_A ((u_char)0x00)
+
+
+/* MCC Event and Mask Register.
+ */
+#define MCCM_QOV0 ((ushort)0x8000) /* Rx int. queue overflow */
+#define MCCM_RINT0 ((ushort)0x4000) /* Rx interrupt */
+#define MCCM_QOV1 ((ushort)0x2000)
+#define MCCM_RINT1 ((ushort)0x1000)
+#define MCCM_QOV2 ((ushort)0x0800)
+#define MCCM_RINT2 ((ushort)0x0400)
+#define MCCM_QOV3 ((ushort)0x0200)
+#define MCCM_RINT3 ((ushort)0x0100)
+#define MCCM_TQOV ((ushort)0x0008) /* Tx int. queue overflow */
+#define MCCM_TINT ((ushort)0x0004) /* Tx interrupt */
+#define MCCM_GUN ((ushort)0x0002) /* Global tx underrun */
+#define MCCM_GOV ((ushort)0x0001) /* Global rx overrun */
+
+
+/* MCC Interrupt Table Entries.
+ */
+#define MCCI_V ((uint)0x80000000) /* Valid bit */
+#define MCCI_W ((uint)0x40000000) /* Wrap bit */
+#define MCCI_UN ((uint)0x02000000) /* Tx no data */
+#define MCCI_TXB ((uint)0x01000000) /* Tx buffer */
+#define MCCI_NID ((uint)0x00200000) /* Not idle pattern */
+#define MCCI_IDL ((uint)0x00100000) /* Idle */
+#define MCCI_MRF ((uint)0x00080000) /* Rx frame length violation */
+#define MCCI_RXF ((uint)0x00040000) /* Rx frame */
+#define MCCI_BSY ((uint)0x00020000) /* Busy */
+#define MCCI_RXB ((uint)0x00010000) /* Rx buffer */
+#define MCCI_CHAN ((uint)0x00003FC0) /* Channel number mask */
+
+
+/* MCC Receive Buffer Descriptor.
+ */
+#define BD_MCC_RX_E ((ushort)0x8000) /* Empty */
+#define BD_MCC_RX_W ((ushort)0x2000) /* Wrap */
+#define BD_MCC_RX_I ((ushort)0x1000) /* Interrupt */
+#define BD_MCC_RX_L ((ushort)0x0800) /* Last */
+#define BD_MCC_RX_F ((ushort)0x0400) /* First in frame */
+#define BD_MCC_RX_CM ((ushort)0x0200) /* Continuous mode */
+#define BD_MCC_RX_UB ((ushort)0x0080) /* User bit */
+#define BD_MCC_RX_LG ((ushort)0x0020) /* Frame length violation */
+#define BD_MCC_RX_NO ((ushort)0x0010) /* Nonoctet-aligned frame */
+#define BD_MCC_RX_AB ((ushort)0x0008) /* Abort sequence */
+#define BD_MCC_RX_CR ((ushort)0x0004) /* CRC error */
+
+
+/* MCC Transmit Buffer Descriptor.
+ */
+#define BD_MCC_TX_R ((ushort)0x8000) /* Ready */
+#define BD_MCC_TX_W ((ushort)0x2000) /* Wrap */
+#define BD_MCC_TX_I ((ushort)0x1000) /* Interrupt */
+#define BD_MCC_TX_L ((ushort)0x0800) /* Last */
+#define BD_MCC_TX_TC ((ushort)0x0400) /* CRC */
+#define BD_MCC_TX_CM ((ushort)0x0200) /* Continuous mode */
+#define BD_MCC_TX_UB ((ushort)0x0080) /* User bit */
+
+
/* How about some FCCs.....
*/
#define FCC_GFMR_DIAG_NORM ((uint)0x00000000)
^ permalink raw reply
* Re: bdi2000 debugging
From: Matej Kupljen @ 2005-02-16 12:20 UTC (permalink / raw)
To: Stefan Nickl; +Cc: linuxppc-embedded
In-Reply-To: <1108555596.12161.10.camel@lucy.pep-kaufbeuren.de>
Hi
> > I am trying to debug a problem in a user space application
> > (X windows), which when the process exits, crashes the kernel.
> > ---------------------------------------------------------------
> > Oops: Exception in kernel mode, sig: 4
> > NIP: 000003B4 XER: 00000000 LR: C002B540 SP: C3B8DD10 REGS: c3b8dc60
>
> Your dump says "sig: 4" (Illegal Instruction), which is different
> from what I see. I get signal 11 (segfault), this is why I'm looking
> after possible memory mapping issues.
>
> Are you sure you use the right compiler/flags for mpc5200
> when compiling the kernel and X?
Well, I think so, because everything else works.
Mplayer is especially peaky about the compiler, isn't it?
And it works.
Everything works, but when I quit X server, the kernel crashes :-(
NIP points to 000003B4?? Overwritten??
LR points to 0xc002b540 -- 0xc002b478 + 0x00c8 do_generic_file_write
SP seems good.
Still trying to locate it.
BR,
Matej
^ permalink raw reply
* Re: bdi2000 debugging
From: Stefan Nickl @ 2005-02-16 12:06 UTC (permalink / raw)
To: Matej Kupljen; +Cc: linuxppc-embedded
In-Reply-To: <1108547431.30212.37.camel@mbmatejdebian.ultra.si>
On Wed, 2005-02-16 at 10:50 +0100, Matej Kupljen wrote:
> Hi
>
> I am trying to debug a problem in a user space application
> (X windows), which when the process exits, crashes the kernel.
> ---------------------------------------------------------------
> Oops: Exception in kernel mode, sig: 4
> NIP: 000003B4 XER: 00000000 LR: C002B540 SP: C3B8DD10 REGS: c3b8dc60
Your dump says "sig: 4" (Illegal Instruction), which is different
from what I see. I get signal 11 (segfault), this is why I'm looking
after possible memory mapping issues.
Are you sure you use the right compiler/flags for mpc5200
when compiling the kernel and X?
--
Stefan Nickl
Kontron Modular Computers
^ permalink raw reply
* Re: Support for Adder875 in Linux 2.4
From: Jan Damborsky @ 2005-02-16 10:48 UTC (permalink / raw)
To: Markus Westergren; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.50.0502142045070.28518-100000@220a.licentiaten.umea.hsb.se>
[-- Attachment #1: Type: text/plain, Size: 411 bytes --]
Markus Westergren wrote:
>I got my board working with both ethernet ports today. I'm interested in your
>patch so that I can see if we made the same ugly hack and if I have overlocked
>something :)
>
>/Markus
>
>
The patch is here. I am sorry it has not been done against current denk
source tree,
I used the one from 19th January. But I hope it might satisfy for
understanding the way
the hack is done.
[-- Attachment #2: fec.diff --]
[-- Type: text/plain, Size: 8434 bytes --]
diff -purN linuxppc_2_4_devel-org/arch/ppc/8xx_io/fec.c linuxppc_2_4_devel-new/arch/ppc/8xx_io/fec.c
--- linuxppc_2_4_devel-org/arch/ppc/8xx_io/fec.c 2004-08-02 17:34:43.000000000 +0200
+++ linuxppc_2_4_devel-new/arch/ppc/8xx_io/fec.c 2005-02-15 21:36:09.000000000 +0100
@@ -181,6 +181,7 @@ typedef struct {
* the buffer descriptor determines the actual condition.
*/
struct fec_enet_private {
+ int irq_num;
/* The saved address of a sent-in-place packet/buffer, for skfree(). */
struct sk_buff* tx_skbuff[TX_RING_SIZE];
ushort skb_cur;
@@ -232,6 +233,10 @@ struct fec_enet_private {
#endif
};
+/* Initialize the FEC Ethernet on 860T and 2nd FEC on Duet.
+ */
+static int __init fec_enet_low_init(int ch);
+
static int fec_enet_open(struct net_device *dev);
static int fec_enet_start_xmit(struct sk_buff *skb, struct net_device *dev);
#ifdef CONFIG_USE_MDIO
@@ -250,7 +255,6 @@ static struct net_device_stats *fec_enet
static void set_multicast_list(struct net_device *dev);
static void fec_restart(struct net_device *dev, int duplex);
static void fec_stop(struct net_device *dev);
-static ushort my_enet_addr[3];
#ifdef CONFIG_USE_MDIO
static int fec_enet_ioctl(struct net_device *dev, struct ifreq *rq, int cmd);
@@ -2018,7 +2022,7 @@ static void set_multicast_list(struct ne
volatile fec_t *ep;
fep = (struct fec_enet_private *)dev->priv;
- ep = &(((immap_t *)IMAP_ADDR)->im_cpm.cp_fec);
+ ep = (volatile fec_t *)dev->base_addr;
if (dev->flags&IFF_PROMISC) {
@@ -2128,14 +2132,31 @@ static void set_multicast_list(struct ne
}
}
-/* Initialize the FEC Ethernet on 860T.
- */
int __init fec_enet_init(void)
{
+#ifdef CONFIG_FEC2_ENET
+ int ret;
+
+ if ((ret = fec_enet_low_init(0)) < 0)
+ return(ret);
+
+ return(fec_enet_low_init(1));
+#else
+ return(fec_enet_low_init(0));
+#endif
+} /* end of fec_enet_init() */
+
+/* Initialize the FEC Ethernet on 860T and 2nd FEC on Duet.
+ */
+static int __init
+fec_enet_low_init(
+ int ch)
+{
struct net_device *dev;
struct fec_enet_private *fep;
int i, j, k;
- unsigned char *eap, *iap, *ba;
+
+ unsigned char *iap, *ba;
dma_addr_t mem_addr;
volatile cbd_t *bdp;
cbd_t *cbd_base;
@@ -2162,7 +2183,10 @@ int __init fec_enet_init(void)
*/
dev = init_etherdev(0, 0);
+ if (ch == 0)
fecp = &(immap->im_cpm.cp_fec);
+ else
+ fecp = &(immap->im_cpm.cp_fec2);
/* Whack a reset. We should wait for this.
*/
@@ -2179,7 +2203,7 @@ int __init fec_enet_init(void)
/* Set the Ethernet address. If using multiple Enets on the 8xx,
* this needs some work to get unique addresses.
*/
- eap = (unsigned char *)my_enet_addr;
+
iap = bd->bi_enetaddr;
#ifdef CONFIG_SCC_ENET
@@ -2201,12 +2225,15 @@ int __init fec_enet_init(void)
tmpaddr[3] |= 0x80;
# endif
iap = tmpaddr;
-#endif
+#endif /* CONFIG_SCC_ENET */
for (i=0; i<6; i++) {
- dev->dev_addr[i] = *eap++ = *iap++;
+ dev->dev_addr[i] = *iap++;
}
+ if (ch == 1)
+ dev->dev_addr[3] ^= 0x01;
+
/* Allocate memory for buffer descriptors.
*/
if (((RX_RING_SIZE + TX_RING_SIZE) * sizeof(cbd_t)) > PAGE_SIZE) {
@@ -2258,8 +2285,15 @@ int __init fec_enet_init(void)
fep->ph_priv = NULL;
#endif
/* Install our interrupt handler. */
+ if (ch == 0) {
+ fep->irq_num = FEC_INTERRUPT;
if (request_irq(FEC_INTERRUPT, fec_enet_interrupt, 0, "fec", dev) != 0)
panic("Could not allocate FEC IRQ!");
+ } else {
+ fep->irq_num = FEC2_INTERRUPT;
+ if (request_irq(FEC2_INTERRUPT, fec_enet_interrupt, 0, "fec2", dev) != 0)
+ panic("Could not allocate FEC2 IRQ!");
+ }
dev->base_addr = (unsigned long)fecp;
dev->priv = fep;
@@ -2316,6 +2350,33 @@ int __init fec_enet_init(void)
mii_free = mii_cmds;
#endif /* CONFIG_USE_MDIO */
+/* MPC87x/88x have got 2 FECs and different pinout */
+#if defined(CONFIG_TS3_DUET)
+ if (ch == 0) {
+ immap->im_ioport.iop_papar |= 0xf830;
+ immap->im_ioport.iop_padir |= 0x0830;
+ immap->im_ioport.iop_padir &= ~0xf000;
+
+ immap->im_cpm.cp_pbpar |= 0x00001001;
+ immap->im_cpm.cp_pbdir &= ~0x00001001;
+
+ immap->im_ioport.iop_pcpar |= 0x000c;
+ immap->im_ioport.iop_pcdir &= ~0x000c;
+
+ immap->im_cpm.cp_pepar |= 0x00000003;
+ immap->im_cpm.cp_pedir |= 0x00000003;
+ immap->im_cpm.cp_peso &= ~0x00000003;
+
+ immap->im_cpm.cp_cptr &= ~0x00000100;
+ } else {
+ immap->im_cpm.cp_pepar |= 0x0003fffc;
+ immap->im_cpm.cp_pedir |= 0x0003fffc;
+ immap->im_cpm.cp_peso &= ~0x000087fc;
+ immap->im_cpm.cp_peso |= 0x00037800;
+
+ immap->im_cpm.cp_cptr &= ~0x00000080;
+ } /*endif*/
+#else
#ifndef CONFIG_ICU862
/* Configure all of port D for MII.
*/
@@ -2355,6 +2416,7 @@ int __init fec_enet_init(void)
immap->im_ioport.iop_pddir = 0x1c58; /* Pre rev. D */
else
immap->im_ioport.iop_pddir = 0x1fff; /* Rev. D and later */
+#endif /* CONFIG_TS3_DUET */
#ifdef CONFIG_USE_MDIO
/* Set MII speed to 2.5 MHz
@@ -2373,7 +2435,10 @@ int __init fec_enet_init(void)
", MII irq %d"
#endif
", addr ",
- dev->name, FEC_INTERRUPT
+
+ dev->name,
+ fep->irq_num
+
#ifdef PHY_INTERRUPT
, PHY_INTERRUPT
#endif
@@ -2411,12 +2476,9 @@ fec_restart(struct net_device *dev, int
struct fec_enet_private *fep;
int i;
volatile cbd_t *bdp;
- volatile immap_t *immap;
volatile fec_t *fecp;
- immap = (immap_t *)IMAP_ADDR; /* pointer to internal registers */
-
- fecp = &(immap->im_cpm.cp_fec);
+ fecp = (volatile fec_t *)dev->base_addr;
fep = dev->priv;
@@ -2439,8 +2501,9 @@ fec_restart(struct net_device *dev, int
/* Set station address.
*/
- fecp->fec_addr_low = (my_enet_addr[0] << 16) | my_enet_addr[1];
- fecp->fec_addr_high = my_enet_addr[2];
+ fecp->fec_addr_low = (dev->dev_addr[0] << 24) | (dev->dev_addr[1] << 16)
+ | (dev->dev_addr[2] << 8) | (dev->dev_addr[3] << 0);
+ fecp->fec_addr_high = (dev->dev_addr[4] << 8) | dev->dev_addr[5];
/* Reset all multicast.
*/
@@ -2531,7 +2594,7 @@ fec_restart(struct net_device *dev, int
*/
fecp->fec_ievent = 0xffc0;
- fecp->fec_ivec = (FEC_INTERRUPT/2) << 29;
+ fecp->fec_ivec = (fep->irq_num/2) << 29;
/* Enable interrupts we wish to service.
*/
@@ -2552,21 +2615,17 @@ fec_restart(struct net_device *dev, int
static void
fec_stop(struct net_device *dev)
{
- volatile immap_t *immap;
volatile fec_t *fecp;
struct fec_enet_private *fep;
int i;
- immap = (immap_t *)IMAP_ADDR; /* pointer to internal registers */
-
- fecp = &(immap->im_cpm.cp_fec);
+ fecp = (volatile fec_t *)dev->base_addr;
if ((fecp->fec_ecntrl & FEC_ECNTRL_ETHER_EN) == 0)
return; /* already down */
fep = dev->priv;
-
fecp->fec_x_cntrl = 0x01; /* Graceful transmit stop */
for (i = 0;
@@ -2584,7 +2643,8 @@ fec_stop(struct net_device *dev)
/* Enable MII command finished interrupt
*/
- fecp->fec_ivec = (FEC_INTERRUPT/2) << 29;
+ fecp->fec_ivec = (fep->irq_num/2) << 29;
+
fecp->fec_imask = FEC_ENET_MII;
#ifdef CONFIG_USE_MDIO
diff -purN linuxppc_2_4_devel-org/include/asm-ppc/8xx_immap.h linuxppc_2_4_devel-new/include/asm-ppc/8xx_immap.h
--- linuxppc_2_4_devel-org/include/asm-ppc/8xx_immap.h 2004-08-02 17:40:47.000000000 +0200
+++ linuxppc_2_4_devel-new/include/asm-ppc/8xx_immap.h 2005-02-15 21:09:22.000000000 +0100
@@ -9,6 +9,7 @@
* a combination that I found difficult to separate into logical
* functional files.....but anyone else is welcome to try. -- Dan
*/
+
#ifdef __KERNEL__
#ifndef __IMMAP_8XX__
#define __IMMAP_8XX__
@@ -426,8 +427,21 @@ typedef struct comm_proc {
uint cp_pbpar;
char res12[2];
ushort cp_pbodr;
- uint cp_pbdat;
- char res13[0x18];
+ uint cp_pbdat;
+
+ /*
+ * Port E - MPC87x/88x only.
+ */
+ uint cp_pedir;
+ uint cp_pepar;
+ uint cp_peso;
+ uint cp_peodr;
+ uint cp_pedat;
+
+ /* Communications Processor Timing Register -
+ Contains RMII Timing for the FECs on MPC87x/88x only.
+ */
+ uint cp_cptr;
/* Serial Interface and Time Slot Assignment.
*/
@@ -454,7 +468,12 @@ typedef struct comm_proc {
union fec_lcd fl_un;
#define cp_fec fl_un.fl_un_fec
#define lcd_cmap fl_un.fl_un_cmap
- char res18[0x1000];
+
+ char res18[0xE00];
+
+ /* The DUET family has a second FEC here */
+ fec_t cp_fec2;
+#define cp_fec1 cp_fec /* consistency macro */
/* Dual Ported RAM follows.
* There are many different formats for this memory area
^ permalink raw reply
* Re: bdi2000 debugging
From: Hans Thielemans @ 2005-02-16 10:15 UTC (permalink / raw)
To: Matej Kupljen; +Cc: linuxppc-embedded
In-Reply-To: <1108547431.30212.37.camel@mbmatejdebian.ultra.si>
On Wed, 16 Feb 2005, Matej Kupljen wrote:
> Hi
>
> I am trying to debug a problem in a user space application
> (X windows), which when the process exits, crashes the kernel.
> ---------------------------------------------------------------
> Oops: Exception in kernel mode, sig: 4
> NIP: 000003B4 XER: 00000000 LR: C002B540 SP: C3B8DD10 REGS: c3b8dc60
> TRAP: 0700 Not tainted
> MSR: 00081000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> TASK = c3b8c000[55] 'Xorg.strip' Last syscall: 146
> last math c36aa000 last altivec 00000000
> GPR00: 00000000 C3B8DD10 C3B8C000 C3B8DD20 30105D0C 20000000 C3B8DDE0
> 00136DA8
> GPR08: 00136DA8 00000000 00000035 000081A4 24048424 1031688C C0200000
> C3B8DDE0
> GPR16: C0200000 C3B7F3E0 00000000 0C3B80C5 00001032 03B8DD10 C002B580
> 00009032
> GPR24: 00000035 00000000 00000FCB C3B80C50 00136DA8 00000000 00000035
> C3B80C10
> Call backtrace:
> C0200000 C002B540 C002BCE8 C0090A58 C0039B64 C0039DCC C0005A7C
> 00000000 0FE20BFC 0FE29878 0FE29D1C 0FE29DE8 0FD7E354 0FD65D78
> 00000000
> Oops: Exception in kernel mode, sig: 4
> NIP: 000003B4 XER: 20000000 LR: 0FDF527C SP: C3BAFF40 REGS: c3baff50
> TRAP: 0700 Not tainted
> MSR: 00081000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> TASK = c3bae000[54] 'run_xorg.sh' Last syscall: 114
> last math c36aa000 last altivec 00000000
> GPR00: 00000000 C3BAFF40 30012738 C3BAFF50 0FEF1C6C 20000000 00000000
> 7F7F0000
> GPR08: FFFFFFFD 00000000 1015E4CC 00000000 44000828 10094078 00000000
> 00000000
> GPR16: 00000000 00000000 00000005 7FFFFA20 00001032 03BAFF40 0FE49374
> 0000D032
> GPR24: 1009949C 00000000 00000003 00000000 7FFFFF8F 0FF0B59C 0FF09120
> 7FFFF8B0
> Call backtrace:
> C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8
> C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8
> C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8
> C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8
> C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8
> ---------------------------------------------------------------
>
> And that goes on for every process running :-(
>
> Something is overwriting memory in kernel space I guess.
> Now, I have the BDI 2000 and I am trying to debug this, but until
> now I was unsuccessful :-(
>
> When I debug the kernel, the BDI prints this out in the telnet
> interface:
> - Target MBAR is 0xF0000000
> - Target XLBA is 0x8000A366
>
> I know what MBAR is, but what the XLBA is?
I would assume this is the XLB arbiter register.
> The problem is that while this value remains the same everything
> is fine. But sometimes it is set to 0x00000000 and then I cannot
> use debugger anymore. I can make a few steps when this value
> is set to 0x0, but the "stepping" is done in completely unrelated
> code. I first noticed this while stepping trough hc_found_ohci
> function when the return 0 is executed. When I disabled the USB
> support in my kernel I could use debugger to debug a kernel.
> But is still does not work all the time, because the XLBA still
> gets set to 0!
>
> I am using CVS version of DENX kernel version 2.4.25.
>
> Has anybody seen this?
>
> Maybe a tip how to debug this problem?
>
> Best regards,
> Matej
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Incomplete network configuration information when booting from NFS root on Ebony
From: Eugene Surovegin @ 2005-02-16 10:27 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b05021518037b1758cc@mail.gmail.com>
On Tue, Feb 15, 2005 at 06:03:12PM -0800, Shawn Jin wrote:
> zmii0: input 0 in SMII mode
...
> zmii0: input 1 in RMII mode
BTW, this is wrong. All inputs must be in the same mode. This is not a
cause for you current problem, but will be the next one :).
--
Eugene
^ permalink raw reply
* Re: Incomplete network configuration information when booting fro m NFS root on Ebony
From: Eugene Surovegin @ 2005-02-16 10:18 UTC (permalink / raw)
To: Demke Torsten-atd012; +Cc: ppcembed
In-Reply-To: <43395BE65409D911B9FF00110A9BFFDCDF4EF4@zwg57exm01.ea.mot.com>
On Wed, Feb 16, 2005 at 11:09:10AM +0100, Demke Torsten-atd012 wrote:
> is this correct?
> nfsroot=192.68.0.47:/opt/eldk3.1/ppc_4xx
> ^^
> ip=192.168.0.245:192.168.0.47:::::off
> ^^^
>
> Why does your kernel uses the IP address 130.27.84.47
> (where comes this address from?), but not the IP address from u-boot?
[snip]
> > IP-Config: Incomplete network configuration information.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That's why. This is what original poster was asking, actually :)
--
Eugene
^ permalink raw reply
* bdi2000 debugging
From: Matej Kupljen @ 2005-02-16 9:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi
I am trying to debug a problem in a user space application
(X windows), which when the process exits, crashes the kernel.
---------------------------------------------------------------
Oops: Exception in kernel mode, sig: 4
NIP: 000003B4 XER: 00000000 LR: C002B540 SP: C3B8DD10 REGS: c3b8dc60
TRAP: 0700 Not tainted
MSR: 00081000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK = c3b8c000[55] 'Xorg.strip' Last syscall: 146
last math c36aa000 last altivec 00000000
GPR00: 00000000 C3B8DD10 C3B8C000 C3B8DD20 30105D0C 20000000 C3B8DDE0
00136DA8
GPR08: 00136DA8 00000000 00000035 000081A4 24048424 1031688C C0200000
C3B8DDE0
GPR16: C0200000 C3B7F3E0 00000000 0C3B80C5 00001032 03B8DD10 C002B580
00009032
GPR24: 00000035 00000000 00000FCB C3B80C50 00136DA8 00000000 00000035
C3B80C10
Call backtrace:
C0200000 C002B540 C002BCE8 C0090A58 C0039B64 C0039DCC C0005A7C
00000000 0FE20BFC 0FE29878 0FE29D1C 0FE29DE8 0FD7E354 0FD65D78
00000000
Oops: Exception in kernel mode, sig: 4
NIP: 000003B4 XER: 20000000 LR: 0FDF527C SP: C3BAFF40 REGS: c3baff50
TRAP: 0700 Not tainted
MSR: 00081000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK = c3bae000[54] 'run_xorg.sh' Last syscall: 114
last math c36aa000 last altivec 00000000
GPR00: 00000000 C3BAFF40 30012738 C3BAFF50 0FEF1C6C 20000000 00000000
7F7F0000
GPR08: FFFFFFFD 00000000 1015E4CC 00000000 44000828 10094078 00000000
00000000
GPR16: 00000000 00000000 00000005 7FFFFA20 00001032 03BAFF40 0FE49374
0000D032
GPR24: 1009949C 00000000 00000003 00000000 7FFFFF8F 0FF0B59C 0FF09120
7FFFF8B0
Call backtrace:
C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8
C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8
C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8
C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8
C0005CC8 C0005CC8 C0005CC8 C0005CC8 C0005CC8
---------------------------------------------------------------
And that goes on for every process running :-(
Something is overwriting memory in kernel space I guess.
Now, I have the BDI 2000 and I am trying to debug this, but until
now I was unsuccessful :-(
When I debug the kernel, the BDI prints this out in the telnet
interface:
- Target MBAR is 0xF0000000
- Target XLBA is 0x8000A366
I know what MBAR is, but what the XLBA is?
The problem is that while this value remains the same everything
is fine. But sometimes it is set to 0x00000000 and then I cannot
use debugger anymore. I can make a few steps when this value
is set to 0x0, but the "stepping" is done in completely unrelated
code. I first noticed this while stepping trough hc_found_ohci
function when the return 0 is executed. When I disabled the USB
support in my kernel I could use debugger to debug a kernel.
But is still does not work all the time, because the XLBA still
gets set to 0!
I am using CVS version of DENX kernel version 2.4.25.
Has anybody seen this?
Maybe a tip how to debug this problem?
Best regards,
Matej
^ permalink raw reply
* RE: Incomplete network configuration information when booting fro m NFS root on Ebony
From: Demke Torsten-atd012 @ 2005-02-16 10:09 UTC (permalink / raw)
To: Shawn Jin, ppcembed
Hi,
is this correct?
nfsroot=192.68.0.47:/opt/eldk3.1/ppc_4xx
^^
ip=192.168.0.245:192.168.0.47:::::off
^^^
Why does your kernel uses the IP address 130.27.84.47
(where comes this address from?), but not the IP address from u-boot?
Torsten
> -----Original Message-----
> From: linuxppc-embedded-bounces@ozlabs.org
> [mailto:linuxppc-embedded-bounces@ozlabs.org]On Behalf Of Shawn Jin
> Sent: Mittwoch, 16. Februar 2005 03:03
> To: ppcembed
> Subject: Incomplete network configuration information when
> booting from
> NFS root on Ebony
>
>
> Hi,
>
> Is anybody using linux-2.6.10 from kernel.org for testing IBM
> Ebony board?
>
> I found that 2.6.10 is not aware of U-Boot. That is, it neither
> understands U-Boot's bd_info nor parses U-Boot's bootargs. So even if
> the ethernet MAC address is set for EMAC0 on uboot, the kernel doesn't
> get the value from it. Instead it reads MAC address from Ebony VPD,
> which results in FF:FF:FF:FF:FF:FF. Isn't it strange that mac address
> isn't set in its VPD?
>
> After some hacks in arch/ppc/platforms/4xx/ebony.c, the kernel now can
> get MAC address and boot arguments from uboot. However a new problem
> occurs. When the kernel tries to mount a NFS root filesystem, it
> complains incomplete network configuration information. See the
> following message dump. Any hints to solve the problem? Thanks a lot.
>
> ## Transferring control to Linux (at address 00000000) ...
> Linux version 2.6.10 (xjin@swl001.scs.agilent.com) (gcc version 3.3.3
> (DENX ELDK 3.1 3.3.3-8)) #11 T
> ue Feb 15 16:41:47 PST 2005
> IBM Ebony port (MontaVista Software, Inc. (source@mvista.com))
> Built 1 zonelists
> Kernel command line: root=/dev/nfs rw
> nfsroot=192.68.0.47:/opt/eldk3.1/ppc_4xx
> ip=192.168.0.245:192.168.0.47:::::off
>
> <snipped>
>
> mal0: Initialized, 4 tx channels, 2 rx channels
> emac: IBM EMAC Ethernet driver, version 2.0
> Maintained by Benjamin Herrenschmidt <benh@kernel.crashing.org>
> zmii0: input 0 in SMII mode
> eth0: IBM emac, MAC 00:04:ac:e3:1b:bb
> eth0: Found Generic MII PHY (0x08)
> zmii0: input 1 in RMII mode
> eth1: IBM emac, MAC FF:FF:FF:FF:FF:FF
> eth1: Found Generic MII PHY (0x09)
>
> <--- only eth0's mac address is set on uboot -->
>
> mice: PS/2 mouse device common for all mice
> NET: Registered protocol family 2
> IP: routing cache hash table of 1024 buckets, 8Kbytes
> TCP: Hash tables configured (established 8192 bind 16384)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> eth0: Link is Up
> eth0: Speed: 100, Full duplex.
> IP-Config: Incomplete network configuration information.
>
> ????
>
> Looking up port of RPC 100003/2 on 130.27.84.47
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get nfsd port number from server, using default
> Looking up port of RPC 100005/1 on 130.27.84.47
> RPC: sendmsg returned error 101
> portmap: RPC call returned error 101
> Root-NFS: Unable to get mountd port number from server, using default
> RPC: sendmsg returned error 101
> mount: RPC call returned error 101
> Root-NFS: Server returned error -101 while mounting
> /opt/eldk3.1/ppc_4xx
> VFS: Unable to mount root fs via NFS, trying floppy.
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(2,0)
> <0>Rebooting in 180 seconds..<6>eth0: Link is Up
> eth0: Speed: 100, Full duplex.
>
> -Shawn.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: uart.c: avoid changing parameter RAM on-the-fly for the console
From: Steffen Rumler @ 2005-02-16 9:56 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc
In-Reply-To: <754ecc31c2497b32a0c3f6df5ce21881@embeddededge.com>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
Dan Malek wrote:
>
> On Feb 3, 2005, at 10:17 AM, Steffen Rumler wrote:
>
>> According to Motorola this is _NOT_ allowed and dangerous.
>
>
> :-) yeah, ok ...
>
>> I suggest to do this inside rs_8xx_init() and startup() as shown
>> in the patch below.
>
>
> would you please read Documentation/CodingStyle and
> try sending the patch again?
>
> Although it doesn't make too much difference in this case,
> 2.4.20 is pretty old and it helps to get patches against
> the latest kernels.
>
>> With this fix, the modules hanging before can boot now.
>
>
> I suspect there is something else amiss, but I'll take a
> look at it. What is the speed of the processor and the
> baud rate?
Hi Dan,
have you checked this problem in detail now ?
Unfortunately, I have forgotten the 'INIT RX TX' inside
my patched startup() (see new patch attached).
Sorry.
Thank you for help. The serial driver is rather complex.
Please, can you look into this (ignoring coding style at this time).
Steffen
--
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 3216 bytes --]
diff -Naur old/arch/ppc/8xx_io/uart.c new/arch/ppc/8xx_io/uart.c
--- old/arch/ppc/8xx_io/uart.c Wed Feb 16 10:43:24 2005
+++ new/arch/ppc/8xx_io/uart.c Wed Feb 16 10:42:01 2005
@@ -119,6 +119,11 @@
static int uart_buf_read_proc (char *, char **, off_t, int, int *, void *);
#endif
+#ifdef CONFIG_SERIAL_CONSOLE
+static void full_seq_smc_stop (int port);
+static void smc_init_rx_tx (int port);
+#endif
+
/*
* Serial driver configuration section. Here are the various options:
*/
@@ -831,10 +836,17 @@
else {
smcp = &cpmp->cp_smc[idx];
+#ifdef CONFIG_SERIAL_CONSOLE
+ /* stop SMC in the correct way, before re-configuring it
+ */
+ if (((state - rs_table) == CONFIG_SERIAL_CONSOLE_PORT)){
+ full_seq_smc_stop(PORT_NUM(info->state->smc_scc_num));
+ }
+#endif
+
/* Enable interrupts and I/O.
*/
smcp->smc_smcm |= (SMCM_RX | SMCM_TX);
- smcp->smc_smcmr |= (SMCMR_REN | SMCMR_TEN);
/* We can tune the buffer length and idle characters
* to take advantage of the entire incoming buffer size.
@@ -848,6 +860,17 @@
up->smc_mrblr = RX_BUF_SIZE;
up->smc_maxidl = RX_BUF_SIZE;
up->smc_brkcr = 1; /* number of break chars */
+
+#ifdef CONFIG_SERIAL_CONSOLE
+ if (((state - rs_table) == CONFIG_SERIAL_CONSOLE_PORT)){
+
+ smc_init_rx_tx(PORT_NUM(info->state->smc_scc_num));
+ info->rx_cur = info->rx_bd_base;
+ info->tx_cur = info->tx_bd_base;
+ }
+#endif
+
+ smcp->smc_smcmr |= (SMCMR_REN | SMCMR_TEN);
}
info->flags |= ASYNC_INITIALIZED;
@@ -2694,6 +2717,46 @@
} /* end uart_removeProcEntries() */
+
+#ifdef CONFIG_SERIAL_CONSOLE
+static void full_seq_smc_stop (int port)
+{
+ volatile cpm8xx_t *cp=cpmp;
+ volatile smc_t *sp;
+ ushort chan;
+ unsigned long flags;
+
+ sp = &cp->cp_smc[port];
+ chan = smc_chan_map[port];
+
+ local_irq_save(flags);
+
+ while (cp->cp_cpcr & CPM_CR_FLG);
+ cp->cp_cpcr = mk_cr_cmd(chan, CPM_CR_STOP_TX) | CPM_CR_FLG;
+ while (cp->cp_cpcr & CPM_CR_FLG);
+ sp->smc_smcmr &= ~(SMCMR_REN | SMCMR_TEN);
+
+ local_irq_restore(flags);
+
+} /* full_seq_smc_stop */
+
+static void smc_init_rx_tx (int port)
+{
+ unsigned long flags;
+ volatile cpm8xx_t *cp=cpmp;
+ ushort chan;
+
+ chan = smc_chan_map[port];
+
+ local_irq_save(flags);
+ while (cp->cp_cpcr & CPM_CR_FLG);
+ cp->cp_cpcr = mk_cr_cmd(chan, CPM_CR_INIT_TRX) | CPM_CR_FLG;
+ while (cp->cp_cpcr & CPM_CR_FLG);
+ local_irq_restore(flags);
+
+} /* smc_init_rx_tx */
+#endif /* CONFIG_SERIAL_CONSOLE */
+
/*
* The serial driver boot-time initialization code!
*/
@@ -2905,6 +2968,15 @@
}
else {
sp = &cp->cp_smc[idx];
+
+#ifdef CONFIG_SERIAL_CONSOLE
+ /* stop SMC in the correct way, before re-configuring it
+ */
+ if (i == CONFIG_SERIAL_CONSOLE_PORT){
+ full_seq_smc_stop(idx);
+ }
+#endif
+
up = (smc_uart_t *)&cp->cp_dparam[state->port];
up->smc_rbase = dp_addr;
}
^ permalink raw reply
* RE: Mounta Vista Linux prompt on serial console
From: srinivas.surabhi @ 2005-02-16 3:18 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
>> Do not ignore this error. How big is your cramfs image? How much
RAM
>> do you have?
cramfs is 2.7MB where as the RAM size is 32MB. While building ofcourse
the RAMDISK size was told as 8MB. This I mentioned in the devrocket
kernel configuration.
Just FYI. Kernel Image was 640KB.
Here I have one doubt while building the uBoot image using mkImage with
multi option where was the FileSystem image getting downloaded ? and how
the downloaded location was known to the kernel Image for pointing out
the File System image location. The options -a and -e are applicable
only for first image, isn't it? First image I mean the kernel Image. I
was giving -a 0x0 and -e 0x0 since while building the kernel the kernel
base address was mentioned 0.
...
>> Is there any chance that you built your cramfs image on a x08 (or any
>> other little-endian) system and forgot to give the "-r" (reverse
>> endian-ness of filesystem) option to mkcramfs??
YES. You are right I am building the image on x86 (Windows platform).
But I checked the build log it used the -r option. The default build was
cpio format and after that using fstool converting to CRAMS and the
option -r was present .I believe that devrocket of MountaVista has
makefiles specific to OS i.e for Windows, because while installation it
asks for what type of OS do you want to have the Image Development
environment.
Thanks & Regards
Surabhi Srinivas
-----Original Message-----
From: wd@denx.de [mailto:wd@denx.de]=0D
Sent: Wednesday, February 16, 2005 1:30 AM
To: Srinivas Surabhi (WT01 - EMBEDDED & PRODUCT ENGINEERING SOLUTIONS)
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Mounta Vista Linux prompt on serial console=0D
In message
<EF9B29C78F41FA488927FCBC7750AF0E011DA5CB@hyd-mdp-msg.wipro.com> you
wrote:
>=0D
> My replies in blue tagged with surabhi
Don't do this. Email is a plain text medium only.
Read the netiquette, and quote properly.
> [surabhi --- start] could you please guide me how to provide a working
> file system on SDRAM before decompressing the Linux Image on SDRAM. Is
> it really related to init process failed.
It is obviously related -there was a clear error message that the
uncompressing of the cramfs filesystem failed.
> Is the below doesn't mean that the mounted one is working one ?
> "VFS: Mounted root (cramfs filesystem) readonly.
> Mounted devfs on /dev "
No, not at all. You can for example mount an empty filesystem - it
will mount perfectly fine, but it still doesn't work.
You should also read my message until the end; I asked:
>> Do not ignore this error. How big is your cramfs iage? How much RAM
>> do you have?
cramfs is 2.7MB where as the RAM size is 32MB. While building ofcourse
the RAMDISK size was told as 8MB. This I mentioned in the devrocket
kernel configuration.
...
>> Is there any chance that you built your cramfs image on a x08 (or any
>> other little-endian) system and forgot to give the "-r" (reverse
>> endian-ness of filesystem) option to mkcramfs??
YES. You are right I am building the image on x86 (Windows platform).
But I checked the build log it used the -r option. The default build was
cpio format and after that using fstool converting to CRAMS and the
option -r was present .I believe that devrocket of MountaVista has
makefiles specific to OS i.e for Windows, because while installation it
asks for what type of OS do you want to have the Image Development
environment.
Thanks & Regards
Surabhi Srinivas
=0D
Best regards,
Wolfgang Denk
--=0D
See us @ Embedded World, Nuremberg, Feb 22 - 24, Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Looks clean and obviously correct to me, but then _everything_ I
write always looks obviously correct to me. - Linus Torvalds in
<Pine.LNX.4.10.10012090054360.791-100000@penguin.transmeta.com>
Confidentiality Notice=0D
The information contained in this electronic message and any attachments to=
this message are intended
for the exclusive use of the addressee(s) and may contain confidential or=
privileged information. If
you are not the intended recipient, please notify the sender at Wipro or=
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
^ 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