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

[Peter Barada]

On 03/07/2012 02:28 PM, Tom Rini wrote:
> 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.
Unfortunately I don't have the luxury of looking in an eeprom to ID
board components...  So I need to figure out the best approach to
probing for different memory chips, some which can't run at the max
speed the DM37x support (like the Hynix it can't run at 200Mhz).  To do
this I'm thinking of evolving my previous patch at [1] to have
board_mem_get_timings() pass a second arg that is a pointer to an int
that contains the ARRAY_SIZE() of the structure returned, as well as add
to the structure the max MHz that memory configuration can run at.  Then
I can list all the large/fast parts first and have the sdrc code probe
each CS and possibly across CS (for dual CS parts) to make sure that
aliasing, etc are handled.

[1] - http://patchwork.ozlabs.org/patch/143095/

>> 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.
Definitely, this will require multiple patch submissions and is wholly
separate from DDR probing.

>> 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.
There is, but no useful H/W identifier in it to use to ID DDR (I'm
trying to change that going forward to have in the eeprom data that
holds the actual DDR timing sheet values at various speeds, and have SPL
compute the register settings from it).


-- 
Peter Barada
peter.barada at logicpd.com