From: "Eric Bénard" <eric@eukrea.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: barebox@lists.infradead.org
Subject: Re: how do i add the defn for the beagle xM to barebox?
Date: Sun, 5 Feb 2012 18:43:40 +0100 [thread overview]
Message-ID: <20120205184340.1bddd53a@eb-e6520> (raw)
In-Reply-To: <alpine.DEB.2.02.1202051026020.9491@oneiric>
Le Sun, 5 Feb 2012 10:37:59 -0500 (EST),
"Robert P. J. Day" <rpjday@crashcourse.ca> a écrit :
> On Sun, 5 Feb 2012, Eric Bénard wrote:
>
> > Hi Robert,
> >
> > Le Sun, 5 Feb 2012 06:52:28 -0500 (EST),
> > "Robert P. J. Day" <rpjday@crashcourse.ca> a écrit :
> > > thoughts? i'd actually like to make the tweaks one at a time so
> > > that the git log shows clearly how the two boards differ one feature
> > > at a time.
> >
> > By sensing a few GPIO, you can easily check which board you are running
> > barebox on and thus have ony binary which supports all beagleboards
> > (as already done in u-boot).
> >
> > Check around line 108 in u-boot's beagle support for the details :
> > http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/beagle/beagle.c;h=5c04b34e1ab0140aca93e7752c8672ce7aebc0b9;hb=HEAD
> >
> > So in the end you can register the nand support only if you run on a
> > board which has a NAND flash and have one defconfig for all
> > beagleboards (some tweaks in the clock settings may be nedded -
> > especially for USB IIRC - as beagle XM is built around a DM3730 which
> > can run at 1GHz when older beagles had older OMAP3530 limited to
> > 720MHz).
>
> hmmmm ... i see one possible problem that maybe means i just haven't
> read far enough. in u-boot, in that beagle.c file, here's a chunk of
> code that identifies the NAND chip, of which there is none on the xM:
>
> /*
> * We need to identify what PoP memory is on the board so that
> * we know what timings to use. If we can't identify it then
> * we know it's an xM. To map the ID values please see nand_ids.c
> */
> identify_nand_chip(&pop_mfr, &pop_id);
>
> *mr = MICRON_V_MR_165;
> switch (get_board_revision()) {
> case REVISION_C4:
> if (pop_mfr == NAND_MFR_STMICRO && pop_id == 0xba) {
> /* 512MB DDR */
> *mcfg = NUMONYX_V_MCFG_165(512 << 20);
> *ctrla = NUMONYX_V_ACTIMA_165;
> *ctrlb = NUMONYX_V_ACTIMB_165;
> *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
> break;
> } else if (pop_mfr == NAND_MFR_MICRON && pop_id == 0xbc) {
> /* Beagleboard Rev C5, 256MB DDR */
> *mcfg = MICRON_V_MCFG_200(256 << 20);
> *ctrla = MICRON_V_ACTIMA_200;
> *ctrlb = MICRON_V_ACTIMB_200;
> *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
> break;
> }
> case REVISION_XM_A:
> case REVISION_XM_B:
> case REVISION_XM_C:
> if (pop_mfr == 0) {
> /* 256MB DDR */
> *mcfg = MICRON_V_MCFG_200(256 << 20);
> *ctrla = MICRON_V_ACTIMA_200;
> *ctrlb = MICRON_V_ACTIMB_200;
> *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_200MHz;
> } else {
> /* 512MB DDR */
> *mcfg = NUMONYX_V_MCFG_165(512 << 20);
> *ctrla = NUMONYX_V_ACTIMA_165;
> *ctrlb = NUMONYX_V_ACTIMB_165;
> *rfr_ctrl = SDP_3430_SDRC_RFR_CTRL_165MHz;
> }
> break;
> ... snip ...
>
> ok, i can see how that works, but if you need to test this way, it
> means that you'll constantly be overriding the CONFIG settings in the
> beagle defconfig file.
>
> if i read you correctly, then one should be able to use the same
> defconfig file for both a regular beagle and an xM. but the current
> barebox beagle xload defconfig file contains stuff like:
>
> CONFIG_MTD=y
> # CONFIG_MTD_WRITE is not set
> # CONFIG_MTD_OOB_DEVICE is not set
> CONFIG_NAND=y
> # CONFIG_NAND_ECC_SOFT is not set
> # CONFIG_NAND_ECC_HW_SYNDROME is not set
> # CONFIG_NAND_ECC_HW_NONE is not set
> # CONFIG_NAND_INFO is not set
> # CONFIG_NAND_BBT is not set
> CONFIG_NAND_OMAP_GPMC=y
>
> which is fine for a regular beagle but totally wrong for an xM. does
> this mean that, with an xM, i'd include the same (incorrect) defconfig
> file, and have to be constantly overriding some of those settings?
>
> i can see how getting the board revision lets you test how to do
> things differently across a related set of boards. but the difference
> between a regular beagle and an xM is *sizable* when you're talking
> about NAND versus no NAND. ideally, i'd like to have that board
> revision test available in the defconfig file itself. :-)
>
This is the case where u-boot is built with SPL thus reoplacing
x-load : they always read NAND ID as some XM boards were mounted with
Numonyx POP which includes NAND and 166MHz RAM when mot XM boards have
a POP with only 200MHz DDR (and in that case manufacturer ID is 0). So
even on a XM you need to check the NAND ID to set the right RAM
settings.
Eric
--
http://eukrea.com/en/news/104-2012
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2012-02-05 17:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-05 11:52 how do i add the defn for the beagle xM to barebox? Robert P. J. Day
2012-02-05 14:52 ` Eric Bénard
2012-02-05 14:58 ` Robert P. J. Day
2012-02-05 15:37 ` Robert P. J. Day
2012-02-05 17:43 ` Eric Bénard [this message]
2012-02-05 18:00 ` Robert P. J. Day
2012-02-05 19:44 ` Eric Bénard
2012-02-05 21:04 ` Robert P. J. Day
2012-02-06 9:33 ` Eric Bénard
2012-02-06 11:29 ` Sascha Hauer
2012-02-06 11:33 ` Robert P. J. Day
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=20120205184340.1bddd53a@eb-e6520 \
--to=eric@eukrea.com \
--cc=barebox@lists.infradead.org \
--cc=rpjday@crashcourse.ca \
/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.