anyone configured u-boot to recognize *specifically* a beagle xM?

GoogleGroups
1

i brought this up recently on the u-boot list, but i thought this
would be at least as appropriate a forum to ask -- is there any value
(and how hard would it be) to adding some simple config option to
u-boot to build specifically for a beagle xM rather than a classic
beagle? the primary difference being, all of the NAND flash-related
u-boot commands could be deselected.

  AFAICT, the generic beagle u-boot build works fine for the xM --
it's running happily on the xM (rev C) sitting next to my laptop right
this minute. the drawback is that the "help" output is cluttered with
commands related to NAND flash -- fsinfo, fsload, mtdparts, nandecc,
nand, nboot and so on -- that have no value to me or the board.

  as was explained to me, a simple solution would be to add a new line
for a beaglexm to the "boards.cfg" file, which would pick up an
additional header file that would (as i read it) simply turn around
and deselect NAND-related functionality.

  is that a reasonable approach? it would just be nice to be able to
configure and build u-boot for the xM, and not have all the NAND junk
sitting there taking up space.

  thoughts?

rday

2

Do you want u-boot to detect NAND presence on the fly (running on the board) and include/exclude NAND commands or during compilation? If during compilation phase then why don’t you DIY in the config file? Simply comment NAND related strings by # and enjoy

3

i know that's an option -- i was suggesting making it official by
possibly just adding an extra config file that does all that
automatically so one doesn't need to do it manually.

rday

4

  i brought this up recently on the u-boot list, but i thought this
would be at least as appropriate a forum to ask -- is there any value
(and how hard would it be) to adding some simple config option to
u-boot to build specifically for a beagle xM rather than a classic
beagle? the primary difference being, all of the NAND flash-related
u-boot commands could be deselected.

It wouldn't be hard. Just make a new target in boards.cfg and append
some options to it such that those options then comment out the nand
parts of the omap3_beagle config. Similar to how am335x_evm now has
many uarts possible for those with bones and uart capes (or
frankenstein messes of wires) except you'll also want to #if(n)def a few
places in the omap3_beagle config.

  AFAICT, the generic beagle u-boot build works fine for the xM --
it's running happily on the xM (rev C) sitting next to my laptop right
this minute. the drawback is that the "help" output is cluttered with
commands related to NAND flash -- fsinfo, fsload, mtdparts, nandecc,
nand, nboot and so on -- that have no value to me or the board.

But, as mentioned in the u-boot ml thread, some xM do have nand, just
not very many of them. Maybe a good option name would be something
like CONFIG_BEAGLE_WITHOUT_NAND or similar, to make it clear that it's
not a beagle / xM split but a beagle with or without nand split.

  as was explained to me, a simple solution would be to add a new line
for a beaglexm to the "boards.cfg" file, which would pick up an
additional header file that would (as i read it) simply turn around
and deselect NAND-related functionality.

  is that a reasonable approach? it would just be nice to be able to
configure and build u-boot for the xM, and not have all the NAND junk
sitting there taking up space.

Yes, that's the reasonable approach. Give it a shot, mail a patch. I
can test the xM part of things for you (sorry, don't have an orig
beagle).

Related, can't original beagles boot from mmc? Wouldn't then this
beagle-without-nand option be usable there, too? At least for those
who don't want to use the nand?

-Andrew

5

yup, i agree with all of the above -- not so much a "xM" selection
as a "i have no NAND flash" selection. i'll play with that later
today. in fact, it wouldn't even need to be restricted to beagles --
why not a generic "i have no NAND flash" switch that anyone can add to
their configuration, and which de-activates all NAND flash
functionality?

rday

6

do NAND related commands bother you? I still don’t understand why these commands are so annoying

7

I think that already exists, you just don't put any of the CONFIG
options for NAND in. Like omap4_panda and omap4_common, there's no
CONFIG_*NAND* options at all. There's also already
CONFIG_SYS_NO_FLASH, which may do what you want but doesn't seem to go
about it the same way you're describing (but maybe it does?).

I would focus more on just the beagle with and without nand for now.

-Andrew

8

i believe that option relates to NOR flash, not NAND flash. if you
look through numerous files in include/configs, they have lines like
this:

include/configs/devkit8000.h:#define CONFIG_SYS_NO_FLASH /* no NOR flash */

but i'll check to make sure.

rday

9

it's just a matter of tidiness. i'm currently writing a chapter on
u-boot for one of my courses that will be delivered on an xM, and when
students stop in u-boot and run "help", i don't want them to have to
wade through numerous commands that aren't relevant.

  it seems like this should be a fairly trivial thing to add.

rday

10

... snip ...

I think that already exists, you just don't put any of the CONFIG
options for NAND in. Like omap4_panda and omap4_common, there's no
CONFIG_*NAND* options at all. There's also already
CONFIG_SYS_NO_FLASH, which may do what you want but doesn't seem to go
about it the same way you're describing (but maybe it does?).

I would focus more on just the beagle with and without nand for now.

  since i think i've made some progress, i figured i'd share what
little i learned. it's obvious that the boards.cfg file in u-boot
gives you the opportunity to define a new "target", and here's a
trivial example:

