diff mbox

[U-Boot,1/8] mx28evk: Configure CONFIG_BOOTDELAY to one second

Message ID 1353078550-574-1-git-send-email-festevam@gmail.com
State Awaiting Upstream
Delegated to: Stefano Babic
Headers show

Commit Message

Fabio Estevam Nov. 16, 2012, 3:09 p.m. UTC 
From: Fabio Estevam <fabio.estevam@freescale.com>

One second is enough time for users to react in case they want to stop the
booting process.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
 include/configs/mx28evk.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Stefano Babic Nov. 19, 2012, 7:51 a.m. UTC | #1 
On 16/11/2012 16:09, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@freescale.com>
> 
> One second is enough time for users to react in case they want to stop the
> booting process.
> 
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
>  include/configs/mx28evk.h |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
> index 2916c71..8b89b25 100644
> --- a/include/configs/mx28evk.h
> +++ b/include/configs/mx28evk.h
> @@ -238,7 +238,7 @@
>   */
>  #define CONFIG_CMDLINE_TAG
>  #define CONFIG_SETUP_MEMORY_TAGS
> -#define CONFIG_BOOTDELAY	3
> +#define CONFIG_BOOTDELAY	1
>  #define CONFIG_BOOTFILE	"uImage"
>  #define CONFIG_LOADADDR	0x42000000
>  #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR
> 

Applied (whole series) to u-boot-imx, thanks.

Best regards,
Stefano Babic
Marek Vasut Nov. 19, 2012, 11:52 p.m. UTC | #2 
Dear Stefano Babic,

> On 16/11/2012 16:09, Fabio Estevam wrote:
> > From: Fabio Estevam <fabio.estevam@freescale.com>
> > 
> > One second is enough time for users to react in case they want to stop
> > the booting process.
> > 
> > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > ---
> > 
> >  include/configs/mx28evk.h |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
> > index 2916c71..8b89b25 100644
> > --- a/include/configs/mx28evk.h
> > +++ b/include/configs/mx28evk.h
> > @@ -238,7 +238,7 @@
> > 
> >   */
> >  
> >  #define CONFIG_CMDLINE_TAG
> >  #define CONFIG_SETUP_MEMORY_TAGS
> > 
> > -#define CONFIG_BOOTDELAY	3
> > +#define CONFIG_BOOTDELAY	1
> > 
> >  #define CONFIG_BOOTFILE	"uImage"
> >  #define CONFIG_LOADADDR	0x42000000
> >  #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR
> 
> Applied (whole series) to u-boot-imx, thanks.

What about making some generic ... config-mx28.h AND config-fsl.h ... and 
including those in board-specific configs?

Best regards,
Marek Vasut
Stefano Babic Nov. 20, 2012, 3:44 p.m. UTC | #3 
On 20/11/2012 00:52, Marek Vasut wrote:
> Dear Stefano Babic,
> 
>> On 16/11/2012 16:09, Fabio Estevam wrote:
>>> From: Fabio Estevam <fabio.estevam@freescale.com>
>>>
>>> One second is enough time for users to react in case they want to stop
>>> the booting process.
>>>
>>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>>> ---
>>>
>>>  include/configs/mx28evk.h |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
>>> index 2916c71..8b89b25 100644
>>> --- a/include/configs/mx28evk.h
>>> +++ b/include/configs/mx28evk.h
>>> @@ -238,7 +238,7 @@
>>>
>>>   */
>>>  
>>>  #define CONFIG_CMDLINE_TAG
>>>  #define CONFIG_SETUP_MEMORY_TAGS
>>>
>>> -#define CONFIG_BOOTDELAY	3
>>> +#define CONFIG_BOOTDELAY	1
>>>
>>>  #define CONFIG_BOOTFILE	"uImage"
>>>  #define CONFIG_LOADADDR	0x42000000
>>>  #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR
>>
>> Applied (whole series) to u-boot-imx, thanks.
> 
> What about making some generic ... config-mx28.h AND config-fsl.h ... and 
> including those in board-specific configs?

Any clean-up is welcome. Then maybe (and this is not related to i.MX
only) we could have a cpu-config, a vendor config and on the top a board
config.

#include <cpu-config.h>
#include <vendor-config.h>
#include <board-config.h>

The main problem is that an exception can breaks our castle, and we are
constrained to add #undef in board configuration file.

