Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-21 Thread Ladislav Michl 
On Wed, Sep 21, 2016 at 10:02:47AM -0400, Tom Rini wrote:
> On Wed, Sep 21, 2016 at 03:46:08PM +0200, Enric Balletbo Serra wrote:
> > 2016-09-21 14:51 GMT+02:00 Tom Rini :
> > > On Wed, Sep 21, 2016 at 01:46:51PM +0200, Enric Balletbo Serra wrote:
> > >> Hi,
> > >>
> > >> 2016-09-21 11:39 GMT+02:00 Ladislav Michl :
> > >> > On Tue, Sep 20, 2016 at 08:26:36PM -0400, Tom Rini wrote:
> > >> >> On Wed, Sep 21, 2016 at 01:52:21AM +0200, Ladislav Michl wrote:
> > >> >> > On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote:
> > >> > [snip]
> > >> >> > > But why do we even need to set MACH_TYPE these days?
> > >> >> >
> > >> >> > That's only needed for non-device tree kernel boot. These boards 
> > >> >> > run mostly
> > >> >> > vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree 
> > >> >> > with
> > >> >> > daughter boards specific patches on top of it. Enric is concerned 
> > >> >> > not
> > >> >> > to break that support, so I'm trying to keep it.
> > >> >>
> > >> >> OK, if you're still supporting stuff that old then yes, it makes 
> > >> >> sense.
> > >> >> And we can't get this right at run time?
> > >> >
> > >> > I asked several times, if there's a way to differentiate those boards
> > >> > (0020, 0030 and 0032) at runtime, but never get an answer. Of course
> > >> > I'd like to see one U-Boot binary to rule them all, but I'm out of clue
> > >> > there. Few people added to Cc...
> > >>
> > >> There is no way to differentiate those boards at runtime, those boards
> > >> are completely different platforms that share same processor, like
> > >> BeagleBoard or OMAP3 Overos . For me what you're trying to do is join
> > >> different platforms with the same processor, so why not join
> > >> BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?
> > >
> > > Note that the different beagleboard used GPIOs to tell which platform is
> > > which :)
> > 
> > Yes, but if I'm not mistaken you have different GPIOs for different
> > hardware revisions of Beagleboard. For IGEPv2 this is also true, you
> > have different GPIOs for different hardware revisions of IGEPv2. But
> > we're talking about join two completely different boards, i.e join
> > IGEPv2 (IGEP0020) with IGEP COM PROTON (IGEP0032) would be similar to
> > join Beagleboard with OMAP3 OVERO COM.

Well, on igep platform MACH_TYPE is currently used for:
- mux configuration (with IGEP COM PROTON strangely left out)
- status LED configuration
I wouldn't say these are completely different boards, at lest from
software perspective.

> > OTOH I think the Ladis work trying to join the IGEP boards is really
> > interesting, just want to look deeper :)
> 
> Right.  To play the thought exercise out a bit farther, if all of the
> detection methods for Beagleboard would _not_ cause an OVERO COM to be
> identified as a Beagle, we could move on to trying to see what rev overo
> we're on, or just assume it's that if all else fails.  Is anything like
> that possible with these IGEP boards?

I certainly didn't mean any board detection method hardware designer had in
mind while drawing schemantics, but more likely something like this:
IGEPv2 is using GPIO_94 to drive WIFI_PD_n and there's 100K pullup, so
setting this pin as input and reading its value could give some clue.
Now question is if there's such a combination of gpios used over this board
family, which provides reliable detection method. Unfortunately, I have only
IGEPv2 and public schemantics is available only for this board.

> > >> > Another approach might be to configure U-Boot using FDT and translate
> > >> > that information into MACH_TYPE and kernel command line to support
> > >> > non-device tree enabled kernels.
> 
> And to be clear over on this part, if we can tell at run time (or normal
> build time even, without directly passing MACH_TYPE=..) we should set
> that then instead of SYS_EXTRA_OPTIONS.

