[U-Boot-Users] bd_info vs. global_data

[Timur Tabi <timur@freescale.com>]

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?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale