RFC - how to support multipl DRAM chips in a single SPL build?
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!
Signature · 2 lines
Peter Barada peter.barada at logicpd.com
Quoted 5 lines · 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:
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.
Quoted 9 lines
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_MT29C2G24MAKLAJG6128MB 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.
Quoted 11 lines
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.
Quoted 6 lines
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.
Signature · 1 line
Tom
Quoted 11 lines · Tom Rini
Quoted 5 lines · 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:
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/
Quoted 23 lines
Quoted 9 lines
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_MT29C2G24MAKLAJG6128MB 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.
Quoted 10 lines
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).
Quoted 2 lines
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.
Quoted 9 lines
Quoted 6 lines
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).
Signature · 2 lines
Peter Barada peter.barada at logicpd.com
Dear Tom Rini,
Quoted 6 lines · In message <CA+M6bXkgRyPFf2iLyiP6rptnkdU3=zG_wCpQhLvcjMDp1Of9PA@mail.gmail.com>…
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).
Quoted 3 lines
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
Signature · 5 lines
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
Quoted 4 lines · Wolfgang Denk
Dear Tom Rini,
Quoted 1 line · In message <CA+M6bXkgRyPFf2iLyiP6rptnkdU3=zG_wCpQhLvcjMDp1Of9PA@mail.gmail.com>…
Quoted 8 lines
Quoted 5 lines
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?
Signature · 1 line
Tom
Dear Peter Barada,
Quoted 2 lines · In message <[email protected]> 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.
Quoted 5 lines
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
...
Quoted 1 line
2) Probe for multiple configurations of NOR/NAND
...
This is what get_ram_size() is good for.
Quoted 1 line
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
Signature · 5 lines
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