ladis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-21 Thread Tom Rini 
On Wed, Sep 21, 2016 at 03:46:08PM +0200, Enric Balletbo Serra wrote:
> 2016-09-21 14:51 GMT+02:00 Tom Rini :
> > On Wed, Sep 21, 2016 at 01:46:51PM +0200, Enric Balletbo Serra wrote:
> >> Hi,
> >>
> >> 2016-09-21 11:39 GMT+02:00 Ladislav Michl :
> >> > On Tue, Sep 20, 2016 at 08:26:36PM -0400, Tom Rini wrote:
> >> >> On Wed, Sep 21, 2016 at 01:52:21AM +0200, Ladislav Michl wrote:
> >> >> > On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote:
> >> > [snip]
> >> >> > > But why do we even need to set MACH_TYPE these days?
> >> >> >
> >> >> > That's only needed for non-device tree kernel boot. These boards run 
> >> >> > mostly
> >> >> > vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with
> >> >> > daughter boards specific patches on top of it. Enric is concerned not
> >> >> > to break that support, so I'm trying to keep it.
> >> >>
> >> >> OK, if you're still supporting stuff that old then yes, it makes sense.
> >> >> And we can't get this right at run time?
> >> >
> >> > I asked several times, if there's a way to differentiate those boards
> >> > (0020, 0030 and 0032) at runtime, but never get an answer. Of course
> >> > I'd like to see one U-Boot binary to rule them all, but I'm out of clue
> >> > there. Few people added to Cc...
> >>
> >> There is no way to differentiate those boards at runtime, those boards
> >> are completely different platforms that share same processor, like
> >> BeagleBoard or OMAP3 Overos . For me what you're trying to do is join
> >> different platforms with the same processor, so why not join
> >> BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?
> >
> > Note that the different beagleboard used GPIOs to tell which platform is
> > which :)
> 
> Yes, but if I'm not mistaken you have different GPIOs for different
> hardware revisions of Beagleboard. For IGEPv2 this is also true, you
> have different GPIOs for different hardware revisions of IGEPv2. But
> we're talking about join two completely different boards, i.e join
> IGEPv2 (IGEP0020) with IGEP COM PROTON (IGEP0032) would be similar to
> join Beagleboard with OMAP3 OVERO COM.
> 
> OTOH I think the Ladis work trying to join the IGEP boards is really
> interesting, just want to look deeper :)

Right.  To play the thought exercise out a bit farther, if all of the
detection methods for Beagleboard would _not_ cause an OVERO COM to be
identified as a Beagle, we could move on to trying to see what rev overo
we're on, or just assume it's that if all else fails.  Is anything like
that possible with these IGEP boards?

> >> > Another approach might be to configure U-Boot using FDT and translate
> >> > that information into MACH_TYPE and kernel command line to support
> >> > non-device tree enabled kernels.

And to be clear over on this part, if we can tell at run time (or normal
build time even, without directly passing MACH_TYPE=..) we should set
that then instead of SYS_EXTRA_OPTIONS.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-21 Thread Enric Balletbo Serra 
2016-09-21 14:51 GMT+02:00 Tom Rini :
> On Wed, Sep 21, 2016 at 01:46:51PM +0200, Enric Balletbo Serra wrote:
>> Hi,
>>
>> 2016-09-21 11:39 GMT+02:00 Ladislav Michl :
>> > On Tue, Sep 20, 2016 at 08:26:36PM -0400, Tom Rini wrote:
>> >> On Wed, Sep 21, 2016 at 01:52:21AM +0200, Ladislav Michl wrote:
>> >> > On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote:
>> > [snip]
>> >> > > But why do we even need to set MACH_TYPE these days?
>> >> >
>> >> > That's only needed for non-device tree kernel boot. These boards run 
>> >> > mostly
>> >> > vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with
>> >> > daughter boards specific patches on top of it. Enric is concerned not
>> >> > to break that support, so I'm trying to keep it.
>> >>
>> >> OK, if you're still supporting stuff that old then yes, it makes sense.
>> >> And we can't get this right at run time?
>> >
>> > I asked several times, if there's a way to differentiate those boards
>> > (0020, 0030 and 0032) at runtime, but never get an answer. Of course
>> > I'd like to see one U-Boot binary to rule them all, but I'm out of clue
>> > there. Few people added to Cc...
>>
>> There is no way to differentiate those boards at runtime, those boards
>> are completely different platforms that share same processor, like
>> BeagleBoard or OMAP3 Overos . For me what you're trying to do is join
>> different platforms with the same processor, so why not join
>> BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?
>
> Note that the different beagleboard used GPIOs to tell which platform is
> which :)
>