at91rm9200ek arm arm920t at91rm9200ek atmel at91 at91rm9200ek
at91rm9200ek_ram arm arm920t at91rm9200ek atmel at91 at91rm9200ek:RAMBOOT

so that second target is defined in terms of the original config file,
but additionally defining the "CONFIG_RAMBOOT" preprocessor symbol.

  well, that's great if you're *adding* symbols, but it doesn't seem
to help if you want to *undefine* symbols from the original file. in
cases like that, it seems you need to do the following, as i did:

omap3_beagle arm armv7 beagle ti omap3
omap3_beaglexm arm armv7 beagle ti omap3

so if i run:

$ make omap3_beaglexm_config

the make will consult the (new) config file omap3_beaglexm.h, whose
contents are (as a first attempt):

#include "omap3_beagle.h"
#undef CONFIG_CMD_NAND
#undef CONFIG_CMD_JFFS2
#undef CONFIG_CMD_MTDPARTS

  that config step works, at which point running "make" finally
generates errors:

... snip ...
arch/arm/cpu/armv7/omap3/libomap3.o: In function `do_switch_ecc':
/home/rpjday/uboot/git/master/arch/arm/cpu/armv7/omap3/board.c:334:
undefined reference to `omap_nand_switch_ecc'
/home/rpjday/uboot/git/master/arch/arm/cpu/armv7/omap3/board.c:336:
undefined reference to `omap_nand_switch_ecc'
common/libcommon.o: In function `do_env_save':
/home/rpjday/uboot/git/master/common/cmd_nvedit.c:632: undefined
reference to `saveenv'
common/libcommon.o: In function `readenv':
/home/rpjday/uboot/git/master/common/env_nand.c:283: undefined
reference to `nand_read_skip_bad'
/home/rpjday/uboot/git/master/common/env_nand.c:296: undefined
reference to `nand_info'
... snip ...

  all that tells me is that i need to undefine even more symbols, but
it also tells me that the dependencies could be cleaned up, no? after
all, if i undefine NAND support entirely, that should also drop the
compilation of anything depending on NAND, don't you think?

  the above seems like the easiest way to get what i'm after. i don't
see a way to do this solely within the confines of the boards.cfg
file.

rday

11

Add a symbol, similar to the RAMBOOT, e.g. NO_NAND
   omap3_beagle arm armv7 beagle ti omap3
   omap3_beagle_no_nand arm armv7 beagle ti omap3:NO_NAND

Then, in include/configs/omap3_beagle.h (at the end, after everything else is defined)

#ifdef CONFIG_NO_NAND
#undef CONFIG_CMD_NAND
  ... etc
#endif

To get rid of the undefined reference to 'saveenv', try adding
#define CONFIG_ENV_IS_NOWHERE

12

ah, quite so ... embarrassed i didn't think of that. but it still
seems there might be some cleanup in order since, as i mentioned in
my last post, if one, say, undefs CONFIG_CMD_NAND, that should
automatically deselect anything that depends on that.

  for now, it can be a brutally manual undef'ing of the appropriate
content. thanks.

rday

13

regarding removing NAND support from u-boot to build for an xM
without flash:

... snip ...

Add a symbol, similar to the RAMBOOT, e.g. NO_NAND
  omap3_beagle arm armv7 beagle ti
omap3
  omap3_beagle_no_nand arm armv7 beagle ti
omap3:NO_NAND

Then, in include/configs/omap3_beagle.h (at the end, after everything else is
defined)

#ifdef CONFIG_NO_NAND
#undef CONFIG_CMD_NAND
... etc
#endif

To get rid of the undefined reference to 'saveenv', try adding
#define CONFIG_ENV_IS_NOWHERE

  i'm willing to experiment with this and add a single(?) config
option to u-boot's omap3_beagle.h file to deselect NAND-related stuff
to make it more appropriate for the (NAND-less versions of the) xM and
add another entry to boards.cfg to choose this.

  open to advice -- does this mean i can remove any and all config
options related to NAND, MTD, JFFS2? it would *seem* so -- that is,
without NAND flash, would there be any need to retain JFFS2 support?

  as i noted yesterday, it's not enough to just #under CONFIG_CMD_NAND
as a lot of NAND-related functionality remains, so one has to do a
clean sweep of the options in that file to get them all.

rday

p.s. to do it properly, i guess one would even have to redefine the
variables for booting and environment to remove variable definitions
related to NAND, but i'll leave that alone for the time being.

14

Robert,

  regarding removing NAND support from u-boot to build for an xM
without flash:

... snip ...

> Add a symbol, similar to the RAMBOOT, e.g. NO_NAND
> omap3_beagle arm armv7
> beagle ti omap3
> omap3_beagle_no_nand arm armv7
> beagle ti omap3:NO_NAND
>
> Then, in include/configs/omap3_beagle.h (at the end, after
> everything else is defined)
>
> #ifdef CONFIG_NO_NAND
> #undef CONFIG_CMD_NAND
> ... etc
> #endif
>
> To get rid of the undefined reference to 'saveenv', try adding
> #define CONFIG_ENV_IS_NOWHERE

  i'm willing to experiment with this and add a single(?) config
