[U-Boot] RFC - how to support multipl DRAM chips in a single SPL build?

[Tom Rini]

On Wed, Mar 7, 2012 at 11:05 AM, Peter Barada <peter.barada at logicpd.com> wrote:
> I'm trying to build a single SPL/u-boot that supports multiple Logic
> OMAP 35x/37x boards, with multiple configurations of DRAM/NAND/NOR.
> This is to make our support/production much simpler, and allow one
> SPL/u-boot "just work" on all or various boards.  To do so I need to
> figure out:

Note that beagleboard handles this today, and the intent is that we
should be able to support a wide range of choices, with whatever
method is best on the board.  For example (and hiding from Wolfgang)
in am335x land, we plan to poke the EEPROM over i2c and see what it
tells us for a board and pick out based on that.

> 1) Probe for different DDR/NAND chips
>
> Our boards have multiple PoP parts on them (e.g. MT46H128M32L2K1-5 512MB
> DDR/0MB NAND, MT29C4G48MAPLCJI6 256MB DDR/512MB NAND,
> H8KCS0SJ0AER_MT29C2G24MAKLAJG6 128MB DDR/256MB NAND, etc), and no clear
> way in SPL to pick the right timings.  In my current x-loader code I
> have a table of SDRC register settings, set them up, and then probe to
> see if memory exists (including holes), and if a configuration doesn't
> work then move onto the next set of SDRC settings and try again.

This is similar to beagle where we poke and the NAND side of PoP and
then know what we've got, in both cases, along with other board-rev
tests.

>
> 2) Probe for multiple configurations of NOR/NAND
>
> Our boards can be populated with PoP/NOR flash in multiple combinations
> including cases where NAND+NOR exist, NAND or NOR exist, or neither NAND
> or NOR exist.  Currently u-boot has a static belief (driven by
> CONFIG_ENV_IS_*) of whether NAND/NOR exist and where to load/store the
> environment.  If the runtime detection is inconsistent with u-boot's
> configuration u-boot wedges due to accessing incomplete structures (i.e.
> nand_info[0].block_isbad is NULL if no NAND is found causing u-boot to
> go off in the weeds).

This is a separate issue I'd love to see resolved as well, but I think
we want to make these as two separate fixups.

> I currently have x-loader/u-boot code that does this, but want to
> identify an approach for doing this in the current u-boot trees(and
> incorporate such changes), such that it doesn't break other
> boards/archs, but also minimize impact on SPL/u-boot size...
>
> Any suggestions on an approach are much appreciated!

Part of the problem is, for hardware out in the wild, do you have a
method to determine what rev you're on?  This is where the EEPROM on
am335x comes in.

-- 
Tom