Yes, but if I'm not mistaken you have different GPIOs for different
hardware revisions of Beagleboard. For IGEPv2 this is also true, you
have different GPIOs for different hardware revisions of IGEPv2. But
we're talking about join two completely different boards, i.e join
IGEPv2 (IGEP0020) with IGEP COM PROTON (IGEP0032) would be similar to
join Beagleboard with OMAP3 OVERO COM.

OTOH I think the Ladis work trying to join the IGEP boards is really
interesting, just want to look deeper :)

>> > Another approach might be to configure U-Boot using FDT and translate
>> > that information into MACH_TYPE and kernel command line to support
>> > non-device tree enabled kernels.
>>
>> That is what I would like to see someday ;) All OMAP3 based boards
>> sharing the same binary and configure U-Boot using FDT.
>
> The probably trickiest part here is DDR config, which still punts things
> down to a board specific MLO.  But within an SoC this is probably a lot
> closer than people might think.
>
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-21 Thread Tom Rini 
On Wed, Sep 21, 2016 at 01:46:51PM +0200, Enric Balletbo Serra wrote:
> Hi,
> 
> 2016-09-21 11:39 GMT+02:00 Ladislav Michl :
> > On Tue, Sep 20, 2016 at 08:26:36PM -0400, Tom Rini wrote:
> >> On Wed, Sep 21, 2016 at 01:52:21AM +0200, Ladislav Michl wrote:
> >> > On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote:
> > [snip]
> >> > > But why do we even need to set MACH_TYPE these days?
> >> >
> >> > That's only needed for non-device tree kernel boot. These boards run 
> >> > mostly
> >> > vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with
> >> > daughter boards specific patches on top of it. Enric is concerned not
> >> > to break that support, so I'm trying to keep it.
> >>
> >> OK, if you're still supporting stuff that old then yes, it makes sense.
> >> And we can't get this right at run time?
> >
> > I asked several times, if there's a way to differentiate those boards
> > (0020, 0030 and 0032) at runtime, but never get an answer. Of course
> > I'd like to see one U-Boot binary to rule them all, but I'm out of clue
> > there. Few people added to Cc...
> 
> There is no way to differentiate those boards at runtime, those boards
> are completely different platforms that share same processor, like
> BeagleBoard or OMAP3 Overos . For me what you're trying to do is join
> different platforms with the same processor, so why not join
> BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?

Note that the different beagleboard used GPIOs to tell which platform is
which :)

> > Another approach might be to configure U-Boot using FDT and translate
> > that information into MACH_TYPE and kernel command line to support
> > non-device tree enabled kernels.
> 
> That is what I would like to see someday ;) All OMAP3 based boards
> sharing the same binary and configure U-Boot using FDT.

The probably trickiest part here is DDR config, which still punts things
down to a board specific MLO.  But within an SoC this is probably a lot
closer than people might think.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-21 Thread Enric Balletbo Serra 
Hi,

