From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valentin Longchamp Date: Fri, 18 Jul 2014 11:10:23 +0200 Subject: [U-Boot] [PATCH] km-powerpc: define CONFIG_PRAM to protect PHRAM and PNVRAM In-Reply-To: <20140717124745.DAAD3383374@gemini.denx.de> References: <1405599840-11984-1-git-send-email-valentin.longchamp@keymile.com> <20140717124745.DAAD3383374@gemini.denx.de> Message-ID: <53C8E47F.3020600@keymile.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Wolfgang, On 07/17/2014 02:47 PM, Wolfgang Denk wrote: > Dear Valentin, > > In message <1405599840-11984-1-git-send-email-valentin.longchamp@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