[OLPC-devel] Re: LinuxBIOS and integrated system debug status (Friday night).

[Richard Smith]

> 1) the Marvell wireless patch to LB does not appear to work, so the
>Marvell wireless won't run from LinuxBIOS: the existing patch was known

Wireless testers.  Please send my a copy of your serial log for the bootup.

By not work does that mean its the same issue?   That it doesn't show
up in the USB enumeration?

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

My experience is different.  I've been using the same ext3 key to drop
my linubios.rom test images on and I routinely mout it when its dirty.
 In fact I often hit the reset button rather than unmount.

The buildrom kernel config only contains ext2 not ext3 so regardless
of what the key is its mounted as ext2

What I _have_ seen though are times when the key either just will not
mount.  Unknown error -2 or maybe -6.  I'll note it next time it
happens.  A reset button hit has always fixed this.  Same board same
key.

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

That's LB copying itself to RAM. I'll enable the quick RAM sanity
check do see if the RAM is somewhat functional prior to the copy.

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

I'm with David.  This is _way_ before the NAND.  LB has no concept of
the NAND.  The kernel payload does all that.

> Did we also get the DCON mode in, conditional on actually finding a DCON
> on the SMBus?

Not in LB.  Send me what you want to check on the SMbus and I'll add
it.  Then we just need to make a decision on how to communicate that
to Linux.

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

LinuxBIOS has seen issues in the past with different system libs.  But
not with anything recient.  Please send me a serial log off the boot
sequence that hangs.

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

Not to my knowledge.

-- 
Richard A. Smith