This would be a great GSOC project to finish it up. <div><br></div><div>Really nice work!</div><div><br></div><div>ro<br><br><div class="gmail_quote">On Tue Jan 20 2015 at 9:09:12 PM Scott Duplichan <<a href="mailto:scott@notabs.org">scott@notabs.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ron minnich [mailto:<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>] wrote:<br>
<br>
]Sent: Sunday, August 10, 2014 06:34 PM<br>
]To: Marc Jones<br>
]Cc: Scott Duplichan; coreboot<br>
]Subject: Re: [coreboot] why is firmware 32 bit as opposed to 64 bit<br>
]<br>
]I understand the arguments.<br>
]<br>
]It's worth remembering that coreboot has to date run on 5 different<br>
]architectures. 4 of those used paging. The x86 has always been the<br>
]outlier. Lack of paging has costs not discussed much. Rmodules would<br>
]be a lot simpler if we had paging. We could make the code space<br>
]readonly, which we should be doing anyway. We would have less fighting<br>
]with the granularity and alignment restrictions of MTRRs. We could<br>
]catch NULL pointers in hardware. These are clear benefits. And they<br>
]all apply to the ramstage as well as other stages.<br>
]<br>
]As to 64 bit ramstage, I see lots of benefits for my use cases, but I<br>
]may be the only one.<br>
]<br>
]In any event, this is all stuff that can be measured, and I propose to<br>
]implement and measure it. Then we can see. I'm not convinced that a<br>
]few percent either way on code size is a showstopper.<br>
<br>
Certainly true about code size. Until coreboot starts using gcc link<br>
time optimization, any talk of code size is out of place. By the way,<br>
gcc link time optimization is finally working well. I got it working<br>
with UEFI for x86, ARM, and AARCH64 (though boot testing on real<br>
hardware was limited to x86). Gcc link time optimization should be<br>
simpler to enable on coreboot than UEFI. This is because coreboot<br>
doesn't replace libgcc.a like UEFI does. Here some notes on using<br>
gcc link time optimization with UEFI: <a href="http://notabs.org/uefi/gcc-lto.htm" target="_blank">http://notabs.org/uefi/gcc-<u></u>lto.htm</a>.<br>
I abandoned the idea of submitting a UEFI patch due to lack of interest.<br>
<br>
Another reason to convert coreboot x86 to 64-bit mode is to avoid<br>
negative comparisons to UEFI by those who don't know better. UEFI x86<br>
uses 32-bit code for the first part of execution and then 64-bit for<br>
the remainder. Some might say "x86 UEFI is 64-bit, why not coreboot?"<br>
<br>
A big negative of using 64-bit execution is lack of source code needed<br>
for recompile. What's the chance of getting Intel to support 64-bit<br>
binaries for reference code? Zero, unless the UEFI guys decide to move<br>
reference code execution to 64 bit mode.<br>
<br>
I wanted to do an experimental proof of concept port of x86 coreboot to<br>
64 bit mode. I was hoping to switch to 64-bit mode immediately. Running<br>
romstage before the x64 switch is too much like UEFI, in that a whole<br>
lot of execution runs in 32-bit mode.<br>
<br>
I chose ASRock E350M1 for the experiment because I have the board and<br>
the reference code is built from source. I did the conversion and got<br>
it working on simnow. But it failed on real hardware. It turns out the<br>
processor (and possibly all AMD processors) can't handle rom-based page<br>
tables. I tried presetting dirty and accessed bits, along with every<br>
MTRR cache setting. Nothing worked. It is possible Intel processors can<br>
use rom based page tables. But I have not bothered to test that because<br>
of lack of needed Intel reference code source.<br>
<br>
Someone with some clout needs to request a solution from Intel and AMD.<br>
While 32-bit mode includes built-in identity mapped paging, x64 mode<br>
does not. Why did AMD leave this feature out of the original x64 design?<br>
I imagine rom developers at the time (1999 or 2000) didn't object to its<br>
omission. If AMD and Intel would add this feature, both UEFI and coreboot<br>
could switch to 64-bit mode right out of the reset vector.<br>
<br>
I almost scrapped the experiment after finding rom based page tables<br>
couldn't be used. But I did try the next best thing, cache as ram page<br>
tables. This works and the board boots all the way to SeaBIOS. So cache<br>
as ram initialization runs in 32-bit mode as before, but agesa, cimx, and<br>
everything until payload launch runs in x64 mode.<br>
<br>
I put the experimental conversion here: <a href="http://notabs.org/coreboot/e350m1-x64.7z" target="_blank">http://notabs.org/coreboot/<u></u>e350m1-x64.7z</a>.<br>
This is not a patch or submission. It is a proof of concept experiment only.<br>
Only ASRock E350M1 builds. Because I am not good with makefiles, I hard-coded<br>
the changes rather than make a 32/64 selection option. I took a lot of short-<br>
cuts because the experiment is only intended to see if anything unexpected<br>
would be encountered. Only features I needed are ported. I did not port<br>
option rom execution for example. There are some inconsistent line endings.<br>
Here is a summary of changes:<br>
<br>
Switch compiler code generation from 32-bit to 64-bit. Switch asm code too,<br>
except for cache as ram. Yes, I have some .intel_syntax in there. I have to<br>
write it that way then convert afterwards.<br>
<br>
Change GDB_DEBUG flag from -O0 to -Og to support source level debugging<br>
without such a drastic code size increase.<br>
<br>
Switch back to 32-bit mode for payload execution.<br>
<br>
Add x64 code segment to GDTs and do some 64-bit changes. I skipped the<br>
IDT to save time because it is not essential for this board.<br>
<br>
Fix definitions like intptr_t and UINT32 to give the sizes needed for<br>
x64 compile.<br>
<br>
flag_is_changeable_p was not ported because it is not needed for this<br>
test.<br>
<br>
Fix integer overflow problem in rom_media.c. Not sure if I got it right,<br>
but it is good enough for this test.<br>
<br>
Work around some section alignment related problems. I did not use a good<br>
solution because I was in a hurry.<br>
<br>
There are a couple of small changes to simplify simnow testing. Those<br>
changes are marked and are not needed when booting on real hardware.<br>
<br>
A very few changes were needed in order to get the GDB_DEBUG (-Og) build<br>
to compile. Both the normal and GDB_DEBUG builds boot on real hardware.<br>
<br>
A hack was made to agesa ExecuteFinalHltInstruction so that the cache<br>
as ram page tables do not disappear before shadowed to RAM.<br>
<br>
Made the AMD NMI handler compatible with -Og debug build.<br>
<br>
Increased cache as ram for AP cores from 4 to 8 KB to make room for<br>
cache as ram page tables.<br>
<br>
There are lots of 64-bit pointer truncations left. Some work would be<br>
needed in order to run the code about 4GB.<br>
<br>
I used 2GB pages to minimize cache as ram usage. Those are left in<br>
place for the whole boot, but could easily be replaced once ram is<br>
initialized.<br>
<br>
Builds were done with Windows 7 and win-build-env-015.7z from:<br>
<a href="http://sourceforge.net/projects/coreboot-tools-for-windows/" target="_blank">http://sourceforge.net/<u></u>projects/coreboot-tools-for-<u></u>windows/</a><br>
It will most likely build on linux without change.<br>
<br>
The archive contains the git files. Hopefully this will make<br>
it easier to diff. The archive also contains the build directory.<br>
<br>
Thanks,<br>
Scott<br>
<br>
<br>
]ron<br>
]<br>
]--<br>
<br>
<br>
</blockquote></div></div>