Best regards,
Stefano
Otavio Salvador Nov. 20, 2012, 5:50 p.m. UTC | #4 
On Tue, Nov 20, 2012 at 1:44 PM, Stefano Babic <sbabic@denx.de> wrote:
> On 20/11/2012 00:52, Marek Vasut wrote:
>> Dear Stefano Babic,
>>
>>> On 16/11/2012 16:09, Fabio Estevam wrote:
>>>> From: Fabio Estevam <fabio.estevam@freescale.com>
>>>>
>>>> One second is enough time for users to react in case they want to stop
>>>> the booting process.
>>>>
>>>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>>>> ---
>>>>
>>>>  include/configs/mx28evk.h |    2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
>>>> index 2916c71..8b89b25 100644
>>>> --- a/include/configs/mx28evk.h
>>>> +++ b/include/configs/mx28evk.h
>>>> @@ -238,7 +238,7 @@
>>>>
>>>>   */
>>>>
>>>>  #define CONFIG_CMDLINE_TAG
>>>>  #define CONFIG_SETUP_MEMORY_TAGS
>>>>
>>>> -#define CONFIG_BOOTDELAY   3
>>>> +#define CONFIG_BOOTDELAY   1
>>>>
>>>>  #define CONFIG_BOOTFILE    "uImage"
>>>>  #define CONFIG_LOADADDR    0x42000000
>>>>  #define CONFIG_SYS_LOAD_ADDR       CONFIG_LOADADDR
>>>
>>> Applied (whole series) to u-boot-imx, thanks.
>>
>> What about making some generic ... config-mx28.h AND config-fsl.h ... and
>> including those in board-specific configs?
>
> Any clean-up is welcome. Then maybe (and this is not related to i.MX
> only) we could have a cpu-config, a vendor config and on the top a board
> config.
>
> #include <cpu-config.h>
> #include <vendor-config.h>
> #include <board-config.h>
>
> The main problem is that an exception can breaks our castle, and we are
> constrained to add #undef in board configuration file.

I support this idea; currently I think we ought to have as much as
common code by vendor so it is easy to document things and avoid
duplication.

Currently we cannot expect a board to have same (or near the same) set
of features. Some provide a good default environment, others doesn't.
Marek Vasut Nov. 20, 2012, 6:09 p.m. UTC | #5 
Dear Otavio Salvador,

> On Tue, Nov 20, 2012 at 1:44 PM, Stefano Babic <sbabic@denx.de> wrote:
> > On 20/11/2012 00:52, Marek Vasut wrote:
> >> Dear Stefano Babic,
> >> 
> >>> On 16/11/2012 16:09, Fabio Estevam wrote:
> >>>> From: Fabio Estevam <fabio.estevam@freescale.com>
> >>>> 
> >>>> One second is enough time for users to react in case they want to stop
> >>>> the booting process.
> >>>> 
> >>>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> >>>> ---
> >>>> 
> >>>>  include/configs/mx28evk.h |    2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>> 
> >>>> diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
> >>>> index 2916c71..8b89b25 100644
> >>>> --- a/include/configs/mx28evk.h
> >>>> +++ b/include/configs/mx28evk.h
> >>>> @@ -238,7 +238,7 @@
> >>>> 
> >>>>   */
> >>>>  
> >>>>  #define CONFIG_CMDLINE_TAG
> >>>>  #define CONFIG_SETUP_MEMORY_TAGS
> >>>> 
> >>>> -#define CONFIG_BOOTDELAY   3
> >>>> +#define CONFIG_BOOTDELAY   1
> >>>> 
> >>>>  #define CONFIG_BOOTFILE    "uImage"
> >>>>  #define CONFIG_LOADADDR    0x42000000
> >>>>  #define CONFIG_SYS_LOAD_ADDR       CONFIG_LOADADDR
> >>> 
> >>> Applied (whole series) to u-boot-imx, thanks.
> >> 
> >> What about making some generic ... config-mx28.h AND config-fsl.h ...
> >> and including those in board-specific configs?
> > 
> > Any clean-up is welcome. Then maybe (and this is not related to i.MX
> > only) we could have a cpu-config, a vendor config and on the top a board
> > config.
> > 
> > #include <cpu-config.h>
> > #include <vendor-config.h>
> > #include <board-config.h>
> > 
> > The main problem is that an exception can breaks our castle, and we are
> > constrained to add #undef in board configuration file.
> 
> I support this idea; currently I think we ought to have as much as
> common code by vendor so it is easy to document things and avoid
> duplication.

WFM

> Currently we cannot expect a board to have same (or near the same) set
> of features. Some provide a good default environment, others doesn't.

Let's leave ENV out of this discussion. Moreover, this needs to be done in 
proper incremental steps.

