Problems with MMU: address translation for 0xXXXXXXXX failed
I'm trying to get a BDI2000 (firmware v1.09) working in order to debug a kernel module. I'm using an Embedded Planet RPXlite MPC850 board running kernel v2.4.20 from kernel.org with CONFIG_BDI_SWITCH=y and CONFIG_COMPILE_OPTIONS=-g -ggdb in my .config I have compiled gdb v5.3 with --host=i686-pc-linux-gnu --target=powerpc-linux. The relevant bit of my BDI config file is here: = WSPR796 0x ;;M_TWB: invalibdate TWB WM320x00f0 0x ;;invalidate page table base (PTBASE) [TARGET] CPUTYPE MPC800 CPUCLOCK5000;the CPU clock rate after processing the init list WORKSPACE 0x ;workspace in target RAM for fast download BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT) BREAKMODE SOFT;SOFT or HARD, HARD uses PPC hardware breakpoints MMU XLAT ; Enable address translation == I have scanned the archives of this mailing list and have seen a number of messages relating to getting the BDI working with the MMU but I don't seem to be able to get this working on my system. My kernel is stored in flash and booted by u-boot v0.3.0 I start the system by telneting into the BDI and issuing: BDIbi 0xc000 0xc00f BDIgo U-boot starts, loads the kernel and it is decompressed. At this point the system stops. I then do the following: BDIci BDImm 0xf0 0xc014f000 (gdb) target remote 192.168.240.242:2001 Remote debugging using 192.168.240.242:2001 0xc00020f0 in start_here() (gdb) c Continuing. Everything is OK until after I get a login prompt. After I log in, I don't seem to be able to debug successfully. I'm wanting to break on a call from a user-space program to a kernel function. On executing the program that triggers the kernel breakpoint I get the following error in the telnet session to the BDI *** MMU: address translation for 0xC400E69C failed ... *** MMU: address translation for 0xC0A05EF0 failed etc.. and in dgb: (gdb) Cannot remove breakpoints because program is no longer writeable. It might be running in another process. Further execution is probably impossible. Breakpoint 3, m8xx_cpm_dpalloc (size=16) at commproc.c:216 (gdb) bt Cannot access memory at address 0xc0a05ef0 Am I missing something obvious ? Is this the right way to go about debugging a loadable module ? Any help would be gratefully appreciated. Cheers Jeremy ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems with MMU: address translation for 0xXXXXXXXX failed
Jeremy Bowen wrote: BDImm 0xf0 0xc014f000 Don't do this. Use 'PTBASE 0xf0' in your BDI configuration file. Chances are the 0xc014f000 is not the right number, so just let the software determine this on its own. If that doesn't work, just out of curiosity use hard breakpoints (set BREAKMODE HARD). Just test it setting one breakpoint. If this works, I suspect the BDI is honoring the write protection (via the MMU) on the kernel text pages and we can't set a soft breakpoint. In this case, we'll have to add a kernel configuration to allow a debugger write. The CONFIG_KGDB and CONFIG_XMON enable the text writing, but they also add too much baggage and could interfere with the BDI. It's another thing to try that would provide some information, though. I didn't remember the BDI having trouble with this before, but I could have been using different software or configurations. Thanks. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems with MMU: address translation for 0xXXXXXXXX failed
In message DEA23DB61B62D4118B5900508B323B84012CC7D1 at OPENMAIL you wrote: I'm trying to get a BDI2000 (firmware v1.09) working in order to debug a kernel module. I'm using an Embedded Planet RPXlite MPC850 board running kernel v2.4.20 ... Am I missing something obvious ? Is this the right way to go about debugging a loadable module ? Any help would be gratefully appreciated. There were a couple of changes / extensions to the MMU support. Firmware version 1.09 is pretty old (Aug 2001). You might want to try a more recent one. Also check the changes to the Linux kernel - the use of the PTBASE parameter has changed; the BDI2000 now expects (and the Linux kernel automatically updates) the physical address which holds the virtual address of the array with the two page table pointers. Best regards, 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 Status quo. Latin for the mess we're in. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Why my console output nothing
Hi all I am using ELDK to port linux to a simple MPC860T board. I use SMC1 to connect to the serial port and as the console.But I can't go any further because when i powerup,the console doesnot show any message.List my steps here: 1. edit ~/.kermrc as what was shown in Denx ppcboot and linux Guide(tqm8xxl). 2. modify several line of 'TQM860L.h'. 3. modify my UPM table and register OR1/BR1 to OR4/BR4(my sdram uses cs4) in the file tqm8xx.c. 4. bashmake distclean. 5. bashmake TQM860L_config. 7. bashmake all 8. use a flash programmer to burn the u-boot.bin to my boot flash. 9. bashkermit -c Connecting to /dev/ttyS0, speed 115200 Escape character:xxx :enabled Type xxx to got back or x options -- 10.power up,but nothing is output. PS:my board info:MPC860T/SCC1 ETHERNET/SMC1 Serial/PCMCIA/CS0 FLASH 0/CS4 SDRAM It's my first time to build a embedded linux project,wish u can help me out. Thanks a lot! Best regards! --http://www.eyou.com --?? ... ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Problems with MMU: address translation for 0xXXXXXXXX failed
In message 3EC07D9A.6050604 at embeddededge.com you wrote: If that doesn't work, just out of curiosity use hard breakpoints (set BREAKMODE HARD). Just test it setting one breakpoint. If this works, I suspect the BDI is honoring the write protection (via the MMU) on the kernel text pages and we can't set a soft breakpoint. In this case, we'll have to add a kernel configuration to allow a debugger write. The CONFIG_KGDB and CONFIG_XMON enable the text writing, but they also add too much baggage and could interfere with the BDI. It's another thing It should be sufficient to enable CONFIG_BDI_SWITCH in the kernel configuration (after enabling CONFIG_DEBUG_KERNEL). Best regards, 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 If it happens once, it's a bug. If it happens twice, it's a feature. If it happens more than twice, it's a design philosophy. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
what 's wrong with the kernel booting?
hi,all I port uboot0.2.0 in my 405Gpr board.But I got some problems when booting kernel.Have anyone gave some advice? Thanks wood tftp 0x20 ENET Speed is 100 Mbps - FULL duplex connection ARP broadcast 1 Got good ARP - start TFTP TFTP from server 192.168.0.83; our IP address is 192.168.0.2 Filename 'zImage.treeboot'. Load address: 0x20 Loading: # ## done Bytes transferred = 568052 (8aaf4 hex) = tfp 0x10 ENET Speed is 100 Mbps - FULL duplex connection ARP broadcast 1 Got good ARP - start TFTP TFTP from server 192.168.0.83; our IP address is 192.168.0.2 Filename 'zImage.treeboot'. Load address: 0x10 Loading: *# ## done Bytes transferred = 379656 (5cb08 hex) = bootm 0x10 0x20 ## Booting image at 0010 ... Image Name: Powerpc Linux Kernel Created: 2003-05-09 15:01:24 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:379592 Bytes = 370.7 kB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x00F8F580 = set upper limit to 0x0080 ## cmdline at 0x007FFC00 ... 0x007FFC0D bd address = 0x00F8FF90 memstart= 0x memsize = 0x0100 flashstart = 0xFFF8 flashsize = 0x0008 flashoffset = 0x0004 sramstart = 0x sramsize= 0x bootflags = 0x7F00 procfreq=400 MHz plb_busfreq =100 MHz pci_busfreq = 33.333 MHz ethaddr = 00:D0:59:B8:36:C0 IP addr = 192.168.0.2 baudrate= 9600 bps ## Loading RAMDisk Image at 0020 ... Image Name: Simple Ramdisk-Image Created: 2001-05-13 10:49:23 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:567988 Bytes = 554.7 kB Load Address: Entry Point: Verifying Checksum ... OK ## initrd at 0x00200040 ... 0x0028AAF3 (len=567988=0x8AAB4) Loading Ramdisk to 00f04000, end 00f8eab4 ... OK ## Transferring control to Linux (at address ) ... id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:mapin_ram done MMU:setio MMU:exit setup_arch: enter setup_arch: bootmem arch: exit ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
FEC on MPC862P freezes CPM
I don't understand what you mean by SCC1 is used for ethernet. You already said that you're using the FEC! Either use FEC for ethernet or use an SCC. You cannot use both - after all there's only one MII bus! Alex On Mon, 2003-05-12 at 18:45, Willy Jacobs wrote: We are using a MPC862P (XPC862PCZP80B, 2K26A silicon) in a system with UTOPIA (master) and FEC simultaneously in UTOPIA muxed bus mode. The processor runs at 50 MHz (CPM and bus). For references in the MPC862 Users' Manual, see figure 35-1 (page 35-4), table 41-6 (page 41-7), and figure 42-3 (page 42-7). The FEC MII signals are mapped on PCMCIA port A. For testing we are using Linux. The Linux console is mapped onto SCC3, and SCC1 is used for ethernet. Initialization for SCC3 is done first, followed by the initialization of the FEC (as described on paragraph 41.3 (page 41-8)): ECNTRL[FEC_PINMUX]=1; setup the buffer descriptors; UTMODE[SPLIT]=0, PDPAR[UT]=1; PDPAR[8]=1 (MDII_MDC). A printk to SCC3 in above situation will freeze the CPM in the transmit of the SCC3 buffers. More concrete it will never pass this while loop: while (bdp-cbd_sc BD_SC_READY) ; The UTIOPIA initialization will be done later. With PDPAR[UT]=0 SCC3 and UTOPIA works without any problem. Note that above CPM freeze problem also occurs using another RTOS (VRTX) and a similar use of SCCs, FEC, and UTOPIA. Is this problem known? Is there another initialization sequence needed? -- willy ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
FEC on MPC862P freezes CPM
Dear Alex, The FEC and SCC Ethernet don't share the PHY chip and each one has its own bus to the PHY, so way cant you use both FEC and SCC for Ethernet ? Actually we did configure FEC and SCC for Ethernet both on the u-boot and kernel (ELDK on TQM860L) and we got eth0 and eth1. I have noticed that u-boot (and ppc-boot) prohibits this on the FADS860T board (don't know why). Regards, Eli Brin -Original Message- From: Alex Zeffertt [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 13, 2003 10:56 AM To: linuxppc-embedded at lists.linuxppc.org Subject: Re: FEC on MPC862P freezes CPM I don't understand what you mean by SCC1 is used for ethernet. You already said that you're using the FEC! Either use FEC for ethernet or use an SCC. You cannot use both - after all there's only one MII bus! Alex On Mon, 2003-05-12 at 18:45, Willy Jacobs wrote: We are using a MPC862P (XPC862PCZP80B, 2K26A silicon) in a system with UTOPIA (master) and FEC simultaneously in UTOPIA muxed bus mode. The processor runs at 50 MHz (CPM and bus). For references in the MPC862 Users' Manual, see figure 35-1 (page 35-4), table 41-6 (page 41-7), and figure 42-3 (page 42-7). The FEC MII signals are mapped on PCMCIA port A. For testing we are using Linux. The Linux console is mapped onto SCC3, and SCC1 is used for ethernet. Initialization for SCC3 is done first, followed by the initialization of the FEC (as described on paragraph 41.3 (page 41-8)): ECNTRL[FEC_PINMUX]=1; setup the buffer descriptors; UTMODE[SPLIT]=0, PDPAR[UT]=1; PDPAR[8]=1 (MDII_MDC). A printk to SCC3 in above situation will freeze the CPM in the transmit of the SCC3 buffers. More concrete it will never pass this while loop: while (bdp-cbd_sc BD_SC_READY) ; The UTIOPIA initialization will be done later. With PDPAR[UT]=0 SCC3 and UTOPIA works without any problem. Note that above CPM freeze problem also occurs using another RTOS (VRTX) and a similar use of SCCs, FEC, and UTOPIA. Is this problem known? Is there another initialization sequence needed? -- willy ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Why my console output nothing
Dear Rick, in message 20030513160515.79677.qmail at eyou.com you wrote: I am using ELDK to port linux to a simple MPC860T board. I use SMC1 to connect to the serial port and as the console.But I can't go any further because when i powerup,the console doesnot show any message.List my steps here: 1. edit ~/.kermrc as what was shown in Denx ppcboot and linux Guide(tqm8xxl). 2. modify several line of 'TQM860L.h'. 3. modify my UPM table and register OR1/BR1 to OR4/BR4(my sdram uses cs4) in the file tqm8xx.c. 4. bashmake distclean. 5. bashmake TQM860L_config. 7. bashmake all 8. use a flash programmer to burn the u-boot.bin to my boot flash. Only now it becomes clear that you are not talking about Linux at all. Your posting is off topic in the linuxppc-embedded mailing list. Chances for useful replies are much better in the u-boot-users mailing list instead. Chances for useful replies would be even better if you provided a little more information. modify several line of ... is not really a precise description of what you did. Porting U-Boot to new hardware requires more than just tweaking a line here and there. It will require both an in-depth understanding of the hardware and U-Boot. It's my first time to build a embedded linux project,wish u can help me out. Did you read the README that comes with U-Boot? Finally: did you order your BDI2000 yet? You will probably need it soon. Best regards, 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 If all you have is a hammer, everything looks like a nail. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IDE driver support in PPC440
Hi, I am working on a PPC440 board that supports a PCI-IDE device, and I am experiencing an interrupt handling problem. The PCI-IDE controller uses External Interrupt 7 and the controller interrupt line is wired to the processor directly. When the IDE device is being initialized, I can see that the interrupt goes off. But the code is stuck in the ISR and can not get out. Here are the screen debug messages: Linux booting up ide1: CMD649 Bus-Master DMA disabled (BIOS) disabling irq 50 defensively ppc405_uic_disable - irq 50 word 1 bit 0x12 hda: SanDisk SDCFB-128, ATA DISK drive ppc405_uic_enable - irq 50 word 1 bit 0x12 ppc405_uic_enable - irq 50 word 1 bit 0x12 ide0 at 0x2000-0x2007,0x3002 on irq 50 hda: 250880 sectors (128 MB) w/1KiB Cache, CHS=980/8/32 Partition check: hda:ppc405_pic_get_irq - irq 50 bit 0x2000 ppc405_uic_disable_and_ack - irq 50 word 1 bit 0x12 ppc405_pic_get_irq - irq 64 bit 0x0 ppc405_pic_get_irq - irq 64 bit 0x0 - I am able to retrieve a stack trace when the console is displaying the above messages. It is shown as follows. --- #8 0xc0004950 in do_IRQ (regs=0xc02b68a4) at irq.c:585 #9 0xc00037cc in ret_from_fork () at entry.S:97 #10 0xc0004730 in ppc_irq_dispatch_handler (regs=0xc02a522f, irq=3178) at irq.c:477 #11 0xc0004938 in do_IRQ (regs=0xc01dbf30) at irq.c:583 Does anybody have an explaination on what is going on? Thank you for your help. Regards, Terry ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
