abatron and kernel modules.
Dear David, in message <200207251713.MAA00232 at mint.mw.cray.com> you wrote: > > We've been very happily using BDI2000 for kernel debugging on our 405GP > on a 2.4.2 kernel with builtin abatron MMU support (via PTBASE at 0xf0). There have been some changes in the way how the Linux kernel and the BDI2000 exchange information about the MMU state; I'd recommend to use a more recent kernel (linuxppc_2_4_devel) with the latest version of the Abatron firmware (afaik 1.08 for 4xx) > But I have not figured out how to get it deal with the address space of > a loaded kernel module: it claims that the region is missing from the > page tables. Kernel addresses are in 0xC00x ranges, and when we load > the module, 'module_list' now points to 0xC340 ranges. BDI can > dump the physical addresses of my module, but cant talk to the virual > kernel address space of the loaded module. We have a bit of documentation about this at http://www.denx.de/doc/TQM8xxL/debugging.html#DEBUGGING-LINUX-KERNEL Hope it helps, 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 A person who is more than casually interested in computers should be well schooled in machine language, since it is a fundamental part of a computer. -- Donald Knuth ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
can jffs2 on DOC?
Hi I searched and read all the list but still confusing... I'm sure my DOC is OK with cat /proc/mtd, but I just can't mount jffs2 image on DOC dev:size erasesize name mtd0: 0100 4000 "DiskOnChip 2000" My step to mount jffs2 is: mkfs.jffs2 -r /imgdata -o /data.img -e 0x4000 dd if=/data.img of=/dev/mtd0 mount -t jffs2 /dev/mtdblock0 /mnt and my system hangs... These are the questions: 1) Can I mount jffs2 image on DOC? 2) To support jffs2, what kernel MTD options should I enable, I'm not sure my choice is right? Any response is appreciate... W.B. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
abatron and kernel modules.
John W. Linville wrote: > I recall having to add the BDI support to the linux-2.4.2_hhl20 kernel > source here. There are a couple of different versions of that kernel :-) The first one was all PPC except 4xx. There was one for 4xx, where I managed to break some of the other PPCs (sorry). There may be later ones that include other processor architectures. There are minor version numbers contained in the packages, take a look at them as they are important. Of course, the processor specific CD packages were all correct, just be careful when mixing from one to another (which isn't recommend). -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
PPMC8260 - bdi2000.cnf
Here is a bdi2000 config file, that works with PPMC8260. Thanks, Kedar Kedar Madineni wrote: > > Hi: > > I am looking for a working configuration file for the PPMC8260 board for > use > with bdi2000. If you have one, would you please share it and post it > here. > > Thanks, > Kedar > -- next part -- ; - ; Abatron bdiGDB configuration file for the Wind River ppmc8260 ; ; This file has been tested with the following hardware: ; Abatron BDI2000 firmware revision 1.10 ; PPMC8260-0074 PCA-00205-005 4101-0434 REV 10 ; XPC8260ZU166A (Mask 0K26N) CPU ; 256MB Synchronous DRAM DIMM ; 16MB Flash SIMM - StrataFlash 28F640J3A - (4Mx16) ; 2 Devices (32 bit) ; ; The h/w reset configuration word for this board is at ; 0xFE00. This will be programmed to 0x1E848205 when you load ppcboot ; (at 0xfe00). The default onboard is 0x1C840502. You can have the ppcboot ; live at 0xfe00 and have the vware at 0xfff000e0 (so that it skips ; the first 32 bytes) when executing it at 0xfff00100. If you don't want ; ppcboot, you don't need to do anything. ; All the switches are default from the factory ; -- ; [INIT] WREGMSR 0x ; clear MSR ; Normal setting WM320xF00101A8 0xF000 ; IMMR == 0xF000 ; If you ever erase the whole flash, use this setting for IMMR ;WM320x000101A8 0xF000 ; IMMR == 0x ; WM320xF001 0x4220 ; SIUMCR WM320xF0010004 0xFFC3 ; SYPCR == no watchdog WM160xF001000E 0x ; SWSR WM320xF0010024 0xB000 ; BCR WM8 0xF0010028 0x22; PPC_ACR WM320xF001002C 0x71234560 ; PPC_ALRH WM320xF0010030 0x89ABCDEF ; PPC_ALRL WM8 0xF0010038 0x02; LCL_ACR WM320xF0010040 0x8002 ; TESCR1 WM320xF0010C80 0x ; SCCR == normal operations ; ;TSZ40x 0x0300 ; ; Memory controller ; ; These writes configure /CS0 to be the 2MB FLASH at 0xFE0 ; and /CS6 to be the 4MB FLASH at 0xE00 ; These writes configure: ; CHIP SELECT BASE ADDRESSSIZE COMMENTS ; --- ; /CS0 0xFE00 8MB 8MB ON BOARD FLASH ; WM320xF0010100 0xFE001801 ; BR0 WM320xF0010104 0xFE000856 ; OR0 ; WM320xF0010110 0x0041 ; BR2 WM320xF0010114 0xF8002500 ; OR2 ; WM320xF0010118 0x0841 ; BR3 WM320xF001011C 0xF8002500 ; OR3 ; WM320xF0010120 0x38001861 ; BR4 WM320xF0010124 0xFF0030C0 ; OR4 ; WM320xF0010128 0x32000801 ; BR5 WM320xF001012C 0x3FFF06F6 ; OR5 ; WM320xF0010130 0x ; BR6 WM320xF0010134 0x ; OR6 ; WM320xF0010138 0xF1000801 ; BR7 WM320xF001013C 0x06F6 ; OR7 ; WM320xF0010140 0x ; BR8 WM320xF0010144 0x ; OR8 ; WM320xF0010148 0x ; BR9 WM320xF001014C 0x ; OR9 ; WM320xF0010150 0x ; BR10 WM320xF0010154 0x ; OR10 ; WM320xF0010158 0x ; BR11 WM320xF001015C 0x ; OR11 ; ; ; Initialize the SDRAM on the 60x bus. ; ;WM320xF0010190 0xC265A562 ; PSDMR: normal WM320xF0010168 0x0200 ; MAR WM320xF0010170 0x ; MAMR WM320xF0010174 0x ; MBMR WM320xF0010178 0x ; MCMR WM160xF0010184 0x3200 ; MPTPR WM320xF0010188 0x ; MDR WM320xF0010190 0x412EB45A ; PSDMR WM320xF0010194 0x4066A552 ; LSDMR: ; WM8 0xF0010198 0x08; PURT WM8 0xF001019C 0x0E; PSRT ; WM8 0xF00101A0 0x08; LURT WM8 0xF00101A4 0x0E; LSRT ; WM320xF00101AC 0x ; PCIBR0 WM320xF00101B0 0x ; PCIBR1 WM320xF00101C4 0x ; PCIMSK0 WM320xF00101C8 0x ; PCIMSK1 WM160xF0010220 0x ; TMCNTSC WM320xF0010224 0x ; TMCNT WM160xF0010240 0x ; PISCR WM320xF0010244 0x ; PITC WM320xF0010248 0x ; PITR ; WM160xF0010C00 0x ; SICR WM320xF0010C04 0x3C00 ; SIVEC WM320xF0010C08 0x0040 ; SIPNR_H WM320xF0010C10 0x05309770 ; SIPRR WM320xF0010C14 0x05309770 ; SIPRR_H WM320xF0010C18 0x05309770 ; SIPRR_L WM320xF0010C1C 0x ; SIMR_H WM320xF0010C20 0x1800 ; SIMR_L ; ;
abatron and kernel modules.
Dan Malek wrote: > > There was also a version of the 2.4.2 kernel, perhaps even a MontaVista > snapshot, where I screwed up loading the address of the pte pointer I recall having to add the BDI support to the linux-2.4.2_hhl20 kernel source here. If the original poster doesn't want to use a later kernel for whatever reason (e.g. no support contract), he should get some late 2.4 source, find the BDI references (there aren't that many), and port them back to his 2.4.2-derived base. Good luck! John -- John W. Linville LVL7 Systems, Inc. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
abatron and kernel modules.
David Updegraff wrote: > We've been very happily using BDI2000 for kernel debugging on our 405GP > on a 2.4.2 kernel with builtin abatron MMU support (via PTBASE at 0xf0). H.there was a time when we screwed up the kernel PTE by moving around some bits and not telling the folks at Abatron we did that. I unfortunately don't remember the kernel versions nor the BDI2000 firmware versions that match. All I know is the latest versions of both work together :-) There was also a version of the 2.4.2 kernel, perhaps even a MontaVista snapshot, where I screwed up loading the address of the pte pointer label during initialization. This caused the BDI2000 to go looking into the weeds for random bits that it tried to interpret as page tables. I know that what you are trying to do will work when all of the bits are lined up correctly. If you could upgrade to a newer kernel, it would really help. Thanks. -- Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Tigon3 driver, broadcom 5307, 440GP, working?
> > On Wed, Jul 24, 2002 at 01:29:23PM -0500, Stephen Cameron wrote: > > > > I've been playing around with the tigon3 driver and a broadcom > > 5307 gigabit NIC in my IBM ebony... No luck so far. The > driver compiles > > and even loads, I can run ifconfig(busybox really) to configure > > the NIC, and if I pull the network cable, the driver seems to > > notice (get log messages about link is down, link is up) but so > > far, I can't actually transmit or receive any packets. > > > > Anyone had any luck with this combination? > > I assume you mean a BCM5703? I guess so... I know it colloquially as a "Broadcom 5703 gigabit NIC" > > FWIW, BCM5700/5701 on 440GP works for me with the current tg3 driver. > Hmm, I got ahold of a 5701 and tried it. Same behavior as my 5703. I can load the driver, ifconfig it, the link status appears correct, but can't transmit packets. here's what I get (on the off chance that somebody will see this and recognized the problem): Upon loading the driver: eth2: Tigon3 [partno(284685-001) rev 0105 PHY(5701)] (PCIX:133MHz:64-bit) 10/102 Then, /sbin/ifconfig eth2 192.168.2.55 netmask 255.255.255.0 broadcast 192.168.2.255 eth2: Link is up at 10 Mbps, half duplex. eth2: Flow control is off for TX and off for RX. So far so good. Then, ping 192.168.2.55 Now, trouble: (some debugging output is in here) sys_sendto sock_sendmsg, sock=c3a8a1c0, len=64 scm_send returns 0 sk->prot->sendmsg = c00c1058 a b d g j L b e f g rt_intern_hash A B C, n = -22z2, err=-22 rt_intern_has returns -22 err = -22 sock->ops->sendmsg = c00c9a50 sock->ops->sendmsg returns -22 err = -22 sendto: Invalid argument so, it seems that in net/ipv4/arp.c, arp_bind_neighbour(), __neigh_lookup_errno returns -22. Don't know why. Other NICs in the system (on-chip NICs) work fine. Also, if I try to ping 192.168.2.0 (the network address) ping doesn't bail, but I still get the -22 from arp_bind_neighbour, and though ping claims such-and-such many packets transmitted, when I do ifconfig eth2, I see: eth2 Link encap:Ethernet HWaddr 00:02:A5:E7:1C:Dand though ping claims such-and-such many packets transmitted, when I do ifconfig eth2, I see: eth2 Link encap:Ethernet HWaddr 00:02:A5:E7:1C:D2 inet addr:192.168.2.55 Bcast:192.168.2.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8 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:1448 (1.4 kb) TX bytes:0 (0.0 b) Interrupt:24 (notice, zero packets transmitted.) ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
VME driver (Universe II)
Greetings, Has the universe II driver been updated against the 2_4_devel tree? I have found the patches from Gabriel Paubert, against 2_2. Should I attempt to merge that into the 2.4.11 area to get a driver for VME? It would be a learning experience for me, but one that I'd rather avoid if possible. The board is MVME-5100 using 2.4.11 from the devel tree. Any pointers would be appreciated. Thanks, Gary Gary Hannon CSPI (978)663-7598 x1509 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
VME driver (Universe II)
The vme driver I have is from the 5100 lsp MVista provided. It's running under the 2.4.2 kernel and been exercised pretty extensively. I'm not doing any DMA transfer though. Did you have any special setup files (arch/ppc/kernel) for the 5100? > -Original Message- > From: owner-linuxppc-embedded at lists.linuxppc.org > [mailto:owner-linuxppc-embedded at lists.linuxppc.org]On Behalf Of > ghannon at cspi.com > Sent: Thursday, July 25, 2002 11:17 AM > To: linuxppc-embedded at lists.linuxppc.org > Subject: VME driver (Universe II) > > > > Greetings, > > Has the universe II driver been updated against the 2_4_devel tree? > > I have found the patches from Gabriel Paubert, against 2_2. > Should I attempt to merge that into the 2.4.11 area to get a > driver for VME? It would be a learning experience for me, but > one that I'd rather avoid if possible. > > The board is MVME-5100 using 2.4.11 from the devel tree. > > Any pointers would be appreciated. > > Thanks, > Gary > > Gary Hannon > CSPI > (978)663-7598 x1509 > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
abatron and kernel modules.
Hi. We've been very happily using BDI2000 for kernel debugging on our 405GP on a 2.4.2 kernel with builtin abatron MMU support (via PTBASE at 0xf0). But I have not figured out how to get it deal with the address space of a loaded kernel module: it claims that the region is missing from the page tables. Kernel addresses are in 0xC00x ranges, and when we load the module, 'module_list' now points to 0xC340 ranges. BDI can dump the physical addresses of my module, but cant talk to the virual kernel address space of the loaded module. Is there some page table magic that goes on with module loading that is confusing both me and the BDI? Thanx. -- Dave Updegraff, Cray Inc. / dave at cray.com ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[Fwd: Re: How to get rid of unused data in LKM]
Hi Dan, that's a better idea. I think I will do that if there is no way to free the firmware data from my module. I found a little code snippet to do kernel file access. It does not seem to be that complicated. Thanks Matthias > Couldn't you do a kernel file open during module_init, store the > PCI device code and close the file? > > Regards, > > Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
can jffs2 on DOC?
Since your question is specific to MTD, you might prefer to use a more appropriate mailing list. Try at http://lists.infradead.org/mailman/listinfo/linux-mtd/ Jean-Denis Boyer, B.Eng., System Architect Mediatrix Telecom Inc. 4229 Garlock Street Sherbrooke (Quebec) J1L 2C8 CANADA (819)829-8749 x241 ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
driver for 440GP
On Wed, Jul 24, 2002 at 03:06:10PM -0700, Khai Trinh wrote: > > Hi folks, > > I am trying to write a driver for the 440GP peripheral > device with physical memory map of 0x1 (total > of 36 bits) on the PLB address space. > > When I get to do: > > request_mem_region() and then > ioremap64() > > Don't I need a 64 bit request_mem_region() call? Is > there such a kernel call before I call ioremap64()? Two options for now: 1) Use the least significant 32-bits of the physical address to do the region manipulation. 2) Don't register the region. We don't really do a good job of this in most PPC code anyway. In 2.5, we can make resource start/end u64's, but it's intrusive enough that I can't imagine it going into 2.4 (I certainly wouldn't ask for it). The region manipulation API would now use u64's and printk formatting has to be handled since a u64 is a different type on 32/64 platforms. 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/
Tigon3 driver, broadcom 5307, 440GP, working?
On Wed, Jul 24, 2002 at 01:29:23PM -0500, Stephen Cameron wrote: > > I've been playing around with the tigon3 driver and a broadcom > 5307 gigabit NIC in my IBM ebony... No luck so far. The driver compiles > and even loads, I can run ifconfig(busybox really) to configure > the NIC, and if I pull the network cable, the driver seems to > notice (get log messages about link is down, link is up) but so > far, I can't actually transmit or receive any packets. > > Anyone had any luck with this combination? I assume you mean a BCM5703? FWIW, BCM5700/5701 on 440GP works for me with the current tg3 driver. 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/
embedded devices
Charles Lockhart wrote: > > Has anyone had much luck porting orbit to embedded linux devices? I'm > looking at trying to port it to an ipEngine (product of Brightstar > Engineering, www.brightstareng.com), running an embedded version of Linux > on a ppc (mpc823). What problems have people had? What kind of > performance did you get? What kind of footprint did you end up with? > A summary of what it might entail? Yes, I've done it; we ported it to the ppc405, sh4, and ppc750. Footprint was as small as any commercial corba server. There were some minor annoying bits to the port, mostly having to do with cross-compiling. Oh, and gcc-3.0.2 wasn't up to the task of running orbitcpp, at least on sh4; I think you need gcc-3.0.4 if you want that to work. This is a work in progress, so be kind. It's at http://www.kegel.com/xgcc3/orbit.html - Dan ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
[Fwd: Re: How to get rid of unused data in LKM]
Original Message Subject: Re: How to get rid of unused data in LKM Date: Thu, 25 Jul 2002 02:04:53 -0700 From: Dan Taylor <[EMAIL PROTECTED]> Reply-To: danieltaylor at acm.org To: Matthias Fuchs References: <20020724154914.5C03C10875 at denx.denx.de> <3D3FA821.40106 at esd-electronics.com> Couldn't you do a kernel file open during module_init, store the PCI device code and close the file? Regards, Dan Matthias Fuchs wrote: > > Hi Wolfgang, > >> >> >> Why don't you load the firmware using some ioctl() _after_ loading >> the module? > > Of course this is a good and definetly the default solution. But our > application requires > that everything is done by the init function of the module. > Life would be boring and mailing list obsolete, if we can always use the > default solutions :-) > >>> But after doing so, the firmware data is still wasting kernel memory >>> on the host system >>> and is not used anymore. >>> How can I free that memory ? Is there a better way to handle that data ? >> >> If you really think you must link the data with the module: Declare >> it using "__initdata" ? > > I think that John is right. __initdata only makes sense, when the module > is compiled into > the kernel. But I will check it again, just to be sure. > > Matthias > > > > ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
