If it is quite slow, then I think there is something wrong with the code.
You only need to write FS base or GS base MSR once per 4GB assuming you can use 32-bit Protected non-paged mode. I don't see why this should be slower than creating page tables and populating them and doing the memory testing.
I'd like to get to the bottom of this one, but on offline topic.
I personally agree with Ron, we should get AMD Opteron squeaky clean first, before moving to 64-bit.
-----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Lu, Yinghai Sent: Friday, December 16, 2005 11:02 AM To: Stefan Reinauer; Ronald G Minnich Cc: LinuxBIOS Subject: Re: [LinuxBIOS] about make LinuxBIOS 64bit for Opteron
I hate that in LinuxBIOS (CAR and RAM stage) I can not access the range above 4G, esp the last 4G in 1T Range.
I could use fs base to access that, but that is quite slow...
-----Original Message----- From: Stefan Reinauer [mailto:email@example.com] Sent: Friday, December 16, 2005 10:53 AM To: Ronald G Minnich Cc: Lu, Yinghai; Li-Ta Lo; Eric W. Biederman; LinuxBIOS Subject: Re: about make LinuxBIOS 64bit for Opteron
- Ronald G Minnich firstname.lastname@example.org [051216 19:35]:
I think we have to do it.
That said, BEFORE this effort starts, I want to make sure
SINGLE OPTERON TARGET works as well as it did 6 months ago. And, currently, I don't think that is the case -- see ward's letter.
We need to get this code base back to being more solid than it
I fully agree. We should make a feature freeze and only let changes in that fix something until we _verified_ that all (K8) mainboards are working and on the same level (ie. equal cmos layouts, dual core, car enabled, etc pp.)
One step at a time. We just recovered.
Besides that, 64bit is a must, no doubt.
-- LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios