LBA vs CHS?

I've got an issue I'm trying to figure out, and it looks to me as
though it has something to do with a BIOS int 0x13 function 2 call
ignoring the cylinder number.  I'm hoping the collective wisdom here
can point me in a useful direction.

I have a machine (a fairly old one, a Soekris net4501).  I wanted to
give it a nontrivial amount of storage.  The only mass storage it has
onboard is a CompactFlash socket.  (It has two expansion bus
connectors, and I probably could use one of them if I have to, but I'd
rather not.)

So I picked up an advertised-as-16G CF (and, yes, it is only 16
artifically-shrunken disk-manufacturer GB - "wd0: 16279 MB" - but 14.9G
is big enough for my purposes).

But, upon trying to install on it, bootxx_ffsv1 was having trouble
loading /boot.  I've been sprinkling debugging around.  It is
definitely reading the wrong blocks off the CF "disk"...and it appears
that the BIOS call it's using, int 0x13 function 2, is ignoring the
cylinder number.  (I'm doing this with my mutant 5.2, but this is all
about bootxx_ffsv1 code, so, unless bootxx_ffsv1 has been substantially
worked over, I doubt the OS rev matters.)

The CF shows up as

wd0 at atabus0 drive 0: <ATP COMPACT FLASH>
wd0: drive supports 1-sector PIO transfers, LBA48 addressing
wd0: 15279 MB, 31045 cyl, 16 head, 63 sec, 512 bytes/sect x 31293360 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)

and everything seems to be fine, except that the BIOS (int 0x13
function 8) reports the disk as having 256 heads (and 63 sectors), and,
as I said above, ignores the cylinder number when doing reads.  For
example, if the booter tries to read sector 16399, it uses cyl=1 hd=4
sec=19, which is correct given the geometry it's got, but it actually
obtains the sector that NetBSD (running diskless) considers sector 271,
(4*63)+19.

Has, perchance, anyone run into something similar and have any hints
for dealing with it?  Is this simply a BIOS bug?  In theory, of course,
this can be worked around, by using a /boot that has its own driver for
the disk interface, but that would be a significant departure from the
current state of /boot, so I'd rather not.

I could put the kernel and /boot in a partition entirely below the
problem point, but then there wouldn't be enough room for two kernels,
which makes changing kernels a bit difficult.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B