David,
The attached sounds like the cause of BIOS freakout problem.... You may
not have waded through to this mail yet....
- Jim
On Tue, 2006-08-22 at 12:19 -0400, David Zeuthen wrote:
> On Mon, 2006-08-21 at 22:13 -0400, Ivan Krstić wrote:
> > Hey folks,
> >
> > I just poked around a bit; we're currently blocking on a couple of
> > things before we can release instructions for upgrading to LinuxBIOS.
> >
> > - OLPC Fedora build 59, marked 'last stable', doesn't contain fbdev and
> > the requisite bits that LinuxBIOS is counting on, so we need a more
> > recent stable build to actually upgrade.
>
> We don't mark builds as stable until we're happy with them.
>
> This includes booting off the targets we want to support
>
> - USB image @ devboard with Insyde BIOS
> - NAND image @ devboard with Insyde BIOS, booting via USB and kexec'ing
> into a kernel loaded from NAND (select OLPC NAND in grub on the USB
> stick)
> - qemu image
>
> now our criterion also includes
>
> - USB image for devboard with LinuxBIOS
>
> and at some point it will include
>
> - NAND flash image for devboard with LinuxBIOS
>
>
> > - David, can you brief us on where your machine currently stands? If I
> > understand correctly, you've successfully flashed it with LinuxBIOS, but
> > don't have it giving a usable VGA signal (is it expecting the DCON to be
> > there?), so you can only use it through ssh. Is this accurate? How long
> > will this take to fix?
>
> I was able to follow the instructions on the Wiki and have had no
> VGA/DCON signals except with a ROM sent to me by Jordan. I haven't tried
> since Friday though.
>
> The blocker right now is that the BIOS freaks out when trying to boot
> USB. It mounts the image but when the linuxrc script (or one of it child
> scripts) run /usr/bin/[ busybox says "Memory Exhausted". I've tried to
> work on this but got nowhere - it's not really my area of expertise. So
> I'm kinda waiting for that to get fixed. It's block marking a build as
> stable...
>
> However.. it does work... the BIOS, after freaking out, will drop you to
> a shell on the UART and you can then manually do the following
> ". /key/boot/olpc-boot.sh" and we boot just fine. This works IIRC with
> build72 or build73. The images needs some fixing as to choose the right
> X driver (we just use fbdev(4) which works with both vesafb and gxfb)
> but by and large we start X and things work.
>
> David
>
>
> _______________________________________________
> Devel mailing list
> [email protected]
> http://mailman.laptop.org/mailman/listinfo/devel
--
Jim Gettys
One Laptop Per Child
--- Begin Message ---
Christopher Blizzard wrote:
David, can you brief Mitch on the problems you've been seeing? I know
you and Jordan have been looking at it, but it sounds like you guys
have been going 'round and 'round about it. Might be good to get some
more eyes on the problem with some creative ideas.
I think that the symptom of the problem is listed here:
http://pastebin.com/772962
--Chris
Okay, Jordan and I found it. Jordan noticed that getgroups() was
returning -1, which caused an attempt to allocate a negative number
(i.e. an enormous positive number) of bytes.
I tracked it from there. The problem is that the LB payload kernel is
config'ed to omit UID16 support. But uClibc uses the UID16 version of
the getgroups() syscall.
The solution is to build the payload kernel with CONFIG_UID16=y . I did
that and the "memory exhausted" problem went away. "test -x
/key/olpc-boot.sh" now does the right thing.
Jordan, can you fix this in your master copy, or wherever the right
place is?
Mitch
--- End Message ---
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
