From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Thu, 08 Oct 2015 06:40:15 +0200 Subject: [U-Boot] Inconsistencies in commands regarding load_addr In-Reply-To: <5613E20F.8060306@wsystem.com> References: <5613E20F.8060306@wsystem.com> Message-ID: <20151008044015.BC4DB380905@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Beno?t, In message <5613E20F.8060306@wsystem.com> you wrote: > > I've just noticed that before the commit > 045fa1e1142552799ad3203e9e0bc22a11e866ea, ext2load and ext4load were setting the > load_addr global variable, but not fatload. Since then, none of these commands > set load_addr (initially derived from the loadaddr environment variable). That's bad. > ubifsload also does not set load_addr, but a quick grep shows that some other > filesystem commands set it, e.g. for zfs, jffs2, reiser or cramfs. > > Also, some commands set it only on success, while some other commands set it > from the command line arguments unconditionally. > > What's the expected correct behavior here? After successful loading the data to memory, load_addr should be set correctly, for all commands. In the error case, the value of load_addr is undefined. 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 A verbal contract isn't worth the paper it's written on. -- Samuel Goldwyn