[U-Boot] [PATCH 0/2]: OMAP3 SPL updates

[Igor Grinberg <grinberg@compulab.co.il>]

Hi Tom,

On 10/10/11 05:01, Tom Rini wrote:
> On Sun, Oct 9, 2011 at 2:21 AM, Igor Grinberg <grinberg@compulab.co.il> wrote:
>> On 10/07/11 02:28, Tom Rini wrote:
>>> On Tue, Oct 4, 2011 at 7:59 AM, Tom Rini <trini@ti.com> wrote:
>>>> Hey all,
>>>>
>>>> The following short series does two things.  First, it re-works where
>>>> we do memory initalization in SPL for OMAP3 to be board-specific.
>>>> This is needed since in many cases (beagleboard, omap3evm) what timings
>>>> we set depend on what hardware we detect ourself to be running on.  Second,
>>>> along those same lines what omap_rev_string tells us is doing to be
>>>> board specific as well so provide a weak version in the common omap SPL
>>>> code and lets it be replaced as needed.
>>>
>>> Please disregard this version, I need to do a full v3 with the right
>>> set of board_early_sdrc_init, sorry for the noise.
>>
>> While I was looking at the series, I've got similar thoughts.
>> May be this should be facilitated by providing kind of framework
>> for the board file only to set the right settings and not duplicate
>> the board_early_sdrc_init() function (with changed values)?
> 
> The problem is that what to do is very board specific.  For example
> for beagleboard we need to probe the nand driver to see what package
> we have and then pick from at least 3, maybe 4 or 5 (I don't have the
> code in front of me) settings.

This only means that the framework (or just a common function call)
should be flexible enough to let the board choose the right configuration
in runtime.
After all the DRAM controller should be initialized by the same sequence
just with different values.

> That said, perhaps a function that
> takes the series of values that do change would be a little clearer in
> the end so I'll give that a spin once I've gotten beagle and omap3evm
> spun up again (and maybe finally gotten NAND SPL working there, it
> seems to be an omap3-specific issue sadly).

How about a something like board_get_dram_params() (defined weak)
implemented by a board file and a call added to current
DRAM controller initialization sequence?
 

-- 
Regards,
Igor.