Furthermore, new thread should be started.

Just an idea, to avoid undef in board-files, we can have #ifdef CONFIG... 
#define CONFIG... #endif constructions in the CPU-specific files. This will 
allow simple overriding (of course, these files would have to be included at the 
bottom of the board config file then).

Otavio, any plans to finish u-boot/mx23 soon?

Best regards,
Marek Vasut
Otavio Salvador Nov. 20, 2012, 6:19 p.m. UTC | #6 
On Tue, Nov 20, 2012 at 4:09 PM, Marek Vasut <marex@denx.de> wrote:
> Dear Otavio Salvador,
>
>> On Tue, Nov 20, 2012 at 1:44 PM, Stefano Babic <sbabic@denx.de> wrote:
>> > On 20/11/2012 00:52, Marek Vasut wrote:
>> >> Dear Stefano Babic,
>> >>
>> >>> On 16/11/2012 16:09, Fabio Estevam wrote:
>> >>>> From: Fabio Estevam <fabio.estevam@freescale.com>
>> >>>>
>> >>>> One second is enough time for users to react in case they want to stop
>> >>>> the booting process.
>> >>>>
>> >>>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>> >>>> ---
>> >>>>
>> >>>>  include/configs/mx28evk.h |    2 +-
>> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>>>
>> >>>> diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
>> >>>> index 2916c71..8b89b25 100644
>> >>>> --- a/include/configs/mx28evk.h
>> >>>> +++ b/include/configs/mx28evk.h
>> >>>> @@ -238,7 +238,7 @@
>> >>>>
>> >>>>   */
>> >>>>
>> >>>>  #define CONFIG_CMDLINE_TAG
>> >>>>  #define CONFIG_SETUP_MEMORY_TAGS
>> >>>>
>> >>>> -#define CONFIG_BOOTDELAY   3
>> >>>> +#define CONFIG_BOOTDELAY   1
>> >>>>
>> >>>>  #define CONFIG_BOOTFILE    "uImage"
>> >>>>  #define CONFIG_LOADADDR    0x42000000
>> >>>>  #define CONFIG_SYS_LOAD_ADDR       CONFIG_LOADADDR
>> >>>
>> >>> Applied (whole series) to u-boot-imx, thanks.
>> >>
>> >> What about making some generic ... config-mx28.h AND config-fsl.h ...
>> >> and including those in board-specific configs?
>> >
>> > Any clean-up is welcome. Then maybe (and this is not related to i.MX
>> > only) we could have a cpu-config, a vendor config and on the top a board
>> > config.
>> >
>> > #include <cpu-config.h>
>> > #include <vendor-config.h>
>> > #include <board-config.h>
>> >
>> > The main problem is that an exception can breaks our castle, and we are
>> > constrained to add #undef in board configuration file.
>>
>> I support this idea; currently I think we ought to have as much as
>> common code by vendor so it is easy to document things and avoid
>> duplication.
>
> WFM
>
>> Currently we cannot expect a board to have same (or near the same) set
>> of features. Some provide a good default environment, others doesn't.
>
> Let's leave ENV out of this discussion. Moreover, this needs to be done in
> proper incremental steps.

So you prefer it to manage features only, at least for now?

> Furthermore, new thread should be started.

Agreed.

> Just an idea, to avoid undef in board-files, we can have #ifdef CONFIG...
> #define CONFIG... #endif constructions in the CPU-specific files. This will
> allow simple overriding (of course, these files would have to be included at the
> bottom of the board config file then).

So basically a global feature-aware setting file.

> Otavio, any plans to finish u-boot/mx23 soon?

No reply yet from the guy who got it further. I am almost getting onto
it without his patches ...
Marek Vasut Nov. 20, 2012, 6:43 p.m. UTC | #7 
Dear Otavio Salvador,

