From: Peter Barada <peter.barada@logicpd.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] RFC - how to support multipl DRAM chips in a single SPL build?
Date: Wed, 07 Mar 2012 13:05:48 -0500 [thread overview]
Message-ID: <4F57A37C.8070501@logicpd.com> (raw)
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
next reply other threads:[~2012-03-07 18:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-07 18:05 Peter Barada [this message]
2012-03-07 19:28 ` [U-Boot] RFC - how to support multipl DRAM chips in a single SPL build? Tom Rini
2012-03-07 19:58 ` Peter Barada
2012-03-07 22:13 ` Wolfgang Denk
2012-03-07 22:21 ` Tom Rini
2012-03-07 22:10 ` Wolfgang Denk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F57A37C.8070501@logicpd.com \
--to=peter.barada@logicpd.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.