[OLPC-devel] Re: LinuxBIOS and integrated system debug status (Friday night).
David Woodhouse
David at Woodhou.se
Sat Aug 26 02:56:35 EDT 2006
On Fri, 2006-08-25 at 23:25 -0400, Jim Gettys wrote:
> 2) If a flash key/disk running ext3 is not shutdown cleanly, LinuxBIOS
> won't boot the file system. This means you have to take the key or disk
> and clean it on a different machine to reboot the machine. This is not a
> blocker, but is sure irritating.
I used ext2 for /boot to avoid this. And ext3 on a flash device isn't a
hugely cunning plan anyway.
> 3) after following the directions to install an image to flash
> (uneventfully), the board I used will no longer boot anything; Samat saw
> this problem a couple weeks ago and again tonight, but no one else had
> reproduced it until I did. The machine says "Jumping to LinuxBIOS" on
> the serial port and then does nothing. Samat has seen this problem on a
> different board tonight as well; it started working again after being
> unplugged for a while (20 minutes). This smells like an uninitialized
> register in the NAND flash, or some such problem. Not a blocker to a
> release, as we can tell people not to install onto NAND until we find
> and fix it.
Do you mean NAND here? This is long before NAND flash is relevant,
surely?
> 4) the current sugar in build 79 looks to not scale itself properly to
> the 1024x768 resolution screen I chose for the default since that is the
> most likely to "just work on everyone's screen" size.
Did we also get the DCON mode in, conditional on actually finding a DCON
on the SMBus?
> o We determined that FC6 and Ubuntu Edgy cannot successfully build a
> ROM image; the resulting image hangs long into the boot sequence. FC5
> and Ubuntu Dapper can build an image reliably. So we'll stop beating
> our heads on this wall for the moment. Half of today was lost on this
> one.
Different compilers?
> I don't think we're quite ready to ship this one yet. Close, very, very,
> very close, but not quite. 1) and 2) are the (potential) blockers. I'd
> probably settle for the Marvell working, and live with the mount problem
> temporarily. We can tell people not to use the NAND until we track it
> down. The sugar problem is pretty minor.
Do we also have some attempt at a resume-from-RAM path?
--
dwmw2
More information about the Devel
mailing list