bitkeeper
Hi, everybody. (I'm not trying to start a flamewar here, really.) I couldn't help but notice the recent discussion/flamewar about the bitkeeper license changes over on LKML. These changes, as I understand them, impact anybody who develops or distributes software deemed to compete with bitkeeper. In my experience, powerpc linux development seems to rely on bitkeeper much more so than the regular linux kernel development, by which I mean that if you want to keep up to date with powerpc linux kernel, you pretty much have to use bitkeeper, or at least that's been my experience. And, since I have personally contributed to CVS development in the past, and odds are, will again in the future, I thknk maybe this means I can't use bitkeeper anymore (well, not for free). So that leaves me in a bit of a tight spot. So, I was wondering if there are any plans to say, mirror the development linux powerpc bitkeeper tree as a tar.bz2 on a more regular basis, like the regular linux kernel development team does? Or perhaps someone is already doing that, and I just don't know about it? This is not exactly urgent for me right now, as I've not been working on powerpc lately, but probably will be getting back to it sometime not far away. If I'm the only one in this position perhaps it would be possible for me to get an up-to-date tree from someone on an as-needed basis? Thanks, -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
linuxppc_2_4_dev tree
Khai Trinh wrote: How can I build a kernel image with target filesystem mounted via NFS fro mthe dev tree? The dev tree doesn't seem to have the target filesystem directory structure like the ones distributed by MVista for NFS mount. The bitkeeper tree is the kernel only. A root filesystem you have to make or get elsewhere. I've had good luck with the DENX Embedded Linux Development Kit. Here: http://www.denx.de/ELDK/ It has a working rootfs that can be mounted via NFS. You can then pare that down to make it smaller if you need to. Busybox and Tinylogin are also useful for creating user-land to go with your kernel. http://www.busybox.net/ http://tinylogin.busybox.net/ Busybox can act as init, though the inittab needs to be a bit different than a regular inittab, if I remember right. I found getting a satisfactory rootfs was not exactly easy. Not too hard, but a lot of details to get just right, especially if you need to make it small. You'll want to make a script to create your root fs, which you can then use from a kernel which mounts it by NFS (useful for debugging applications) or by cramfs/initrd setup where the whole image, kernel and rootfs, is loaded into RAM. Hope that helps some. -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Tigon3 driver, broadcom 5307, 440GP, working? (solved)
I wrote: I've been playing around with the tigon3 driver and a broadcom 5307 [5703, I meant] gigabit NIC in my IBM ebony... No luck so far. and Ok, I have determined that my problem lies in user-land, not the kernel. Heh. The reason it couldn't ping it's own IP address? I forgot to ifconfig the loopback interface, duh. ifconfig lo 127.0.0.1 makes it all work. (Sometimes the easy ones are the hardest.) Thanks, -- steve ** 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, I 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? Ok, I have determined that my problem lies in user-land, not the kernel. Using the same kernel, but with a more elaborate start-up scripts/root filesystem (those from DENX ELDK-1.0) it works fine. Using my minimal rootfs, with busybox, tinylogin, it doesn't work. Is there anything needed to get the broadcom 5703 going besides ifconfig? Well, I now have a root filesystem that works and one that doesn't so I can slowly make one more like the other until I see which piece is the culprit/magic. Thanks, -- steve ** 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/
ioremap on powerpc question
I wrote: Hmm, I continue to have difficulties... Matt Porter wrote: On Mon, Jul 15, 2002 at 01:58:21PM -0500, Cameron, Steve wrote: It blows up with a machine check. [...] Try this patch: [...] when I attempt to DMA into the physical address with my PCI device, it is as if the DMA never occurs. Prior to the DMA, I fill the buffer with 0x55's, and after the DMA, the 0x55's are still there. [...]. BTW, my device seems happy with the physical addresses I pass it, [...] And now I see, I have (at least) two errors, one hiding the other. In fact my PCI device was _not_ happy with those addresses at all, (because they were wrong, I botched the swapping) and also my code to check for this device's unhappiness happened to be broken... So, now I think ioremap is likely now working with this patch. Thanks, and sorry for all the noise. (still not sure about my problems with alloc_bootmem_pages, but not too worried about it now.) -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ioremap on powerpc question
[...] However, on powerpc, as soon as I try to do, for example: *buf = '\0'; // write one char to virt addr returned by ioremap It blows up with a machine check. You are hitting a 440GP specific feature. ioremap is trapping ranges of addresses and fixing them up with the proper ERPN. Unfortunately, I left the default on a no match as an ERPN=1 which will ioremap 1 0400 . That's why you get a bus error. Try this patch: Thanks! That appears to work. and thanks for explaining the rationale on the readb/writeb requirement. -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ioremap on powerpc question
Hello, I have a question about ioremap_nocache() on powerpc. I want to create a huge RAM buffer for i/o purposes, so I boot the kernel with parameter mem=64M (actually, my system, an IBM ebony 440, has 128M RAM) This leave 64M sitting around unused by the linux kernel. Then, I can do unsigned char *buf; buf = ioremap_nocache(64*1024*1024, 64*1024*1024); And get back some kind of virtual address, buf which I want to use for example to recieve data coming in from an IP socket. Then, since I know the physical address of buf (because I set it up myself with ioremap), I want to DMA from buf to a PCI device. I have all this working fine on x86, so far so good. However, on powerpc, as soon as I try to do, for example: *buf = '\0'; // write one char to virt addr returned by ioremap It blows up with a machine check. (BTW, buf happens to be == 0xc505c000, so alignment shouldn't be a problem.) Now, I see threads on LKML via google that say, essentially, you _must_ use readb/writeb, etc to access addresses returned by ioremap, I had presumed this is because ioremap is used most typically to access memory, registers, etc which are actually on PCI devices. In my case, I am simply remapping actual RAM, not on the PCI bus at all. I thought this meant that I can get away with accessing those virtual addresses directly. Am I wrong about that? (well, it seems I am wrong somewhere, but why?) Using readb/writeb would defeat my purpose. My purpose is to avoid an extra copy of the data. I want to read/write the data off an IP socket into/from a buffer which is then directly DMA-able to/from a PCI device, and thus avoid having to copy the data into a special DMA-able buffer from a more ordinary buffer that's used with the socket. I'm using ioremap because kmalloc can't give me big enough buffers. (nothing even close to 64M, and in the end it's likely I would want even more than 64M.) Is what I'm trying to do possible? Where am I going wrong? Thanks, -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ioremap on powerpc question
I wrote: I have a question about ioremap_nocache() on powerpc. [...] Now, I see threads on LKML via google that say, essentially, you _must_ use readb/writeb, etc to access addresses returned by ioremap, [...] Using readb/writeb would defeat my purpose. One more data point. I tried it with writeb, just to see, and it blows up just the same anyway, with machine check (bus error). -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cramfs for root filesystem?
Stephen Cameron wrote: I have tried to fix up the endian-swapping patch for the mkcramfs from sourceforge CVS, circa Mon Jun 24, 2002 :pserver:anonymous at cvs.cramfs.sourceforge.net:/cvsroot/cramfs If you are going to take that version of mkcramfs, you could just as well take the corresponding version of the cramfs fs implemention since it hardwires conversion to *little endian* into the kernel Yes, this would be the preferable solution, and is what I looked for first, but I didn't know it was done already. Where can I get that? Oh! Duh! Now I see it! (knocking self on head :-) I hadn't noticed that I got it up when I did the cvs co . to check out mkcramfs from sourceforge. I wasn't expecting kernel parts in there. I just tried it out, and it works great! Thanks for saving me some effort. -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cramfs for root filesystem?
Steven Hein [mailto:ssh at sgi.com] wrote: [...] You do need a kernel patch to add cramfs to the list of filesystems to check for in the initrd, also my patch forces the blocksize of the initrd to 4K if it finds that it contains cramfs. [...] Hmm, this patch doesn't seem to apply to my fairly recent linuxppc_2_4_devel tree. identify_ramdisk_image() for instance is in init/do_mounts.c, not drivers/block/rd.c, and there is a #define BUILD_CRAMDISK in there I guess relating to cramfs, though I'm not sure what it's doing. I have also previously posted a patch to mkcramfs to swap endianness on a cramfs filesystem [...] http://lists.linuxppc.org/linuxppc-embedded/200206/msg00128.html Hmm, this patch doesn't seem to apply to the mkcramfs I got from sourceforge yesterday. Thanks, just the same. -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cramfs for root filesystem?
I wrote: I have tried to fix up the endian-swapping patch for the mkcramfs from sourceforge CVS, circa Mon Jun 24, 2002 :pserver:anonymous at cvs.cramfs.sourceforge.net:/cvsroot/cramfs Well, I missed one thing, at least, so here is an additional patch, below. There must be more to it still as I haven't yet got it working. (not sure if problem is in mkcramfs or my kernel). -- steve diff -u -r1.2 mkcramfs.c --- mkcramfs.c 25 Jun 2002 16:12:58 - 1.2 +++ mkcramfs.c 25 Jun 2002 20:09:45 - @@ -573,6 +573,7 @@ stack_entries++; } entry = entry-next; + fix_inode(inode); } /* ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Can I run linux without a file system?
Dr. Craig Hollabaugh wrote: I can say that a minimum RedHat install uses 29,296 files - 382.020MB, debian 10,734 files - 67.428MB, my minimal root filesystem 82 files and 4.8MB. Hmm, my minimal rootfs is (so far) 7 Mb, (as reported by du -s). Or, is this 4Mb you cite compressed? I wonder because my libc.so is over 5 Mb. (which I got from DENX eldk-1.0) Instead of ldd, I used objdump -x $library | grep NEEDED which has the advantage that you can (er, that I know how to :-) run it in a cross environment, so I don't have to fire up the powerpc just to run ldd on a bunch of binaries. (maybe there's a way to cross run ldd? ) Using that, I wrote a script (just today, as a matter of fact) to scan all the executables and their libraries (and links to libs) iteratively until it produced a minimal set, then deletes whatever isn't on the list, which got me down to 7Mb with busybox and tinylogin as my only apps. (It occurs to me now that apps using dlopen() could be a problem, but those are relatively rare.) Any hints or links to into on crunching down the individual libraries would be helpful. BTW, nice book. -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Can I run linux without a file system?
Wolfgang Denk wrote: In message 45B36A38D959B44CB032DA427A6E10640167CFE3 at cceexc18.americas.cpqcorp.net you wrote: Hmm, my minimal rootfs is (so far) 7 Mb, [...] Have a look at the SELF Makefile... you should run $(CROSS_PREFIX)strip --remove-section=.note --remove-section=.comment *.so Whoa! That is better. ~2.8 Mb now, as reported by du. Thanks! -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Unrecognized opcode: `mtdcr'
[..snip...] I think we need to change arch/ppc/Makefile from: ifdef CONFIG_40x CFLAGS := $(CFLAGS) -Wa,-m405 endif To: ifdef CONFIG_4xx CFLAGS := $(CFLAGS) -Wa,-m405 endif Ok, this worked for me. Thanks! (I guess I wasn't so far off track after all.) For the moment. Until there's some 440-specific opcodes we use (are there any?) which means we'll need to do -Wa,-m440. When I had tried -Wa,-m440 before, it wasn't recognized as an option. (but perhaps by do -Wa,-m440, you mean enhance the C compiler and/or assembler.) ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Bitkeeper trouble
On Tue, May 28, 2002 at 04:56:39PM -0500, Stephen Cameron wrote: bk pull used to work, (1 week ago) but now fails for me. [...] What does 'bk parent' say? If it's not bk://ppc.bkbits.net/linuxppc_2_4_devel, try doing: bk parent bk://ppc.bkbits.net/linuxppc_2_4_devel and then pulling again. I'm not sure why, but ppc.bkserver.net seems to be gone. bk parent http://ppc.bkbits.net/linuxppc_2_4_devel bk pull works great. Thanks! -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
bitkeeper question
Hi, I'm not sure if this is the right place to ask. I'm wondering about how (and if) tags are being used for the bk://ppc.bkserver.net/linuxppc_2_4_devel tree. I would like to be able to clone and export a known state (lets call it state_1) of the tree, then later be able to get another known state of the tree (state_2) and have (or be able to generate) a patch that can take me from state_1 to state_2. I guess I can do this by doing bk export -r state_1 state_1 then, later after some bk pulls have been done, bk export -r state_2 state_2 provided that state_1 and state_2 are the two tags. But, i don't know what the tags are that people are using, if any. Or am I grossly misunderstanding bitkeeper? Is it up to me to tag my own clone of the repository whenever I want, and just use bk pull to get the latest stuff, whatever that might be? If there is a regular tagging scheme already in use, I think I'd rather just use those existing tags, as long as I can stay reasonably up to date that way. Thanks for any info. -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
tlbwe, rfci instructions and gcc cross assembler
Tom Rini [mailto:trini at kernel.crashing.org] wrote: On Thu, Apr 11, 2002 at 04:53:18PM -0500, Cameron, Steve wrote: [snip] strace /usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/home/scameron/ppc/testdir/include -c -o head_4xx.o head_4xx.S -Wa,-m405 is missing here. Where should it go? I tried all possibilities I could think of with no luck: [scameron at quandary kernel]$ cat x /usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/home/scameron/ppc/testdir/include -c -o head_4xx.o head_4xx.S -Wa,m405 /usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/home/scameron/ppc/testdir/include -c -Wa,m405 -o head_4xx.o head_4xx.S /usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/home/scameron/ppc/testdir/include -Wa,m405 -c -o head_4xx.o head_4xx.S /usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -Wa,m405 -I/home/scameron/ppc/testdir/include -c -o head_4xx.o head_4xx.S /usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__ -Wa,m405 -D__KERNEL__ -I/home/scameron/ppc/testdir/include -c -o head_4xx.o head_4xx.S /usr/local/ppc/bin/powerpc-linux-gcc -Wa,m405 -D__ASSEMBLY__ -D__KERNEL__ -I/home/scameron/ppc/testdir/include -c -o head_4xx.o head_4xx.S [scameron at quandary kernel]$ sh x Assembler messages: Error: can't open m405 for reading m405: No such file or directory head_4xx.S:111: Error: Unrecognized opcode: `tlbwe' head_4xx.S:112: Error: Unrecognized opcode: `tlbwe' head_4xx.S:420: Error: Unrecognized opcode: `rfci' Assembler messages: Error: can't open m405 for reading m405: No such file or directory head_4xx.S:111: Error: Unrecognized opcode: `tlbwe' head_4xx.S:112: Error: Unrecognized opcode: `tlbwe' head_4xx.S:420: Error: Unrecognized opcode: `rfci' Assembler messages: Error: can't open m405 for reading m405: No such file or directory head_4xx.S:111: Error: Unrecognized opcode: `tlbwe' head_4xx.S:112: Error: Unrecognized opcode: `tlbwe' head_4xx.S:420: Error: Unrecognized opcode: `rfci' Assembler messages: Error: can't open m405 for reading m405: No such file or directory head_4xx.S:111: Error: Unrecognized opcode: `tlbwe' head_4xx.S:112: Error: Unrecognized opcode: `tlbwe' head_4xx.S:420: Error: Unrecognized opcode: `rfci' Assembler messages: Error: can't open m405 for reading m405: No such file or directory head_4xx.S:111: Error: Unrecognized opcode: `tlbwe' head_4xx.S:112: Error: Unrecognized opcode: `tlbwe' head_4xx.S:420: Error: Unrecognized opcode: `rfci' Assembler messages: Error: can't open m405 for reading m405: No such file or directory head_4xx.S:111: Error: Unrecognized opcode: `tlbwe' head_4xx.S:112: Error: Unrecognized opcode: `tlbwe' head_4xx.S:420: Error: Unrecognized opcode: `rfci' ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
tlbwe, rfci instructions and gcc cross assembler
You did -Wa,m405, not -Wa,-m405. What tree is this from anyhow, this has been fixed in linuxppc_2_4_devel for awhile now. Doh! At least daily, I prove myself to be an idiot. Of course it works if I put the dash in there. I'm using linuxppc_2_4. I thought that'd be more stable than linuxppc_2_4_devel. Maybe that wasn't such a good choice. I'll give linuxppc_2_4_devel a try, since I'm not sure how to fix the Makefiles anyway. (I think ASFLAGS = -Wa,-m405, but I'm don't know how to tie it in with Config.in.) Thanks, -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
tlbwe, rfci instructions and gcc cross assembler
I wrote about trouble compiling linuxppc_2_4
kernel on i686-powerpc cross compiler:
[...]
/usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__
-D__KERNEL__ -I/home/scameron/ppc/testdir/include -c -o
head_4xx.o head_4xx.S
head_4xx.S: Assembler messages:
head_4xx.S:111: Error: Unrecognized opcode: `tlbwe'
head_4xx.S:112: Error: Unrecognized opcode: `tlbwe'
head_4xx.S:420: Error: Unrecognized opcode: `rfci'
make[1]: *** [head_4xx.o] Error 1
make[1]: Leaving directory
I have a bit more info. Looking through my binutils
(v. 2.12.90.0.4) I see some references to tlbwe so
I would think my binutils is recent enough...but
perhaps still broken?
So thinking maybe I wasn't running the assembler
I thought I was running, I did this:
cd /home/scameron/ppc/testdir/arch/ppc/kernel
strace /usr/local/ppc/bin/powerpc-linux-gcc -D__ASSEMBLY__ -D__KERNEL__
-I/home/scameron/ppc/testdir/include -c -o head_4xx.o head_4xx.S
[...]
access(/usr/local/ppc/powerpc-linux/bin/as, X_OK) = 0
vfork() = 16198
wait4(-1, head_4xx.S: Assembler messages:
head_4xx.S:111: Error: Unrecognized opcode: `tlbwe'
head_4xx.S:112: Error: Unrecognized opcode: `tlbwe'
head_4xx.S:420: Error: Unrecognized opcode: `rfci'
[WIFEXITED(s) WEXITSTATUS(s) == 1], 0, NULL) = 16198
--- SIGCHLD (Child exited) ---
stat64(head_4xx.o, 0xb780)= -1 ENOENT (No such file or directory)
stat64(/tmp/cc7egQ8n.s, {st_mode=S_IFREG|0600, st_size=49044, ...}) = 0
unlink(/tmp/cc7egQ8n.s) = 0
_exit(1)= ?
So, I'm running /usr/local/ppc/powerpc-linux/bin/as
for my assembler, which seems right. Let me try:
strings /usr/local/ppc/powerpc-linux/bin/as | grep tlbwe
tlbwe
tlbwelo
tlbwehi
So...looks like my assembler has at least _some_ kind
of knowledge of the tlbwe instruction. Looking through
my binutils source, I see the tlbwe instruction in
a big table along with other instructions in
opcodes/ppc-opc.c
Hmmm, running out of ideas here.
-- steve
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
