Subject: Re: Current status (was Reliable network cards? CF cards?)
To: Andy Ruhl <>
From: Todd Vierling <>
List: port-hpcmips
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
feet.  8-)

> 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 <> <>