Vasili Galka [Thu, 14 Aug 2014 14:42:05 +0000 (17:42 +0300)]
nios2: Fix printf size_t format related warnings (again...)
When compiling the current code on GCC 4.8.3, the following warnings
appear:
warning: format '%zu' expects argument of type 'size_t', but argument
2 has type 'long unsigned int' [-Wformat=]
There were many mails about such warnings on different architectures.
This patch limits itself to the nios2 architecture.
The problem is that for the size_t (%zu, %zd, ...) arguments of
printf GCC does not verify the type match to size_t type. It verifies
the type match to the compiler-defined __SIZE_TYPE__ type. Thus, if
size_t is defined different from __SIZE_TYPE__ - warnings inevitably
appear.
There is a comment by Thomas Chou to the (rejected) patch:
http://patchwork.ozlabs.org/patch/272102/
which explains that the older GCC toolchains (gcc-3.4.6 and gcc-4.1.2)
expect size_t to be "unsigned long" and the newer expect it to be
"unsigned int". Thus, no matter how we define size_t - either way
warnings appear when using some GCC version.
By rejecting that patch, a choice was made to prefer older GCC versions
and leave the warnings when building with the newer toolchains.
Personally, I disagree with this choice...
In any case, this patch proposes a way to fix the warnings for any GCC
version. Just define size_t using the __SIZE_TYPE__ compiler-defined
type and the type verification will pass.
I tested that this fixes the warning on GCC 4.8.3. I don't have an
older toolchain to test with, but __SIZE_TYPE__ was definitely defined
in GCC 3.4.6, so it should work there too.
Signed-off-by: Vasili Galka <vvv444@gmail.com> Signed-off-by: Thomas Chou <thomas@wytron.com.tw>
Masahiro Yamada [Thu, 21 Aug 2014 02:44:34 +0000 (11:44 +0900)]
kconfig: convert Kconfig helper script into a shell script
Commit 51148790 added scripts/multiconfig.py written in Python 2
to adjust Kconfig for U-Boot.
It has been hard for Python 3 users because Python 2 and Python 3
are not compatible with each other.
We are not happy about adding a new host tool dependency
(in this case, Python version dependency) for the core build process.
After some discussion, we decided to use only basic tools.
The script may get a bit more unreadable by shell scripting,
but we believe it is worthwhile.
In addition, this commit revives "<board>_config" target that is
equivalent to "<board>_defconfig" for backwards compatibility.
It is annoying to adjust various projects which use U-Boot.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Suggested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Acked-by: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@ti.com> Cc: Jeroen Hofstee <jeroen@myspectrum.nl> Cc: Stephen Warren <swarren@nvidia.com>
Roger Meier [Wed, 20 Aug 2014 20:10:29 +0000 (22:10 +0200)]
Makefile: remove generated boards.cfg within make distclean
Signed-off-by: Roger Meier <roger@bufferoverflow.ch> Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Tested-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Tom Rini <trini@ti.com> Cc: Wolfgang Denk <wd@denx.de> Cc: Simon Glass <sjg@chromium.org>
Thierry Reding [Tue, 19 Aug 2014 08:21:24 +0000 (10:21 +0200)]
net: More BOOTP retry timeout improvements
It's not unusual for DHCP servers to take a couple hundred milliseconds
to respond to DHCP discover messages. One possible reason for the delay
can be that the server checks (typically using an ARP request) that the
IP it's about to hand out isn't in use yet. To make matters worse, some
servers may also queue up requests and process them sequentially, which
can cause excessively long delays if clients retry too fast.
Commit f59be6e850b3 ("net: BOOTP retry timeout improvements") shortened
the retry timeouts significantly, but the BOOTP/DHCP implementation in
U-Boot doesn't handle that well because it will ignore incoming replies
to earlier requests. In one particular setup this increases the time it
takes to obtain a DHCP lease from 630 ms to 8313 ms.
This commit attempts to fix this in two ways. First it increases the
initial retry timeout from 10 ms to 250 ms to give DHCP servers some
more time to respond. At the same time a cache of outstanding DHCP
request IDs is kept so that the implementation will know to continue
transactions even after a retransmission of the DISCOVER message. The
maximum retry timeout is also increased from 1 second to 2 seconds. An
ID cache of size 4 will keep DHCP requests around for 8 seconds (once
the maximum retry timeout has been reached) before dropping them. This
should give servers plenty of time to respond. If it ever turns out
that this isn't enough, the size of the cache can easily be increased.
With this commit the DHCP lease on the above-mentioned setup still takes
longer (1230 ms) than originally, but that's an acceptable compromise to
improve DHCP lease acquisition time for a broader range of setups.
To make it easier to benchmark DHCP in the future, this commit also adds
the time it took to obtain a lease to the final "DHCP client bound to
address x.x.x.x" message.
Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Bryan Wu [Fri, 15 Aug 2014 23:51:38 +0000 (16:51 -0700)]
image: fix bootm failure for FIT image
Commit b3dd64f5d537 "bootm: use genimg_get_kernel_addr()" introduced
a bug for booting FIT image. It's because calling fit_parse_config()
twice will give us wrong value in img_addr.
Add a new function genimg_get_kernel_addr_fit() whichl will always
return fit_uname_config and fit_uname_kernel for CONFIG_FIT.
genimg_get_kernel_addr() will ignore those to parameters.
Reported-by: York Sun <yorksun@freescale.com> Signed-off-by: Bryan Wu <pengw@nvidia.com>
Masahiro Yamada [Fri, 15 Aug 2014 17:50:12 +0000 (02:50 +0900)]
kconfig: remove DEFCONFIG_LIST
CONFIG_DEFCONFIG_LIST specifies the default defconfig.
It is used by "make savedefconfig" when .config is missing.
But that's it. I could not find other useful cases.
As a side effect, CONFIG_DEFCONFIG_LIST="configs/sandbox_defconfig"
is contained in .config of every target board, which some people
think is odd. So, let's remove it.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Michal Simek <michal.simek@xilinx.com> Acked-by: Michal Simek <michal.simek@xilinx.com>
Vasili Galka [Thu, 14 Aug 2014 09:40:55 +0000 (12:40 +0300)]
Makefile: Use Kbuild style for system_map.o generation step
The command generating the "common/system_map.o" file was always shown
during the build making the output messy. Now it is called using the
Kbuild "cmd" macro, so that the full command is shown only when
building in verbose mode.
Colin Cross [Tue, 12 Aug 2014 17:59:27 +0000 (10:59 -0700)]
add header for Android sparse image format
Add a BSD-3 relicensed version of the Android sparse format image
header from:
https://android.googlesource.com/platform/system/core/+/28fa5bc347390480fe190294c6c385b6a9f0d68b/libsparse/sparse_format.h
Unchanged except for the license header.
Cc: Tom Rini <trini@ti.com> Signed-off-by: Colin Cross <ccross@android.com>
Masahiro Yamada [Wed, 6 Aug 2014 04:42:34 +0000 (13:42 +0900)]
tools/genboardscfg.py: Do not output SPLCPU field
Prior to Kconfig, the CPU field of boards.cfg could optionally have
":SPLCPU", like "armv7:arm720t".
(Actually this syntax was only used for Tegra platform.)
Now it is not necessary at all because CPU is defined by
CONFIG_SYS_CPU in Kconfig.
For Tegra platform, the Kconfig option is described as follows:
config SYS_CPU
string
default "arm720t" if SPL_BUILD
default "armv7" if !SPL_BUILD
Masahiro Yamada [Tue, 5 Aug 2014 06:56:43 +0000 (15:56 +0900)]
kbuild: move extra gcc checks to scripts/Makefile.extrawarn
This commit was imported from Linux Kernel:
commit a86fe353 written by me.
W=... provides extra gcc checks.
Having such code in scripts/Makefile.build results in the same flags
being added to KBUILD_CFLAGS multiple times becuase
scripts/Makefile.build is invoked every time Kbuild descends into
the subdirectories.
Since the top Makefile is already too cluttered, this commit moves
all of extra gcc check stuff to a new file scripts/Makefile.extrawarn,
which is included from the top Makefile.
Masahiro Yamada [Fri, 15 Aug 2014 15:59:26 +0000 (00:59 +0900)]
tools, scripts: refactor error-out statements of Python scripts
In Python, sys.exit() function can also take an object other
than an integer.
If an integer is given to the argument, Python exits with the return
code of it. If a non-integer argument is given, Python outputs it
to stderr and exits with the return code of 1.
That means,
print >> sys.stderr, "Blah Blah"
sys.exit(1)
is equivalent to
sys.exit("Blah Blah")
The latter is a useful shorthand.
Note:
Some error messages in Buildman and Patman were output to stdout.
But they should go to stderr. They are also fixed by this commit.
This is a nice side effect.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Simon Glass <sjg@chromium.org>
Shaohui Xie [Wed, 13 Aug 2014 10:19:15 +0000 (18:19 +0800)]
powerpc/T4240QDS/eth: some fix for XFI
XFI is supported on T4QDS-XFI board, which removed slot3, and four LANEs
of serdes2 are routed to a SFP+ cages, which to house fiber cable or
direct attach cable(copper), the copper cable is used to emulate the
10GBASE-KR scenario.
So, for XFI usage, there are two scenarios, one will use fiber cable,
another will use copper cable. For fiber cable, there is NO PHY, while
for copper cable, we need to use internal PHY which exist in Serdes to
do auto-negotiation and link training, which implemented in kernel.
We use hwconfig to define cable type for XFI, and fixup dtb based on the
cable type.
For copper cable, set below env in hwconfig:
fsl_10gkr_copper:<10g_mac_name>
the <10g_mac_name> can be fm1_10g1, fm1_10g2, fm2_10g1, fm2_10g2. The
four <10g_mac_name>s do not have to be coexist in hwconfig. For XFI ports,
if a given 10G port will use the copper cable for 10GBASE-KR, set the
<10g_mac_name> of the port in hwconfig, otherwise, fiber cable will be
assumed to be used for the port.
For ex. if four XFI ports will both use copper cable, the hwconfig
should contain:
1. give PHY address to a XFI port, otherwise, the XFI ports will not be
available in U-boot, there is no PHY physically for XFI when using fiber
cable, this is just to make U-boot happy and we can use the XFI ports
in U-boot.
2. fixup dtb to use fixed-link in case of fiber cable which has no PHY.
Kernel requests that a MAC must have a PHY or fixed-link.
When using XFI protocol, the MAC 9/10 on FM1 should init as 10G interface.
Change serdes 2 protocol 56 to 55 which has same feature as 56 since 56
is not valid any longer.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
km-powerpc: define CONFIG_PRAM to protect PHRAM and PNVRAM
When u-boot initializes the RAM (early in boot) it looks for the "pram"
env variable to know which is area it cannot use. If the "pram" env variable
is not found, the default CONFIG_PRAM value is used.
This value used to be 0 (no protection at all). This patch sets it to a
value that covers PHRAM and PNVRAM that must be protected in our case.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by: Holger Brunck <holger.brunck@keymile.com> Reviewed-by: York Sun <yorksun@freescale.com>
powerpc/mpc85xx: Enabling CPC conditionally based on hwconfig options
If hwconfig does not contains "en_cpc" then by default all cpcs are enabled
If this config is defined then only those individual cpcs which are defined
in the subargument of "en_cpc" will be enabled e.g en_cpc:cpc1,cpc2; (this
will enable cpc1 and cpc2) or en_cpc:cpc2; (this enables just cpc2)
Signed-off-by: Shaveta Leekha <shaveta@freescale.com> Signed-off-by: Sandeep Singh <Sandeep@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
Lukasz Majewski [Mon, 18 Aug 2014 10:12:27 +0000 (12:12 +0200)]
test: dfu: cosmetic: Add missing license information to DFU test scripts
By mistake I've forgotten to add the SPDX license tags for the DFU testing
scripts.
This commit fixes that and also provides some other relevant information.
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Acked-by: Stephen Warren <swarren@nvidia.com>
Simon Glass [Sat, 9 Aug 2014 21:33:09 +0000 (15:33 -0600)]
buildman: Allow selection of the number of commits to build
It is useful to be able to build only some of the commits in a branch. Add
support for the -c option to allow this. It was previously parsed by
buildman but not implemented.
Suggested-by: York Sun <yorksun@freescale.com> Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: York Sun <yorksun@freescale.com>
Simon Glass [Sat, 9 Aug 2014 21:33:08 +0000 (15:33 -0600)]
buildman: Introduce an 'and' operator for board selection
Currently buildman allows a list of boards to build to be specified on the
command line. The list can include specific board names, architecture, SOC
and so on.
At present the list of boards is dealt with in an 'OR' fashion, and there
is no way to specify something like 'arm & freescale', meaning boards with
ARM architecture but only those made by Freescale. This would exclude the
PowerPC boards made by Freescale.
Support an '&' operator on the command line to permit this. Ensure that
arguments can be specified in a single string to permit easy shell quoting.
Suggested-by: York Sun <yorksun@freescale.com> Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: York Sun <yorksun@freescale.com>
Simon Glass [Sat, 9 Aug 2014 21:33:03 +0000 (15:33 -0600)]
buildman: Add verbose option to display errors as they happen
Normally buildman operates in two passes - one to do the build and another
to summarise the errors. Add a verbose option (-v) to display build problems
as they happen. With -e also given, this will display errors too.
When building the current source tree (rather than a list of commits in a
branch), both -v and -e are enabled automatically.
Simon Glass [Sat, 9 Aug 2014 21:33:02 +0000 (15:33 -0600)]
buildman: Refactor output options
We need the output options to be available in several places. It's a pain
to pass them into each function. Make them properties of the builder and
add a single function to set them up. At the same time, add a function which
produces summary output using these options.
Simon Glass [Sat, 9 Aug 2014 21:32:59 +0000 (15:32 -0600)]
buildman: Allow building of current source tree
Originally buildman had some support for building the current source tree.
However this was dropped before it was submitted, as part of the effort to
make it faster when building entire branches.
Reinstate this support. If no -b option is given, buildman will build the
current source tree.
Reported-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Signed-off-by: Simon Glass <sjg@chromium.org>
powerpc/t104xrdb: support deep sleep in SPI/SD boot
Add deep sleep support in SPI/SD boot. The destination address
second stage uboot image is loaded to is changed because
currently this address will be used by kernel which means
we can't reserve it for resume.
Entry point to kernel is still placed in second stage uboot.
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
Jason Jin [Wed, 19 Mar 2014 02:47:56 +0000 (10:47 +0800)]
powerpc/t1042RDB: Add Video - HDMI support
T1042 has internal display interface unit (DIU) for driving video.
T1042RDB supports video mode via
-LCD using TI enconder
-HDMI type interface via HDMI encoder
Chrontel, CH7301C encoder which is I2C programmable is used
as HDMI connector on T1042RDB.
This patch add support to
-enable Video interface for T1042RDB
-route qixis multiplexing to enable DIU-HDMI interface on board
-program DIU pixel clock gerenartor for T1042
-program HDMI encoder via I2C on board
Signed-off-by: Jason Jin <Jason.Jin@freescale.com> Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
[York Sun: resolve conflict and move changes to T104xRDB.h] Reviewed-by: York Sun <yorksun@freescale.com>
Jeroen Hofstee [Tue, 17 Jun 2014 17:20:27 +0000 (19:20 +0200)]
video: ipu_disp: squash clang warning
Since rgb2ycbcr_coeff and friends are declared const, but assigned
to a void pointer, clang will warn that the const is implicity casted
away. If the pointer is changed to void const * gcc will warn when it
is implicitly casted to a const int array. Just add a correctly
typed pointer instead to prevent these casts and hence the warnings.
Liu Ying [Fri, 28 Feb 2014 07:12:25 +0000 (15:12 +0800)]
video: ipu_disp: wait for DP SF end irq when disabling sync BG flows
Instead of waiting for DC triple buffer to be cleared, this patch
changes to wait for a relevant DP sync flow end interrupt to come
when disabling sync BG flows. In this way, we align the implement
to the freescale internal IPUv3 driver. After applying this patch,
an uboot hang up issue at the arch_preboot_os() stage, where we
disable a relevant ipu display channel, is not observed any more on
some MX6DL platforms.
This patch removes following two functions:
- lcd_getbgcolor(...)
not used somewhere outside lcd.c, internally we use now the global
variable lcd_color_bg (was return value of function before)
- lcd_getfgcolor(...)
not used in any place of u-boot
Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
[agust: rebased] Signed-off-by: Anatolij Gustschin <agust@denx.de>
Bryan Wu [Fri, 1 Aug 2014 00:39:59 +0000 (17:39 -0700)]
pxe: detect image format before calling bootm/bootz
Trying bootm for zImage will print out several error message which
is not necessary for this case. So detect image format firstly, only
try bootm for legacy and FIT format image then try bootz for others.
This patch needs new function genimg_get_kernel_addr().
Bryan Wu [Fri, 1 Aug 2014 00:39:58 +0000 (17:39 -0700)]
image: introduce genimg_get_kernel_addr()
Kernel address is normally stored as a string argument of bootm or bootz.
This function is taken out from boot_get_kernel() of bootm.c, which can be
reused by others.
Signed-off-by: Bryan Wu <pengw@nvidia.com>
[trini: Fix warnings with CONFIG_FIT] Signed-off-by: Tom Rini <trini@ti.com>
Stephen Warren [Thu, 31 Jul 2014 19:40:07 +0000 (13:40 -0600)]
lib: lmb: fix overflow in __lmb_alloc_base w/ large RAM
If a 32-bit system has 2GB of RAM, and the base address of that RAM is
2GB, then start+size will overflow a 32-bit value (to a value of 0).
__lmb_alloc_base is affected by this; it calculates the minimum of
(start+size of RAM) and max_addr. However, when start+size is 0, it
is always less than max_addr, which causes the value of max_addr not
to be taken into account when restricting the allocation's location.
Fix this by calculating start+size separately, and if that calculation
underflows, using -1 (interpreted as the max unsigned value) as the
value instead, and then taking the min of that and max_addr. Now that
start+size doesn't overflow, it's typically large, and max_addr
dominates the min() call, and is taken into account.
The user-visible symptom of this bug is that CONFIG_BOOTMAP_SZ is ignored
on Tegra124 systems with 2GB of RAM, which in turn causes the DT to be
relocated at the very end of RAM, which the ARM Linux kernel doesn't map
during early boot, and which causes boot failures. With this fix,
CONFIG_BOOTMAP_SZ correctly restricts the relocated DT to a much lower
address, and everything works.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Stephen Warren [Wed, 30 Jul 2014 22:37:16 +0000 (16:37 -0600)]
ARM: rpi_b: use new generic $bootcmd
Replace the custom $bootcmd with that from <config_distro_bootcmd.h>.
There should be no functional change, since the new generic $bootcmd was
derived strongly from tegra-common-post.h, after which this part of
rpi_b.h was modelled.
The #defines to enable/disable U-Boot commands/features were moved
earlier in rpi_b.h, so they are set up before config_distro_bootcmd.h
is included, since it tests whether certain features should be included
based on those defines.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
Stephen Warren [Wed, 30 Jul 2014 22:37:15 +0000 (16:37 -0600)]
ARM: tegra: use new generic $bootcmd
Replace the custom $bootcmd with that from <config_distro_bootcmd.h>.
There should be no functional change, since the new generic $bootcmd was
derived strongly from tegra-common-post.h.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Simon Glass <sjg@chromium.org>
Dennis Gilmore [Wed, 30 Jul 2014 22:37:14 +0000 (16:37 -0600)]
config: introduce a generic $bootcmd
This generic $bootcmd, and associated support macros, automatically
searches a defined set of storage devices (or network protocols) for an
extlinux configuration file or U-Boot boot script in various standardized
locations. Distros that install such a boot config file/script in those
standard locations will get easy-to-set-up booting on HW that enables
this generic $bootcmd.
Boards can define the set of devices from which boot is attempted, and
the order in which they are attempted. Users may later customize this
set/order by edting $boot_targets.
Users may interrupt the boot process and boot from a specific device
simply by executing e.g.:
$ run bootcmd_mmc1
or:
$ run bootcmd_pxe
This patch was originally written by Dennis Gilmore based on Tegra and
rpi_b boot scripts. I have made the following modifications since then:
* Boards must define the BOOT_TARGET_DEVICES macro in order to specify
the set of devices (and order) from which to attempt boot. If needed,
we can define a default directly in config_distro_bootcmd.h.
* Removed $env_import and related variables; nothing used them, and I
think it's better for boards to pre-load an environment customization
file using CONFIG_PREBOOT if they need.
* Renamed a bunch of variables to suit my whims:-)
Signed-off-by: Dennis Gilmore <dennis@ausil.us> Signed-off-by: Stephen Warren <swarren@nvidia.com> Reviewed-by: Marek Vasut <marex@denx.de> Acked-by: Simon Glass <sjg@chromium.org>
- Add 'p1023rds' to the list since commit d0bc5140 dropped
the board support but missed to update this file
- Fill the Commit and Removed Date fields for boards removed
by earlier commits
- Move 'incaip' to keep the list sorted in reverse
chronological order
- Describe the soring rule in the comment block:
"The list should be sorted in reverse chronological order."
- Fix typos in the comment block
Stephen Warren [Fri, 25 Jul 2014 23:30:48 +0000 (17:30 -0600)]
net: BOOTP retry timeout improvements
Currently, the BOOTP code sends out its initial request as soon as the
Ethernet driver indicates "link up". If this packet is lost or not
replied to for some reason, the code waits for a 1s timeout before
retrying. For some reason, such early packets are often lost on my
system, so this causes an annoying delay.
To optimize this, modify the BOOTP code to have very short timeouts for
the first packet transmitted, but gradually increase the timeout each
time a timeout occurs. This way, if the first packet is lost, the second
packet is transmitted quite quickly and hence the overall delay is low.
However, if there's still no response, we don't keep spewing out packets
at an insane speed.
It's arguably more correct to try and find out why the first packet is
lost. However, it seems to disappear inside my Ethenet chip; the TX chip
indicates no error during TX (not that it has much in the way of
reporting...), yet wireshark on the RX side doesn't see any packet.
FWIW, I'm using an ASIX USB Ethernet adapter. Perhaps "link up" is
reported too early or based on the wrong condition in HW, and we should
add some fixed extra delay into the driver. However, this would slow down
every link up event even if it ends up not being needed in some cases.
Having BOOTP retry quickly applies the fix/WAR to every possible
Ethernet device, and is quite simple to implement, so seems a better
solution.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Stephen Warren [Wed, 23 Jul 2014 00:06:46 +0000 (18:06 -0600)]
pxe: clear Bootfile before returning
When "pxe boot" downloads the initrd/kernel/DTB, netboot_common() saves
the downloaded filename to global variable BootFile. If the boot
operation is aborted, this global state is not cleared. If "dhcp" is
executed later without any arguments, BootFile is not cleared, and when
the DHCP response is received, BootpCopyNetParams() writes the value into
environment variable bootfile.
This causes the following scenario:
* Boot script executes dhcp; pxe get; pxe boot
* User CTRL-C's the PXE menu, which causes the first menu item to be
booted, which causes some file to be downloaded.
(This boot-on-CTRL-C behaviour is arguably a bug too, but it's a
separate bug and the bug this patch fixes would still exist if the user
simply waited to press CTRL-C until "pxe boot" started downloading
files)
* User CTRL-C's the file downloads, but the filename is still written to
the bootfile environment variable.
* User re-runs the boot command, which in my case executes "dhcp; pxe get;
pxe boot" again, and "dhcp" picks up the saved bootfile environment
variable and proceeds to download a file that it shouldn't.
To solve this, modify the implementation of "pxe get" to clear BootFile
if the whole boot operation fails, which avoids this whole mess.
An alternative would be to modify netboot_common() such that the no-
arguments case explicitly clears the global variable BootFile. However,
that would prevent the following command sequences from working:
doc: README.android-fastboot: Add note about vendor ID
The Android fastboot client only communicates with specific vendor IDs.
This addition to the documentation points out that fact so everyone is
aware that not just any vendor ID will work and where to find the IDs
that will.
Signed-off-by: Clifton Barnes <cabarnes@indesign-llc.com> Cc: Rob Herring <robh@kernel.org>
projects / u-boot.git / log