Hi Simon,
On Thu, Oct 4, 2012 at 11:17 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Wed, Oct 3, 2012 at 6:12 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Thu, Oct 4, 2012 at 10:39 AM, Simon Glass sjg@chromium.org wrote:
From: Stefan Reinauer reinauer@chromium.org
coreboot.c and coreboot_pci.c don't contain board specific but only coreboot specific code. Hence move it to the coreboot directory in arch/x86/cpu (which should probably be moved out of cpu/ in another commit)
You are right - this PCI code needs to move to arch/x86/lib but the naming will clash with the existing arch/x86/lib/pci.c (which is 16-bit PCI BIOS stuff)
Right, OK... It's about time I said this - All 16-bit code in U-Boot after the reset vector and protected mode switch is crap!
I did do a whole heap of work to enable U-Boot to boot Linux without the stupid BIOS stub. That work expanded upon what the coreboot guys have done and went so far as to strip the protected-mode and real-mode header components of the bzImage out. The vendor of the board I was working on lost interest and the project lost momentum and it all got too hard :(
But anyway - You will get no resistance from me if you want to take to the 16-bit code with a flame thrower (I'll even dig up my old patches, but that may take a little time)
Hmm ok. So, should we look at moving pci.c into lib/ now (and renaming it). Or leave that until later?
I think it's about time it moved
Not sure about removing all the 16-bit code. Are there really no users?
There is exactly one - eNET and as it's maintainer, I am very happy to see that code disappear. It will give me incentive to dust of my eNET (which I have not touched for two years) and get the kernel booting without the real-mode fluff.
The main issue is how the Linux kernel is built - You end up with bzImage that looks like:
+-----------------------+ | Header | +-----------------------+ | Real-Mode code | +-----------------------+ | Decompress Code | | (Protected Mode) | +-----------------------+ | Compressed | | Protected Mode Code | | (The Kernel) | | | +-----------------------+
What you end up with is a double-copy - bzImage from storage to RAM and then a decompress by the bzImage's own decompress code. I had some script which stripped out the Real-Mode and Decompress code and produced two files (the Header and the compressed kernel) - From there you could read the header and the decompress directly from the file system to the kernel's final resting place
Now HPA will not like that one little bit :) But I'm open to suggestions
Regards,
Graeme