[U-Boot] [RFC] Make U-Boot log great again

[Wolfgang Denk]

Dear Sam,

In message <CAKaJLVvL-E7b5XKqixM4yn=2rXW5qzRRS5ijkWRjmdetdakZ2Q at mail.gmail.com> you wrote:
> 
> AFAIU, that behavior was changed in the mentioned patch (please see my
> original message). Let me elaborate a bit. In v2018.01 everything
> works fine and none errors/warnings are present on my boards (AM57x
> EVM and X15 board). The problem appears after commit fb69464eae1e
> ("env: Allow to build multiple environments in Kconfig"). Now U-Boot
> tries to load the environment from SD card first (uEnv.txt file on FAT
> partition), and then from eMMC partition. In case when SD card is not
> inserted, I observe mentioned errors. So I'm not sure how to handle
> this properly, that's why I created this thread... Let me try and
> explain my concerns better:

I think we both are talking about the same thing.  I just see it
differently :-)

If the user configures the system to try the SDCard first for the
environment, and it cannot find it there, then this should be
considered an error situation (even if recoverable by falling back
to secondary storage), and at least a warning must be printed (or an
error, if there is no secondary storage configured).

I agree with you that both the part about the CRC error and the part
about using the default environment are wrong in this case, so the
tezt of the warning message needs to be fixed - it should say
clearly that the attempt to _read_ the environment from storage
device _XXX_ failed.

>  1. On the one hand, it's good to check the environment on both SD
> card and eMMC (that was done in mentioned patch). This case seems to
> be legit (at least as far as I understand it), i.e. when SD card is
> not inserted, it's fine, we just check the env on eMMC

If this is what is configured, yes.  In this case I would expoect to
see something like this:

# Warning: Can't read environment from SDCard, trying now: eMMC.

or such [eventually - and if available - with additional information
like "no card present"].

>  2. But on the other hand, errors shouldn't appear in boot log, if
> it's legit case, it's confusing the user

Well, the "legit case" is that the primary storage for the
environment works.  If it is not available, this is something that
the user should be made aware of.

> Please correct me if I'm wrong, I'm just trying to come up with
> correct perspective about what should be done about it. Like:
>  1. Just disable SD card environment (i.e. revert that patch changes
> for my board). But it's probably a useful feature?

It is definitely a useful feature in many situations.

On the other hand, as always you should know what you are doing. For
example:

Assume no error/warning is printed when no SDCard is present.  Then
the user might not even be aware that the SDCard is being probed.
He may assume he can secure his system for example by setting
bootdelay=0 to prevent commandline access in U-Boot.  And apparently
this will work fine for him - until someone comes along wh inserts a
SDCard with different environment settings.

I think it is a good ide to inform the user what is actually going
on...

>  2. Fix errors handling when multiple environments are enabled

THis is definitely needed, agreed.

> In my case, we have two sources for the env: SD card and eMMC. And we
> have 2 possible state of the board:
>  1. SD card is inserted. U-Boot will be ran from SD card
>  2. SD card is not inserted. U-Boot will be ran from eMMC
> 
> The question is, how we are supposed to handle environment for those
> two cases? Right now it's being tested from SD card first, then (if
> not found), it's going to be tested from eMMC. That's where the error
> appears (if SD card is not inserted).

I think this is pretty clear: the configuration apparently selects
SDCard as the primary storage for the environment and probes it
first.  When it is not present, it tries the second best option,
eMMC.  In this case a warning is appropriate.  And i eMMC does not
work either, then an error message must be printed.

> Ok, you are saying that the error shouldn't happen. But the only way I
> see to change that, is to implement conditional probing for the
> environment. Like:
>  1. If we are being booted from SD card, load the environment only from SD card
>  2. If we are being booted from eMMC, load the environment only from eMMC

This is another configuration.  it is as valid as the other one.  I
assume you can insert a SDCard without SPL/U-Boot on it, so you will
still boot from eMMC, but read the environment from SDCard?

There are many configurations which could be implemented, but they
all should be explicit about the "search order" for the environment.

Of course ou can make this as complicated as you like.  One could
also define a policy if all storage locations are equal, so you
don't care where the environment is coming from as long as any of
them works.  Or you define a clear sequence, in which case you will
want to be informed (warning) when the primary location does not
work.  One could even make this behavious switchable at run-time.
But: do we really need that?

I would expect, that the strict order primary forst, then try next
storage devices in strict sequence, and warn for not working ones,
is what most users expect and find useful.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
The White Rabbit put on his spectacles. "Where shall I begin,  please
your Majesty ?" he asked.
"Begin at the beginning,", the King said, very gravely,  "and  go  on
till you come to the end: then stop."                -- Lewis Carroll