| Message ID | 1350769476-32163-2-git-send-email-sjg@chromium.org |
|---|---|
| State | Superseded, archived |
| Delegated to: | Simon Glass |
| Headers | show |
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 >
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 >>
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
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
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
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
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. */
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(-)