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

login
register
mail settings
Submitter Simon Glass
Date Oct. 20, 2012, 9:44 p.m.
Message ID <1350769476-32163-2-git-send-email-sjg@chromium.org>
Download mbox | patch
Permalink /patch/192953/
State Superseded, archived
Delegated to: Simon Glass
Headers show

Comments

Simon Glass - Oct. 20, 2012, 9:44 p.m.
Coreboot uses this controller to implement GPIO access.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/configs/coreboot.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
Graeme Russ - Oct. 20, 2012, 10:22 p.m.
Hi Simon,

On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@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.

Regards,

Graeme

>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>  include/configs/coreboot.h |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
> index 0e89242..2e084ee 100644
> --- a/include/configs/coreboot.h
> +++ b/include/configs/coreboot.h
> @@ -99,6 +99,9 @@
>  #undef CONFIG_VIDEO
>  #undef CONFIG_CFB_CONSOLE
>
> +/* x86 GPIOs are accessed through a PCI device */
> +#define CONFIG_INTEL_ICH6_GPIO
> +
>  /*-----------------------------------------------------------------------
>   * Command line configuration.
>   */
> --
> 1.7.7.3
>
Simon Glass - Oct. 20, 2012, 10:32 p.m.
Hi Graeme,

On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> Hi Simon,
>
> On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@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?

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.

Regards,
Simon

>
> Regards,
>
> Graeme
>
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>  include/configs/coreboot.h |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
>> index 0e89242..2e084ee 100644
>> --- a/include/configs/coreboot.h
>> +++ b/include/configs/coreboot.h
>> @@ -99,6 +99,9 @@
>>  #undef CONFIG_VIDEO
>>  #undef CONFIG_CFB_CONSOLE
>>
>> +/* x86 GPIOs are accessed through a PCI device */
>> +#define CONFIG_INTEL_ICH6_GPIO
>> +
>>  /*-----------------------------------------------------------------------
>>   * Command line configuration.
>>   */
>> --
>> 1.7.7.3
>>
Graeme Russ - Oct. 20, 2012, 10:57 p.m.
Hi Simon,

On Oct 21, 2012 9:32 AM, "Simon Glass" <sjg@chromium.org> wrote:
>
> Hi Graeme,
>
> On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ@gmail.com>
wrote:
> > Hi Simon,
> >
> > On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@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

>
> 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

Regards,

Graeme
Simon Glass - Oct. 20, 2012, 11:51 p.m.
Hi Graeme,

On Sat, Oct 20, 2012 at 3:57 PM, Graeme Russ <graeme.russ@gmail.com> wrote:
> Hi Simon,
>
> On Oct 21, 2012 9:32 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>
>> Hi Graeme,
>>
>> On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ@gmail.com>
>> wrote:
>> > Hi Simon,
>> >
>> > On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@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?

>
>>
>> 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.

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.

Regards,
Simon

>
> Regards,
>
> Graeme
Graeme Russ - Oct. 21, 2012, 5:01 a.m.
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@gmail.com> wrote:
>> Hi Simon,
>>
>> On Oct 21, 2012 9:32 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>>
>>> Hi Graeme,
>>>
>>> On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ@gmail.com>
>>> wrote:
>>>> Hi Simon,
>>>>
>>>> On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@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?

>>> 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?

> 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.

Regards,

Graeme
Simon Glass - Oct. 24, 2012, 4:09 a.m.
Hi Graeme,

On Sat, Oct 20, 2012 at 10:01 PM, Graeme Russ <graeme.russ@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@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Oct 21, 2012 9:32 AM, "Simon Glass" <sjg@chromium.org> wrote:
>>>>
>>>> Hi Graeme,
>>>>
>>>> On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ <graeme.russ@gmail.com>
>>>> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Oct 21, 2012 8:45 AM, "Simon Glass" <sjg@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

Patch

diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h
index 0e89242..2e084ee 100644
--- a/include/configs/coreboot.h
+++ b/include/configs/coreboot.h
@@ -99,6 +99,9 @@ 
 #undef CONFIG_VIDEO
 #undef CONFIG_CFB_CONSOLE
 
+/* x86 GPIOs are accessed through a PCI device */
+#define CONFIG_INTEL_ICH6_GPIO
+
 /*-----------------------------------------------------------------------
  * Command line configuration.
  */