Marc Zyngier [Sat, 12 Jul 2014 13:24:04 +0000 (14:24 +0100)]
ARM: HYP/non-sec: add generic ARMv7 PSCI code
Implement core support for PSCI. As this is generic code, it doesn't
implement anything really useful (all the functions are returning
Not Implemented).
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
Marc Zyngier [Sat, 12 Jul 2014 13:24:03 +0000 (14:24 +0100)]
ARM: HYP/non-sec: allow relocation to secure RAM
The current non-sec switching code suffers from one major issue:
it cannot run in secure RAM, as a large part of u-boot still needs
to be run while we're switched to non-secure.
This patch reworks the whole HYP/non-secure strategy by:
- making sure the secure code is the *last* thing u-boot executes
before entering the payload
- performing an exception return from secure mode directly into
the payload
- allowing the code to be dynamically relocated to secure RAM
before switching to non-secure.
This involves quite a bit of horrible code, specially as u-boot
relocation is quite primitive.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
Marc Zyngier [Sat, 12 Jul 2014 13:24:00 +0000 (14:24 +0100)]
ARM: non-sec: reset CNTVOFF to zero
Before switching to non-secure, make sure that CNTVOFF is set
to zero on all CPUs. Otherwise, kernel running in non-secure
without HYP enabled (hence using virtual timers) may observe
timers that are not synchronized, effectively seeing time
going backward...
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Acked-by: Ian Campbell <ijc@hellion.org.uk>
ARM: omap: move board specific NAND configs out from ti_armv7_common.h
This patch moves some board specific NAND configs:
- FROM: generic config file 'ti_armv7_common.h'
- TO: individual board config files using these configs.
So that each board can independently set the value as per its design.
Following configs are affected in this patch:
CONFIG_SYS_NAND_U_BOOT_OFFS: <refer doc/README.nand>
CONFIG_CMD_SPL_NAND_OFS: <refer doc/README.falcon>
CONFIG_SYS_NAND_SPL_KERNEL_OFFS: <refer doc/README.falcon>
CONFIG_CMD_SPL_WRITE_SIZE: <refer doc/README.falcon>
This patch also updates documentation for few of above NAND configs.
ARM: omap: clean redundant PISMO_xx macros used in OMAP3
PISMO_xx macros were used to define 'Platform Independent Storage MOdule'
related GPMC configurations. This patch
- Replaces these OMAP3 specific macros with generic CONFIG_xx macros as provided
by current u-boot infrastructure.
- Removes unused redundant macros, which are no longer required after
merging of common platform code in following commit
commit a0a37183bd75e74608bc78c8d0e2a34454f95a91
ARM: omap: merge GPMC initialization code for all platform
1) NAND device are not directly memory-mapped to CPU address-space, they are
indirectly accessed via following GPMC registers:
- GPMC_NAND_COMMAND_x
- GPMC_NAND_ADDRESS_x
- GPMC_NAND_DATA_x
Therefore from CPU's point of view, NAND address-map can be limited to just
above register addresses. But GPMC chip-select address-map can be configured
in granularity of 16MB only.
So this patch uses GPMC_SIZE_16M for all NAND devices.
2) NOR device are directly memory-mapped to CPU address-space, so its
address-map size depends on actual addressable region in NOR FLASH device.
So this patch uses CONFIG_SYS_FLASH_SIZE to derive GPMC chip-select address-map
size configuration.
The errata is applicable on all OMAP4 (4430 and 4460/4470) and OMAP5
ES 1.0 devices. The current revision check erroneously implements this
on all DRA7 varients and with DRA722 device (which has only 1 EMIF instance)
infact causes an asynchronous abort and ends up masking it in CPSR,
only to be uncovered once the kernel switches to userspace.
This patch adds hardware definitions specific to Keystone II
K2E device. It has a lot common definitions with k2hk SoC, so
move them to common hardware.h. This is preparation patch for
adding K2E SoC support.
keystone: ddr3: move K2HK DDR3 configuration to a common file
It's convenient to hold configurations for DDR3 PHY and EMIF in
separate common place. This patch moves K2HK DDR3 PHY and EMIF
configuration data with different rates and memory size to a common
ddr3_cfg.c file.
configs: k2hk_evm: config: add common EVM configuration header
This patch adds a common config header file for all the Keystone II
EVM platforms. It combines a lot of general definitions in one file.
The common header included in the EVM should be specific configuration
header.
ARM: keystone: clock: move K2HK SoC dependent code in separate file
This patch in general spit SoC type clock dependent code and general
clock code. Before adding keystone II Edison k2e SoC which has
slightly different dpll set, move k2hk dependent clock code to
separate clock-k2hk.c file.
Acked-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
ARM: keystone2: move K2HK board files to common KS2 board directory
This patch moves K2HK board directory to a common Keystone II board
directory. The Board related common functions are moved to a common
keystone board file.
With latest v3.13 kernel, unitrd dt fixup is not needed. However for
older kernel versions such as v3.8/v3.10, it is needed. So to work
with both, add a u-boot env variable that can be set to do dt fixup
for older kernels.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
k2hk: use common KS2_ prefix for all hardware definitions
Use KS2_ prefix in all definitions, for that replace K2HK_ prefix and
add KS2_ prefix where it's needed. It requires to change names also
in places where they're used. Align lines and remove redundant
definitions in kardware-k2hk.h at the same time.
Using common KS2_ prefix helps resolve redundant redefinitions and
adds opportunity to use KS2_ definition across a project not thinking about
what SoC should be used. It's more convenient and we don't need to worry
about the SoC type in common files, hardware.h will think about that.
The hardware.h decides definitions of what SoC to use.
Acked-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
ARM: keystone2: keystone_nav: make it dependent on keystone driver
This driver is needed in case if keystone driver is used.
Currently only keystone_net driver uses it. So to avoid
redundant code compilation make the keystone_nav dependent
on keystone net driver. It also leads to compilation errors
for boards that does't use it.
Acked-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
These functions have been merged into the common GPMC init code
with this commit a0a37183 (ARM: omap: merge GPMC initialization code
for all platform). The file is not compiled any more. So remove it
as well.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Pekon Gupta <pekon@ti.com> Cc: Tom Rini <trini@ti.com> Acked-by: Pekon Gupta <pekon@ti.com>
Stefan Roese [Wed, 9 Jul 2014 15:18:09 +0000 (17:18 +0200)]
ARM: omap: Fix GPMC init for OMAP3 platforms
Commit a0a37183 (ARM: omap: merge GPMC initialization code for all
platform) broke NAND on OMAP3 based platforms. I noticed this while
testing the latest 2014.07-rc version on the TAO3530 board. NAND
detection did not work with this error message:
NAND: nand: error: Unable to find NAND settings in GPMC Configuration - quitting
As OMAP3 configs don't set CONFIG_NAND but CONFIG_NAND_CMD. the GPMC
was not initialized for NAND at all. This patch now fixes this issue.
Tested on TAO3530 board.
Signed-off-by: Stefan Roese <sr@denx.de> Cc: Pekon Gupta <pekon@ti.com> Cc: Tom Rini <trini@ti.com> Acked-by: Pekon Gupta <pekon@ti.com>
Tom Rini [Tue, 8 Jul 2014 01:40:16 +0000 (21:40 -0400)]
am335x_evm / gumstix pepper: Correct DDR settings
As noted by clang, we have been shifting certain values out of 32bit
range when setting some DDR registers. Upon further inspection these
had been touching reserved fields (and having no impact). These came in
from historical bring-up code and can be discarded. Similarly, we had
been declaring some fields as 0 when they will be initialized that way.
Tested on Beaglebone White.
Reported-by: Jeroen Hofstee <jeroen@myspectrum.nl> Cc: Ash Charles <ash@gumstix.com> Signed-off-by: Tom Rini <trini@ti.com> Tested-By: Ash Charles <ashcharles@gmail.com>
k2hk_evm: add script to automate NAND flash process
Add script to automate NAND flash process. As for now the board has
two burn scripts - burn to boot from SPI NOR flash and burn to boot
from AEMIF NAND flash, rename burn_uboot script to burn_uboot_spi.
Also update README to contain NAND burn U-boot process description.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> Acked-by: Murali Karicheri <m-karicheri2@ti.com>
Add support for NAND gpheader image. TI Keystone2 ROM bootloader
expects 8 bytes of trailing zeroes in the nand u-boot image.
So add zeros at the end of the nand gph image.
Acked-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
mtd: nand: davinci: add opportunity to write keystone U-boot image
The Keystone SoCs use the same NAND driver as Davinci.
This patch adds opportunity to write Keystone U-boot image to NAND
device using appropriate RBL ECC layout. This is needed only if RBL
boots U-boot from NAND device and that's supposed that raw u-boot
partition is used only for writing image.
The main problem is that default Davinci ECC layout is different from
Keystone RBL layout. To read U-boot image the RBL needs that image was
written using RBL ECC layout.
The BBT table is written using default Davinci layout and has to
be updated using one. The BBT can be updated only while erasing
chip or by forced bad block assigning, so erase function has to
use native ecc layout in order to be able to write BBT correctly.
So if we're writing to NAND U-boot address we use RBL layout for
others we use default ECC layout.
Also remove definition for CONFIG_CMD_NAND_ECCLAYOUT as there is no
reasons to use ECC layout commands. It was added by mistake.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
Simon Glass [Sun, 13 Jul 2014 20:03:41 +0000 (14:03 -0600)]
buildman: Avoid retrying a build if it definitely failed
After a build fails buildman will reconfigure and try again, if it did not
reconfigure before the build. However it doesn't actually keep track of
whether it did reconfigure on the previous attempt.
Fix that logic to avoid a pointless rebuild. This speeds things up quite a
bit for failing builds. Previously they would always be built twice.
Change-Id: Ib37f21320baa7c60bed98f4042c0b7ed7c0dc85e Signed-off-by: Simon Glass <sjg@chromium.org>
Simon Glass [Sun, 13 Jul 2014 18:22:31 +0000 (12:22 -0600)]
buildman: Add -F flag to retry failed builds
Generally a build failure with a particular commit cannot be fixed except
by changing that commit. Changing the commit will automatically cause
buildman to retry when you run it again: buildman sees that the commit
hash is different and that it has no previous build result for the new
commit hash.
However sometimes the build failure is due to a toolchain issue or some
other environment problem. In that case, retrying failed builds may yield
a different result.
Add a flag to retry failed builds. This differs from the force rebuild
flag (-f) in that it will not rebuild commits which are already marked as
succeeded.
Masahiro Yamada [Thu, 29 May 2014 05:46:13 +0000 (14:46 +0900)]
zynq: disable -Wstrict-prototypes option for ps7_init.c
The files ps7_init.c and ps7_init.h are supposed to be generated by
hw projects such as Vivado, PlanAhead and then to be copied into
board/xilinx/zynq directory.
But some prototypes in them cause annoying warning messages:
CC spl/board/xilinx/zynq/ps7_init.o
In file included from board/xilinx/zynq/ps7_init.c:50:0:
board/xilinx/zynq/ps7_init.h:137:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.h:138:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.h:139:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.h:145:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.c:12602:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.c:12723:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.c:12742:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.c:12761:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
board/xilinx/zynq/ps7_init.c:12854:6: warning: function declaration isn't a prototype [-Wstrict-prototypes]
The prototypes should be
int ps7_init(void);
int ps7_post_config(void);
int ps7_debug(void);
rather than
int ps7_init();
int ps7_post_config();
int ps7_debug();
We do not want to be bothered because of automatically generated files.
But we cannot touch the external projects for now.
What we can do is to disable -Wstrict-prototypes for ps7_init.c
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Michal Simek <michal.simek@xilinx.com> Tested-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Simon Glass [Wed, 23 Jul 2014 12:55:23 +0000 (06:55 -0600)]
dm: Add dm_scan_other() to locate board-specific devices
Some boards will have devices which are not in the device tree and do not
have platform data. They may be programnatically created, for example.
Add a hook which boards can use to bind those devices early in boot.
Simon Glass [Wed, 23 Jul 2014 12:55:21 +0000 (06:55 -0600)]
dm: Add child_pre_probe() and child_post_remove() methods
Some devices (particularly bus devices) must track their children, knowing
when a new child is added so that it can be set up for communication on the
bus.
Add a child_pre_probe() method to provide this feature, and a corresponding
child_post_remove() method.
Simon Glass [Wed, 23 Jul 2014 12:55:20 +0000 (06:55 -0600)]
dm: Introduce per-child data for devices
Some device types can have child devices and want to store information
about them. For example a USB flash stick attached to a USB host
controller would likely use this space. The controller can hold
information about the USB state of each of its children.
The data is stored attached to the child device in the 'parent_priv'
member. It can be auto-allocated by dm when the child is probed. To
do this, add a per_child_auto_alloc_size value to the parent driver.
Simon Glass [Wed, 23 Jul 2014 12:55:19 +0000 (06:55 -0600)]
dm: Add functions to access a device's children
Devices can have childen that can be addressed by a simple index, the
sequence number or a device tree offset. Add functions to access a child
in each of these ways.
The index is typically used as a fallback when the sequence number is not
available. For example we may use a serial UART with sequence number 0 as
the console, but if no UART has sequence number 0, then we can fall back
to just using the first UART (index 0).
The device tree offset function is useful for buses, where they want to
locate one of their children. The device tree can be scanned to find the
offset of each child, and that offset can then find the device.
Simon Glass [Wed, 23 Jul 2014 12:55:18 +0000 (06:55 -0600)]
dm: Provide a function to scan child FDT nodes
At present only root nodes in the device tree are scanned for devices.
But some devices can have children. For example a SPI bus may have
several children for each of its chip selects.
Add a function which scans subnodes and binds devices for each one. This
can be used for the root node scan also, so change it.
A device can call this function in its bind() or probe() methods to bind
its children.
Simon Glass [Wed, 23 Jul 2014 12:55:14 +0000 (06:55 -0600)]
dm: Allow a device to be found by its FDT offset
Each device that was bound from a device tree has an node that caused it to
be bound. Add functions that find and return a device based on a device tree
offset.
Simon Glass [Wed, 23 Jul 2014 12:55:12 +0000 (06:55 -0600)]
dm: Introduce device sequence numbering
In U-Boot it is pretty common to number devices from 0 and access them
on the command line using this numbering. While it may come to pass that
we will move away from this numbering, the possibility seems remote at
present.
Given that devices within a uclass will have an implied numbering, it
makes sense to build this into driver model as a core feature. The cost
is fairly small in terms of code and data space.
With each uclass having numbered devices we can ask for SPI port 0 or
serial port 1 and receive a single device.
Devices typically request a sequence number using aliases in the device
tree. These are resolved when the device is probed, to deal with conflicts.
Sequence numbers need not be sequential and holes are permitted.
At present there is no support for sequence numbers using static platform
data. It could easily be added to 'struct driver_info' if needed, but it
seems better to add features as we find a use for them, and the use of -1
to mean 'no sequence' makes the default value somewhat painful.
Simon Glass [Wed, 23 Jul 2014 12:55:11 +0000 (06:55 -0600)]
dm: Avoid activating devices in 'dm uclass' command
This command currently activates devices as it lists them. This is not
desirable since it changes the system state. Fix it and avoid printing
a newline if there are no devices in a uclass.
Simon Glass [Wed, 23 Jul 2014 12:55:07 +0000 (06:55 -0600)]
Add a flag indicating when the serial console is ready
For sandbox we have a fallback console which is used very early in
U-Boot, before serial drivers are available. Rather than try to guess
when to switch to the real console, add a flag so we can be sure. This
makes sure that sandbox can always output a panic() message, for example,
and avoids silent failure (which is very annoying in sandbox).
Simon Glass [Wed, 23 Jul 2014 12:55:06 +0000 (06:55 -0600)]
console: Remove vprintf() optimisation for sandbox
If the console is not present, we try to reduce overhead by stopping any
output in vprintf(), before it gets to putc(). This is of dubious merit
in general, but in the case of sandbox it is incorrect since we have a
fallback console which reports errors very early in U-Boot. If this is
defeated U-Boot can hang or exit with no indication of what is wrong.
Simon Glass [Wed, 23 Jul 2014 12:55:05 +0000 (06:55 -0600)]
stdio: Provide functions to add/remove devices using stdio_dev
The current functions for adding and removing devices require a device name.
This is not convenient for driver model, which wants to store a pointer to
the relevant device. Add new functions which provide this feature and adjust
the old ones to call these.
Simon Glass [Wed, 23 Jul 2014 12:55:03 +0000 (06:55 -0600)]
dm: Allow drivers to be marked 'before relocation'
Driver model currently only operates after relocation is complete. In this
state U-Boot typically has a small amount of memory available. In adding
support for driver model prior to relocation we must try to use as little
memory as possible.
In addition, on some machines the memory has not be inited and/or the CPU
is not running at full speed or the data cache is off. These can reduce
execution performance, so the less initialisation that is done before
relocation the better.
An immediately-obvious improvement is to only initialise drivers which are
actually going to be used before relocation. On many boards the only such
driver is a serial UART, so this provides a very large potential benefit.
Allow drivers to mark themselves as 'pre-reloc' which means that they will
be initialised prior to relocation. This can be done either with a driver
flag or with a 'dm,pre-reloc' device tree property.
To support this, the various dm scanning function now take a 'pre_reloc_only'
parameter which indicates that only drivers marked pre-reloc should be
bound.
Simon Glass [Wed, 23 Jul 2014 12:55:02 +0000 (06:55 -0600)]
sandbox: Remove all drivers before exit
Drivers are supposed to be able to close down cleanly. To set a good example,
make sandbox shut down its driver model drivers and remove them before exit.
It may be desirable to do the same more generally once driver model is more
widely-used. This could be done during bootm, before U-Boot jumps to the OS.
It seems far too early to make this change.
Simon Glass [Wed, 23 Jul 2014 12:55:00 +0000 (06:55 -0600)]
dm: Make sure that the root device is probed
The root device should be probed just like any other device. The effect of
this is to mark the device as activated, so that it can be removed (along
with its children) if required.
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Marek Vasut <marex@denx.de>
Simon Glass [Wed, 23 Jul 2014 12:54:59 +0000 (06:54 -0600)]
stdio: Pass device pointer to stdio methods
At present stdio device functions do not get any clue as to which stdio
device is being acted on. Some implementations go to great lengths to work
around this, such as defining a whole separate set of functions for each
possible device.
For driver model we need to associate a stdio_dev with a device. It doesn't
seem possible to continue with this work-around approach.
Instead, add a stdio_dev pointer to each of the stdio member functions.
Note: The serial drivers have the same problem, but it is not strictly
necessary to fix that to get driver model running. Also, if we convert
serial over to driver model the problem will go away.
Code size increases by 244 bytes for Thumb2 and 428 for PowerPC.
22: stdio: Pass device pointer to stdio methods
arm: (for 2/2 boards) all +244.0 bss -4.0 text +248.0
powerpc: (for 1/1 boards) all +428.0 text +428.0
Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Marek Vasut <marex@denx.de> Reviewed-by: Marek Vasut <marex@denx.de>
Simon Glass [Fri, 11 Jul 2014 04:23:33 +0000 (22:23 -0600)]
sandbox: Always enable malloc debug
Tun on DEBUG in malloc(). This adds code space and slows things down but
for sandbox this is acceptable. We gain the ability to check for memory
leaks in tests.
Simon Glass [Fri, 11 Jul 2014 04:23:28 +0000 (22:23 -0600)]
Add a simple malloc() implementation for pre-relocation
If we are to have driver model before relocation we need to support some
way of calling memory allocation routines.
The standard malloc() is pretty complicated:
1. It uses some BSS memory for its state, and BSS is not available before
relocation
2. It supports algorithms for reducing memory fragmentation and improving
performace of free(). Before relocation we could happily just not support
free().
3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
this has been loaded anyway this is not really a problem.
The simplest way to support pre-relocation malloc() is to reserve an area
of memory and allocate it in increasing blocks as needed. This
implementation does this.
To enable it, you need to define the size of the malloc() pool as described
in the README. It will be located above the pre-relocation stack on
supported architectures.
Note that this implementation is only useful on machines which have some
memory available before dram_init() is called - this includes those that
do no DRAM init (like tegra) and those that do it in SPL (quite a few
boards). Enabling driver model preior to relocation for the rest of the
boards is left for a later exercise.
Simon Glass [Fri, 11 Jul 2014 04:23:25 +0000 (22:23 -0600)]
Remove form-feeds from dlmalloc.c
These don't really serve any purpose in the modern age. On the other hand
they show up as annoying control characters in my editor, which then happily
removes them.
I believe we can drop these characters from the file.
m68k: define __kernel_size_t as unsinged int again
Commit ddc94378d changed the definition of __kernel_size_t
from unsigned int to unsigned long.
It is true that it fixed warnings on some crosstools
but it increased warnings on the others.
The problem is that we cannot see consistency in terms of
the typedef of __kernel_size_t on M68K architecture.
However, I'd like to suggest to have __kernel_size_t to be
unsigned int again.
Rationale:
[1] Linux Kernel defines __kernel_size_t on M68K as unsigned int.
Let's stick to the Linux's way.
[2] We want to build boards with popular pre-built toolchains,
not the one locally-built by indivisuals.
I think m68-linux-gcc which can be downloaded from www.kernel.org
is the candidate for our _recommended_ toolchains.
With this patch, all the m68k boards can be built without any warnings.
Ian Campbell [Mon, 21 Jul 2014 18:23:18 +0000 (19:23 +0100)]
board_r: run scsi init() on ARM too
This has been disabled for ARM in initr_scsi since that function was
introduced. However it works fine for me on Cubieboard and Cubietruck (with the
upcoming AHCI glue patch).
I also tested on two random ARM platforms which seem to define CONFIG_CMD_SCSI:
- highbank worked fine (on midway hardware)
- omap5_uevm built OK and I confirmed using objdump that things were as
expected (i.e. the default weak scsi_init nop was used).
While there remove the mismatched comment from the #endif (omitting the comment
seems to be the prevailing style in this file).
Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Acked-by: Simon Glass <sjg@chromium.org>
Ian Campbell [Fri, 18 Jul 2014 19:38:39 +0000 (20:38 +0100)]
AHCI: Increase link timeout to 200ms
In 73545f75b66d "ahci: wait longer for link" I increased the
timeout to 40ms based on the observed behaviour of a WD disk on a
Cubietruck. Since then Karsten Merker and myself have both
observed timeouts with HGST disks (Karsten on Cubietruck, me on
Cubieboard2). Increasing the timeout to ~175ms fixes this, so go
to 200ms for a bit of headroom.
Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Cc: Karsten Merker <merker@debian.org> Acked-by: Hans de Goede <hdegoede@redhat.com>
projects / u-boot / log