Hi Scott, congratulations to this awesome feat!
On 21.01.2015 06:08, Scott Duplichan wrote: > ron minnich [mailto:rminn...@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. Regards, Carl-Daniel -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot