[PATCH] Probe Efika platform before CHRP.

[David Woodhouse]

On Sat, 2007-01-06 at 15:23 -0700, Grant Likely wrote:
> 2. Dwmw2 says that reading the HD has an off-by-one showstopper bug
> which prevents Linux from reading the partition table (and that it is
> the same bug that was on the pegasos, but is now fixed).

It's an off-by-one in partition table numbering. When we ask for
"hd:0" (the whole disk) we get "hd:1", and so on. It screws yaboot's
partition table scan, because when it asks for the first sector of the
disk it's given the first sector of the first partition.

Something very similar to this already got fixed on Pegasos after I
reported it -- and I didn't think it was _particularly_ far-fetched for
me to expect the Efika firmware to be adapted to the "definitions, whims
and determinations" of the CHRP specification too.

> I have not confirmed this issues as I don't have a working HD on my
> Efika.  However, dwmw2 has stated that he cannot support the Efika in
> Fedora until this issue is resolved. 

"Cannot" is a strong word when you're talking about software -- and is
almost always untrue. I think what I said was "can't sensibly", which
makes a lot more sense.

I've got a locally-hacked yaboot which works around it enough to boot my
system, but I'm not going to get far if I suggest that we ship a
different copy of the boot loader just for Efika "because it's speshul".
Especially when the bug was known so long ago.

I think the workaround on Pegasos was to use Amiga partitions, and to
hack (perhaps even unintentionally) the Amiga partition code in yaboot
to compensate for the brokenness. So the Amiga partition code probably
won't work on CHRP-compatible machines, while the rest of the partition
code won't work on Efika/oldPegasos. I baulked at the idea of continuing
this hack by using Amiga partitions on Efika too, and preferred to put
the thing back on the shelf and wait for it to be fixed -- especially as
I'm away for the rest of the month anyway.

-- 
dwmw2