[U-Boot] [PATCH 5/5] MX5:MX53: add initial support for MX53EVK board

[Albert ARIBAUD]

Hi Jason,

(cutting to essential parts of the discussion)

Le 20/12/2010 06:19, Jason Liu a écrit :

> Forget about the case about boot From NAND, we are talking about boot
> from SD/MMC card here.

Which is exactly the same: usually the ROM code is just sophisticated 
enough to do a single, small, read from the lowest address and execute 
what was read. How this small piece of code is called varies, but 
basically it does a first-stage bootstrap and loads the next piece, 
usually a (more) full-fledged bootloader.

> Why I call it here"plug-in", it due to it use the plugin feature of ROM.
>
> This section of code is for ROM to load and run, thus it should meet
> the ROM boot structure requirement.
> The plugin feature of ROM can give more flexibility and it can
> overcome some shortcomings of DCD(used on mx51).
>
> By using this plugin we can get around the following issues:
> 1.	DCD size limitation issue, plugin can be the size of OCRAM free space region.
> 2.	Safe environment to re-configure PLL1 (without impacting SDRAM) as
> the plugin runs from OCRAM.

This is certainly good, although I'm not familiar enough with the mx 
series to appreciate the improvements. What I can appreciate, though, is 
that you're decribing a first-stage bootloader of sorts, and that 
nothing in your description forces this "plug-in" to be linked with 
u-boot, and even less, to be linked instead of u(boot's start code.

> I don't know .kwb format, but know .imx format. Here the .imx use the
> DCD table to do DDR init
> but with plugin, it need run the binary code not the DCD configure
> table. So, We need use assembly
> code to run the DDR init script.

Right! But you don't need to tack this code inside the u-boot binary.

> Here, We can talking about SD/MMC boot. It's some different with NAND
> boot.

Not really. for this "plug-in" boot, the ROM loads a small "plug-in" 
from some fixed location in SD/MMC and executes it, hoping that it'll 
contribute to some initializations and to loading the next payload. 
Ditto for NAND boot.

> It's different with MX51 DCD approach.

AIUI, for mx51 providing added inits and payload info are is done by a 
pure-data header; that is indeed different from NAND and SD/MMC boot 
where doing inits and putting payload in RAM are done by code. But your 
approach, from what I see, is not a third way; it seems to be a 
combination of both the data and code approaches.

> ROM will only load 2KB data from the beginning of SD/MMC card. The
> first 1KB is not used, it means
> that only 1KB data is used. We need put ivt table and ddr init
> assembly code into this
> 1KB section. So, we can't put the assembly code into board_init or
> board_early_init_f.

I don't get this. Why can you only use 1 KB of IRAM? If your plugin is 
supposed to setup DDR, how come it cannot fit in the IRAM which is the 
only place where it can go? When the plug-in feature was designed, 
surely people knew about that 1 KB constraint, right?

Please, check your requirements and actual hardware constraints and come 
back with a simpler design where first stage bootloader will not "bleed 
over" the payload.

Amicalement,
-- 
Albert.