Re: [coreboot] Black window when running qemu with coreboot+LegacyBIOS

[Zhang Rui]

Hi Kevin,

2008/6/19 Kevin O'Connor :
> Please 'cc the coreboot mailing list too.

OK.
> On Thu, Jun 19, 2008 at 09:29:29AM +0800, Zhang Rui wrote:
> > Hello,
> >
> > I build the latest code of LegacyBIOS and get bios.bin.elf.  Then use
> > it as payload of coreboot. Then I put bios.bin produced by coreboot
> > and Vgabios-cirrus in one directory.
> > And then run "qemu -L <directory of Vgabios-cirrus and bios.bin> -hda
> > /dev/zero -serial stdio".   But I get a black window of qemu with no
> > output and cannot close. There are lots of messages in the command
> > console.
> >
> > Is that OK or is there any problem?
>
> You've done well to get this far.  You have an issue with coreboot:
> > the message in the console:
> >
> > coreboot-3.0.674 Thu Jun 19 08:39:43 CST 2008 starting...
>
> [...]
> > LAR: Attempting to open 'normal/payload/segment0'.
> > LAR: Start 0xfffc0000 len 0x40000
> > LAR: seen member normal/option_table
> > LAR: seen member normal/initram/segment0
> > LAR: seen member normal/stage2/segment0
> > LAR: seen member normal/stage2/segment1
> > LAR: seen member normal/stage2/segment2
> > LAR: seen member normal/payload/segment0
> > LAR: CHECK normal/payload/segment0 @ 0xfffc43c0
> > start 0xfffc4410 len 20789 reallen 65652 compression 1 entry
> > 0x000f66e0 loadaddress 0x08048000
> > LAR: Compression algorithm #1 (lzma) used
> > Decoding error = 1
>
> The above is not right.
>
> To compare, I get:
>
> LAR: Attempting to open 'normal/payload/segment0'.
> LAR: Start 0xfffc0000 len 0x40000
> LAR: seen member normal/option_table
> LAR: seen member normal/initram/segment0
> LAR: seen member normal/stage2/segment0
> LAR: seen member normal/stage2/segment1
> LAR: seen member normal/stage2/segment2
> LAR: seen member normal/payload/segment0
> LAR: CHECK normal/payload/segment0 @ 0xfffc3e30
> start 0xfffc3e80 len 21037 reallen 65536 compression 1 entry 0x000f66a0 loadaddress 0x000f0000
> LAR: Compression algorithm #1 (lzma) used
>
> You have an incorrect reallen and loadaddress.  You can use "objdump
> -x bios.bin.elf" to confirm that the elf file is correct.  I get:
>
> $ objdump -x out/bios.bin.elf
>
> out/bios.bin.elf:     file format elf32-i386
> out/bios.bin.elf
> architecture: i386, flags 0x00000112:
> EXEC_P, HAS_SYMS, D_PAGED
> start address 0x000f66a0
>
> Program Header:
>    LOAD off    0x00001000 vaddr 0x000f0000 paddr 0x000f0000 align 2**12
>         filesz 0x00010000 memsz 0x00010000 flags rw-
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  0 .data         00010000  000f0000  000f0000  00001000  2**0
>                  CONTENTS, ALLOC, LOAD, DATA
> SYMBOL TABLE:
> 000f0000 l    d  .data  00000000 .data
> 00010000 g       *ABS*  00000000 _binary_out_bios_bin_size
> 00100000 g       *ABS*  00000000 __bss_start
> 00100000 g       .data  00000000 _binary_out_bios_bin_end
> 00100000 g       *ABS*  00000000 _edata
> 00100000 g       *ABS*  00000000 _end
> 000f0000 g       .data  00000000 _binary_out_bios_bin_start
>
> -Kevin

You are right.  There is something wrong with my elf file. The address
and size is not correct.
Here is the message about my bios.bin.elf:

