Hi Albert, On Fri, Oct 21, 2011 at 3:24 PM, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > Le 21/10/2011 23:54, Simon Glass a écrit : >> >> Hi Albert, >> >> On Fri, Oct 21, 2011 at 2:43 PM, Albert ARIBAUD >> <albert.u.b...@aribaud.net> wrote: >>> >>> Le 21/10/2011 23:18, Simon Glass a écrit : >>>> >>>> Hi Albert, >>>> >>>> On Fri, Oct 21, 2011 at 1:58 PM, Albert ARIBAUD >>>> <albert.u.b...@aribaud.net> wrote: >>>>> >>>>> Le 13/10/2011 23:05, Simon Glass a écrit : >>>>>> >>>>>> Some SOCs have do not start up with their 'main' CPU. The first U-Boot >>>>>> code may then be executed with a CPU which does not have a CP15, or >>>>>> not >>>>>> a >>>>>> useful one. >>>>>> >>>>>> Here we split the initialization of CP15 into a separate call, which >>>>>> can >>>>>> be performed later if required. >>>>>> >>>>>> Once the main CPU is running, you should call cpu_init_cp15() to >>>>>> perform >>>>>> this init as early as possible. >>>>>> >>>>>> Existing ARMv7 boards which define CONFIG_SKIP_LOWLEVEL_INIT should >>>>>> not >>>>>> need to change, this CP15 init is still skipped in that case. The only >>>>>> impact for these boards is that the cpu_init_cp15() will be available >>>>>> even if it is never used on these boards. >>>>> >>>>> I'm not too sure I understand how this is working: if you are moving >>>>> cp15 >>>>> init to later, it will still be done by the same core that would have >>>>> done >>>>> it earlier, won't it? >>>>> >>>>> IOW, I would like to better understand how this boot core/main core >>>>> business >>>>> works. How does the main core start execution? At which address? Does >>>>> it >>>>> go >>>>> through its reset vector? Do the cores share the same location for >>>>> reset >>>>> vectors? Etc. >>>> >>>> For Tegra is it like this: >>>> >>>> The ARM7 CPU (called AVP for Audio Video Processor) starts up first. >>>> It runs the boot ROM and then U-Boot and gets as far as >>>> arch_cpu_init(). The AVP does not have a CP15 or a cache so cannot run >>>> the CP15 init code. The AVP then starts up the first Cortex-A9 (an >>>> ARMv7 architecture CPU). This CPU (the main core, if you like) starts >>>> from the same address as the first one (i.e. the start of U-Boot). It >>>> is as if this is the core that we really wanted to use, but it wasn't >>>> available initially. This main core runs through arch_cpu_init() and >>>> sails into board_init_f(). At this point no CP15 init has been done. >>> >>> Thanks. So what this amounts to is, both cores will run the same binary, >>> and >>> I assume the AVP will shut itself off once the A9 runs. But what I don't >>> get >> >> Yes >> >>> is, if A9 goes through the same sequence of code as AVP, then it will >>> execute cp15 where is is not, won't it? >> >> On Tegra we have CONFIG_SKIP_LOWLEVEL_INIT set to avoid this. That >> much is already supported by U-Boot. > > I still don't get it: if you have lowlevel init skipped for one core, it > will be for the other as well.
OK so let's run through the U-Boot code in order for each of the two CPUs: First AVP: _start skips lowlevel init (so no CP15) board_init_f arch_cpu_init (at this point it starts up the A9 and halts) A9: _start skips lowlevel init (so no CP15) board_init_f arch_cpu_init cpu_init_cp15 The call to cpu_init_cp15() is performed in arch_cpu_init() when we detect that we are the A9. > >>> Anyway: your patch moves cp15 init far enough that the AVP won't execute >>> it, >>> but the A9 will. >> >> Well, on Tegra we call the cp15 init directly when it is safe to do so, >> later. >> >>> >>> Only, what will happen when another multiple-core ARM SoC gets U-Boot >>> support but the location you chose for cp15 init is inadequate for it? >>> Shall >>> we move cp15 init again, and where? >> >> If CONFIG_SKIP_LOWLEVEL_INIT is not defined, then the low level init >> will operate exactly as now. My patch effectively just allows you to >> have CONFIG_SKIP_LOWLEVEL_INIT but later call part of that lowlevel >> init. In my view, the cp15 init should not be lumped in with the >> 'memory init' or whatever else it expected to be done in the lowlevel >> init. > > I think I get the point: due to the fact that both cores run the same starup > code path, and due to the fact that they run it one after the other and > share a lot of devices, at mots one of them shoud perform low level inits > (e.g. RAM init), and some low-level inits can only be performed by one of > them (e.g., cp15). Well on Tegra the RAM init is down by the boot ROM. There is no low level init bar the cp15 stuff. > >>> I'd prefer the cp15 init to stay where it is but execute only for A9, for >>> instance by checking some core identification register. >> >> Well I actually haven't moved it! It is just that previously it was >> impossible to call cp15_init from anywhere later. > > It is moved, in that it belongs to low level init... of A9. OK, I see - you mean moved in order if not in source code file. > >> What you say can be done, it would involve some assembler though and >> would need to be another CONFIG option. Was trying to avoid adding new >> assembler. > > Low level init is about assembler and, well, low level. :) Yes but it's yuck. Part of the clean-up is to remove most of the assembler - really very little is needed. > > But I don't see why there should be another CONFIG option. IIUC, you should > be able to do with only CONFIG_SKIP_LOWLEVEL_INIT: within the low level init > code under it, you would do the equivalent of a switch, with one branch for > AVM (and DDR init etc) and one branch for A9 (with cp15 init etc). Yes I can, but I need to be able to call cp15_init. And I can't do that because if CONFIG_SKIP_LOWLEVEL_INIT is defined, that code is compiled out! So I need to move that cp15_init code outside the CONFIG_SKIP_LOWLEVEL_INIT #ifdef. That is all I am trying to do, honest! Regards, Simon > > Amicalement, > -- > Albert. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot