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

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Wed Jan 21 10:56:12 CET 2015

Hi Scott,

congratulations to this awesome feat!

On 21.01.2015 06:08, Scott Duplichan 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.
> ][...]
> ]
> ]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.
> 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?"
> [...]
> 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.
> [...]
> 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.
> [...]
> Here is a summary of changes:
> Switch compiler code generation from 32-bit to 64-bit. Switch asm code too,
> [...]

I really hope this patch will not bitrot. It's a nice way to check where
we still hardcode things like 32 bit addresses.

From a coreboot promotion perspective, it also will help a lot. I look
forward to telling people at FOSDEM that coreboot can run in AMD64 long
mode if anyone is inclined to do that.


More information about the coreboot mailing list