> On Tue, Nov 20, 2012 at 4:09 PM, Marek Vasut <marex@denx.de> wrote:
> > Dear Otavio Salvador,
> > 
> >> On Tue, Nov 20, 2012 at 1:44 PM, Stefano Babic <sbabic@denx.de> wrote:
> >> > On 20/11/2012 00:52, Marek Vasut wrote:
> >> >> Dear Stefano Babic,
> >> >> 
> >> >>> On 16/11/2012 16:09, Fabio Estevam wrote:
> >> >>>> From: Fabio Estevam <fabio.estevam@freescale.com>
> >> >>>> 
> >> >>>> One second is enough time for users to react in case they want to
> >> >>>> stop the booting process.
> >> >>>> 
> >> >>>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> >> >>>> ---
> >> >>>> 
> >> >>>>  include/configs/mx28evk.h |    2 +-
> >> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>>> 
> >> >>>> diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
> >> >>>> index 2916c71..8b89b25 100644
> >> >>>> --- a/include/configs/mx28evk.h
> >> >>>> +++ b/include/configs/mx28evk.h
> >> >>>> @@ -238,7 +238,7 @@
> >> >>>> 
> >> >>>>   */
> >> >>>>  
> >> >>>>  #define CONFIG_CMDLINE_TAG
> >> >>>>  #define CONFIG_SETUP_MEMORY_TAGS
> >> >>>> 
> >> >>>> -#define CONFIG_BOOTDELAY   3
> >> >>>> +#define CONFIG_BOOTDELAY   1
> >> >>>> 
> >> >>>>  #define CONFIG_BOOTFILE    "uImage"
> >> >>>>  #define CONFIG_LOADADDR    0x42000000
> >> >>>>  #define CONFIG_SYS_LOAD_ADDR       CONFIG_LOADADDR
> >> >>> 
> >> >>> Applied (whole series) to u-boot-imx, thanks.
> >> >> 
> >> >> What about making some generic ... config-mx28.h AND config-fsl.h ...
> >> >> and including those in board-specific configs?
> >> > 
> >> > Any clean-up is welcome. Then maybe (and this is not related to i.MX
> >> > only) we could have a cpu-config, a vendor config and on the top a
> >> > board config.
> >> > 
> >> > #include <cpu-config.h>
> >> > #include <vendor-config.h>
> >> > #include <board-config.h>
> >> > 
> >> > The main problem is that an exception can breaks our castle, and we
> >> > are constrained to add #undef in board configuration file.
> >> 
> >> I support this idea; currently I think we ought to have as much as
> >> common code by vendor so it is easy to document things and avoid
> >> duplication.
> > 
> > WFM
> > 
> >> Currently we cannot expect a board to have same (or near the same) set
> >> of features. Some provide a good default environment, others doesn't.
> > 
> > Let's leave ENV out of this discussion. Moreover, this needs to be done
> > in proper incremental steps.
> 
> So you prefer it to manage features only, at least for now?

For now, yes. And let's not do it all in one massive swipe, but rather slowly. 
First pull out CPU-specific goo, then sep-out manufacturer stuff etc.

> > Furthermore, new thread should be started.
> 
> Agreed.
> 
> > Just an idea, to avoid undef in board-files, we can have #ifdef CONFIG...
> > #define CONFIG... #endif constructions in the CPU-specific files. This
> > will allow simple overriding (of course, these files would have to be
> > included at the bottom of the board config file then).
> 
> So basically a global feature-aware setting file.

More or less, yes.

> > Otavio, any plans to finish u-boot/mx23 soon?
> 
> No reply yet from the guy who got it further. I am almost getting onto
> it without his patches ...

