Re: [U-Boot] environment access before relocation does not work on (some) arm
Hi, On 29.06.2012 13:26, Wolfgang Denk wrote: Dear Matthias Fuchs, In message 4fed7877.2020...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] environment access before relocation does not work on (some) arm
Dear Matthias Fuchs, In message 4ff306fc.9040...@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 -- 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: w...@denx.de Remember, Information is not knowledge; Knowledge is not Wisdom; Wisdom is not truth; Truth is not beauty; Beauty is not love; Love is not music; Music is the best. - Frank Zappa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] environment access before relocation does not work on (some) arm
Dear Matthias Fuchs, In message 4fed7877.2020...@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 -- 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: w...@denx.de Time is an illusion perpetrated by the manufacturers of space. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
