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

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

[Peter Barada]

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:

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.

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).


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!

-- 
Peter Barada
peter.barada at logicpd.com

[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@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

[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@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

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

[Wolfgang Denk]

Dear Peter Barada,

In message <4F57A37C.8070501@logicpd.com> you 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. 

On ARM this is still not not exactly a rampant feature (and some
[mostly ARM] SoCs try to be clever and makeit extra hard for you),
but for a large number of boards this has been a standard feature
right since the beginning of U-Boot (and PPCBoot) twelf years ago.

> 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:
> 
> 1) Probe for different DDR/NAND chips
...
> 2) Probe for multiple configurations of NOR/NAND
...

This is what get_ram_size() is good for.

> Any suggestions on an approach are much appreciated!

The normal approach is: set a configuration, run get_ram_size(), and
store the detected size. Repeat for all configurations. The
configuration that results in the biggest detected RAM size is the
correct one.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Yes, it is written.  Good shall always destroy evil.
	-- Sirah the Yang, "The Omega Glory", stardate unknown

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

[Wolfgang Denk]

Dear Tom Rini,

In message <CA+M6bXkgRyPFf2iLyiP6rptnkdU3=zG_wCpQhLvcjMDp1Of9PA@mail.gmail.com> you wrote:
>
> 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.

There should be no need for that.  If the possible configuration
options are know, auto-detection is possible as well.

Given that EEPROM access is pretty slow, auto-detecting might even be
faster.  And it helps detecting memory problems (usually when boards
get booted fresh from production).

> 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.

You don't need to know the board rev.  All you need to know is the
set of possible config options.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Nature is very un-American.  Nature never hurries."
- William George Jordan

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

[Tom Rini]

On Wed, Mar 7, 2012 at 3:13 PM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Tom Rini,
>
> In message <CA+M6bXkgRyPFf2iLyiP6rptnkdU3=zG_wCpQhLvcjMDp1Of9PA@mail.gmail.com> you wrote:
>>
>> 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.
>
> There should be no need for that. ?If the possible configuration
> options are know, auto-detection is possible as well.

So throw the DDR3 timings at the part, if it works, great, if not try
the DDR2 timings?

-- 
Tom