[U-Boot] environment access before relocation does not work on (some) arm
Hi,
I just noticed that using getenv (and friends) does not work on ARM (namely i.MX28) from board_init_f() after running through the init_sequence.
So getenv_ulong() always returns the given default. So the baudrate on affected boards is always set by CONFIG_BAUDRATE and cannot be adjusted by the baudrate env variable and so on. Environment access before relocation is required for some functions: pram, fdtcontroladdr, baudrate, ...
Env access does not work before env_relocate() in board_init_r().
Didn't this behave different sometimes before? Even after the big env rework?
Matthias
Dear Matthias Fuchs,
In message 4FED7877.2020505@esd.eu you wrote:
I just noticed that using getenv (and friends) does not work on ARM (namely i.MX28) from board_init_f() after running through the init_sequence.
This is normal, and documented. Before relocation, you must not use getenv().
Env access does not work before env_relocate() in board_init_r().
It does, but you have to play by the rules, i. e. use getenv_f() instead.
Didn't this behave different sometimes before? Even after the big env rework?
No. The use of getenv() before relocation has never been supported. It may have worked (by pure chance) on some systems, but that's all.
Best regards,
Wolfgang Denk
Hi,
On 29.06.2012 13:26, Wolfgang Denk wrote:
Dear Matthias Fuchs,
In message 4FED7877.2020505@esd.eu you wrote:
I just noticed that using getenv (and friends) does not work on ARM (namely i.MX28) from board_init_f() after running through the init_sequence.
This is normal, and documented. Before relocation, you must not use getenv().
Yes, I am aware of this. I even think that the getenv() implementation falls back to getenv_f() before relocation.
Env access does not work before env_relocate() in board_init_r().
It does, but you have to play by the rules, i. e. use getenv_f() instead.
Yes, I did not care about where my env comes from :-) So env_sf.c does not support an early env at all. Running on an i.MX28 with env in a SPI flash I probably need SPI support in my SPL and an improved env_sf.c.
... and all this to get CONFIG_PRAM working in arch/arm/lib/board.c. So I will stuck at using a constant pram value for the moment. This works.
Didn't this behave different sometimes before? Even after the big env rework?
No. The use of getenv() before relocation has never been supported. It may have worked (by pure chance) on some systems, but that's all.
Of course. My question was not very precise.
Matthias
Best regards,
Wolfgang Denk
Dear Matthias Fuchs,
In message 4FF306FC.9040305@esd.eu you wrote:
This is normal, and documented. Before relocation, you must not use getenv().
Yes, I am aware of this. I even think that the getenv() implementation falls back to getenv_f() before relocation.
This is not guaranteed to work.
Yes, I did not care about where my env comes from :-) So env_sf.c does not support an early env at all. Running on an i.MX28 with env in a SPI flash I probably need SPI support in my SPL and an improved env_sf.c.
This is a bigger topic. We all wait anxiously for Mareks group to implement a clean device driver model, so we can clean up and unify all this code. I am aware that it needs it.
Best regards,
Wolfgang Denk
participants (2)
-
Matthias Fuchs -
Wolfgang Denk