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...
YH
-----Original Message----- From: Stefan Reinauer [mailto:stepan@openbios.org] 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 rminnich@lanl.gov [051216 19:35]:
I think we have to do it.
That said, BEFORE this effort starts, I want to make sure that EVERY 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
currently is.
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.
Stefan
Lu, Yinghai wrote:
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...
I hate it too. All I am asking is that we take this thing one step at a time. We MUST get k8 back on a stable footing before we go on to needed features like 64bit mode.
thanks
ron
"Lu, Yinghai" yinghai.lu@amd.com writes:
I hate that in LinuxBIOS (CAR and RAM stage) I can not access the range above 4G, esp the last 4G in 1T Range.
Ah the magic Opteron memory mapped registers. :)
I could use fs base to access that, but that is quite slow...
Also don't forget that you can't initialize ECC properly from cpus that are not on the same die as the memory controller.
I used fs base for that it worked ok. It was a little slow because it was over hypertransport but nothing bad but the ECC state did not initialize correctly.
Eric