[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