From mboxrd@z Thu Jan 1 00:00:00 1970 From: Graeme Russ Date: Sun, 21 Oct 2012 16:01:55 +1100 Subject: [U-Boot] [PATCH 2/3] x86: Enable ICH6 GPIO controller for coreboot In-Reply-To: References: <1350769476-32163-1-git-send-email-sjg@chromium.org> <1350769476-32163-2-git-send-email-sjg@chromium.org> Message-ID: <508381C3.7030703@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 wrote: >> Hi Simon, >> >> On Oct 21, 2012 9:32 AM, "Simon Glass" wrote: >>> >>> Hi Graeme, >>> >>> On Sat, Oct 20, 2012 at 3:22 PM, Graeme Russ >>> wrote: >>>> Hi Simon, >>>> >>>> On Oct 21, 2012 8:45 AM, "Simon Glass" 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