legacybios/out> objdump -x bios.bin.elf
bios.bin.elf:     file format elf32-i386
bios.bin.elf
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x000f66e0

Program Header:
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x00010074 memsz 0x00010074 flags rw-

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00010000  08048074  08048074  00000074  2**0
                  CONTENTS, ALLOC, LOAD, DATA
SYMBOL TABLE:
08048074 l    d  .data  00000000 .data
00000000 l    d  *ABS*  00000000 .shstrtab
00000000 l    d  *ABS*  00000000 .symtab
00000000 l    d  *ABS*  00000000 .strtab
00010000 g       *ABS*  00000000 _binary_out_bios_bin_size
08058074 g       *ABS*  00000000 __bss_start
08058074 g       .data  00000000 _binary_out_bios_bin_end
08058074 g       *ABS*  00000000 _edata
08058074 g       *ABS*  00000000 _end
08048074 g       .data  00000000 _binary_out_bios_bin_start

What could be wrong in my building process? I build LegacyBIOS again
with the config.h setting in http://www.coreboot.org/LegacyBIOS and
the result is the same.

Here is the building message:
[...]legacybios> make AVOIDCOMBINE=1
mkdir out
  Compiling whole program out/blob.16.s
In file included from out/blob.16.s.tmp.c:7:
out/../src/kbd.c: In function 'process_key':
out/../src/kbd.c:658: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:659: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:661: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:662: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:667: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:673: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:674: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:676: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:677: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:682: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:683: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:685: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/kbd.c:686: warning: dereferencing type-punned pointer will
break strict-aliasing rules
In file included from out/blob.16.s.tmp.c:12:
out/../src/disk.c: In function 'extended_access':
out/../src/disk.c:135: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:136: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:138: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:150: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c: In function 'disk_1348':
out/../src/disk.c:358: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:375: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:378: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:381: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:390: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:396: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:405: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:407: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:408: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:462: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:463: warning: dereferencing type-punned pointer will
break strict-aliasing rules
out/../src/disk.c:466: warning: dereferencing type-punned pointer will
break strict-aliasing rules
In file included from out/blob.16.s.tmp.c:13:
out/../src/cdrom.c: At top level:
out/../src/disk.h:111: warning: 'cdrom_read_emu' declared inline after
being called
out/../src/disk.h:111: warning: previous declaration of
'cdrom_read_emu' was here
out/../src/cdrom.c: In function 'cdemu_134b':
out/../src/cdrom.c:282: warning: dereferencing type-punned pointer
will break strict-aliasing rules
out/../src/cdrom.c:283: warning: dereferencing type-punned pointer
will break strict-aliasing rules
out/../src/cdrom.c:284: warning: dereferencing type-punned pointer
will break strict-aliasing rules
out/../src/cdrom.c:285: warning: dereferencing type-punned pointer
will break strict-aliasing rules
  Generating assembler for src/font.c
  Moving data sections to text in out/font.16.s
  Generating assembler for src/cbt.c
  Moving data sections to text in out/cbt.16.s
  Generating assembler for src/floppy_dbt.c
  Moving data sections to text in out/floppy_dbt.16.s
  Generating 16bit layout of out/romlayout16.o
  Precompiling src/rombios16.lds.S
  Linking out/rom16.o
  Extracting binary out/rom16.bin
  Generating symbol offset header out/rom16.offset.auto.h
  Compiling whole program out/romlayout32.o
  Precompiling src/rombios32.lds.S
  Linking out/rom32.o
  Extracting binary out/rom32.bin
  Generating symbol offset header out/rom32.offset.auto.h
  Building out/bios.bin
Writing output rom out/bios.bin
 16bit C-code size: 26336
 32bit C-code size: 11044
 Total C-code size: 37380

Black window when running qemu with coreboot+LegacyBIOS

