[U-Boot-Users] Advice on approach for adding a new memory bank initialization

[Wolfgang Denk]

In message <1085150982.15257.31.camel at gleep.sps.mot.com> you wrote:
> 
> I have a board that has two completely disjoint banks of RAM,
> on different buses, that will most likely never be mapped
> contiguously.  I need U-Boot to initialize both banks, make
> one of them available as the normal system RAM for U-Boot and
> Linux, and then after initializing the second, leave it for
> some future Linux device driver to use.

Normally, it is good policy to have the Linux  driver  not  make  any
assumptions  about  what  the  firmware  did  or did not, and instead
perform all required initialization itself.

I'd recommend to deal with this in the Linux driver, and if you don;t
need to use this second bank of memory in U-Boot, then deal  with  it
in the Linux driver only.

> As the code stands now, the initialization sequence is fairly
> standard:
...
> I want to extend this model to initialize the second bank

Don't.

> Should I:
> 
>     A) Add a new init_func_ram_other() entry to the init_sequence[]

No. Please don't add very board specific stuff to global files.

>     B) Add a second "paragraph" of code to init_func_ram(), one for
>        each type of memory, sort of like this:

This sounds better to me than A), but I'll still reject such a patch.

>     C) Re-work the printing of "DRAM" and the size into initdram()

No.

> So, if I missed a better approach, let me know.  I am leaning toward
> plan B), with A) as followup.  C) gives me some headache just due to
> the implications of fixing up the code on other boards, of course.

I think: Leave it to the Linux driver.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
A Vulcan can  no  sooner  be  disloyal  than  he  can  exist  without
breathing.
	-- Kirk, "The Menagerie", stardate 3012.4