<div dir="ltr">Hello Folks <div><br></div><div>Well Im still trying to figure out how to get the debug messages of updatememorymap () written to the serial port. If any help could be provided.</div><div><br></div><div>Secondly since I'm facing the same freeze problem I would like to try something different.I need the code to execute DUET as a coreboot payload as spoken earlier by Partick Georgi </div>
<div><br></div><div>Thirdly since I already have the latest seabios prepped I would like to prepare a HDD image with duet installed to its mbr and the efi loaders set to its active partitions.</div><div><br></div><div>Thanks........</div>
<div><br></div><div>Neo.. </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 7, 2013 at 3:00 AM, Patrick Georgi <span dir="ltr"><<a href="mailto:patrick@georgi-clan.de" target="_blank">patrick@georgi-clan.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 2013-11-06 14:55, schrieb Scott Duplichan:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
]We had that 4 years ago or so. Want me to look up the code?<br>
<br>
Yes, I would be interested to see how others approach it,<br>
though I have the payload support working now.<br>
</blockquote></div>
I'll take a look, but it can take some days.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1) Hack in a change to make it use the proper I/O port when<br>
reading the ACPI power management timer. The ideal solution<br>
is to get the ACPI PM timer address from the ACPI tables,<br>
which is what Duet does.<br>
</blockquote></div>
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.<br>
The change might also be useful for DUET, but I don't know if upstream is actually still interested in it.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Change PCI device and function numbers hard-coded in<br>
bdsplatform.h from 440BX values to AMD SB800 values. Not<br>
sure if this is essential for shell boot.<br>
3) Disable PCI ARI support to eliminate some EDK2 code<br>
crashes. Not sure if the cause of the problem is an EDK2<br>
problem or a simnow model problem.<br>
4) Work around a crash in SmbiosDxe.c. I didn't investigate<br>
the cause.<br>
5) Expand the temporary identity mapped page tables. I<br>
believe they map up to 1GB, and I am using more.<br>
6) Big changes to make it build on Windows using Microsoft<br>
tools. It is really unfortunate that as of 2013, Microsoft<br>
doesn't support C99. I used fasm in place of Microsoft's<br>
assembler because it can assemble a module containing both<br>
32-bit and 64-bit code.<br>
</blockquote></div>
Any chance you could publish these somewhere?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
might even be possible to extract the native UEFI GOP video driver<br>
from an OEM UEFI ROM for reuse. But I believe in the case of my<br>
ASRock E350M1 the OEM UEFI ROM has no GOP driver, only legacy.<br>
</blockquote></div>
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.<br>
<br>
Unfortunately my time for UEFI work is rather limited these days.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The biggest work is going to be support for the large NVRAM<br>
area needed by EDK2 UEFI. A generic solution is not possible.<br>
</blockquote></div>
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).<br>
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.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I will start with support for AMD systems.<br>
</blockquote></div>
Great!<br>
<br>
<br>
Regards,<div class="HOEnZb"><div class="h5"><br>
Patrick<br>
<br>
-- <br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="http://www.coreboot.org/mailman/listinfo/coreboot" target="_blank">http://www.coreboot.org/<u></u>mailman/listinfo/coreboot</a><br>
</div></div></blockquote></div><br></div>