On 07/18/2014 02:10 AM, Valentin Longchamp wrote: > Hello Wolfgang, > > On 07/17/2014 02:47 PM, Wolfgang Denk wrote: >> Dear Valentin, >> >> In message >> <1405599840-11984-1-git-send-email-valentin.longch...@keymile.com> you wrote: >>> When u-boot initializes the RAM (early in boot) it looks for the "pram" >>> env variable to know which is area it cannot use. >>> >>> At this early boot stage, the "pram" env variable is not avaible yet >>> since it gets computed in set_km_env that gets called AFTER the RAM >>> initialization. If the "pram" env variable is not found, the default >>> CONFIG_PRAM value is used. >> >> Note that I am not objecting against this patch, but I highly >> recommend to fix your board - RAM initialization is actually pretty >> late in the init sequence, and you should have a valid envionment long >> before. >> > > Maybe my commit message is unclear about this. You are right, at the RAM > initialization time, there is a valid environment, and that's the case on our > board too. > > However, at the very first boot on a board, the environment is empty (or > unvalid) and the default one is used where this "pram" env variable is not > defined. That's why the CONFIG_PRAM is used in this case and it should be > defined. This is not going to be the case at any later boot if a valid > environment (with pram defined) is found and used. > > Best regards, >
Valentin, How about you update the commit message to explain you are defining the default CONFIG_PRAM for your board in case "pram" variable is not available? York _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
