ocp emac phy wierdness
On Thu, Aug 22, 2002 at 11:09:19AM -0700, Armin Kuster wrote: David, The whole phy idea back when I did it was modeled after the fec.c driver with the thought that at some point we could merge all phy_info structs into a common file. The same idea was applied to the mii routines. I noticed that code/information is duplicated in a few ethernet drivers in ppc. Some of the what you see will be used when we add link support driver, some of the 4xx boards with zmii bridges have interrupt capability. The phy implementation is a project that is not completed. :) By all means share the phy_info structures between ethernet drivers. That doesn't explain why: a) We queue the various phy operations, then process the queue, rather than just stepping through the commands as soon as requested. b) Why the queue is processed with schedule_task(), rather than directly inline. David Gibson wrote: There seems to be a whole lot of stuff related to phy handling with no clear purpose to it. The table phy_cmd_config appears to be unused, as are the functions mii_queue_config, mii_display_config. Furthermore process_mii_queue() is dispatched through schedule_task(), from mii_queue_schedule(). But the only place that is called is in ppc405_enet_open(), which immediately calls schedule() to wait for the job to be completed. So what the hell is the point of the schedule_task() rigmarole? -- David Gibson| For every complex problem there is a david at gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Consulting - Motorola MPC860T design verification
Hi everybody, I'm designing a custom board based on an MPC860T processor (MPC860T, flash, SDRAM, serial ports, LTX971A and SpartanII). I'm looking for someone who could verify my design (you would of course be paid for the service). The schematic capture tool I use is Protel. Thanks in advance. Laurent Pinchart ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linux booting
hi,WD There are some more hints at http://www.denx.de/doc/TQM8xxL/debugging.html I have read it before,but only for module or application, not for kernel and ppcboot,someone told me because of ppcboot's relocation,so it is difficult in some externd. Anyway it helps some:) I want to watch r3,r4,r5,r6,r7 register when ppcboot transferring to kernel.Could you tell me how to get that? thanks a lot! Start PPCBoot, setup bootargs etc., load the kernel image. Before finally typing the bootm command set a (hardware) breakpoint at the kernel entry point (= physical address 0x). When hitting the breakpoint, print the registers... Yes,it works:),and I can check thoes regs when entering kernel. and I am sure ppcboot handle correct value to kernel now. the kernel can boot and I can see some in the console now. I replaced the ppcboot.h in the 1.1.6 with one in old version so I think it is still bdinfo problem. However,new ones come: kernel can not find init in the ramdisk! the initrd had been tested in the old kernel and can mount fs and entering system.so a little strange:( the only reason I am wondering is the compiler! the file in the initrd were compiled with HHL1.2 ppc compiler. and the kernel was created with eldk. Is that make sense? leeyang ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linux booting
Hi, in message 000901c24cfd$de617140$0141b73d at leeyang you wrote: http://www.denx.de/doc/TQM8xxL/debugging.html I have read it before,but only for module or application, not for kernel and ppcboot,someone told me because of ppcboot's relocation,so it is difficult in some externd. See the Q+A section However,new ones come: kernel can not find init in the ramdisk! the initrd had been tested in the old kernel and can mount fs and entering system.so a little strange:( the only reason I am wondering is the compiler! the file in the initrd were compiled with HHL1.2 ppc compiler. and the kernel was created with eldk. Is that make sense? That should be no problem. Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de The nice thing about standards is, there are so many to choose from. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
NFS root thru PPP
Have anybody experience with NFS root using PPP ? I have ported 2.4.18 kernel to a factory developed 850 board. It has two serial port but no ETH (the next version will have one). How can I use the 2nd serial as NFS root dev? Ludwig ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IBM 440GP 36-bit addressing
On Sat, 2002-08-24 at 02:05, Vishwanath wrote: By going through the code, I understood that ioremap64() is used for mapping the 36-bit real address onto 32-bit effective address space. How this mapping information is conveyed to user applications ? I don't understand the question. Do you mean how does userspace know what the kernel has ioremapped? I don't think it does. Do you mean how can userspace map in a 36-bit real address? The usual (32-bit) way is to mmap(/dev/mem). I don't know if that will work with 36-bit addresses. If I am writing assembly instructions to access 440GP registers, do I have to pass 36-bit real address or 32-bit effective address ? Do you mean a memory-mapped register, i.e. an on-chip peripheral like the UART? If so, that's what we've been talking about. You must map the 36-bit real address into your 32-bit effective address space, then access the effective address. Physical address map of 440GP provides information only about Real addresses. How can I convert these real addresses onto effective addresses ? Do I have to write a TLB entry regarding my addresses ? Exactly, that's what I mean by mapping. Of course, some TLB entries may already have been set up for you by the kernel or firmware. Whatever the case, you need to make sure there is a TLB entry in place. -Hollis ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IBM 440GP 36-bit addressing
Hollis, At 08:48 AM 8/26/2002, you wrote: The usual(32-bit) way is to mmap(/dev/mem). I don't know if that will work with 36-bit addresses. It will work only for first 4G of physical address space. /dev/mem cannot be used to access EPB/OCP or PCI address space on 440. For this purpose /dev/mem-like device can be easily written that takes into account 36-bit phys addresses. Thanks, Eugene Surovegin mailto:ebs at innocent.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
LXT972 FEC problem on MPC855
After running ppcboot on our board successfully (including the fast ethernet LXT972), we have trouble on enabling FEC on linux kernel. The problem is that we cannot send any packets through the network after the kernel is booted. The ethernet looks OK during initialization according to the printed messages. We are trying to locate the problem but haven't found yet so far. Any hints on what caused such problem? The booting messages are as follows, -duing initialization- eth0: FEC ENET Version 0.2, FEC irq 9, MII irq 10, addr 00:06:17:01:02:00 eth0: Phy @ 0x0, type LXT971 (0x001378e2) -duing initialization- -Stack init (I guess)- NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. IP-Config: Incomplete network configuration information. NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. -Stack init (I guess)- Using FLUKE to test the ethernet interface, it looks OK. No problem is reported. But we couldn't see any packets transmitted out by the interface. Have you encountered such problem before? Any hints will be greatly appreciated. Thanks a lot. My configuration on kernel (linux-2.4.4-08-09 from DENX) is 860T FEC Ethernet Use MDIO for PHY configuration Support LXT971 PHY BTW, if I disable Use MDIO for PHY configuration, after I ping an address, it'll dump data in TX ring buffer. If those data will help to diagnose the problem, I'll paste them later. - Shawn. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
LXT972 FEC problem on MPC855
In message 3D6A6D9D.20404 at redswitch.com you wrote: After running ppcboot on our board successfully (including the fast ethernet LXT972), we have trouble on enabling FEC on linux kernel. The problem is that we cannot send any packets through the network after the kernel is booted. The ethernet looks OK during initialization according to the printed messages. We are trying to locate the problem but haven't found yet so far. Any hints on what caused such problem? ... eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. IP-Config: Incomplete network configuration information. You are passing bad/insufficient boot arguments to the Linux kernel; unfortunaltely you don;t show us this part of the boot messages, so I cannot even guess what you're doing wrong. Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de Do not underestimate the value of print statements for debugging. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
4 bit LCD interface on 823e not working
As you probably can guess I'm trying to get this Optrex display working. Well I've finally scoped it out, and I can't find the cause (or solution to) my problems. When I write the following nibbles for display, I get these bit patterns out of the pins and on screen: 0: 1: 1010 2: 0111 4: 0100 5: 1011 8: 0100 A: 0110 F: 1101 There seems to be no rhyme or reason, at least I don't have a clue. The bits are all clocked in parallel, 4 at a time. Can any please help? I'm digging in the 823e book for any registers that may need to be changed. -Jason ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
LXT972 FEC problem on MPC855
eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX. IP-Config: Incomplete network configuration information. You are passing bad/insufficient boot arguments to the Linux kernel; unfortunaltely you don;t show us this part of the boot messages, so I cannot even guess what you're doing wrong. Well, if IP-Config is not complete, we can change the configuration using 'ifconfig' after the kernel starts. I did that. And I noticed that 'eth0' can receive packets but cannot transmit any packets. Here is the result of running ifconfig. ---once-- #ifconfig eth0 Link encap:Ethernet HWaddr 00:06:17:01:02:00 inet addr:192.168.5.24 Bcast:192.168.5.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:180 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:18110 (17.6 kb) TX bytes:0 (0.0 b) Base address:0xe00 ---once-- ---twice- #ifconfig eth0 Link encap:Ethernet HWaddr 00:06:17:01:02:00 inet addr:192.168.5.24 Bcast:192.168.5.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:282 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:26831 (26.2 kb) TX bytes:0 (0.0 b) Base address:0xe00 ---twice- - Shawn. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
4 bit LCD interface on 823e not working
I'm digging in the 823e book for any registers that may need to be changed. -Jason Which port are you using? How are you configuring it? Do you have the all the peripherals turned off? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Downloading Image
On Tue, Aug 27, 2002 at 01:52:34AM +0530, Aman wrote: Hi I have build a linux image for IBM PPC 440 using the src-linuxppc_2_4_devel.tar.bz2 [Powerpc Kernel Source] taken from the website http://www.ppckernel.org/tree.php?id=5. Now I want to download the image to the IBM PPC 440 evalkit for which I used elf2ppceval utilility by Grant Erickson. I copied the script and named as mkevimg.shar. When I executed the command unshar mkevimg.shar . I got the following error This step is unnecessary. The kernel build process generates a 'zImage.ebony' which is directly bootable on the IBM 440GP reference board. Can anyone help me in solving this issue or please suggest the way of downloading a the 440 image to the IBM PPC 440 evalkit. Also can you suggest me the cross-compiler for PPC 440. The ppc4xx toolchain from the free ELDK is what you are looking for. Regards, -- Matt Porter porter at cox.net This is Linux Country. On a quiet night, you can hear Windows reboot. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
LXT972 FEC problem on MPC855
Shawn: Maybe I have a contribution... On Monday 26 August 2002 18:32, Xiaogeng (Shawn) Jin wrote: You are passing bad/insufficient boot arguments to the Linux kernel; unfortunaltely you don;t show us this part of the boot messages, so I cannot even guess what you're doing wrong. Finally I figured out the problem and solved it. The problem is that the kernel didn't get the LINK status correctly. The 'fep-link' was always 0 which means the link is down or autonegotiation is in progress. In the code which defines 'phy_info_lxt971', it says that somehow LXT971 tells me that the link is down when the first read after power-up. So you have to read MII_REG_SR to set 'fep-phy_status' accordingly. But in my case, the read action occurred too early to wait till the link is up. So what I did is to delay 5s before reading MII_REG_SR during opening FEC device. I guess it takes the link a while to autonegotiate the speed. Hmm. I suppose PHY should interrupt when link status change, and therefore phy_status would be updated accordingly. So, maybe you have a problem with your board's PHY interrupt signal. Hope this helps. -Scop. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Question about ppc4xx_dma.h
Todd Poynor wrote:
Noticed that the order of clearing the old transfer mode bits and
setting the p_dma_ch-mode bits is reversed in the new patch, not sure
if this causes problems:
+ tmp_cntl |= (p_dma_ch-mode | DMA_CH_ENABLE);
+
+ switch (dmanr) {
+ case 0:
+ control = mfdcr(DCRN_DMACR0);
+ control |= tmp_cntl;
+ control = ~(DMA_TM_MASK | DMA_TD); /* clear all
mode bits */
This seems to set and then clear the p_dma_ch-mode bits in control
prior to writing to the DMACR, a problem?
--
Todd
Here is a patch that should address the above issue. I put in
additional checks for if a the current dma channel is all ready claimed
and if the requestion channel is greater than max dma channels.
dma_enable no longer clears mode bits. ( TODO: should document 4xx dma
usage)
Armin
-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: dma_fix_0826.patch
Url:
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20020826/49578eae/attachment.txt
-- next part --
A non-text attachment was scrubbed...
Name: dma_fix_0826.patch.gz
Type: application/x-gunzip
Size: 1796 bytes
Desc: not available
Url :
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20020826/49578eae/attachment.bin
