All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] environment reliability after "env default -f -a"
@ 2018-11-15 20:02 Sam Protsenko
  2018-11-16 13:20 ` Wolfgang Denk
  0 siblings, 1 reply; 3+ messages in thread
From: Sam Protsenko @ 2018-11-15 20:02 UTC (permalink / raw)
  To: u-boot

Hi all,

It was noticed that after resetting the U-Boot environment ("env
default -f -a") some variables are missing, and being added back after
"reset". E.g. in my case it's next variables:

    board_name=am57xx_evm_reva3
    ethaddr=fc:0f:4b:7b:27:9c
    fastboot.board_rev=A.3A
    fastboot.cpu=DRA752
    fastboot.secure=GP
    fastboot.userdata_size=2352351
    fdtcontroladdr=fdf0d188
    scsidevs=0
    serial#=0c0090170f6e0122
    stderr=serial at 48020000
    stdin=serial at 48020000
    stdout=serial at 48020000
    ver=U-Boot 2018.11-00028-g3ad6ba7780 (Nov 15 2018 - 21:17:57 +0200)

Most likely those variables are being set on board_late_init(), so we
don't see them after "env default -f -a".

My question is: do we rely on environment to be the same after doing
"env default -f -a", comparing to environment after reboot? If so,
should I provide some sort of env callback to run corresponding
routines on "env default" event (like [1])?

P.S. As I understand, we don't rely on this. But I didn't find this in
documentation, so asking just to be completely sure.

Thanks!

[1] https://pastebin.ubuntu.com/p/z9bhsJ9cTG/

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot] environment reliability after "env default -f -a"
  2018-11-15 20:02 [U-Boot] environment reliability after "env default -f -a" Sam Protsenko
@ 2018-11-16 13:20 ` Wolfgang Denk
  2018-11-19 15:21   ` Sam Protsenko
  0 siblings, 1 reply; 3+ messages in thread
From: Wolfgang Denk @ 2018-11-16 13:20 UTC (permalink / raw)
  To: u-boot

Dear Sam,

In message <CAKaJLVveZcdD-OCCRXCSJT0KVeWD1M9G+AqPxX9pSs4MRoLoaw@mail.gmail.com> you wrote:
> 
> My question is: do we rely on environment to be the same after doing
> "env default -f -a", comparing to environment after reboot? If so,
> should I provide some sort of env callback to run corresponding
> routines on "env default" event (like [1])?

We should rather not rely on this.

I think many boards contain board-specific code to manipulate the
environment, especially on first boot (and resetting the env usually
makes the next boot a "first" one).  You cannot scan all board
specific code for such actions, or implement any generic handler for
this.

[Well yes, maybe one could rewrite all such board-specific code into
some common "first boot handler" that could be called from a central
place,  but who should do that?

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
As usual, this being a 1.3.x release, I haven't  even  compiled  this
kernel yet. So if it works, you should be doubly impressed.
      - Linus Torvalds in <199506181536.SAA10638@keos.cs.Helsinki.FI>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [U-Boot] environment reliability after "env default -f -a"
  2018-11-16 13:20 ` Wolfgang Denk
@ 2018-11-19 15:21   ` Sam Protsenko
  0 siblings, 0 replies; 3+ messages in thread
From: Sam Protsenko @ 2018-11-19 15:21 UTC (permalink / raw)
  To: u-boot

Hi,

On Fri, Nov 16, 2018 at 3:20 PM Wolfgang Denk <wd@denx.de> wrote:
>
> Dear Sam,
>
> In message <CAKaJLVveZcdD-OCCRXCSJT0KVeWD1M9G+AqPxX9pSs4MRoLoaw@mail.gmail.com> you wrote:
> >
> > My question is: do we rely on environment to be the same after doing
> > "env default -f -a", comparing to environment after reboot? If so,
> > should I provide some sort of env callback to run corresponding
> > routines on "env default" event (like [1])?
>
> We should rather not rely on this.
>
> I think many boards contain board-specific code to manipulate the
> environment, especially on first boot (and resetting the env usually
> makes the next boot a "first" one).  You cannot scan all board
> specific code for such actions, or implement any generic handler for
> this.
>
> [Well yes, maybe one could rewrite all such board-specific code into
> some common "first boot handler" that could be called from a central
> place,  but who should do that?
>

Sounds logical. Thank you for confirming this, Wolfgang!

> 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
> As usual, this being a 1.3.x release, I haven't  even  compiled  this
> kernel yet. So if it works, you should be doubly impressed.
>       - Linus Torvalds in <199506181536.SAA10638@keos.cs.Helsinki.FI>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-11-19 15:21 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-15 20:02 [U-Boot] environment reliability after "env default -f -a" Sam Protsenko
2018-11-16 13:20 ` Wolfgang Denk
2018-11-19 15:21   ` Sam Protsenko

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.