[coreboot] why is firmware 32 bit as opposed to 64 bit

[ron minnich]

This would be a great GSOC project to finish it up.

Really nice work!

ro

On Tue Jan 20 2015 at 9:09:12 PM Scott Duplichan <scott at notabs.org> wrote:

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