Age | Commit message (Collapse) | Author |
|
Since burst_length is now set up at init time, it can never be < 0, and
we don't need to write the last byte in a separate I2C transaction.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: I0050dd49ba151ee267f2790b550c0ffea4cd976f
Reviewed-on: https://gerrit.chromium.org/gerrit/13375
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
The intent is for LCD init to happen such that we never need to call
udelay(). Add tracking that this is indeed the case, and report it
with the boot time report.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: I78e458a6b878a4237e4e059525bae4fa47844ed9
Reviewed-on: https://gerrit.chromium.org/gerrit/13377
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Indent all but the top-level messages which indicate a new transaction.
This makes it much easier to follow the debug trace.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: I3259c4e266f87ce4da8ce590f837542e5b219539
Reviewed-on: https://gerrit.chromium.org/gerrit/13372
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
We need to make sure that the LCD is ready before we complete booting, so
put this code into board_late_init().
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: I97bd1fce6ac93d0639dd8fdb17bf83e8a78d2645
Reviewed-on: https://gerrit.chromium.org/gerrit/13213
Commit-Ready: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Prior to relocation it is expensive to find out the LCD dimensions. Instead
we select the maximum possible size and allow lcd_ctrl_init() to correct
this later.
This works since the only purpose of this early init is to set the LCD
frame buffer size. So long as we set it to the largest value that could
possible be requested, all will be well.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: I850ee5cb2b6bf051e32c6a52c42c368a940ea045
Reviewed-on: https://gerrit.chromium.org/gerrit/13212
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
The LCD init takes place over five stages. We want to hide this init
behind other operations, so turn it into a state machine which we can
call at any time.
For now, call it in lcd_enable().
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: Ia0b50ec74108ac4e015de12b7a9628426ea17656
Reviewed-on: https://gerrit.chromium.org/gerrit/13211
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
The interrupt endpoint handling code stores the buffer pointer in the QH
padding field. We need to make it the size of a pointer to avoid strict
aliasing issue with the compiler.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chromium-os:24760
TEST=emerge-lumpy chromeos-u-boot ; emerge-tegra2_kaen chromeos-u-boot
Change-Id: Iecbfa0610591d24452106b79de61abb033c36f2e
Reviewed-on: https://gerrit.chromium.org/gerrit/13732
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
Interrupt transfers aren't meant to be used from the async list
(the EHCI spec indicates trouble with low/full-speed intr on async).
Build a periodic list instead, and provide an API to make use of it.
Then, use that API from the existing interrupt transfer API.
BUG=chrome-os-partner:5752
TEST=Use USB keyboard in u-boot (recovery mode) when later
commits make use of this code
Change-Id: I9bf0ef838af1076f8060c39bd942d95271cf0035
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: https://gerrit.chromium.org/gerrit/13489
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
|
|
Until we bring in the newer MMC code from upstream, this enables 8-bit
support with a minimum of changes.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: I5c3f5e6f4003ae63e08208d9afba66aef8d97ccf
Reviewed-on: https://gerrit.chromium.org/gerrit/13202
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Commit-Ready: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
Timeouts should use get_timer() where possible, and avoid looping
with fixed delays. This improves performance.
BUG=chromium-os:22938
TEST=build and boot on Kaen
Change-Id: I7e11151ddc0ac2faf14e05593181470558a52ab2
Reviewed-on: https://gerrit.chromium.org/gerrit/13199
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
BUG=none
TEST=emerge-tegra_kaen chromeos-u-boot
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
CQ-DEPEND=Ibb8f42116812dba74e726129ea92a941e15c272b
Change-Id: Iba58e415e7cd6deafa5744c1ff501a8ea5730d1e
Reviewed-on: https://gerrit.chromium.org/gerrit/13227
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
|
|
BUG=none
TEST=emerge-tegra_kaen chromeos-u-boot
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Change-Id: Ibb8f42116812dba74e726129ea92a941e15c272b
Reviewed-on: https://gerrit.chromium.org/gerrit/13226
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
|
|
BUG=chromium-os:23496
TEST=built Seaboard and Waluigi OK
Signed-off-by: Tom Warren <twarren@nvidia.com>
Change-Id: I52fcccc1627d1e9b6e0270e5ba9ab81c5d7fa9b7
Reviewed-on: https://gerrit.chromium.org/gerrit/12444
|
|
New device ID range is included to allow the SPI driver to use the
Panther Point based controller and a new device ID is checked when
attaching the AHCI controller.
BUG=chrome-os-partner:7112
TEST=manual
After this change the top of the tree ChromeOS can be booted on IVB
reworked Stumpy platforms.
Change-Id: Ia41c17b58337cde2d041990b3d1c9da37c0cd92c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/12606
|
|
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Cc: Remy Bohmer <linux@bohmer.net>
(cherry picked from u-boot-usb.git
commit 62d5f9a8b9e9a395b7e8af3344a2b2e47157c8f9)
BUG=chrome-os-partner:5752
TEST=on Lumpy, use USB keyboard to enter commands on U-Boot command line
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Change-Id: I6986ebda2191caf641444fca8909b253867e873b
Reviewed-on: https://gerrit.chromium.org/gerrit/12510
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
|
|
According to EHCI specification v1.0, the controller should stabilize
the power on a port at most 20 ms after the port power bit transition.
So, we put this setting in the virtual descriptor corresponding field,
(bPwrOn2PwrGood = 10 => 10 x 2ms = 20ms), this saves about 500ms at each
controller initialization/enumeration.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chrome-os-partner:6344
TEST=check USB time stamp on Lumpy before and after the patch
Change-Id: Ia09f62bdb6545387e5e7386ef9095abd53a7d192
Reviewed-on: https://gerrit.chromium.org/gerrit/12491
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
|
|
The Winbond W25X40 is now being used in the IP02 (and possibly IP04).
Tested and working on the actual device.
(cherry picked from commit ad8e3bd65766f670007bc5ae7c19b64e69e3dceb)
Change-Id: I0e395dc6c10086a330d2a32e8f7601afe1a1792d
Reviewed-on: https://gerrit.chromium.org/gerrit/11864
Reviewed-by: Taylor Hutt <thutt@chromium.org>
Tested-by: Taylor Hutt <thutt@chromium.org>
Commit-Ready: Simon Glass <sjg@chromium.org>
|
|
Signed-off-by: Tom Warren <twarren@nvidia.com>
BUG=none
TEST=built Seaboard and Waluigi AOK
Change-Id: Ia860abf5ef3af66b3a39d4c57192455986b7a4f4
Reviewed-on: https://gerrit.chromium.org/gerrit/11704
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Warren <twarren@nvidia.com>
Commit-Ready: Doug Anderson <dianders@chromium.org>
|
|
BUG=chromium-os:21033
TEST=run `sf erase, write` and then `sf read` on seaboard
verify the data it reads from SPI flash matches that it writes to
Change-Id: I1b04afa4b54738cd93be29b70f428bdc3e6b234f
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/11472
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Che-Liang Chiou <clchiou@chromium.org>
|
|
Signed-off-by: Tom Warren <twarren@nvidia.com>
BUG=none
TEST=built Seaboard and Waluigi OK. Booted Waluigi OK.
Change-Id: I1bfbe03945d7dae44e0840349b9698fc08cef07d
Reviewed-on: https://gerrit.chromium.org/gerrit/11504
Tested-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
|
|
The U-boot spi interface uses Software Sequencing and handles
write transactions in three distinct steps:
1) issue Write Enable op
2) issue Page Program op
3) poll Read Status Reg for completion
However in an Intel 6-series chipset the Management Engine is
also issuing a lot of transactions through the same controller
to the same chip. It is possible for an ME transaction to
occur between the U-boot issuing WREN and sending the actual
data, resulting in the host WREN being lost and the data not
actually being written to the chip.
This change intercepts WREN opcode and instead applies it as
a prefix operator for the next issued transaction, ensuring
that the two are issued back-to-back to the SPI chip.
Unfortunately this register is not writable when the SPI
contoller is locked down, so it is not always applicable.
BUG=chrome-os-partner:6690
TEST=repeated manual testing on lumpy with boot/suspend/resume
Change-Id: I75e353942fd6148a93be561ff422e37dfc6dc8c4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/11625
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
BUG=chromium-os:21033
TEST=build seaboard successfully
Change-Id: Idbfbdbf0bdb1070f4a2b5f8205c1caff6ef0c811
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/11471
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
BUG=chromium-os:21540
TEST=Able to talk to MMC1 on Waluigi w/ future config changes.
Specifically:
1. mmcinfo 0 - works (shows info)
2. mmcinfo 1 - works (shows info)
3. mmc rescan 1; mmc part 1 - works (shows partitions)
Change-Id: I730d3b91088f20ccf7ca20f3f31f7d59514af243
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/10661
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
BUG=chromium-os:21540
TEST=Built u-boot and booted u-boot on tegra2_kaen
Change-Id: Id6f11512ea1a95bd57b600601b488ae20b34db2d
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/10808
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This change adds a board overridable function which can be used to decide
whether or not to initialize the i8042 keyboard controller. On systems where
it isn't actually connected to anything, this can save a significant amount of
boot time.
On Stumpy, this saves about 200ms on boot.
BUG=chrome-os-partner:6585
TEST=Built and booted on Stumpy. Built and booted on Alex.
Change-Id: Ibac6fd4149fd125f6461ae4e86936eb9b012edb6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/10624
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
On x86, the i8042 keyboard controller driver frequently waits for the keyboard
input buffer to be empty to make sure the controller has had a chance to
process the data it was given. The way the delay loop was structured, if the
controller hadn't cleared the corresponding status bit immediately, it would
wait 1ms before checking again. If the keyboard responded quickly but not
instantly, the driver would still wait a full 1ms when perhaps 1us would have
been sufficient. Because udelay is a busy wait anyway, this change decreases
the delay between checks to 1us.
Also, this change gets rid of a hardcoded 250ms delay.
On Stumpy, this saves 100-150ms during boot. Also, the total boot time I'm
measuring at ToT is a little higher than expected. I'd like to see what other
people measure.
BUG=chrome-os-partner:6585
TEST=Built and booted on Stumpy. Built and booted on Alex, and verified that
the keyboard still worked at the u-boot prompt.
Change-Id: Ic361c4e88ded8e57b4377790dd011a11a0ce385b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/10623
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
|
|
BUG=chromium-os:21540
TEST=With future config change, saw that I could run i2c probe on
busses 0-3
Change-Id: Ibfad91a3e7360434111c7aa6d2ea45f73e9690fc
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10366
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
On the tegra30, it appears that the "DVC" i2c controller has been
normalized and no longer requires special semantics for accessing it
(it has also just been renamed to "i2c5"). This change makes it so
that we don't pick DVC semantics based on the periperal ID, but
instead allow the device tree to specify.
BUG=chromium-os:21540
TEST=Compiled / booted on Kaen
Change-Id: Idfd96d1193b5ac267c61416544c63cc03dab396d
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/10279
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
There is no need to multiply the length of the area in bytes by the
erase sector size.
BUG=none
TEST=manual
. when debug messages are enabled, the sensible erase size value is
printed.
Change-Id: I12373419fc1c136fac45869336487de5eedc441b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/9965
Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
It turns out that the ICH9 SPI controller comes out of reset with the
BIOS memory area write access disabled, the ability to write into the
BIOS space needs to be enabled explicitly.
BUG=chrome-os-partner:6166
TEST=manual
. build the new firmware image
. program it on Stumpy
. bring up ChromeOS
. try using flashrom to change the firmware image
flashrom was failing before this change and is succeeding now.
Change-Id: I9c5dbbe25171529ff1a227113fe07067b6e15aea
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/9956
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
The "scsi write" command requires support from underlying driver.
This CL enables SCSI_WRITE10 in AHCI driver.
BUG=chrome-os-partner:6258
TEST=(enter U-BOOT console, try to i/o with sector #64)
scsi read 1000 40 1
md.b 1000 200 # check if things are not 0xcc
mw.b 1000 cc 200 # try to fill with 0xcc
scsi write 1000 40 1
mw.b 1000 0 200 # fill with zero
md.b 1000 200 # should be all 0
scsi read 1000 40 1
md.b 1000 200 # should be all 0xcc
Change-Id: Ib8d980c88c0d26894434ab62173877b8839d2891
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/9712
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
We need these functions to set up the power chip during low-level init.
BUG=chromium-os:21033
TEST=build and boot on Seaboard
Change-Id: I69b9d3c12581e0a71db39b031b9ea2ef4ec184bf
Reviewed-on: http://gerrit.chromium.org/gerrit/8696
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
The GPIO driver is common between T20 and T30, so rename it to indicate
this.
BUG=chromium-os:21033
TEST=build and boot on seaboard
Change-Id: Ibcdd4142cadccd037326e9f6a8426d3c106e5b18
Reviewed-on: http://gerrit.chromium.org/gerrit/8680
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
The T20 and T30 i2c peripherals can use the same driver. This renames the
driver and puts the header file into the common arch-tegra directory.
BUG=chromium-os:19004
TEST=build and boot on seaboard
Change-Id: Iec76bb27340db037fdc67b3509fd35f7b5aaeb34
Reviewed-on: http://gerrit.chromium.org/gerrit/8643
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
There are some locations in the code which anticipate printf() being called
before the console is ready by squelching printf() on gd->have_console.
Move this squelching into printf(), vprintf(), puts() and putc(). Also
make tstc() and getc() return 0 if console is not yet initialised
Signed-off-by: Graeme Russ <graeme.russ@gmail.com>
Change-Id: If62863017eaa48915b721675a5d520f9caa7e5e0
Reviewed-on: http://gerrit.chromium.org/gerrit/8685
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This is needed by both T2x and T3x.
BUG=chromium-os:19004
TEST=build and boot on seaboard
Change-Id: Idc12f106caaaf7601de8e66d8440840375eb9c42
Reviewed-on: http://gerrit.chromium.org/gerrit/8637
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This is needed by both T2x and T3x.
BUG=chromium-os:19004
TEST=build and boot on seaboard
Change-Id: I03cb8e7b189cae0efb58d1ceed55a1e0dcd57c7f
Reviewed-on: http://gerrit.chromium.org/gerrit/8636
Reviewed-by: Che-Liang Chiou <clchiou@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This patch builds upon the recently introduced CBMEM console
feature of coreboot.
CBMEM console uses a memry area allocated by coreboot to store
the console output. The memory area has a certain structure,
which allows to determine where the buffer is, the buffer size
and the location of the pointer in the buffer. This allows
different phases of the firmware (rom based coreboot, ram based
coreboot, u-boot after relocation with this change) to keep
adding text to the same buffer.
Note that this patch introduces a new console driver and adds the
driver to the list of drivers to be used for console output, i.e.
it engages only after u-boot relocates. Usiong CBMEM console for
capturing the pre-relocation console output will be done under a
separate change.
BUG=chrome-os-partner:4200
TEST=manual
. build the new firmware and program it on a stumpy
. restart the machine
. after it comes up to ChromeOS, run the cbmem.py utility (which
is a part of the coreboot package).
Observe u-boot console output in the log, starting with
vvvvvvvvvvvvvvvvv
SCSI: AHCI 0001.0300 32 slots 6 ports ? Gbps 0xf impl SATA mode
flags: 64bit ilck stag led pmp pio
^^^^^^^^^^^^^^^^
and ending with
vvvvvvvvvvvvvvvvv
Magic signature found
Kernel command line: "cros_secure quiet loglevel=1 console=tty2...
^^^^^^^^^^^^^^^^^
Note that the entire u-boot output fits into the buffer only if
the coreboot log level is reduced from the most verbose. Ether
the buffer size will have to be increased, or the coreboot
verbosity permanently reduced.
Change-Id: I399a90f3aeef9fae074db3e0842d876101c1a85e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8720
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
|
|
BUG=None
TEST=Built tegra2_kaen successfully.
Change-Id: I506cbf33f2d385a895734692f8abd30db9a03c3e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/8718
Reviewed-by: Simon Glass <sjg@chromium.org>
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
For some reason we are getting timeouts in the tegra MMC code
when we're reading from external MMC cards. These don't seem
to be detrimental if we handle them properly. This CL properly
clears the "normal interrupt status register" (norintsts) in
error conditions. If we don't do this, when we come back into
mmc_send_cmd() the register will still contain status from the
last transaction.
BUG=chromium-os:20947
TEST=Booted from MMC 1
Also did the following for detailed test:
0. Ran with legacy u-boot and held space at bootup to get prompt.
1. mmc rescan 1
2. fatload mmc 1:c 0x408000 /u-boot/boot.scr.uimg ff
3. md.b 0x408000 0xff
4. Validated that the above looked like the bootscript (aka
contained text like "boot-A.scr").
Change-Id: Ie4e7736d9b2055dcb4b28775545291b7eb3e633e
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8469
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
|
|
This line is a NC on Asymptote, but right now we're using the pwm line
(incorrectly). This CL removes the backlight-vdd line from Asymptote
dts and ensures that it's safely ignored if it's missing.
BUG=None
TEST=Built u-boot for Asymptote and flashed it on the device. Ensured that the
backlight still works in u-boot.
Change-Id: Id751b6756bac120e2211b7b32c58f356ff30b767
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8063
Reviewed-by: Jon Kliegman <kliegs@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This works together with a kernel change that looks at
the scratchpad register to determine which of the many
UARTs it should use for early printing:
<http://gerrit.chromium.org/gerrit/8148>. While it is
unfortunate to need to pass this information in a
second way (it's already in the device tree), this
does allow the very early boot code (decompressing stub
and early assembly code) to print to the right port.
At the moment, I'm adding this to the UART init function.
Alternatively, we could add a more complex patch to
key off of the 'console' setting.
BUG=chromium-os:19656
TEST=See <http://gerrit.chromium.org/gerrit/8148>
Change-Id: Iea374625f22b9fa64cf22820dfd530eca1c38bb0
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/8156
|
|
The existing code waits a whole second for the AHCI controller to reset.
Instead, let's poll the status register to see if the reset has
succeeded and return earlier if possible. This brings down the time for
AHCI probing from 1s to 20ms.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
TEST=boot coreboot/u-boot on lumpy and notice a boot time of 1.7s
Change-Id: I235ce027ed7a3ba999423700aec44fbbf94e8b68
Reviewed-on: http://gerrit.chromium.org/gerrit/8091
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Ready: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
|
|
Some constants are actually better of with generic Tegra family names.
This also cleans up a few addresses which were in drivers rather than
in the tegra.h header file.
BUG=chromium-os:19004
TEST=build and boot on Seaboard
Change-Id: I1cabb5191a2b36648a37268069beb3b43c12d0e1
Reviewed-on: http://gerrit.chromium.org/gerrit/7128
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This CL is a Winbond SPI flash specific modification following
the same pattern as the earlier Macronix SPI flash specific fix
(http://gerrit.chromium.org/gerrit/7522).
BUG=chromium-os:20105
TEST=manual
. build a Newton bootloader image
. program the image on a Newton device
. restart the device
. at the 'boot>' prompt run the following commands:
setenv xyz 'this is a string'
saveenv
. reboot the device
. at the 'boot>' prompt run 'printenv'
Observe the environment include the new variable.
Change-Id: Ic82751ba8adc4ce8576141899afa989a60249003
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7729
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
I have cherry-picked a few commits which fix bugs in mmc with high capacity
devices. So we can revert most of our required changes here. This sorts out
remaining unreliability with mmc by increasing the timeout further.
BUG=chromium-os:20468
TEST=build and boot on seaboard
Change-Id: Ic9ceeadf226b37a05041f4dbcfcb9f285b831cab
Reviewed-on: http://gerrit.chromium.org/gerrit/7793
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This flag indicates that a high capacity device is being used.
BUG=chromium-os:20468
TEST=build and boot on seaboard
Change-Id: Icb8816d4fc832e7c4de8e7215ccac03ee85c075f
Reviewed-on: http://gerrit.chromium.org/gerrit/7792
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This patch provides handling of the two way handshake when SEND_OP_COND
(CMD1) is send to mmc card. It is necessary to inform eMMC card if the
host can work with high capacity cards (Jedec JESD84-A441, point 7.4.3).
The extra flag MMC_MODE_HC (high capacity) is added to indicate if the
host is capable of handling the high capacity eMMC cards.
Since this change is added to the generic mmc framework, then it requires
other boards to indicate if their mmc controllers can handle high capacity
cards. As it is now - the old behaviour of the framework is preserved.
Change-Id: I043cbddecbfd046888f715837df50f5440a0d3ca
Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/7791
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
Fix the problem that if we use the chip of MMC version 4 and
the capacity is smaller than 2GB or equal, the mmc->capacity is
invalid. According to the JEDEC Standard, the value of ext_csd's
capacity is valid if the value is more than 2GB.
Change-Id: Idd0cdbbea9dbd17bff626b550bb328e41ae38249
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Acked-by: Andy Fleming <afleming@freescale.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/7790
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
The ICH SPI controller can't handle more than 64 bytes in one
write transaction, but the SPI chips' drivers routinely invoke
controller transfer function (spi_xfer()) trying to write a full
SPI chip page, which often exceeds the ICH SPI controller capacity.
This condition goes unnoticed, resulting in only the first 64
bytes of the data written into the flash, the rest gets dropped
on the floor.
With this change an error value will be returned to the caller
and an error message will be printed on the screen.
Also, it turned out that the chip level flash drivers interpret
as errors only the negative values returned by the SPI interface
driver. But the SPI interface driver in ich.c was returning +1 to
report errors. This CL takes care of this discrepancy too.
BUG=chromium-os:20105
TEST=manual
. modify the '#ifdef CONFIG_ICH_SPI' line to read
'#ifdef CONFIG_ICH_SPIxx' in include/spi_flash.h
. build x86-alex bootloader image
. program the image on an alex device
. restart the device
. at the 'boot>' prompt run the 'saveenv' command
Observe the command failed and the error message printed on the console.
. restore include/spi_flash.h
. build x86-alex bootloader image
. program the image on an alex device
. restart the device
. at the 'boot>' prompt run the following commands:
setenv xyz 'this is a string'
saveenv
. reboot the device
. at the 'boot>' prompt run 'printenv'
Observe the environment include the new variable (xyz)
Change-Id: I528a85b208213c10fdf8cf3e908caf7bea94bc62
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7697
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|