Subject: Re: Current status (was Reliable network cards? CF cards?)
To: Andy Ruhl <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 01/03/2005 13:02:50
On Sun, 2 Jan 2005, Andy Ruhl wrote:
> > This will work fine so long as the card is *not* CardBus (and supported by
> > NetBSD, of course). Avoid 802.11g -- those are almost always CardBus.
> > 802.11b is typically OK if the chipset is known by NetBSD.
> Got a response from another kind NetBSDer about network cards. I went
> out today and casually looked for cards, and it seems like all newer
> ones are cardbus... Hmm...
Most 802.11b (11Mbit) cards are still 16-bit PCMCIA, from what I've seen (of
cards that are not Windows-binary-only, Winmodem-like el cheapo wireless
Most 10baseT and 100baseTX cards are also 16-bit. If you want something
that works with NetBSD but takes almost no power, watch eBay or look for a
cheap deal on the LP-E (or CF-E, works in a CF type 1 to PCMCIA adapter)
card. It is only 10baseT, but only uses 5-10mA of power compared to a
typical wired card's 100mA and wireless card's 250mA.
> > Heh. I was going to do the same, but never got a Cobalt to do the building
> > after my 880 decided to go permanently screen-blank (a hard drop to the
> > floor did this).
> Ugh. That makes it a lot less useable.
Well, I doubt it'll affect you. I dropped *my* unit on the floor from five
> It would be nice if some kind soul could build mips packages, but I'm not
> sure if it's more complicated than that. Are we all the same endianess?
You said you had a Cobalt box. That is mipsel, as is hpcmips, so you should
have no problem building binary packages on the cobalt to use on the
hpcmips. They're both little endian.
> What I did was I tried to follow Michael Lucas's article at onlamp
> about installing on an hpcarm machine using a CF card. The failure was
> that the Mobilepro 880 doesn't seem to like anything NetBSD does with
> the disklabel and format.
WinCE uses fdisked drives. You might want to try the following:
* boot NetBSD INSTALL kernel
* exit sysinst and run fdisk from the command line:
$ fdisk -au
* make partition 0 type 6 (16-bit FAT), and make it big enough to hold
hpcboot.exe, a gzipped INSTALL kernel, a real kernel, and perhaps some
work area for other kernels and/or storing WinCE data
* make partition 1 type 169 (NetBSD), sized for the rest of the disk
Write down the absolute start sector number and raw sector count of the
16-bit FAT partition. Then:
$ dd if=/dev/zero of=/dev/wd0d bs=512 seek=START count=20
where START is the starting sector of the FAT partition -- this will prompt
WinCE to reformat it. Then reboot into WinCE and tell it Yes to format the
now-shrunken FAT partition. (WinCE 2.1/2.11 has some kind of oddness in its
FAT implementation; it's best to let it format a repartitioned card.)
When you boot back into NetBSD, you'll have the ability to use the
NetBSD-fdisk'ed partition completely isolated from the FAT side. You can
use the absolute sector start and count of the FAT partition in a customized
disklabel to get access to that partition from the NetBSD side.
> I formatted the CF card in Windows, put on pbsdboot.exe and the kernel and
> left it. I was itching to buy one of these little USB storage devices
> anyway, so I found one for $24 after rebate and bought it. It's 256 megs.
> That's enough to get me started.
It'll be much slower than CF, but it should work fine. (You may need to
plug it in at NetBSD boot time; I don't know if a known problem with umass*
buffer allocation is fixed yet in 2.0.)
> But I can hang the thing up hard anytime I try to mount or fsck the
> msdos partition on the CF card. I can read the disklabel and fdisk,
> but nothing more than that. Ugh.
I'm suspicious that it's an overlap problem between the NetBSD disklabel and
the FAT partition.
> Also, I extracted xbase, xserver and xetc. I was messing around with
> the binary X and somehow hung the entire machine again. Don't know
> what happened.
It's a little touchy if not run properly. I can't entirely remember what
the issue was, though. It may have to do with using /dev/console vs.
/dev/ttyE0 as the "on" entry in /etc/ttys.
-- Todd Vierling <firstname.lastname@example.org> <email@example.com>