From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Thu, 05 Feb 2015 09:27:21 +0100 Subject: [U-Boot] [PATCH 1/3] ARmv7: Add a soc_init hook to start.S In-Reply-To: References: <20150122162058.GF10826@bill-the-cat> <54C14B0E.9000308@redhat.com> <20150122210357.GG10826@bill-the-cat> <54C20C34.1090908@redhat.com> <20150126151802.GB10826@bill-the-cat> <54C69659.3060500@redhat.com> <20150127142347.GK10826@bill-the-cat> <20150131222550.72782f77@lilith> <20150131214956.GC10826@bill-the-cat> <20150202185657.GH10826@bill-the-cat> <20150204094832.4d848e3d@lilith> Message-ID: <54D32969.2030803@redhat.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, On 05-02-15 04:00, Simon Glass wrote: > Hi Albert, > > On 4 February 2015 at 01:48, Albert ARIBAUD wrote: >> Hello Tom, >> >> On Mon, 2 Feb 2015 13:56:57 -0500, Tom Rini wrote: >> >>> And (and this is being split into >>> different email threads, sigh), it would be good, possibly, if we have >>> something that means "very early init things, but we can be written in >>> C". >> >> "Very early" -- and "early" too, BTW -- is way too vague for me to be >> sure we're talking about the same thing, so let's find out what various >> earlinesses mean to us. My own view: >> >> "Starting early": the 'start', or 'reset', entry point, can't get >> earlier than that. This is where U-Boot resets the target to a known >> state (cache disable and invalidate, for instance). For some SoCs, at >> this point core registers have to be saved somewhere because they >> contain informative values that we want to keep, so we need to be able >> to hook this stage. There is no C environment. >> >> "Flipping early": after the entry point but before the DDR is usable. >> That's where PLLs/clocks are set up minimaly to get going and have >> access to the needed resources including DDR. Still no C environment. > > This is the current lowlelvel_init() I think. I don't believe it > should set up DDR. > >> >> "Effing early": after the DDR was made usable but before relocation. >> That's when board_init_f() starts. It's there to get the relocation > > At present board_init_f() ses up DDR and I'd prefer we keep that, e.g. > with console output before DDR is ready. Ack, DRAM setup is iffy, and we definitely want to have (early) console output working at that point. I do not even want to think about having to debug DRAM setup without console output. Regards, Hans