[U-Boot] [PATCH v4] Add initial support for Wandboard dual lite and solo.

[Wolfgang Denk]

Dear Fabio,

In message <CAOMZO5AVbVjXhHvMmZYRmroBWZYXb_-_4eNiQVTUjOOXD=iDhg at mail.gmail.com> you wrote:
> 
> > Is there any reason for not chosing the more standard 5 second delay?
> 
> Ok, so let's go with 3 seconds then ;-)

Why not 5?  For development, 1 or 3 is often quite short.  I've seen
enough cases where connecting to a serial port (for example, through
one of thos @#&^!*y USB devices) eats a major part of that time.  And
for production mode when boot times are important you don;t want such
a dealy anyway, not even with 1 or with 3 seconds.

> > I can confirm that the code boots on a wanboard_dl system, but it does
> > not find the environment as used by the original Technixion port. Is
> > this intentional?

Sorry for my typo.  The company name is Technexion.

> To be honest I haven't really checked the environment settings used in
> the original Technixion port.
> 
> Hopefully this is not a problem.

Not really a problem.  I just wondered if there was a good reason to
chose a different location for the environment.  BTW - would it not
make sense to enable redundant environment?

Actually I don;t think it is worth keepin the old settings, but that's
just my opinion.  Other users might be surprised to lose their whole
environment settings when updating from the vendor provided version to
mainline, so at least a warning should go to the board specific
README.

> > Can we please remove the "Reset cause: WDOG" line in production mode?
> 
> Do you mean the change below?
> 
> --- a/arch/arm/imx-common/cpu.c
> +++ b/arch/arm/imx-common/cpu.c
> @@ -148,7 +148,7 @@ int print_cpuinfo(void)
>                 (cpurev & 0x000F0) >> 4,
>                 (cpurev & 0x0000F) >> 0,
>                 mxc_get_clock(MXC_ARM_CLK) / 1000000);
> -       printf("Reset cause: %s\n", get_reset_cause());
> +       debug("Reset cause: %s\n", get_reset_cause());
>         return 0;
>  }
>  #endif
> 
> Since this is common code I can address it separately with other
> patch. Just let me know if this is OK.

Indeed this is common code, I see it now.  So yes, if we change this,
it should be done as separate patch.  I think debug() makes a lot of
sense here to reduce the output at boot time to a reasonable minimum,
but then - is there another way for the user to inquire for this
information.  If not, should we add it to the bdinfo output?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I used to think that the brain was the most wonderful  organ  in  my
body. Then I realized who was telling me this."        - Emo Phillips