On Sat, Jan 8, 2011 at 1:33 AM, Aneesh V aneesh@ti.com wrote:
John, On Saturday 08 January 2011 12:16 PM, John Rigby wrote:
On Fri, Jan 7, 2011 at 11:33 PM, Aneesh Vaneesh@ti.com wrote:
Hi John,
On Tuesday 28 December 2010 06:17 AM, John Rigby wrote:
Signed-off-by: John Rigbyjohn.rigby@linaro.org
+void board_init_f(unsigned long bootflag) +{
- nand_boot();
+}
I see that you have added a call to nand_boot() in start.S too. Which is the intended one? If we jump to nand_boot() here bss will not be cleared, right?
Also, I see potential issues in start.S that will prevent bss setup for PRELOADERs. I will correct these in my patch.
Best regards, Aneesh
The call to nand_boot in board_init_f makes sense for platforms where the spl code does not need to be relocated because it has been loaded into SRAM by a mask boot rom. The later nand_boot called from start.S is for the traditional nand_spl case where you are typically running in a 4K nand controller buffer so the code needs to be relocated to dram after dram init.
Of course my only testing has been on OMAP3 which fits the first case. I'm not sure if the second case even matters. The arm7 platforms I know about all have rom boot loaders and large enough SRAM to run the spl u-boot in (OMAP[34]) or have boot headers that can be used to init dram before loading a full u-boot into dram (i.mx5[13]).
Also, I was thinking that BSS would not be used in PRELOADERs but of the large SRAM case it certainly would be useful to have BSS.
Agree. So, how about this?
- Call relocate_code() in board_init_f() with destination address same
as TEXT_BASE 2. start.S skips the relocation, clears the bss(this needs to be fixed) and calls board_init_r 3. Call nand_boot() in board_init_r
This is what I am planning to do for OMAP4 preloader.
Sounds good to me.
Hopefully in the next couple of days I will have time to send a new series of my own. Then we need to combine the two. So there is one unified series for proposing for acceptance.
John