2016-09-21 11:39 GMT+02:00 Ladislav Michl :
> On Tue, Sep 20, 2016 at 08:26:36PM -0400, Tom Rini wrote:
>> On Wed, Sep 21, 2016 at 01:52:21AM +0200, Ladislav Michl wrote:
>> > On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote:
> [snip]
>> > > But why do we even need to set MACH_TYPE these days?
>> >
>> > That's only needed for non-device tree kernel boot. These boards run mostly
>> > vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with
>> > daughter boards specific patches on top of it. Enric is concerned not
>> > to break that support, so I'm trying to keep it.
>>
>> OK, if you're still supporting stuff that old then yes, it makes sense.
>> And we can't get this right at run time?
>
> I asked several times, if there's a way to differentiate those boards
> (0020, 0030 and 0032) at runtime, but never get an answer. Of course
> I'd like to see one U-Boot binary to rule them all, but I'm out of clue
> there. Few people added to Cc...
>

There is no way to differentiate those boards at runtime, those boards
are completely different platforms that share same processor, like
BeagleBoard or OMAP3 Overos . For me what you're trying to do is join
different platforms with the same processor, so why not join
BeagleBone, Overos, and IGEPs and all other OMAP3 based platforms?

> Another approach might be to configure U-Boot using FDT and translate
> that information into MACH_TYPE and kernel command line to support
> non-device tree enabled kernels.
>

That is what I would like to see someday ;) All OMAP3 based boards
sharing the same binary and configure U-Boot using FDT.


> ladis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-21 Thread Ladislav Michl 
On Tue, Sep 20, 2016 at 08:26:36PM -0400, Tom Rini wrote:
> On Wed, Sep 21, 2016 at 01:52:21AM +0200, Ladislav Michl wrote:
> > On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote:
[snip]
> > > But why do we even need to set MACH_TYPE these days?
> > 
> > That's only needed for non-device tree kernel boot. These boards run mostly
> > vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with
> > daughter boards specific patches on top of it. Enric is concerned not
> > to break that support, so I'm trying to keep it.
> 
> OK, if you're still supporting stuff that old then yes, it makes sense.
> And we can't get this right at run time?

I asked several times, if there's a way to differentiate those boards
(0020, 0030 and 0032) at runtime, but never get an answer. Of course
I'd like to see one U-Boot binary to rule them all, but I'm out of clue
there. Few people added to Cc...

Another approach might be to configure U-Boot using FDT and translate
that information into MACH_TYPE and kernel command line to support
non-device tree enabled kernels.

ladis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-20 Thread Tom Rini 
On Wed, Sep 21, 2016 at 01:52:21AM +0200, Ladislav Michl wrote:
> On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote:
> > On Wed, Sep 21, 2016 at 12:44:17AM +0200, Ladislav Michl wrote:
> [snip]
> > > Gah... I have to screw it up while resolving conflicts with upstream 
> > > changes.
> > > Obviously MACH_TYPE has to remain the same. Will do v2. I'm sorry for 
> > > that.
> > 
> > But why do we even need to set MACH_TYPE these days?
> 
> That's only needed for non-device tree kernel boot. These boards run mostly
> vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with
> daughter boards specific patches on top of it. Enric is concerned not
> to break that support, so I'm trying to keep it.

OK, if you're still supporting stuff that old then yes, it makes sense.
And we can't get this right at run time?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-20 Thread Ladislav Michl 
On Tue, Sep 20, 2016 at 07:45:14PM -0400, Tom Rini wrote:
> On Wed, Sep 21, 2016 at 12:44:17AM +0200, Ladislav Michl wrote:
[snip]
> > Gah... I have to screw it up while resolving conflicts with upstream 
> > changes.
> > Obviously MACH_TYPE has to remain the same. Will do v2. I'm sorry for that.
> 
> But why do we even need to set MACH_TYPE these days?

That's only needed for non-device tree kernel boot. These boards run mostly
vendor provided kernels based on TI 2.6.32 or 2.6.37 kernel tree with
daughter boards specific patches on top of it. Enric is concerned not
to break that support, so I'm trying to keep it.