option to u-boot's omap3_beagle.h file to deselect NAND-related stuff
to make it more appropriate for the (NAND-less versions of the) xM and
add another entry to boards.cfg to choose this.

Would it make more sense to have the 'omap3_beagle' target have defined
CONFIG_HAS_NAND or something of that nature rather than a
CONFIG_NO_NAND? Reason being, if you have a negative (CONFIG_NO_NAND)
then in the config file you'll have to #ifndef CONFIG_NO_NAND which is
somewhat confusing as a double negative if you don't Gary's idea of
having just everything not related to NAND #undef'ed at the end.

  open to advice -- does this mean i can remove any and all config
options related to NAND, MTD, JFFS2? it would *seem* so -- that is,
without NAND flash, would there be any need to retain JFFS2 support?

I would think you could remove JFFS2, MTD, and all NAND related things,
yes.

<snip>

p.s. to do it properly, i guess one would even have to redefine the
variables for booting and environment to remove variable definitions
related to NAND, but i'll leave that alone for the time being.

Why leave it for now?
If your goal is to remove NAND related things from 'printenv' or
'help', removing the boot command and environment portions related to
NAND is somewhat important.

Have you had a chance to come up with a patch? I haven't seen anything
on the u-boot ml thread.

-Andrew

15

Well... I'm wrong. If you remove more than just the commands related
to JFFS2, MTD, and NAND, you'll run into board/ti/beagle/beagle.c which
has the SPL use NAND chip detection to determine what board is
underneath at runtime. And fixing that may not just be some #defines.
u-boot proper seems to build fine without any NAND related things but
the SPL wants to touch NAND quite a lot, to do some basic setup.

I took a quick shot at it just now and the rabbit hole is a bit deeper
than I expected. Does sound like a fun project though :slight_smile:

Sorry for my lack of help.

-Andrew

16

>
> > open to advice -- does this mean i can remove any and all config
> > options related to NAND, MTD, JFFS2? it would *seem* so -- that is,
> > without NAND flash, would there be any need to retain JFFS2 support?
>
> I would think you could remove JFFS2, MTD, and all NAND related
> things, yes.

Well... I'm wrong. If you remove more than just the commands
related to JFFS2, MTD, and NAND, you'll run into
board/ti/beagle/beagle.c which has the SPL use NAND chip detection
to determine what board is underneath at runtime. And fixing that
may not just be some #defines. u-boot proper seems to build fine
without any NAND related things but the SPL wants to touch NAND
quite a lot, to do some basic setup.

  ok, that's kind of confusing, since how does it work when there's no
NAND? or, wait ... are you saying SPL uses NAND detection, and will
properly detect if there's no NAND? that actually makes sense, it
just means that there needs to be a slightly different configuration
for SPL than there is for u-boot proper, and i don't find that
unreasonable.

I took a quick shot at it just now and the rabbit hole is a bit
deeper than I expected. Does sound like a fun project though :slight_smile:

  if i have the time, i'll check it out more. at the very least, it
would be an educational experience.

rday

p.s. i'm assuming that, WRT to beagle.c, you're referring to this
routine?

        identify_nand_chip(&pop_mfr, &pop_id);

17

>
> >
> > > open to advice -- does this mean i can remove any and all
> > > config options related to NAND, MTD, JFFS2? it would *seem* so
> > > -- that is, without NAND flash, would there be any need to
> > > retain JFFS2 support?
> >
> > I would think you could remove JFFS2, MTD, and all NAND related
> > things, yes.
>
> Well... I'm wrong. If you remove more than just the commands
> related to JFFS2, MTD, and NAND, you'll run into
> board/ti/beagle/beagle.c which has the SPL use NAND chip detection
> to determine what board is underneath at runtime. And fixing that
> may not just be some #defines. u-boot proper seems to build fine
> without any NAND related things but the SPL wants to touch NAND
> quite a lot, to do some basic setup.

  ok, that's kind of confusing, since how does it work when there's no
NAND? or, wait ... are you saying SPL uses NAND detection, and will
properly detect if there's no NAND? that actually makes sense, it
just means that there needs to be a slightly different configuration
for SPL than there is for u-boot proper, and i don't find that
unreasonable.

It works in the sense that no NAND IDs are returned. Then the fact
that no NAND could be found results in assuming the board's an xM.
It wouldn't be unreasonable to have different config for SPL than
u-boot proper but a few of the NAND CONFIGs seem to be used for both
thus making it more difficult to separate the two.

> I took a quick shot at it just now and the rabbit hole is a bit
> deeper than I expected. Does sound like a fun project though :slight_smile:

  if i have the time, i'll check it out more. at the very least, it
would be an educational experience.

p.s. i'm assuming that, WRT to beagle.c, you're referring to this
routine?

        identify_nand_chip(&pop_mfr, &pop_id);

Yes. That's the first one I ran into. There may be others. Sorry, I
had written two different replies to this thread at the same time but
only sent one of them, the unsent one spelled out that function name and
apparently I forgot to do so in the reply I sent.

-Andrew