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

[Scott Duplichan]

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 
]independent.

Sounds good.

]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:
http://notabs.org/coreboot/e350m1-edk2corebootpkg.7z

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 
]works now).
]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.
]Great!
]
]
]Regards,
]Patrick