ladis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-20 Thread Tom Rini 
On Wed, Sep 21, 2016 at 12:44:17AM +0200, Ladislav Michl wrote:
> On Tue, Sep 20, 2016 at 08:52:21AM -0400, Tom Rini wrote:
> > On Tue, Sep 20, 2016 at 11:07:57AM +0200, Ladislav Michl wrote:
> > > Update defconfigs and drop NAND specific defconfig as flash type
> > > is runtime detected.
> > > 
> > > Signed-off-by: Ladislav Michl 
> > > ---
> > >  configs/igep0030_defconfig  |  5 -
> > >  configs/igep0030_nand_defconfig | 30 --
> > >  configs/igep0032_defconfig  |  4 +++-
> > >  3 files changed, 7 insertions(+), 32 deletions(-)
> > >  delete mode 100644 configs/igep0030_nand_defconfig
> > > 
> > > diff --git a/configs/igep0030_defconfig b/configs/igep0030_defconfig
> > > index 66371d6..eb7a28f 100644
> > > --- a/configs/igep0030_defconfig
> > > +++ b/configs/igep0030_defconfig
> > > @@ -2,7 +2,9 @@ CONFIG_ARM=y
> > >  CONFIG_OMAP34XX=y
> > >  # CONFIG_SPL_EXT_SUPPORT is not set
> > >  CONFIG_TARGET_OMAP3_IGEP00X0=y
> > > -CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
> > > +CONFIG_SPL=y
> > > +CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0020"
> > 
> > Since you're even changing MACH_TYPE here, do we really need to be
> > setting this?  For both defconfigs, even.  Thanks!
> 
> Gah... I have to screw it up while resolving conflicts with upstream changes.
> Obviously MACH_TYPE has to remain the same. Will do v2. I'm sorry for that.

But why do we even need to set MACH_TYPE these days?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-20 Thread Ladislav Michl 
On Tue, Sep 20, 2016 at 08:52:21AM -0400, Tom Rini wrote:
> On Tue, Sep 20, 2016 at 11:07:57AM +0200, Ladislav Michl wrote:
> > Update defconfigs and drop NAND specific defconfig as flash type
> > is runtime detected.
> > 
> > Signed-off-by: Ladislav Michl 
> > ---
> >  configs/igep0030_defconfig  |  5 -
> >  configs/igep0030_nand_defconfig | 30 --
> >  configs/igep0032_defconfig  |  4 +++-
> >  3 files changed, 7 insertions(+), 32 deletions(-)
> >  delete mode 100644 configs/igep0030_nand_defconfig
> > 
> > diff --git a/configs/igep0030_defconfig b/configs/igep0030_defconfig
> > index 66371d6..eb7a28f 100644
> > --- a/configs/igep0030_defconfig
> > +++ b/configs/igep0030_defconfig
> > @@ -2,7 +2,9 @@ CONFIG_ARM=y
> >  CONFIG_OMAP34XX=y
> >  # CONFIG_SPL_EXT_SUPPORT is not set
> >  CONFIG_TARGET_OMAP3_IGEP00X0=y
> > -CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
> > +CONFIG_SPL=y
> > +CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0020"
> 
> Since you're even changing MACH_TYPE here, do we really need to be
> setting this?  For both defconfigs, even.  Thanks!

Gah... I have to screw it up while resolving conflicts with upstream changes.
Obviously MACH_TYPE has to remain the same. Will do v2. I'm sorry for that.

