[coreboot] Help required to boot DUET (Seabios floppy mechanism)
spambucket at notabs.org
Thu Nov 7 17:31:09 CET 2013
Patrick Georgi wrote:
]Am 2013-11-06 14:55, schrieb Scott Duplichan:
]> ]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.
]I'll take a look, but it can take some days.
No need to dig it up.
]> 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.
]I started work on FixedAtBuild Pcds that teach the various table
]managers in UEFI to inherit existing tables (SMBIOS, ACPI). That way we
]could pass the coreboot tables into UEFI, making the payload even more
]The change might also be useful for DUET, but I don't know if upstream
]is actually still interested in it.
]> 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.
]Any chance you could publish these somewhere?
OK, I put it here:
The original and modified projects are included for diffing.
I added NOOPT to the dsc file for easier debug.
The size adjustments to the fdf file are to prevent a
build fail when the NOOPT target is built.
Changes to the C code are work-arounds for Microsoft's
lack of C99 support.
corebootPkg\Sec\X64\SecEntry.asm is a port of SecEntry.asm
for use in the Windows build environment. I used the fasm
assembler to minimize changes. Unfortunately the Microsoft
linker won't accept relocations between 32 and 64 bit code
due to pointer truncation concern. I couldn't find a link
solution, so I had to change the code to position independent.
I didn't try to port the asm support for PCDs and replaced
them with hard coded constants.
]> 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.
]Another alternative would be graphics init in coreboot, setting up a
]frame buffer. UEFI could parse out the cbtables to figure out the
]position and layout of the framebuffer in a primitive GOP driver.
]Unfortunately my time for UEFI work is rather limited these days.
]> The biggest work is going to be support for the large NVRAM
]> area needed by EDK2 UEFI. A generic solution is not possible.
]Not totally generic, but I guess we could carve out some space by adding
]a CBFS file (with proper alignment) whose content is managed as nv
]variable storage (similar to how the MRC stuff on both intel and AMD
]For security, I'd also propose doing the actual flash access from SMM in
]coreboot code (which can reuse the existing flash drivers) - but maybe
]that's something for later.
]> I will start with support for AMD systems.
More information about the coreboot