mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
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: Mon, 6 Feb 2012 12:29:06 +0100	[thread overview]
Message-ID: <20120206112906.GM1990@pengutronix.de> (raw)
In-Reply-To: <alpine.DEB.2.02.1202051558230.17815@oneiric>

On Sun, Feb 05, 2012 at 04:04:07PM -0500, Robert P. J. Day wrote:
> On Sun, 5 Feb 2012, Eric Bénard wrote:
> 
> > Le Sun, 5 Feb 2012 13:00:13 -0500 (EST),
> > "Robert P. J. Day" <rpjday@crashcourse.ca> a écrit :
> >
> > > On Sun, 5 Feb 2012, Eric Bénard wrote:
> > >
> > > > 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.
> > >
> > >   ah, got it.  but what about in a more general case?  what if you
> > > have a current, accurate definition for an existing board?  then a
> > > *slight* variant of that board comes along, for which some settings in
> > > the defconfig file are simply wrong?
> > >
> > >   are there any examples of that in barebox right now?  and if not,
> > > how would one handle them?  put another way, what if *all* xM boards
> > > had no NAND?  then we'd be back to my original question, and it's
> > > still not clear how you'd define that new board for barebox.
> > >
> > if no XM board had NAND, you would simply check the board type using the
> > GPIO sampled and you wouldn't register the nand (line 305 in
> > board-beagle.c) and the fact that the nand driver is enabled is not a
> > problem if the device is not registrered the driver won't be used.
> 
>   not to put too fine a point on it but ... yuck.  don't get me wrong,
> i certainly see the value in testing things like board versions so the
> code knows how to handle small differences between similar boards
> (memory speed, flash types or sizes and so on).
> 
>   but this isn't a small difference -- this represents potentially an
> entire subsystem (NAND) that i want the ability to de-activate.  in a
> perfect world, i want the ability to say concisely that i have a
> beagle but i have no NAND flash, period.  i don't want any of the NAND
> code compiled, i don't want it included in the binary, so obviously i
> don't want any of that code to run, only to realize it has nothing to
> do.

The mentioned U-Boot code does not use any of the nand layer but only
some omap specific function to detect the nand id (identify_nand_chip).
This means that you can add this code to barebox and still disable nand
support.

If you still want to have a more fine grained config we can add a

config MACH_PANDA_XM_VARIANT
	bool

config MACH_PANDA_XM_DETECT_RAM_TYPE
	bool

But we should add such options with care. Generally I don't really
like to ask the user complicated questions for things that can be
autodetected.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  parent reply	other threads:[~2012-02-06 11:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-05 11:52 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
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 [this message]
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=20120206112906.GM1990@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox