On Wed, Mar 04, 2015 at 08:42:58AM +0100, Heiko Schocher wrote: > Hello Tom, > > Am 02.03.2015 14:59, schrieb Tom Rini: > >On Mon, Mar 02, 2015 at 07:56:41AM +0100, Heiko Schocher wrote: > >>Hello Simon, > >> > >>Am 24.02.2015 14:31, schrieb Simon Glass: > >>>Hi Heiko, > >>> > >>>On 23 February 2015 at 23:18, Heiko Schocher <h...@denx.de> wrote: > >>>>a6b541b090: TI ARMv7: Don't use GD before crt0.S has set it > >>>> > >>>>moves the init of the debug uart at the very end of SPL code. > >>>>Enable it for the siemens board earlier, as they print > >>>>ddr settings ... all debug output before board_init_r() > >>>>is here currently useless. Maybe we must rework this > >>>>globally? > >>> > >>>Assuming we are talking about U-Boot proper, the DDR init should > >>>happen in board_init_f(), specifically dram_init(). so I think this > >>>code should be updated. > >>> > >>>If it is SPL, then DDR init should happen in SPL's board_init_f(). > >> > >>It is in SPL... > >> > >>sdram_init() is called from: > >> > >>./arch/arm/cpu/armv7/am33xx/board.c from s_init() ... > >> > >>>I sent a series a few weeks ago (available at u-boot-dm branch > >>>spl-working) related to this topic: > >>> > >>>http://patchwork.ozlabs.org/patch/438581/ > >> > >>Ah ... Hmm... so "./arch/arm/cpu/armv7/am33xx/board.c" needs > >>a rework, right? > >> > >>Is a simple rename s_init() -> board_init_f() correct? > > > >Right so, no, we can't just rename s_init to board_init_f. This is what > >I was talking about in the thread about the function Hans wants to add > >to enable some bits in CP15 on sunxi, iirc. > > > >In short, armv7 has a different set of abstraction hooks than the > >previous ARM cores (armv8 followed what we have for v7) and I'm not > >convinced in the end that it really won us anything. See > >http://lists.denx.de/pipermail/u-boot/2015-January/202350.html > > > >For today you need to rework the Siemens code to print out the DDR > >values (when desired) in spl_board_init() as we do not, or will not > >shortly, have gd prior to board_init_f running. > > Hmm... first I thought, ok, no problem, move the output from the RAM > parameters to spl_board_init() ... but thats only the half of the > story ... They read the RAM parameters from an i2c eeprom, and if > there are errors, they print this errors ... currently this does > not work, and thats I think the more important case ... and I could > not move this error printfs to somewhere, because if RAM is not > working ... there is no later ... > > So I have to enable the console early ... maybe I missed something, > but this worked fine in the past (and I think we should not break > this, as this is an essential feature).
OK, I missed something too. I think this gets better now once I merge Simon's SPL series as we do all of this from board_init_f() and the siemens code should just work again. > If I look into arch/arm/cpu/armv7/am33xx/board.c s_init() > there gets the console also in the case: > > #if defined(CONFIG_NOR_BOOT) || defined(CONFIG_QSPI_BOOT) > > very early enabled ... is this buggy? Digging out one of the QSPI bootable boards (which I only _think_ I have) or setting up and confirming the beaglebone white + NOR cape I have still functions at the HW level and then re-testing on mainline are on my list as yes, I'm a bit worried these paths might be broken again. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot