Tigon3 driver, broadcom 5307, 440GP, working?
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? -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
More ioremap trouble (sock_recvmsg)
Hello,
Hmm, I'm *still* having trouble with ioremap on powerpc,
but at least it's different trouble. (It still works fine on x86).
Here's the situation: IBM ebony (440) board w/ 128Mb RAM.
Boot kernel with "mem=64M", then use ioremap to access the
unused 64M RAM.
ioremapped_buffer = ioremap(1024*1024*64, 1024*1024*64);
I'm able to DMA between this memory and a PCI device, although
I have to do virtual-physical address translation myself (pci_map_single
won't do it, virt_to_phys just subtracts C-zillion, turns out wrong, since
I ioremapped the memory myself, the translation is trivial.)
I can also memset()/memcpy() to/from this ioremapped_buffer just fine.
I'm trying to use sock_recvmsg to receive into this ioremapped buffer.
It works, sometimes, but crashes inside __copy_tofrom_user eventually.
It does not appear to always do the exact same thing. This could be due to
the network making things behave differently, I suppose.) The iovec
that I used with sock_recvmsg has just one entry, the address, which is
ioremapped_buffer (or some offset from it) and a length.
I tried a sledgehammer approach, replacing copy_to_user with memcpy
when I know the address in question can work that way.
Index: iovec.c
===
RCS file: /linuxcvs/slipstream/sslinux/net/core/iovec.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 iovec.c
--- iovec.c 28 May 2002 16:03:31 - 1.1.1.1
+++ iovec.c 22 Jul 2002 16:04:48 -
@@ -78,7 +78,7 @@
*
* Note: this modifies the original iovec.
*/
-
+extern unsigned char *ioremapped_buffer;
int memcpy_toiovec(struct iovec *iov, unsigned char *kdata, int len)
{
int err = -EFAULT;
@@ -88,8 +88,14 @@
if(iov->iov_len)
{
int copy = min_t(unsigned int, iov->iov_len, len);
- if (copy_to_user(iov->iov_base, kdata, copy))
+ if (ioremapped_buffer != NULL &&
+ iov->iov_base >= ioremapped_buffer &&
+ iov->iov_base <=
+ (ioremapped_buffer + 64*1024*1024))
+ memcpy(iov->iov_base, kdata, copy);
+ else if (copy_to_user(iov->iov_base, kdata, copy)) {
goto out;
+ }
kdata+=copy;
len-=copy;
iov->iov_len-=copy;
(not sure why it's using copy_to_user anyway... I guess probably
normally this is entered from user context via a recv() system call,
in my case, not so, I come here from a kernel thread in a module...):
So this patch makes it work considerably longer. However, again it crashes
inside __copy_tofrom_user, eventually (in a different call). I'm
thinking maybe I can continue in a similar vein, replacing more
copy_to_user() calls with memcpy, but this strikes me as being
inelegant, and I wonder if I'm doing something wrong with my ioremap...
or, is sock_recvmsg designed to be called only from process context
(e.g. not a kernel thread)? If so, then why does it work on x86
but not powerpc?
Thanks,
-- steve
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ioremap on powerpc question
Hmm, I continue to have difficulties...
Matt Porter wrote:
>
>
> On Mon, Jul 15, 2002 at 01:58:21PM -0500, Cameron, Steve wrote:
[...]
> > 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) [...]
> >
> > unsigned char *buf;
> > buf = ioremap_nocache(64*1024*1024, 64*1024*1024);
> >
[...]
> > 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:
>
> = arch/ppc/mm/pgtable.c 1.19 vs edited =
> --- 1.19/arch/ppc/mm/pgtable.cWed Jun 26 15:00:59 2002
> +++ edited/arch/ppc/mm/pgtable.c Mon Jul 15 16:12:32 2002
> @@ -93,7 +93,7 @@
> ioremap(unsigned long addr, unsigned long size)
> {
> unsigned long long addr64;
> - unsigned long long page_4gb = PPC440_IO_PAGE;
> + unsigned long long page_4gb = 0;
>
> /*
>* Trap the least significant 32-bit portions of an
>
Ok, I tried this all day yesterday. This does allow me to
use the virtual address returned by ioremap_nocache. However,
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.
I'm thinking either caching is getting me, or else the physical
address mapped by ioremap is not what I think it is. Attacking
the caching problem first, I tried, just before the DMA,
consistent_sync(buf, length, data_direction);
where buf is (a page aligned offset from) the virtual address returned by
ioremap, length is either the buffer length, or the buffer length
rounded up to next multiple of SMP_CACHE_BYTES (tried both), and data_direction
is in this case, PCI_DMA_FROMDEVICE. (I also tried using for "buf",
virt_to_phys(physaddr) where physaddr was the physical address
which I (presumably) know because I set it up via ioremap...that is
passing 0xC000 + physaddr to consistent_sync...that panicked).
I also tried ioremap() vs. ioremap_nocache(), thinking possibly that
using ioremap_nocache() was somehow short-circuiting the action of
consistent_sync() (though not seeing any code that does that.) No dice.
Always the same result, the DMA does not work.
BTW, my device seems happy with the physical addresses I pass it,
and the response I get from it indicate the DMA occurred...to
_somewhere_. Maybe it's time to break out the pci analyzer.
Any ideas what's going on here?
I caught some idea from someone here at HP that the caching attributes
were implemented on the 440 such that they applied to 128M physical
regions, so it wasn't really possible to set up 64M to be non-cached
with the other 64M cached not sure if that's right or not,
but perhaps it's related to my problem somehow.
>
> You could use alloc_bootmem_pages() to get a large buffer more
> elegantly than lopping off memory and ioremapping. IMHO, it is
> a slightly more flexible approach to large allocations.
>
Since I was having no luck with ioremap, and this did seem more
elegant, I tried this approach too. In init/main.c, I added code
to call alloc_bootmem_pages via a __setup() type function with
the amount of ram to alloc passed on kernel cmdline.
Here, I could allocate memory. However, if I allocated more than
about 8M, the kernel would hang, the last thing output being
"POSIX conformance testing by UNIFIX". I tried allocating 32M,
then 64M, then freeing the original 32M, thknking perhaps the first
allocation was grabbing some specific memory needed by something
later, this allowed things to get a little bit further, but ultimately
panicked the system.
Allocating small amounts of memory (4M), I did get DMA to succeed at
least once, but without being able to get all the memory I need
this wasn't really useful.
I also tried moving the allocation around in main.c to various
places, but found nothing that worked.
Any ideas on this alloc_bootmem_pages front?
Thanks,
-- steve
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cramfs for root filesystem?
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
No guarantees, of course, use at your own risk.
Currently, I get as far as trying to start init with this
patch, (the same filesystem via NFS works fine.) This
may be due to the fact that I haven't touched the kernel
code, (that is, I have not allowed for ramdisk to handle
4k block size, as I've been led to believe I must.)
Here's what I'm seeing when I try to use my rootfs
(not that it's necessarily relevant, but I don't
want to imply that I know my patch is perfect):
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 1270k freed
VFS: Mounted root (cramfs filesystem) readonly.
Freeing unused kernel memory: 196k init
Warning: unable to open an initial console.
Kernel panic: No init found. Try passing init= option to kernel.
<0>Rebooting in 180 seconds..
-- steve
And here's the patch:
diff -u -r1.1.1.1 mkcramfs.c
--- mkcramfs.c 24 Jun 2002 19:22:19 - 1.1.1.1
+++ mkcramfs.c 25 Jun 2002 15:56:42 -
@@ -95,6 +95,7 @@
static char *opt_name = NULL;
static int warn_dev, warn_gid, warn_namelen, warn_skip, warn_size, warn_uid;
+static int swap_endian = 0;
/* In-core version of inode / directory entry. */
struct entry {
@@ -130,6 +131,7 @@
" -i fileinsert a file image into the filesystem (requires
>= 2.4.0)\n"
" -n nameset name of cramfs filesystem\n"
" -p pad by %d bytes for boot code\n"
+ " -r reverse endianness of filesystem\n"
" -s sort directory entries (old option, ignored)\n"
" -v be more verbose\n"
" -z make explicit holes (requires >= 2.3.39)\n"
@@ -372,6 +374,58 @@
return totalsize;
}
+#define wswap(x) (((x)>>24) | (((x)>>8)&0xff00) | \
+ (((x)&0xff00)<<8) | (((x)&0xff)<<24))
+
+/* routines to swap endianness/bitfields in inode/superblock block data */
+static void fix_inode(struct cramfs_inode *inode)
+{
+ if (!swap_endian) return;
+ inode->mode = (inode->mode >> 8) | ((inode->mode&0xff)<<8);
+ inode->uid = (inode->uid >> 8) | ((inode->uid&0xff)<<8);
+ inode->size = (inode->size >> 16) | (inode->size&0xff00) |
+ ((inode->size&0xff)<<16);
+ ((u32*)inode)[2] = wswap(inode->offset | (inode->namelen<<26));
+}
+
+static void fix_offset(struct cramfs_inode *inode, u32 offset)
+{
+ u32 tmp;
+ if (!swap_endian) return;
+ tmp = wswap(((u32*)inode)[2]);
+ ((u32*)inode)[2] = wswap((offset >> 2) | (tmp&0xfc00));
+}
+
+static void fix_block_pointer(u32 *p)
+{
+ if (!swap_endian) return;
+ *p = wswap(*p);
+}
+
+static void fix_super(struct cramfs_super *super)
+{
+ u32 *p = (u32*)super;
+
+ if (!swap_endian) return;
+
+ /* fix superblock fields */
+ p[0] = wswap(p[0]); /* magic */
+ p[1] = wswap(p[1]); /* size */
+ p[2] = wswap(p[2]); /* flags */
+ p[3] = wswap(p[3]); /* future */
+
+ /* fix filesystem info fields */
+ p = (u32*)&super->fsid;
+ p[0] = wswap(p[0]); /* crc */
+ p[1] = wswap(p[1]); /* edition */
+ p[2] = wswap(p[2]); /* blocks */
+ p[3] = wswap(p[3]); /* files */
+
+ fix_inode(&super->root);
+}
+
+#undef wswap
+
/* Returns sizeof(struct cramfs_super), which includes the root inode. */
static unsigned int write_superblock(struct entry *root, char *base, int size)
{
@@ -405,7 +459,9 @@
super->root.uid = CRAMFS_16(root->uid);
super->root.gid = root->gid;
super->root.size = CRAMFS_24(root->size);
+ fix_super(super);
CRAMFS_SET_OFFSET(&(super->root), offset >> 2);
+ fix_offset(&(super->root), offset);
return offset;
}
@@ -421,6 +477,7 @@
die(MKFS_ERROR, 0, "filesystem too big");
}
CRAMFS_SET_OFFSET(inode, offset >> 2);
+ fix_offset(inode, offset);
}
/*
@@ -610,6 +667,7 @@
}
*(u32 *) (base + offset) = CRAMFS_32(curr);
+ fix_block_pointer((u32*)(base + offset));
offset += 4;
} while (size);
@@ -700,7 +758,7 @@
progname = argv[0];
/* command line options */
- while ((c = getopt(argc, argv, "hEe:i:n:psvz")) != EOF) {
+ while ((c = getopt(argc, argv, "hEe:i:n:prsvz")) != EOF) {
switch (c) {
case 'h':
usage(MKFS_OK);
@@ -727,6 +785,10 @@
case 'p':
opt_pad = PAD_SIZE;
fslen_ub += PAD_SIZE;
+ break;
+ case 'r':
+ swap_endian = 1;
+ fprintf(stderr, "Swapping filesystem endianness.\n
cramfs for root filesystem?
I noticed that here, http://penguinppc.org/embedded/howto/root-filesystem.html it says: > It turns out that cramfs is not supported for a root fs or initrd. > Basically, the kernel checks a hardcoded list of supported > filesystems and if the MAGIC number doesn't match it bails. Then, a couple lines later it says this, which clearly implies a read-only cramfs root fs is possible:: > ramfs from the 2.4 kernel is a simple filesystem ideal for use in a > ramdisk. It can be used in combination with a cramfs read-only root > filesystem, to mount writable filesystems on /tmp and /var, which > typically need to be writable. This combination is ideal for > systems which don't require persistent storage. So, I figured I'd try cramfs as a root fs and see if I'm lucky and the first statement is just a mistake, and I get: RAMDISK: Compressed image found at block 0 Freeing initrd memory: 1270k freed cramfs: wrong magic Kernel panic: VFS: Unable to mount root fs on 01:00 <0>Rebooting in 180 seconds.. Well, it appears maybe the first statement is correct. Then again, the message seems to be coming from the cramfs part of the system... So when I made my cramfs, I used mkcramfs which I got today (jun 24 2002) from sourceforge. I noticed older versions had some notes about endianness. This version seems to say that little-endian is the proper format for the filesystem data, and this is what kind of cramfs it makes and the kernel on a big endian machine like mine needs to do the necessary byte swapping to handle it. Also, I created the cramfs on an intel box (little endian) so in any case the fs is little endian. Does the linuxppc_2_4_devel kernel from bitkeeper handle little-endian cramfs filesystems? Or is there a patch for this? Or a patch to mkcramfs to make it create a big-endian cramfs (despite threads I read saying this is the wrong way to proceed.) Or am I on the wrong track completely in trying to use cramfs for a root filesystem? Thanks, -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Anyone used libopt?
Has anyone used this libopt tool? http://libraryopt.sourceforge.net/ It is supposed to be able to rebuild libraries to contain only the objects that are actually used by the programs in your filesystem. There are some "build" scripts it needs per library, and an example for glibc is given: http://libraryopt.sourceforge.net/buildlibc Are there other build scripts for other libraries floating around? The idea of writing my own build scripts, considering how much of the example script I actually grok, is daunting. Any pointers to more explanatory material would be appreciated. Thanks. -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
scsi_to_pci_dma_dir(),
I noticed that scsi_to_pci_dma_dir() appears to only get defined in include/linux/pci.h if CONFIG_PCI is _not_ set. That doesn't seem right. (my linuxppc_2_4_devel tree is maybe 2 weeks old) -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Unrecognized opcode: `mtdcr'
Hi, I just started trying to play with my new Ebony board... I noticed now 'as' complains: Unrecognized opcode: `mtdcr' when I do this: make ebony_config make mrproper make menuconfig make dep make zImage But, if I do this: make walnut_config make mrproper make menuconfig make dpe make zImage I can make a zImage just fine. Of course I can manually add '-Wa,-m405' into my CFLAGS in the Makefile, and it will build ok, but I'm thinking that's not what I want to do. My 'as' says: [scameron at zuul sslinux]$ /usr/local/powerpc-linux/bin/as --version GNU assembler 2.12 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `powerpc-linux'. I also tried binutils 2.12.1, with the same results. Any ideas? Thanks, -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Bitkeeper trouble
"bk pull" used to work, (1 week ago) but now fails for me. [scameron at zuul lxppc24d]$ bk pull drainErrorMsg: Unexpected response: Anybody else seeing that? [scameron at zuul lxppc24d]$ bk version BitKeeper/Free version is bk-2.1.6-pre5 20020330075529 for x86-glibc21-linux Built by: lm at redhat62.bitmover.com in /usr/build/bk-2.1.x-lm/src Built on: Sat Mar 30 00:29:33 PST 2002 [scameron at zuul lxppc24d]$ cat BitKeeper/*/parent http://ppc.bkserver.net/linuxppc_2_4_devel Do I need a newer version of bitkeeper? I didn't see one around. I am going through an http proxy server http_proxy=http://proxy.compaq.com:8080/ (Hmm, I wonder if they changed something about it due to HP-Compaq merger?) thanks for any hints. -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
walnut, external pci arbiter enabled
Hi,
I have a walnut with a PCI board in it that's got a PCI
bus arbiter on ot. The arbiter is not normally used (in x86
systems, where this board is usually used), but it seems
to be causing trouble now. I'm told (in a vague sort of way)
the arbiter on the PCI board only gets turned on if there's no
other PCI arbiter out there.
I'm using the kernel from linuxppc_2_4_devel kernel from
bitkeeper.
I'm seeing this bit of code in arch/ppc/kernel/ppc405_pci.c triggered:
/* Check if running in slave mode */
if ((mfdcr(DCRN_CHPSR) & PSR_PCI_ARBIT_EN) == 0) {
printk("Running as PCI slave, kernel PCI disabled !\n");
return;
}
When I first turn on my walnut, I see this on the console:
405GP 1.15 ROM Monitor (8/9/00)
- System Info --
Processor = 405GP, PVR: 401100c4
Processor speed = 200 MHz
PLB speed = 100 MHz
OPB speed = 50 MHz
Ext Bus speed = 33 MHz
PCI Bus speed = 33 MHz (Sync)
Amount of SDRAM = 32 MBytes
External PCI arbiter enabled<--- This looks like trouble
Then on booting, "Running as PCI slave, kernel PCI disabled !"
comes out.
Consequently, I can't access the board, which is just sitting
there waiting for somebody to set its BARs.
Any ideas? New ROM maybe?
Thanks,
-- steve
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
IBM walnut, gcc, NIC and recent kernel?
Hi, Lately I find myself playing around with this IBM walnut board and hardhat linux 1.2 with a 2.4.0 based kernel, cross compiling with Montavista's gcc on an intel box. I'd like to use a more recent kernel, but I have some questions. I downloaded 2.4.18 along with the powerpc patch from kernel.org. Then, changed the Makefile to set CROSS_COMPILE = to montavista's compiler, and ARCH = ppc. Then it seems the walnut's network driver turns up missing, so I tried copying over the *405*.[ch] files from the drivers/net directory of the 2.4.0 montavista kernel. (realizing that's probably not going to work straightaway) and hacked the Config.in to try to make it attempt a compile. Well, the assembler complained about some "unsupported relocation type" in ppc4xx_pic.o, so I suspect I need a newer gcc, assembler, etc. (had nothing to do with network driver, I think) So, it occurs to me that other folks must be using this walnut, and perhaps solved these problems already. So if someone has recommendations about a specific recent kernel that works well with the walnut, and has network support for it, that'd be nice. Also any hints on getting gcc & friends to work for intel->ppc cross compiler with a recent kernel would be appreciated. Also, if I'd be better off sticking with hardhat linux (or something else) for an embedded application than trying to use the kernel.org kernels for some reasons, please feel free to educate me about that. Thanks, -- steve ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
