From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] Document config_distro_bootcmd environment variables for interactive booting.
Date: Thu, 19 Mar 2015 15:02:22 -0600 [thread overview]
Message-ID: <550B395E.40509@wwwdotorg.org> (raw)
In-Reply-To: <20150319205334.GB8313@excalibur.cnev.de>
On 03/19/2015 02:53 PM, Karsten Merker wrote:
> On Thu, Mar 19, 2015 at 01:53:14PM -0600, Stephen Warren wrote:
>
>>> +Interactively booting from a specific device at the u-boot prompt
>>> +=================================================================
>>> +
>>> +For interactively booting from a user-selected device at the u-boot command
>>> +prompt, the environment provides predefined bootcmd_<target> variables for
>>> +every target defined in boot_targets, which can be run be the user.
>>> +
>>> +Examples:
>>> +
>>> + - run bootcmd_usb0
>>> + boots from the first USB mass storage device
>>> +
>>> + - run bootcmd_mmc1
>>> + boots from the second MMC device
>>
>> Should we enumerate all the possible device types, e.g. include
>> bootcmd_sata0, bootcmd_ide0, ...?
>
> Hm, I suppose that depends on whether there is such a thing as
> definitve list of all possible device types on all platforms and
> how many elements are in this list. Are functionally equivalent
> devices named the same on all platforms, i.e. is a PATA
> interface always ide0, or could it be ide0 on one platform and
> pata0 on another?
The list is limited to the macros that are set up in
config_distro_bootcmd.h. At least for the device types supported there,
and the set of platforms which use that header so far, a particular
device type is always named the same on all platforms.
I'd expect a patch that added a new device type to the header to update
the list in the documentation.
>> In the text, perhaps rephrase bootcmd_<target> as
>> bootcmd_<devtype><devnum>, and note that <devnum> is not optional in the
>> command name?
>
> I had thought about explictly using devtype and devnum, but there
> are device types such as pxe which do not have a devnum, so I
> chose to use the generic <target> designation instead. I can
> change that, but it might cause confusion so that a user would
> try to use something like "run bootcmd_pxe0" which would not
> work. I would therefore prefer the generic <target> designation.
Ah yes. Perhaps continue to use <target> and then explain that when
<target> is a storage device that can have multiple instances, the
format of <target> must be <devtype><devnum>, but in other cases (pxe,
dhcp), it is just a standalone name?
next prev parent reply other threads:[~2015-03-19 21:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 23:31 [U-Boot] [ANN] U-Boot v2015.04-rc3 released Tom Rini
[not found] ` <20150304195337.GA4874@excalibur.cnev.de>
[not found] ` <20150311202046.GA8890@excalibur.cnev.de>
2015-03-11 20:31 ` [U-Boot] Regression in bootcmd handling in v2015.04-rc3? Stephen Warren
[not found] ` <20150311212100.GA9680@excalibur.cnev.de>
2015-03-11 21:35 ` Stephen Warren
[not found] ` <20150311214825.GB9680@excalibur.cnev.de>
2015-03-17 16:16 ` Tom Rini
2015-03-19 19:41 ` [U-Boot] config_distro_bootcmd and boot environment (was: Regression in bootcmd handling in v2015.04-rc3?) Karsten Merker
2015-03-19 19:41 ` [U-Boot] [PATCH] Document config_distro_bootcmd environment variables for interactive booting Karsten Merker
2015-03-19 19:53 ` Stephen Warren
[not found] ` <20150319205334.GB8313@excalibur.cnev.de>
2015-03-19 21:02 ` Stephen Warren [this message]
2015-03-21 13:15 ` [U-Boot] [PATCH V2] " Karsten Merker
2015-03-21 13:15 ` Karsten Merker
2015-03-23 19:34 ` Stephen Warren
2015-03-28 18:09 ` [U-Boot] [U-Boot, " Tom Rini
2015-03-11 20:31 ` [U-Boot] Regression in bootcmd handling in v2015.04-rc3? (was: [ANN] U-Boot v2015.04-rc3 released) Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=550B395E.40509@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.