Hi MJ, On Wed, Sep 18, 2013 at 12:41 AM, MJ embd <mj.e...@gmail.com> wrote: > Hi Simon/All, > > Any comments > > On 9/17/13, Simon Glass <s...@chromium.org> wrote: >> Hi, >> >> You could try to cc whoever wrote the code. You can use git blame to find >> out. >> >> But it sounds like you are on the right track. I may be able to help, will >> email tomorrow if so. >> >> Regards, >> Simon >> On Sep 16, 2013 8:26 PM, "MJ embd" <mj.e...@gmail.com> wrote: >> >>> Reminder, Please can anyone respond >>> >>> On 9/16/13, MJ embd <mj.e...@gmail.com> wrote: >>> > Hi, >>> > >>> > I was trying to understand the booting (till linux) on samsung exynos >>> > 5250. As this is my first on ARM Cortex. I have a few questions, so >>> > following is a step by step understanding and [Q] mentions the >>> > question I am asking >>> > >>> > [1] At POR (Power on Reset) the Internal Boot rom code executes, and >>> > checks the boot location and if it finds sd card, it copies 14k from >>> > the sd card (which is u-boot-spl.bin) into iRAM. >>> > [2] the internal boot rom branches pc to the entry point of spl at >>> > __start (0x2023400) >>> > [3] First instruction at __start is b reset. >>> > [4] this takes the route reset | cpu_init_crit | low_level_init | >>> first_cpu >>> > >>> > [Q 1] At this point what is the state of secondary core, is it held in >>> reset >>> > ? >>> > As per document, ""
I think the secondary core is powered down or in reset. >>> > "the secondary CPUs (CPU1, CPU2, and CPU3) execute a WFI instruction, >>> > which is actually a loop that checks the value of SYS_FLAGS register." Which document are you referring to here? >>> > >>> > I couldnt find the SYS_FLAGS register in Cortex A15 manual, can some >>> > one >>> > point. This is probably a flag in the IRAM, rather than an A15 register. >>> > >>> > [Q 2] The secondary core until the point the boot core calls >>> > smp_kick_secondary is just waiting in WFI. I don't see smp_kick_secondary() in U-Boot. Where is that? >>> > [5] the smp_kick_secondary does the following >>> > (a) at the address SYSFLAGS_ADDR (0x2020000) which is not in spl but >>> > above it, it write the b reset instruction and >>> > (b) Issues a SGI to the secondary core >>> > >>> > [Q 3] Does this mean that secondary core is listening at address >>> > 0x2020000, I couldnt find that in any document? That's your answer on SYS_FLAGS I guess. That is the start of IRAM so it is quite likely that the secondary core is sitting in a loop waiting for the value to change. >>> > >>> > [6] Supposedly it does and it starts executing the reset function, >>> > secondary core would end up in enter_smp_pen. >>> > [Q 4] I dont understand what is trying to achieve here, Can some one >>> > explain. >>> > >>> > >>> > I am planning to pen down the complete boot sequence, all help >>> appreciated. I'm missing the code you are referring to perhaps, but I think the idea is something like this: 1. Boot primary core 2. Primary code sets up a 'pen' for the secondary cores in IRAM, starts them up to run in that pen 3. Secondary cores watch a value in IRAM which tells them when to leave their pen and where to jump to Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