Yes, I suspect we might have lost him :(

Best regards,
Marek Vasut
Scott Wood Nov. 20, 2012, 11 p.m. UTC | #8 
On 11/19/2012 05:52:07 PM, Marek Vasut wrote:
> Dear Stefano Babic,
> 
> > On 16/11/2012 16:09, Fabio Estevam wrote:
> > > From: Fabio Estevam <fabio.estevam@freescale.com>
> > >
> > > One second is enough time for users to react in case they want to  
> stop
> > > the booting process.
> > >
> > > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > > ---
> > >
> > >  include/configs/mx28evk.h |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
> > > index 2916c71..8b89b25 100644
> > > --- a/include/configs/mx28evk.h
> > > +++ b/include/configs/mx28evk.h
> > > @@ -238,7 +238,7 @@
> > >
> > >   */
> > >
> > >  #define CONFIG_CMDLINE_TAG
> > >  #define CONFIG_SETUP_MEMORY_TAGS
> > >
> > > -#define CONFIG_BOOTDELAY	3
> > > +#define CONFIG_BOOTDELAY	1
> > >
> > >  #define CONFIG_BOOTFILE	"uImage"
> > >  #define CONFIG_LOADADDR	0x42000000
> > >  #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR
> >
> > Applied (whole series) to u-boot-imx, thanks.
> 
> What about making some generic ... config-mx28.h AND config-fsl.h ...  
> and
> including those in board-specific configs?

What configuration subset would be applicable to every "fsl" target,  
including i.MX, mpc83xx, mpc85xx, mpc5xxx, m68k, etc?

-Scott
Marek Vasut Nov. 21, 2012, 12:15 a.m. UTC | #9 
Dear Scott Wood,

> On 11/19/2012 05:52:07 PM, Marek Vasut wrote:
> > Dear Stefano Babic,
> > 
> > > On 16/11/2012 16:09, Fabio Estevam wrote:
> > > > From: Fabio Estevam <fabio.estevam@freescale.com>
> > > > 
> > > > One second is enough time for users to react in case they want to
> > 
> > stop
> > 
> > > > the booting process.
> > > > 
> > > > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > > > ---
> > > > 
> > > >  include/configs/mx28evk.h |    2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
> > > > index 2916c71..8b89b25 100644
> > > > --- a/include/configs/mx28evk.h
> > > > +++ b/include/configs/mx28evk.h
> > > > @@ -238,7 +238,7 @@
> > > > 
> > > >   */
> > > >  
> > > >  #define CONFIG_CMDLINE_TAG
> > > >  #define CONFIG_SETUP_MEMORY_TAGS
> > > > 
> > > > -#define CONFIG_BOOTDELAY	3
> > > > +#define CONFIG_BOOTDELAY	1
> > > > 
> > > >  #define CONFIG_BOOTFILE	"uImage"
> > > >  #define CONFIG_LOADADDR	0x42000000
> > > >  #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR
> > > 
> > > Applied (whole series) to u-boot-imx, thanks.
> > 
> > What about making some generic ... config-mx28.h AND config-fsl.h ...
> > and
> > including those in board-specific configs?
> 
> What configuration subset would be applicable to every "fsl" target,
> including i.MX, mpc83xx, mpc85xx, mpc5xxx, m68k, etc?

That's up to you to think about ... anyway, move it to a separate thread please.

Best regards,
Marek Vasut
Scott Wood Nov. 21, 2012, 12:20 a.m. UTC | #10 
On 11/20/2012 06:15:25 PM, Marek Vasut wrote:
> Dear Scott Wood,
> 
> > On 11/19/2012 05:52:07 PM, Marek Vasut wrote:
> > > Dear Stefano Babic,
> > >
> > > > On 16/11/2012 16:09, Fabio Estevam wrote:
> > > > > From: Fabio Estevam <fabio.estevam@freescale.com>
> > > > >
> > > > > One second is enough time for users to react in case they  
> want to
> > >
> > > stop
> > >
> > > > > the booting process.
> > > > >
> > > > > Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > > > > ---
> > > > >
> > > > >  include/configs/mx28evk.h |    2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/include/configs/mx28evk.h  
> b/include/configs/mx28evk.h
> > > > > index 2916c71..8b89b25 100644
> > > > > --- a/include/configs/mx28evk.h
> > > > > +++ b/include/configs/mx28evk.h
> > > > > @@ -238,7 +238,7 @@
> > > > >
> > > > >   */
> > > > >
> > > > >  #define CONFIG_CMDLINE_TAG
> > > > >  #define CONFIG_SETUP_MEMORY_TAGS
> > > > >
> > > > > -#define CONFIG_BOOTDELAY	3
> > > > > +#define CONFIG_BOOTDELAY	1
> > > > >
> > > > >  #define CONFIG_BOOTFILE	"uImage"
> > > > >  #define CONFIG_LOADADDR	0x42000000
> > > > >  #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR
> > > >
> > > > Applied (whole series) to u-boot-imx, thanks.
> > >
> > > What about making some generic ... config-mx28.h AND config-fsl.h  
> ...
> > > and
> > > including those in board-specific configs?
> >
> > What configuration subset would be applicable to every "fsl" target,
> > including i.MX, mpc83xx, mpc85xx, mpc5xxx, m68k, etc?
> 
> That's up to you to think about ... anyway, move it to a separate  
> thread please.

I think the answer to that question is "nothing" -- and you can change  
the thread title at any time you wish; I'm not going to go create some  
unrelated thread to respond to a point that you raised in this thread.

-Scott
diff mbox

Patch

diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h
index 2916c71..8b89b25 100644
--- a/include/configs/mx28evk.h
+++ b/include/configs/mx28evk.h
@@ -238,7 +238,7 @@ 
  */
 #define CONFIG_CMDLINE_TAG
 #define CONFIG_SETUP_MEMORY_TAGS
-#define CONFIG_BOOTDELAY	3
+#define CONFIG_BOOTDELAY	1
 #define CONFIG_BOOTFILE	"uImage"
 #define CONFIG_LOADADDR	0x42000000
 #define CONFIG_SYS_LOAD_ADDR	CONFIG_LOADADDR