From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Mon, 23 Apr 2012 04:02:16 -0700 Subject: [U-Boot] 'run' no longer aborts on an error, can someone please verify In-Reply-To: <4F94EBE4.6060203@exertus.fi> References: <20120421205158.67291204A81@gemini.denx.de> <4F932CEC.30808@gmail.com> <4F94EBE4.6060203@exertus.fi> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Timo, On Apr 23, 2012 5:43 PM, "Timo Ketola" wrote: > > Dear Gray, Jason, Heiko, Simon, > > I added you, Jason, Heiko and Simon, into the CC-list because there is > your commits in the history which seems somewhere to change the > behaviour below: > > On 22.04.2012 00:55, Gray Remlin wrote: > > U-Boot v2012.04 > > > > Marvell>> setenv ipaddr '192.168.1.130' > > Marvell>> setenv ifhostisup 'ping 192.168.1.100' > > Marvell>> setenv saywearehappy 'echo "We are happy!"' > > Marvell>> run ifhostisup saywearehappy; > > Using egiga0 device > > ping failed; host 192.168.1.100 is not alive > > "We are happy!" > > Marvell>> > > > > This is not the same behaviour as my (unfortunately customised) version based on the ancient U-Boot 2009.11 > > Other commands are also effected, for example 'ide dev 0' would abort a 'run' command if the device did not exist. > > > > Is this my problem (corrupted source\compilation) or a change in policy ? > > I took a quick glance over command/main.c. I think this is the "original > behaviour" (tree 9c506e 23 Aug 2011): > > 1374 /* OK - call function to do the command */ > 1375 if ((cmdtp->cmd) (cmdtp, flag, argc, argv) != 0) { > 1376 rc = -1; > 1377 } > > run_command returns -1 on failure and > > 1407 if (run_command (arg, flag) == -1) > 1408 return 1; > > do_run exits the loop based on that. > > Now (tree 762494 6 Mar 2012) builtin_run_command: > > 1341 rc = cmd_process(flag, argc, argv, &repeatable); > > returns the exit code of the command but: > > 1366 if (builtin_run_command(cmd, flag) == -1) > 1367 return 1; > > run_command now depends on it to return -1 on failure. If I followed the > code right, this is clear change in the behaviour. I hope it is not > intentional and can be fixed because I have (too?) scripts that depends > on old behaviour. For example: > > run get_update_from_usb erase_flash_and_write_it > > Sequence must not continue to touching flash if load from USB fails. Thanks for the detailed information. This might be the problem Wolfgang mentioned at the time...will take a look tomorrow. Regards, Simon > > -- > > Timo