From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 20 Dec 2010 07:52:57 +0100 Subject: [U-Boot] [PATCH 5/5] MX5:MX53: add initial support for MX53EVK board In-Reply-To: References: <1292494665-25674-1-git-send-email-r64343@freescale.com> <1292494665-25674-6-git-send-email-r64343@freescale.com> <4D0A11F2.3070106@denx.de> <4D0B6012.4090407@denx.de> Message-ID: <4D0EFD49.6000206@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.