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:
- DCD size limitation issue, plugin can be the size of OCRAM free space region.
- 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,