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 _______________________________________________ Devel mailing list [email protected] http://mailman.laptop.org/mailman/listinfo/devel
