[coreboot] Help required to boot DUET (Seabios floppy mechanism)

Scott Duplichan spambucket at notabs.org
Wed Nov 6 14:55:34 CET 2013

Patrick Georgi wrote:

]Am 2013-11-06 00:28, schrieb Scott Duplichan:
]> I am working on a project to allow Duet to run as a
]> coreboot payload, and to fix the major Duet problems.
]We had that 4 years ago or so. Want me to look up the code?

Yes, I would be interested to see how others approach it,
though I have the payload support working now.

]> It will also continue to support bootable image form.
]> It may take me a few weeks to reach the goal of booting
]> operating systems in UEFI mode on real hardware though.
]corebootPkg boots the Fedora 19 Live DVD on QEmu.
]Could you try on real hardware? I'm away from mine for the next couple 
]of days.

I did get this going on ASRock E350M1, at least on simnow.
The biggest problem is that parts are taken from the OVMF
project, which is hard-coded for Intel 440BX chipset in
some aspects. I got it to boot the shell with these changes:

1) Hack in a change to make it use the proper I/O port when
reading the ACPI power management timer. The ideal solution
is to get the ACPI PM timer address from the ACPI tables,
which is what Duet does.
2) Change PCI device and function numbers hard-coded in
bdsplatform.h from 440BX values to AMD SB800 values. Not
sure if this is essential for shell boot.
3) Disable PCI ARI support to eliminate some EDK2 code
crashes. Not sure if the cause of the problem is an EDK2
problem or a simnow model problem.
4) Work around a crash in SmbiosDxe.c. I didn't investigate
the cause.
5) Expand the temporary identity mapped page tables. I
believe they map up to 1GB, and I am using more.
6) Big changes to make it build on Windows using Microsoft
tools. It is really unfortunate that as of 2013, Microsoft
doesn't support C99. I used fasm in place of Microsoft's
assembler because it can assemble a module containing both
32-bit and 64-bit code.

These changes are enough to get the shell on the serial
console. Exiting the shell runs into trouble though.

]edk2 source with (some) documentation can be found at
]The image above was built with the GCC47 toolchain, the 64bit issues it 
]had are now fixed.
]Like Duet, the resulting payload should be portable across boards since 
]coreboot does the initialization part.
]CSM is useful to initialize video if you only have a PCBIOS style 
]VGABIOS (eg. on QEmu).

I am hoping to avoid use of full CSM. corebootPkg/Csm/CsmSupportLib
has a lot of hard-coding for Intel 440BX. The Duet project uses
an INT 10h wrapper called BiosVideoThunkDxe which can make legacy
video usable. UEFI has native support for most other devices. It
might even be possible to extract the native UEFI GOP video driver
from an OEM UEFI ROM for reuse. But I believe in the case of my
ASRock E350M1 the OEM UEFI ROM has no GOP driver, only legacy.

The biggest work is going to be support for the large NVRAM
area needed by EDK2 UEFI. A generic solution is not possible.
I will start with support for AMD systems.



More information about the coreboot mailing list