[Kevin O'Connor]

On Thu, Jun 19, 2008 at 04:00:04PM +0800, Zhang Rui wrote:
> 2008/6/19 Kevin O'Connor :
> > $ objdump -x out/bios.bin.elf
> >
> > out/bios.bin.elf:     file format elf32-i386
> > out/bios.bin.elf
> > architecture: i386, flags 0x00000112:
> > EXEC_P, HAS_SYMS, D_PAGED
> > start address 0x000f66a0
> >
> > Program Header:
> >    LOAD off    0x00001000 vaddr 0x000f0000 paddr 0x000f0000 align 2**12
> >         filesz 0x00010000 memsz 0x00010000 flags rw-
> >
> > Sections:
> > Idx Name          Size      VMA       LMA       File off  Algn
> >  0 .data         00010000  000f0000  000f0000  00001000  2**0
> >                  CONTENTS, ALLOC, LOAD, DATA
> > SYMBOL TABLE:
> > 000f0000 l    d  .data  00000000 .data
> > 00010000 g       *ABS*  00000000 _binary_out_bios_bin_size
> > 00100000 g       *ABS*  00000000 __bss_start
> > 00100000 g       .data  00000000 _binary_out_bios_bin_end
> > 00100000 g       *ABS*  00000000 _edata
> > 00100000 g       *ABS*  00000000 _end
> > 000f0000 g       .data  00000000 _binary_out_bios_bin_start
>
> legacybios/out> objdump -x bios.bin.elf
> bios.bin.elf:     file format elf32-i386
> bios.bin.elf
> architecture: i386, flags 0x00000112:
> EXEC_P, HAS_SYMS, D_PAGED
> start address 0x000f66e0
>
> Program Header:
>     LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
>          filesz 0x00010074 memsz 0x00010074 flags rw-
>
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .data         00010000  08048074  08048074  00000074  2**0
>                   CONTENTS, ALLOC, LOAD, DATA
> SYMBOL TABLE:
> 08048074 l    d  .data  00000000 .data
> 00000000 l    d  *ABS*  00000000 .shstrtab
> 00000000 l    d  *ABS*  00000000 .symtab
> 00000000 l    d  *ABS*  00000000 .strtab
> 00010000 g       *ABS*  00000000 _binary_out_bios_bin_size
> 08058074 g       *ABS*  00000000 __bss_start
> 08058074 g       .data  00000000 _binary_out_bios_bin_end
> 08058074 g       *ABS*  00000000 _edata
> 08058074 g       *ABS*  00000000 _end
> 08048074 g       .data  00000000 _binary_out_bios_bin_start

Looks like a difference between our versions of 'ld'.  The build
effectively does:

ld -melf_i386 -e 0xf66e0 -Ttext 0xf0000 -b binary bios.bin -o bios.bin.elf

I'm not sure why it builds a different elf on your machine.  Can you
try modifying tools/buildrom.py so that it uses "-Tdata" instead of
"-Ttext"?

Myles, maybe this was the same problem you were seeing?

-Kevin

Black window when running qemu with coreboot+LegacyBIOS

[Zhang Rui]

2008/6/19 Kevin O'Connor :
> Looks like a difference between our versions of 'ld'.  The build
> effectively does:
>
> ld -melf_i386 -e 0xf66e0 -Ttext 0xf0000 -b binary bios.bin -o bios.bin.elf

my ld version information:
[...]legacybios> ld --version
GNU ld version 2.16.91.0.5 20051219 (SUSE Linux)
> I'm not sure why it builds a different elf on your machine.  Can you
> try modifying tools/buildrom.py so that it uses "-Tdata" instead of
> "-Ttext"?

I get the right elf file after I executed:
        ld -melf_i386 -e 0xf66e0 -Tdata 0xf0000 -b binary bios.bin -o
bios.bin.elf

here is the elf information:
out/bios.bin.elf:     file format elf32-i386
out/bios.bin.elf
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x000f66e0

Program Header:
    LOAD off    0x00001000 vaddr 0x000f0000 paddr 0x000f0000 align 2**12
         filesz 0x00010000 memsz 0x00010000 flags rw-

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00010000  000f0000  000f0000  00001000  2**0
                  CONTENTS, ALLOC, LOAD, DATA
SYMBOL TABLE:
000f0000 l    d  .data  00000000 .data
00000000 l    d  *ABS*  00000000 .shstrtab
00000000 l    d  *ABS*  00000000 .symtab
00000000 l    d  *ABS*  00000000 .strtab
00010000 g       *ABS*  00000000 _binary_out_bios_bin_size
00100000 g       *ABS*  00000000 __bss_start
00100000 g       .data  00000000 _binary_out_bios_bin_end
00100000 g       *ABS*  00000000 _edata
00100000 g       *ABS*  00000000 _end
000f0000 g       .data  00000000 _binary_out_bios_bin_start

And then I build it as payload of coreboot and then run qemu with coreboot.
I get the following messages in the console:

[...]
Stage2 code done.
LAR: Attempting to open 'normal/payload/segment0'.
LAR: Start 0xfffc0000 len 0x40000
LAR: seen member normal/option_table
LAR: seen member normal/initram/segment0
LAR: seen member normal/stage2/segment0
LAR: seen member normal/stage2/segment1
LAR: seen member normal/stage2/segment2
LAR: seen member normal/payload/segment0
LAR: CHECK normal/payload/segment0 @ 0xfffc43c0
start 0xfffc4410 len 20752 reallen 65536 compression 1 entry
0x000f66e0 loadaddress 0x000f0000
LAR: Compression algorithm #1 (lzma) used
LAR: Attempting to open 'normal/payload/segment1'.
LAR: Start 0xfffc0000 len 0x40000
LAR: seen member normal/option_table
LAR: seen member normal/initram/segment0
LAR: seen member normal/stage2/segment0
LAR: seen member normal/stage2/segment1
LAR: seen member normal/stage2/segment2
LAR: seen member normal/payload/segment0
LAR: seen member bootblock
LAR: File not found!
LAR: load_file: No such file 'normal/payload/segment1'
LAR: load_file_segments: All loaded, entry 0x000f66e0
Start bios
bios_table_addr: 0x000ff0a5 end=0x000ff841
ram_size=0x08000000
Scan for VGA option rom
Benter handle_10: a=00000e42 b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000fca0
Ienter handle_10: a=00000e49 b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000fca0
Oenter handle_10: a=00000e4f b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000fca0
Senter handle_10: a=00000e53 b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000fca0
 enter handle_10: a=00000e20 b=00000000 c=00000000 d=00000000
si=00000000 di=00000000

[...]

enter handle_10: a=00000e0d b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000f664
enter handle_10: a=00000e0a b=00000000 c=00000000 d=00000000
si=00000000 di=00000000
  ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000f674
enter handle_18: NULL
No bootable device.

Is that OK?
Thanks for help. ^_^

Zhang Rui

Black window when running qemu with coreboot+LegacyBIOS

[Kevin O'Connor]

On Fri, Jun 20, 2008 at 11:01:14AM +0800, Zhang Rui wrote:
> 2008/6/19 Kevin O'Connor :
> I get the right elf file after I executed:
>         ld -melf_i386 -e 0xf66e0 -Tdata 0xf0000 -b binary bios.bin -o
> bios.bin.elf

Okay, thanks.  I've checked this change into latest git.
> And then I build it as payload of coreboot and then run qemu with coreboot.
> I get the following messages in the console:
>
> [...]
> enter handle_10: a=00000e0a b=00000000 c=00000000 d=00000000
> si=00000000 di=00000000
>   ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000f674
> enter handle_18: NULL
> No bootable device.
>
> Is that OK?

You have succesfully launched LegacyBIOS.  However, the vga rom was
not found.  Make sure you're running with the latest vgabios.  Also,
you probably haven't specified a floppy, hard drive, or cdrom to boot
from.

-Kevin

Black window when running qemu with coreboot+LegacyBIOS

[Jordan Crouse]

On 20/06/08 08:56 -0400, Kevin O'Connor wrote:
> On Fri, Jun 20, 2008 at 11:01:14AM +0800, Zhang Rui wrote:
> > 2008/6/19 Kevin O'Connor :
> > I get the right elf file after I executed:
> >         ld -melf_i386 -e 0xf66e0 -Tdata 0xf0000 -b binary bios.bin -o
> > bios.bin.elf
>
> Okay, thanks.  I've checked this change into latest git.
> > And then I build it as payload of coreboot and then run qemu with coreboot.
> > I get the following messages in the console:
> >
> > [...]
> > enter handle_10: a=00000e0a b=00000000 c=00000000 d=00000000
> > si=00000000 di=00000000
> >   ds=00000000 es=00000000 ip=0000e818 cs=0000f000 f=00000002 r=0000f674
> > enter handle_18: NULL
> > No bootable device.
> >
> > Is that OK?
>
> You have succesfully launched LegacyBIOS.  However, the vga rom was
> not found.  Make sure you're running with the latest vgabios.  Also,
> you probably haven't specified a floppy, hard drive, or cdrom to boot
> from.

We should discuss what needs to be done to bring this goodness to buildrom.

Jordan

Black window when running qemu with coreboot+LegacyBIOS

[Myles Watson]

> > You have succesfully launched LegacyBIOS.  However, the vga rom was
> > not found.  Make sure you're running with the latest vgabios.  Also,
> > you probably haven't specified a floppy, hard drive, or cdrom to boot
> > from.
>
> We should discuss what needs to be done to bring this goodness to
> buildrom.

I submitted a patch a while ago.  After Uwe's suggestions, the only response
I got was from Peter saying that Kevin should decide on the name before we
committed it.

Thanks,
Myles

Black window when running qemu with coreboot+LegacyBIOS

[Jordan Crouse]

On 23/06/08 10:14 -0600, Myles Watson wrote:
> > > You have succesfully launched LegacyBIOS.  However, the vga rom was
> > > not found.  Make sure you're running with the latest vgabios.  Also,
> > > you probably haven't specified a floppy, hard drive, or cdrom to boot
> > > from.
> >
> > We should discuss what needs to be done to bring this goodness to
> > buildrom.
>
> I submitted a patch a while ago.  After Uwe's suggestions, the only response
> I got was from Peter saying that Kevin should decide on the name before we
> committed it.

Ugh - where was I?  Please send it again - We can fight the name battle
later.

Jordan

Black window when running qemu with coreboot+LegacyBIOS

[Stefan Reinauer]

Jordan Crouse wrote:
> On 23/06/08 10:14 -0600, Myles Watson wrote:
> > > > You have succesfully launched LegacyBIOS.  However, the vga rom was
> > > > not found.  Make sure you're running with the latest vgabios.  Also,
> > > > you probably haven't specified a floppy, hard drive, or cdrom to boot
> > > > from.
> > >
> > > We should discuss what needs to be done to bring this goodness to
> > > buildrom.
> >
> > I submitted a patch a while ago.  After Uwe's suggestions, the only response
> > I got was from Peter saying that Kevin should decide on the name before we
> > committed it.
>
> Ugh - where was I?  Please send it again - We can fight the name battle
> later.

Please, before we get this into buildrom, let's get it straight first. 
Zhang Rui is working on integration of LegacyBIOS for all purposes, not 
just int19 booting. It will replace a lot of code in current coreboot. 
We should consider keeping it in util/ in the v3 tree.

Stefan

Black window when running qemu with coreboot+LegacyBIOS

[Jordan Crouse]

On 23/06/08 18:26 +0200, Stefan Reinauer wrote:
> Jordan Crouse wrote:
> > On 23/06/08 10:14 -0600, Myles Watson wrote:
> > > > > You have succesfully launched LegacyBIOS.  However, the vga rom was
> > > > > not found.  Make sure you're running with the latest vgabios.  Also,
> > > > > you probably haven't specified a floppy, hard drive, or cdrom to boot
> > > > > from.
> > > >
> > > > We should discuss what needs to be done to bring this goodness to
> > > > buildrom.
> > >
> > > I submitted a patch a while ago.  After Uwe's suggestions, the only response
> > > I got was from Peter saying that Kevin should decide on the name before we
> > > committed it.
> >
> > Ugh - where was I?  Please send it again - We can fight the name battle
> > later.
>
> Please, before we get this into buildrom, let's get it straight first. 
> Zhang Rui is working on integration of LegacyBIOS for all purposes, not 
> just int19 booting. It will replace a lot of code in current coreboot. 
> We should consider keeping it in util/ in the v3 tree.

I'm not sure what that has to do with the price of tea in China.  Does
it build seperately from coreboot or not?  If it does, then it belongs in
buildrom.  We can always change what it is named or where it lives later.

Jordan

Black window when running qemu with coreboot+LegacyBIOS

[Stefan Reinauer]

Jordan Crouse wrote:
> I'm not sure what that has to do with the price of tea in China.  Does
> it build seperately from coreboot or not?

Not anymore after GSoC is done.

Thanks,

Stefan

Black window when running qemu with coreboot+LegacyBIOS

[Jordan Crouse]

On 23/06/08 18:41 +0200, Stefan Reinauer wrote:
> Jordan Crouse wrote:
> > I'm not sure what that has to do with the price of tea in China.  Does
> > it build seperately from coreboot or not?
>
> Not anymore after GSoC is done.

I'm just trying to get as many people exposed to it as possible.  But if 
there is an advantage to waiting a few weeks, then I'm fine with that.

Jordan

Black window when running qemu with coreboot+LegacyBIOS

[Myles Watson]

> From: Stefan Reinauer [mailto:[e-mail]]
> Jordan Crouse wrote:
> > I'm not sure what that has to do with the price of tea in China.  Does
> > it build seperately from coreboot or not?
>
> Not anymore after GSoC is done.

I'm interested in more than one line here.  Why would LegacyBIOS be more
tightly integrated than any other payload?  What parts will be tightly
integrated?

Thanks,
Myles

Black window when running qemu with coreboot+LegacyBIOS

[Kevin O'Connor]

Hi,

On Mon, Jun 23, 2008 at 06:26:45PM +0200, Stefan Reinauer wrote:
> Please, before we get this into buildrom, let's get it straight first.  
> Zhang Rui is working on integration of LegacyBIOS for all purposes, not  
> just int19 booting. It will replace a lot of code in current coreboot.  
> We should consider keeping it in util/ in the v3 tree.

I think it is a bad idea to copy the LegacyBIOS code into another
repo.  I believe there should be one main repository that qemu, bochs,
kvm, etc. can all use.  See also:

http://www.coreboot.org/pipermail/coreboot/2008-June/035788.html

-Kevin

Black window when running qemu with coreboot+LegacyBIOS

[Myles Watson]

On Mon, Jun 23, 2008 at 4:33 PM, Kevin O'Connor  wrote:
> Hi,
>
> On Mon, Jun 23, 2008 at 06:26:45PM +0200, Stefan Reinauer wrote:
> > Please, before we get this into buildrom, let's get it straight first.
> > Zhang Rui is working on integration of LegacyBIOS for all purposes, not
> > just int19 booting. It will replace a lot of code in current coreboot.
> > We should consider keeping it in util/ in the v3 tree.
>
> I think it is a bad idea to copy the LegacyBIOS code into another
> repo.  I believe there should be one main repository that qemu, bochs,
> kvm, etc. can all use.

I agree.  The more people we can serve with the same code base, the
more stable it will be.

Thanks,
Myles