ladis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-20 Thread Tom Rini 
On Tue, Sep 20, 2016 at 11:07:57AM +0200, Ladislav Michl wrote:
> Update defconfigs and drop NAND specific defconfig as flash type
> is runtime detected.
> 
> Signed-off-by: Ladislav Michl 
> ---
>  configs/igep0030_defconfig  |  5 -
>  configs/igep0030_nand_defconfig | 30 --
>  configs/igep0032_defconfig  |  4 +++-
>  3 files changed, 7 insertions(+), 32 deletions(-)
>  delete mode 100644 configs/igep0030_nand_defconfig
> 
> diff --git a/configs/igep0030_defconfig b/configs/igep0030_defconfig
> index 66371d6..eb7a28f 100644
> --- a/configs/igep0030_defconfig
> +++ b/configs/igep0030_defconfig
> @@ -2,7 +2,9 @@ CONFIG_ARM=y
>  CONFIG_OMAP34XX=y
>  # CONFIG_SPL_EXT_SUPPORT is not set
>  CONFIG_TARGET_OMAP3_IGEP00X0=y
> -CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
> +CONFIG_SPL=y
> +CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0020"

Since you're even changing MACH_TYPE here, do we really need to be
setting this?  For both defconfigs, even.  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/3] igep00x0: consolidate defconfigs

2016-09-20 Thread Ladislav Michl 
Update defconfigs and drop NAND specific defconfig as flash type
is runtime detected.

Signed-off-by: Ladislav Michl 
---
 configs/igep0030_defconfig  |  5 -
 configs/igep0030_nand_defconfig | 30 --
 configs/igep0032_defconfig  |  4 +++-
 3 files changed, 7 insertions(+), 32 deletions(-)
 delete mode 100644 configs/igep0030_nand_defconfig

diff --git a/configs/igep0030_defconfig b/configs/igep0030_defconfig
index 66371d6..eb7a28f 100644
--- a/configs/igep0030_defconfig
+++ b/configs/igep0030_defconfig
@@ -2,7 +2,9 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_ONENAND"
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0020"
+CONFIG_BOOTDELAY=3
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
 CONFIG_SPL_MTD_SUPPORT=y
@@ -26,5 +28,6 @@ CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/igep0030_nand_defconfig b/configs/igep0030_nand_defconfig
deleted file mode 100644
index f63bcac..000
--- a/configs/igep0030_nand_defconfig
+++ /dev/null
@@ -1,30 +0,0 @@
-CONFIG_ARM=y
-CONFIG_OMAP34XX=y
-# CONFIG_SPL_EXT_SUPPORT is not set
-CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0030,BOOT_NAND"
-CONFIG_VERSION_VARIABLE=y
-CONFIG_SPL=y
-CONFIG_SPL_MTD_SUPPORT=y
-CONFIG_SPL_ONENAND_SUPPORT=y
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_BOOTZ=y
-# CONFIG_CMD_IMLS is not set
-CONFIG_CMD_ASKENV=y
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_MMC=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_I2C=y
-CONFIG_CMD_GPIO=y
-# CONFIG_CMD_SETEXPR is not set
-CONFIG_CMD_DHCP=y
-CONFIG_CMD_MII=y
-CONFIG_CMD_PING=y
-CONFIG_CMD_CACHE=y
-CONFIG_CMD_EXT2=y
-CONFIG_CMD_EXT4=y
-CONFIG_CMD_EXT4_WRITE=y
-CONFIG_CMD_FAT=y
-CONFIG_CMD_FS_GENERIC=y
-CONFIG_SYS_NS16550=y
-CONFIG_OF_LIBFDT=y
diff --git a/configs/igep0032_defconfig b/configs/igep0032_defconfig
index 991d9d7..eb7a28f 100644
--- a/configs/igep0032_defconfig
+++ b/configs/igep0032_defconfig
@@ -2,7 +2,9 @@ CONFIG_ARM=y
 CONFIG_OMAP34XX=y
 # CONFIG_SPL_EXT_SUPPORT is not set
 CONFIG_TARGET_OMAP3_IGEP00X0=y
-CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0032,BOOT_ONENAND"
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS="MACH_TYPE=MACH_TYPE_IGEP0020"
+CONFIG_BOOTDELAY=3
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL=y
 CONFIG_SPL_MTD_SUPPORT=y
-- 
2.1.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot