From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 11 Mar 2015 14:31:07 -0600 Subject: [U-Boot] Regression in bootcmd handling in v2015.04-rc3? In-Reply-To: <20150311202046.GA8890@excalibur.cnev.de> References: <20150303233137.GP25373@bill-the-cat> <20150304195337.GA4874@excalibur.cnev.de> <20150311202046.GA8890@excalibur.cnev.de> Message-ID: <5500A60B.5010606@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 03/11/2015 02:20 PM, Karsten Merker wrote: > On Wed, Mar 04, 2015 at 08:53:37PM +0100, Karsten Merker wrote: >> On Tue, Mar 03, 2015 at 06:31:37PM -0500, Tom Rini wrote: >> >>> I've pushed v2015.04-rc3 out to the repository and tarballs should exist >>> soon. >> [...] >>> As always, if anything is broken please speak up. >> >> Hello, >> >> I have tested v2015.04-rc3 and have stumbled over a problem with the >> distro_bootcmd framework when trying to boot from a specific device >> at the u-boot command prompt by using "run _boot". >> Autobooting without user interruption of the boot process works fine: ... >> Interrupting the boot sequence and then manually executing e.g. "run >> usb_boot" results in a "** Bad device specification usb devplist **" >> error message: >> >> sunxi# run usb_boot >> >> USB device 0: Vendor: Intenso Rev: Prod: Rainbow >> Type: Removable Hard Disk >> Capacity: 7620.0 MB = 7.4 GB (15605760 x 512) >> ** Bad device specification usb devplist ** >> sunxi# >> >> The reason for this is that in this constellation ${devnum} is >> undefined, which leads to a failure of the "part list ${devtype} >> ${devnum} devplist" command in ${scan_dev_for_boot_part}. Older >> versions of u-boot did not use the part list command, so this problem >> did not occur there. Using "run bootcmd_usb0" instead of "run >> usb_boot" works, but my understanding (which may of course be wrong) >> was that the user is expected to use "run _boot" for booting >> from a specific device at the u-boot command prompt, and that has >> worked without problems in previous u-boot versions. > > Hello, > > as my original email appears to have fallen through the cracks, > I'd like to ask again whether using "run _boot" is > "officially" expected to work or not. If it is not, what is the > officially supported way for a user to boot from a certain device > at the u-boot prompt? Should people use "setenv boot_targets > foo; run bootcmd" instead? Sorry, I didn't see the original email. For manual booting, I would expect to always run the device-specific command (e.g. bootcmd_usb0 or bootcmd_mmc1) rather than the device-type-specific command (e.g. usb_boot, mmc_boot). I'm not sure how the type-generic commands ever worked without variables such as ${devnum} set, since they all pass ${devnum} to a variety of commands in addition to the new "part list". Perhaps those commands default to devnum==0 if the parameter is missing, and you never wanted to boot e.g. from mmc 1 instead of mmc 0?