legacy bios support and coreboot

[aaron lwe]

Hi kevin,

Great job! Some comments below.
> I suspect the hardware detection and initialization does not have much
>  overlap with coreboot.  The most important part of this section is the
>  IDE initialization and disk scan.  (Some other code, for example
>  keyboard init, may be redundant when used with coreboot.)

yes
> The option rom scan and execution allows the bios code to call out to
>  additional system roms.  The "post" stage runs in 32bit mode, but the
>  option roms are called in 16bit mode - the "legacybios" code simply
>  transitions to/from 16bit mode to make these calls.  The option rom
>  code is executed natively on the processor.

I think this is redundant with coreboot, since coreboot will also run
pci rom, eg. vga bios.
> The "pci init" code looks to be redundant with what coreboot already
>  provides.  The code in "legacybios" seems to be intel
>  northbride/soutbridge specific.

yes, these code could be omitted when used with coreboot.
> Some old DOS programs make assumptions about specific memory locations
>  in the first 1Meg of ram.  The "legacybios" code fills in these areas
>  to make these old programs happy - in short they are the "bios data
>  area" at 0x00000 - 0x00500, the "extended bios data area" at 0x9fc00 -
>  0xa0000, and some hardcoded locations in the 0xf0000 bios segment
>  itself.  The bios working storage areas (in bda and ebda) and the
>  16bit interrupt vector table is also setup (part of the bda).

I think this is necessary.
> It is not clear to me how much of the acpi/mptable/smbios code is
>  reusable on real hardware.  It is possible that most of the info in
>  these tables is irrelevant, and the "legacybios" code may therefore be
>  a good starting point.  However, it may also be simpler to have
>  coreboot just pass these tables in.

I don't think the acpi/mptable is reusable on real hardware, so have
coreboot pass these tables in is better since coreboot developer
should have a better understanding about the mainboard he/she is
developing.
> Some of the hardware accesses made by the "legacybios" code appear to
>  be specific to hardware in the emulator.  The code attempts to enable
>  ram shadowing of the memory segment at 0xf00000 - it does this so that
>  it can put acpi/mptable/smbios tables into that area.  After it is
>  complete, it attempts to disable writes to that region.  The code
>  sequence looks to be specific to intel north/southbridges.  It isn't
>  necessary to disable writes to 0xf0000 (though it would be nice), but
>  it is necessary to have the ability to alter that memory.

This shadowing job should be left to coreboot, if someone is going to
use legacybios, he should take care of this shadowing job in ram init
code.

I've written a loader for coreboot-v2 to load legacybios, it works
well when used with qemu, I've booted freebsd with it. But on real
hardware, via epia-cn, it hangs with a blank screen, the debug port
value is 0x31, I'll take some time to see what's going wrong.

I add a header for legacybios to become a payload, this is done by a
utility createpayload.
I've attached the loader and the utility.
Signed-off-by: Aaron Lwe

Thanks,

