[U-Boot] [PATCH 5/9] x86: coreboot: Move non-board specific files to coreboot arch directory

[Graeme Russ]

Hi Simon,

On Thu, Oct 4, 2012 at 11:17 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Graeme,
>
> On Wed, Oct 3, 2012 at 6:12 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>> Hi Simon,
>>
>> On Thu, Oct 4, 2012 at 10:39 AM, Simon Glass <sjg at chromium.org> wrote:
>>> From: Stefan Reinauer <reinauer at 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