Wolfgang Denk wrote:
In message 4553E0C4.4010207@freescale.com you wrote:
Is the bd located immediately after the gd in memory?
No, not at all. Actually we start with the gd, and space fopr the bd becomes only available after relocation to RAM.
So gd initially lives in cache? I don't see in the README where it says where gd_t is initially allocated, but I do see this in the code:
gd = (gd_t *) (CFG_INIT_RAM_ADDR + CFG_GBL_DATA_OFFSET);
That value is equal to 0xFD000F00. I can't really tell from the code or documentation, but I'm guessing U-Boot has set up a 4KB block of cache-as-RAM at FD000000. Either that or it's some kind of on-chip RAM, but I can't find any reference to that in any of my manuals. I have an 8349.
How about a rule that any function can write to bd_info (to initialize its contents), but only the do_bootm_xxx functions can read from it, and only to prepare it for passing to Linux. This would eliminate code like this:
#define OF_TBCLK (bd->bi_busfreq / 4)
I don't see how such a rule would actually prevent such code...
Well, in this case, the above line would change to "(gd->bus_clk / 4)" to conform with that rule.
In this case, I don't understand the clocks_in_mhz environment variable. Is
RTFM.
Wow, look at that! It's clearly explained in the README! Sorry. :-[
However, it looks like there's some redundancy in this. Couldn't the variable disable_of perform the same function? Or even better, couldn't we just check whether a pointer to an OF tree is passed to the bootm parameter? If the user includes an OF tree on the bootm command line, then boot an OF kernel. Otherwise, convert the frequency values to MHZ and boot a traditional kernel.
Speaking of do_bootm_linux(), why is the PPC version of this function in cmd_bootm.c instead of lib_ppc/ppc_linux.c?