[Kevin O'Connor]

Hi Aaron,

On Wed, May 07, 2008 at 10:50:11AM +0800, aaron lwe wrote:
> > The option rom scan and execution allows the bios code to call out to
> >  additional system roms.  The "post" stage runs in 32bit mode, but the
> >  option roms are called in 16bit mode - the "legacybios" code simply
> >  transitions to/from 16bit mode to make these calls.  The option rom
> >  code is executed natively on the processor.
>
> I think this is redundant with coreboot, since coreboot will also run
> pci rom, eg. vga bios.

I think coreboot only runs the vga bios and only in a simulator.  I
think it would be difficult to run some option roms (eg, scsi) from
within an emulator.  That said, I think it would be great to configure
which roms got run, which got emulated, and which got skipped
entirely.

[...]
> > Some of the hardware accesses made by the "legacybios" code appear to
> >  be specific to hardware in the emulator.  The code attempts to enable
> >  ram shadowing of the memory segment at 0xf00000 - it does this so that
> >  it can put acpi/mptable/smbios tables into that area.  After it is
> >  complete, it attempts to disable writes to that region.  The code
> >  sequence looks to be specific to intel north/southbridges.  It isn't
> >  necessary to disable writes to 0xf0000 (though it would be nice), but
> >  it is necessary to have the ability to alter that memory.
>
> This shadowing job should be left to coreboot, if someone is going to
> use legacybios, he should take care of this shadowing job in ram init
> code.

That's fine, but it means the launched OS will be able to overwrite
the 0xf0000 segment.  It would be nice to write protect it, but it is
not a huge issue.
> I've written a loader for coreboot-v2 to load legacybios, it works
> well when used with qemu, I've booted freebsd with it. But on real
> hardware, via epia-cn, it hangs with a blank screen, the debug port
> value is 0x31, I'll take some time to see what's going wrong.

Changing the legacybios code to forward debug output to a serial port
will definitely help here.
> I add a header for legacybios to become a payload, this is done by a
> utility createpayload.
> I've attached the loader and the utility.
> Signed-off-by: Aaron Lwe

Thanks - I'll take a look.

-Kevin

[Kevin O'Connor]

On Wed, May 07, 2008 at 08:25:32PM -0400, Kevin O'Connor wrote:
> On Wed, May 07, 2008 at 10:50:11AM +0800, aaron lwe wrote:
> > I've written a loader for coreboot-v2 to load legacybios, it works
> > well when used with qemu, I've booted freebsd with it. But on real
> > hardware, via epia-cn, it hangs with a blank screen, the debug port
> > value is 0x31, I'll take some time to see what's going wrong.
>
> Changing the legacybios code to forward debug output to a serial port
> will definitely help here.

FYI, the latest legacybios git repo has the serial debug option.  To
enable, modify src/config.h and turn on CONFIG_DEBUG_SERIAL.  I've
only tested this with qemu.

-Kevin

[aaron lwe]

> I think coreboot only runs the vga bios and only in a simulator.  I
>  think it would be difficult to run some option roms (eg, scsi) from
>  within an emulator.  That said, I think it would be great to configure
>  which roms got run, which got emulated, and which got skipped
>  entirely.

Cool. BTW, for via epia-cn, vgabios is not run by emulator, but by
switching back to real mode and call the rom code. I think this is the
same way legacybios did. Maybe we can have a config option to let
coreboot know when we are using legacybios we can omit runnning pci
roms and let legacybios takes care, but when using other payloads, the
pci rom code should still be run by emulator or vm86.
> That's fine, but it means the launched OS will be able to overwrite
>  the 0xf0000 segment.  It would be nice to write protect it, but it is
>  not a huge issue.

yes, the problem is legacybios cannot know all the chipsets' specific
register settings for shadow ram, so it would be impossible unless we
pass some info from coreboot to legacybios.
> Changing the legacybios code to forward debug output to a serial port
>  will definitely help here.

thanks and I've added serial code and now able to see the output. It
seems that legacybios cannot detect the ide disk... It said: ata0
master: unknown device. Maybe the ata code is ok for qemu emulated
dirves but not for real hardware. I'll take a look at it.

Thanks

[bari]

aaron lwe wrote:
> Cool. BTW, for via epia-cn, vgabios is not run by emulator, but by
> switching back to real mode and call the rom code. I think this is the
> same way legacybios did. Maybe we can have a config option to let
> coreboot know when we are using legacybios we can omit runnning pci
> roms and let legacybios takes care, but when using other payloads, the
> pci rom code should still be run by emulator or vm86.

Do you have a working version of coreboot for the epia-cn?

-Bari

[aaron lwe]

> Do you have a working version of coreboot for the epia-cn?

I attached the auto.c for epia-cn, the northbridge cn700 and
southbridge vt8237r code are all available at svn src tree. note that
for cn700 dram enable, the value for enable dll should be 0x120000,
default ocd calibration should be 0x121c20 and exit calibration mode
should be 0x120020. These values worked for me. If you still have
problem with dram init, you should also change the values of D0F2 to
be the same with your factory bios'.

The serial code is from vt8235.

I cannot make sata work with filo(not sure what's the problem), so I
disabled sata in auto.c.

Thanks

[bari]

aaron lwe wrote:
> > Do you have a working version of coreboot for the epia-cn?
>
> I attached the auto.c for epia-cn, the northbridge cn700 and
> southbridge vt8237r code are all available at svn src tree. note that
> for cn700 dram enable, the value for enable dll should be 0x120000,
> default ocd calibration should be 0x121c20 and exit calibration mode
> should be 0x120020. These values worked for me. If you still have
> problem with dram init, you should also change the values of D0F2 to
> be the same with your factory bios'.
>
> The serial code is from vt8235.
>
> I cannot make sata work with filo(not sure what's the problem), so I
> disabled sata in auto.c.
>
> Thanks

I'm having problems with FILO on the same board. I don't have IDE 
working yet either.

I'll try your patch and compare results.

-Bari

[bari]

Your auto.c includes:
#include "southbridge/via/vt8237r/vt8237r_early_serial.c"

this is not in the current tree.  Please send a copy of this file.

Regards,

Bari

aaron lwe wrote:
> > Do you have a working version of coreboot for the epia-cn?
>
> I attached the auto.c for epia-cn, the northbridge cn700 and
> southbridge vt8237r code are all available at svn src tree. note that
> for cn700 dram enable, the value for enable dll should be 0x120000,
> default ocd calibration should be 0x121c20 and exit calibration mode
> should be 0x120020. These values worked for me. If you still have
> problem with dram init, you should also change the values of D0F2 to
> be the same with your factory bios'.
>
> The serial code is from vt8235.
>
> I cannot make sata work with filo(not sure what's the problem), so I
> disabled sata in auto.c.
>
> Thanks

[aaron lwe]

> Your auto.c includes:
>  #include "southbridge/via/vt8237r/vt8237r_early_serial.c"
>
> this is not in the current tree.  Please send a copy of this file.

vt8237r_early_serial.c is identical with vt8235_early_serial.c

-Aaron

[bari]

aaron lwe wrote:
> > Your auto.c includes:
> >  #include "southbridge/via/vt8237r/vt8237r_early_serial.c"
> >
> > this is not in the current tree.  Please send a copy of this file.
>
> vt8237r_early_serial.c is identical with vt8235_early_serial.c

I copied that over and it still doesn't build.

auto.c:131.22:
ddr_ram_setup undeclared

auto.c

ddr_ram_setup(&ctrl);

Is there any way you can send a patch against the current svn with your 
working code?

I'd like to get this together with all the other C7/D+cn700+vt8237r 
trees and get this into the SVN for all.

-Bari

[aaron lwe]

> Is there any way you can send a patch against the current svn with your
> working code?

Sorry I'm pretty busy trying to make bochs bios ata driver work with
my disk, I'll do that once I have time.

-Aaron

[bari]

aaron lwe wrote:
> > Is there any way you can send a patch against the current svn with your
> > working code?
>
> Sorry I'm pretty busy trying to make bochs bios ata driver work with
> my disk, I'll do that once I have time.

Thanks.

We are working on the FILO issues with SATA and PATA on the vt8237r. You 
seem to have the most stable cn700 tree.

If you get a chance to even send a .tar of your trees for 
/src/mainboard/via/epia-cn  , /src/northbridge/via/cn700 and 
/cpu/via/model_c7 I'll be more than happy to work through it all.

-Bari

[Corey Osgood]

Can I get a copy of both of your trees, and I'll try to get it working
again? I've got the next couple days off, and I should be working on my
project car, but I supposed I can take a break for a little coreboot. My
last rendition before I lost everything had both IDE and SATA working, and
before that I had them working individually, but not both at once.

-Corey

On Thu, May 8, 2008 at 2:08 AM, bari  wrote:
> Your auto.c includes:
> #include "southbridge/via/vt8237r/vt8237r_early_serial.c"
>
> this is not in the current tree.  Please send a copy of this file.
>
> Regards,
>
> Bari
>
> aaron lwe wrote:
> > > Do you have a working version of coreboot for the epia-cn?
> >
> > I attached the auto.c for epia-cn, the northbridge cn700 and
> > southbridge vt8237r code are all available at svn src tree. note that
> > for cn700 dram enable, the value for enable dll should be 0x120000,
> > default ocd calibration should be 0x121c20 and exit calibration mode
> > should be 0x120020. These values worked for me. If you still have
> > problem with dram init, you should also change the values of D0F2 to
> > be the same with your factory bios'.
> >
> > The serial code is from vt8235.
> >
> > I cannot make sata work with filo(not sure what's the problem), so I
> > disabled sata in auto.c.
> >
> > Thanks

[Myles Watson]

> > Changing the legacybios code to forward debug output to a serial port
> >  will definitely help here.
>
> thanks and I've added serial code and now able to see the output. It
> seems that legacybios cannot detect the ide disk... It said: ata0
> master: unknown device. Maybe the ata code is ok for qemu emulated
> dirves but not for real hardware. I'll take a look at it.

I think this is a board-specific problem.  The IDE code works on my Tyan
boards.

Thanks,
Myles

[Myles Watson]

> I've written a loader for coreboot-v2 to load legacybios, it works
> well when used with qemu, I've booted freebsd with it. But on real
> hardware, via epia-cn, it hangs with a blank screen, the debug port
> value is 0x31, I'll take some time to see what's going wrong.
>
> I add a header for legacybios to become a payload, this is done by a
> utility createpayload.
> I've attached the loader and the utility.
> Signed-off-by: Aaron Lwe

It seems like it would be fairly easy to make this compile as a normal ELF
payload, and thus be able to use it with v3 as well.  Have you thought about
the pros and cons?

Thanks,
Myles

[Uwe Hermann]

On Wed, May 07, 2008 at 10:50:11AM +0800, aaron lwe wrote:
> I add a header for legacybios to become a payload, this is done by a
> utility createpayload.
> I've attached the loader and the utility.
> Signed-off-by: Aaron Lwe

Nice, I'll look over it and test later, but in any case, please repost
the patch with proper GPL license+copyright headers in all new files you add.

E.g.:

/*
 * This file is part of the coreboot project.
 *
 * Copyright (C) 2008 Aaron Lwe 
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301
 * USA
 */

Also, not sure what the proper place for this is. We have multiple
options:

- extra payload
 - patch in v2 and in v3
 - maybe others (?)

Thanks, Uwe.

[Kevin O'Connor]

On Wed, May 07, 2008 at 10:50:11AM +0800, aaron lwe wrote:
> I've written a loader for coreboot-v2 to load legacybios, it works
> well when used with qemu, I've booted freebsd with it. But on real
> hardware, via epia-cn, it hangs with a blank screen, the debug port
> value is 0x31, I'll take some time to see what's going wrong.
>
> I add a header for legacybios to become a payload, this is done by a
> utility createpayload.

Hi Aaron,

It looks like your payload launcher transitions to 16bit mode to enter
the bios.  Although this works, it's not needed.

If you look at the file legacybios/out/rom32.offset.auto.h you'll see
a definition for OFFSET__start.  This is the 32bit entry point.
(Jumping to 0xf000:0xfff0 in 16bit mode just causes legacybios to
transition to 32bit mode and then jump to the above.)

So, something like:

typedef void (*entry_t)();
    entry_t myentry = (entry_t)OFFSET__start;
    myentry();

Should be all that is needed.

-Kevin

[Kevin O'Connor]

On Thu, May 08, 2008 at 06:43:48PM -0400, Kevin O'Connor wrote:
> On Wed, May 07, 2008 at 10:50:11AM +0800, aaron lwe wrote:
> > I've written a loader for coreboot-v2 to load legacybios, it works
> > well when used with qemu, I've booted freebsd with it. But on real
> > hardware, via epia-cn, it hangs with a blank screen, the debug port
> > value is 0x31, I'll take some time to see what's going wrong.
> >
> > I add a header for legacybios to become a payload, this is done by a
> > utility createpayload.
>
> Hi Aaron,
>
> It looks like your payload launcher transitions to 16bit mode to enter
> the bios.  Although this works, it's not needed.
>
> If you look at the file legacybios/out/rom32.offset.auto.h you'll see
> a definition for OFFSET__start.  This is the 32bit entry point.
> (Jumping to 0xf000:0xfff0 in 16bit mode just causes legacybios to
> transition to 32bit mode and then jump to the above.)

On second thought, legacybios assumes it is using its idt and gdt.
I'll add an externally available 32bit entry point that sets up the
idt and gdt first.

Indeed, I think I'll just make an elf file with the entry address
populated.

-Kevin