[U-Boot] [PATCH 2/3] x86: Enable ICH6 GPIO controller for coreboot

[Simon Glass]

Hi Graeme,

On Sat, Oct 20, 2012 at 10:01 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Simon,
>
> On 10/21/2012 10:51 AM, Simon Glass wrote:
>> Hi Graeme,
>>
>> On Sat, Oct 20, 2012 at 3:57 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Oct 21, 2012 9:32 AM, "Simon Glass" <sjg at chromium.org> wrote:
>>>>
>>>> Hi Graeme,
>>>>
>>>> On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ at gmail.com>
>>>> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg at chromium.org> wrote:
>>>>>>
>>>>>> Coreboot uses this controller to implement GPIO access.
>>>>>
>>>>> All coreboot supported boards, or just the ones you are dealing with
>>>>> ATM?
>>>>>
>>>>> To give you some perspective, I'm working on n AMD E350 based board.
>>>>> Does it
>>>>> have ICH6 GPIO?
>>>>>
>>>>> I've come to a conclusion that U-Boot as a coreboot payload will be the
>>>>> norm
>>>>> for the foreseeable futre, so let's make board specific support as
>>>>> flexible
>>>>> as possible.
>>>>
>>>> If that's the case then we might need a little rethink. Are you saying
>>>> that coreboot might become the only board, or that the coreboot
>>>> functions should move into generic x86 code?
>>>
>>> Make coreboot a SoC and then have individual board configs which use it
>>
>> Hmmm ok. How is that going to play with real SOCs when x86 gets them?
>
> True. Could we just have a coreboot library and and board that is
> chainloading U-Boot from coreboot simply define CONFIG_X86_COREBOOT?

Yes that sounds good, as discussed.

>
>>>> I am not sure about your board GPIO, but you could test it I suppose.
>>>>
>>>> On ARM we use the fdt to describe what peripherals are there and what
>>>> are not. I suppose we could do the same thing here.
>>>
>>> I was wondering how to pass more info from coreboot to U-Boot, maybe we can
>>> use FDT
>>
>> We have been using that, but I think coreboot wants to stop. Coreboot
>> has its own tag-based data structure.
>
> Linux supports FDT, U-Boot supports FDT - Why not FDT from all the way through?

Agreed, except for coreboot, because for now at least they don't want it.

>
>> But what I mean is that you provide an fdt for your board which
>> describes the GPIO controller. So not something that coreboot deals
>> with, just something for the U-Boot GPIO drivers to look at.
>
> Remember, U-Boot will have the hardware support hard-coded - there will not
> bee support for arbitrary hardware. Your coreboot and U-Boot images must,
> to some extent, be a pigeon pair.
>
> My concern is, who is initialising what hardware? U-Boot should not
> re-initialise hardware already initialised by coreboot. I see FDT as a way
> of passing the 'I have already initialised xxx' from coreboot to U-Boot.

The current plan is that coreboot inits the least possible to get the
machine running - e.g. memory, ACPI stuff. U-Boot drivers should do
the rest. With x86 there are complications like display init, and
calls back into coreboot for ACPI things, but U-Boot should be initing
the drivers where this is possible.

Regards,
Simon

>
> Regards,
>
> Graeme