Age | Commit message (Collapse) | Author |
|
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>
|
|
There have been a couple of problems with the driver:
- the commands which do not involve data transfer (WREN most
notably) were not being issued.
- the write page command was sent trying to send address as data,
which was causing the 3 bytes of the command to overflow to the
next cycle
This change fixes these problems and also refactors the driver
such that the status polling with timeout is implemented once and
used from different places.
BUG=chromium-os:20105
TEST=manual
. this change was tested combined with other modifications; The
ability to read and save the u-boot environment in an SPI
flash was demonstrated.
Change-Id: I12da0363eaf9ae193d1d29a84a9a2b48cbd58fd8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7526
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
|
|
There is a problem with x86 systems using Intel ICH chips as the
SPI controller: whereas the SPI chips allow for 256 byte pages
for write transactions, the controllers allow for only 64 bytes
per transaction. This causes failures when the chip driver
invokes the controller driver write() function passing a 256 byte
page: only 64 bytes get written.
This problem is not easy to fix in u-boot, this change suggests a
scheme to allow the size override for certain SPI controllers.
BUG=chromium-os:20105
TEST=manual
. this change was tested combined with other modification, the
ability to read and save the 16KB environment in a maconix SPI
flash was demonstrated.
Change-Id: Ic42f294da0e6abd554107d6189cabd7269370b96
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7522
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
|
|
This change reduces the erase unit size to 4K from 64K, which
allows for more efficient use of the Macronix SPI flash.
BUG=chromium-os:20105
TEST=manual
. this change was tested combined with other modification, the
ability to read and save the 16KB environment in a Macronix SPI
flash was demonstrated.
Change-Id: Icb723673079d755ffd9d89ac8d1286592722aa52
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7533
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
|
|
Replace register accesses with functions when compiled with DEBUG
defined. Add printf statements in the functions to allow tracing
of the SPI controller register accesses.
The following command was ran at the shell prompt to modify all
invocation sites:
perl -pni -e 's/(\W(read|write).)\(/\1_(/g' ich.c
and then the DEBUG case implementation was added.
BUG=chromium-os:20105
TEST=manual
. the tree builds with and without DEBUG defined when compiling the driver.
Change-Id: Ia0e4198bdf706b96b58347d4c994be83c532338e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7519
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
The correct size format specification for size_t is 'z'.
BUG-=none
TEST=manual
compile with and without DEBUG defined, observe success.
Change-Id: I036500751f0cc271eb0fd5623d61fd05a81013f9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7523
Reviewed-by: Mike Frysinger <vapier@chromium.org>
|
|
We want to move to the idea of drivers and boards using generic tegra
include files, and have these include files deal with the tegra2/3
differences. This will make it easier to share code between tegra2/3.
BUG=chromium-os:19004
TEST=build and boot on Seaboard
Change-Id: I9c4eec30707e41678fb307982a34fe383694ba16
Reviewed-on: http://gerrit.chromium.org/gerrit/7000
Reviewed-by: Yen Lin <yelin@nvidia.com>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Tested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
If no controller is present, the i8402 driver should return immediately and not
attempt to operate on the missing hardware.
In kbd_input_empty, the status register is checked every millisecond to see
whether the input buffer is empty, up to a timeout which is tracked by
decrimenting a counter each time the check is performed. The decrement is
performed with a postfix -- operator, and the value of the counter is checked
in place. That means that when the counter reaches zero and the loop
terminates, it will actually be decrimented one more time and become -1. That
value is returned as the return value of the function. That would give the
right answer if it wasn't for that extra decrement because a timeout would
indicate that the buffer never became empty.
This change fixes both of those bugs.
BUG=chrome-os-partner:5849
TEST=Built and booted on both x86-alex and stumpy. Used the built in keyboard
on x86-alex.
Change-Id: Id79d2067237952f95caca3f32d4928723d1fcdc1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/7248
|
|
First - make sure the ahci driver compiles and links properly when
building for x86 platforms.
Then it turned out that when trying to use AHCI driver on an x86
platform with an Intel AHCI controller, the driver does not operate
properly if the requested amount of blocks to read was exceeding 255.
It is probably possible to specify 0 as the block count and the driver
will read 256 blocks, but it was decided to limit the number of blocks
read at once to 128 (it should be a power of 2 for the optimal
performance of solid state drives).
BUG=chromium-os:19837
TEST=manual
. program updated image (including vbexport SATA support extension)
on an Alex.
. restart the machine and enter `vboot_twostop' at u-boot prompt.
Observe ChromeOS booting all the way to login screen.
Change-Id: I7224ca14ae60f414db6dbe9e2f0a649312a9459c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/7232
Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
This change modifies the existing ICH SPI controller driver so that it
continues to support the ICH7 controller, but now also the ICH9 controller.
This implementation uses software sequencing mode for two reasons. First, it's
very similar to the only mode of the ICH7 and makes supporting both controllers
much easier. Second, it's much more flexible and actually fits into the u-boot
driver API.
BUG=chrome-os-partner:5829
TEST=With this and other changes, built and vbooted on x86-alex and stumpy.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: Ifafd5febab8c905760c7e58eca82ee8a383efe36
Reviewed-on: http://gerrit.chromium.org/gerrit/7163
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Tested-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
Make the Winbond flash chip driver support the CONFIG_SPI_FLASH_NO_FAST_READ
option so that it can be used with the ICH SPI controller.
BUG=chrome-os-partner:5829
TEST=With this and other changes, built and vbooted x86-alex and stumpy.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: I8113b0476818fab1515ce37bd8bba9004d0717ca
Reviewed-on: http://gerrit.chromium.org/gerrit/7161
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
The CONFIG_SPI_FLASH_MACRONIX_NO_FAST_READ currently only applies to the
Macronix flash chip driver as the name suggests. This same option, however,
could be renamed something more generic and reused in other drivers. This
change does that by dropping MACRONIX from the option.
TEST=With this and other changes, built and vbooted on x86-alex, stumpy.
BUG=chrome-os-partner:5829
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: I5878877025baba44b09bce9507b528ba243d132b
Reviewed-on: http://gerrit.chromium.org/gerrit/7160
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Gabe Black (Do Not Use) <gabeblack@google.com>
|
|
It seems that the timeout / command does not work on Seaboard and Aebl.
This gives a 'Card did not respond to voltage select!' error.
This commit makes a few changes to fix this temporarily until a permanent
solution is found.
BUG=chromium-os:19599
TEST=boot; mmc part 0; see that the eMMC is detected and partition table displayed
Change-Id: I6471a110a86f7034abc24745b16284a3ceeb3645
|
|
After some experiments with the TPM and comparing the traces with
the existing i2c based implementation, it became clear that the
generic TPM driver needs to be reworked as follows:
- byte registers reads must use the byte mode (otherwise FIFO
returns 4 bytes in one access).
- byte sequences returned by the TPM contain their length as a 4
byte number in network byte order at offsets 2..5 in the
message.
- to improve robustness of the driver, it is important to verify
that the device does not expect any more data after the
command buffer is sent into the FIFO and has nothing more to
return after the reply length bytes is read from the FIFO.
- timeout granularity was reduced to 1 us (plus overhead) to
avoid waisting excessive time at boot,
- the code was cleaned up and commented.
BUG=chrome-os-partner:4547
TEST=manual
. build the new coreboot image
. run the 'vboot_twostep' command from the console
. observe the system to bring up verified ChromeOS image successfully.
Change-Id: I89b4935a411663812271caed9ed3efdeffedad72
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/6636
Reviewed-by: Stefan Reinauer <reinauer@google.com>
|
|
This basic driver has stubs for the required functions but has no
test functionality.
BUG=chromium-os:19353
TEST=build for Seaboard
Change-Id: I14ffb32fb17c0e3fa942e0df4a53d2d77fdc8ca7
Reviewed-on: http://gerrit.chromium.org/gerrit/6523
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
This is needed to use the same config files for all x86 platforms,
while the right incarnation of register accesses is determined by
the device tree.
BUG=chrome-os-partner:4520
TEST=boot u-boot on Alex and Stumpy, get serial output on both.
Change-Id: Ibb8192657861713d656358c5f085f6dde2cb1365
Reviewed-on: http://gerrit.chromium.org/gerrit/6248
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
|
|
Early in development, we needed a driver for the OXPCIE952 UART which would be
left configured by coreboot and just needed to send and receive characters. It
was only partially developed and was somewhat redundant with the NS16550 UART
support already in u-boot. Now that we're using the device tree to configure
the serial console and it requires us to use the NS16550 driver, the OXPCIE952
driver is no longer necessary. Since it isn't likely to be useful in other
contexts, this change removes support for it entirely.
BUG=chrome-os-partner:4520
TEST=Built on x86-alex and tegra2_kaen. Installed and booted on x86-alex and
verified that the serial console still worked.
Change-Id: I124c4596b224f1b2a8d27b2b38e08ee2ce739c79
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5871
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
|
|
The framebuffer address should be specified in the device tree and not u-boot
assigned. This FDT value should be the same as the one defined in Linux kernel;
otherwise, it causes screen flicker. The FDT value overrides the framebuffer
allocated at the top of memory by board_init_f().
If the framebuffer address is not defined in the FDT, falls back to use the
address allocated by board_init_f().
BUG=chrome-os-partner:5338
TEST=build without error and boot Chrome OS on Aebl, see the screen not
corrupted and splash screen showed.
Change-Id: Ia6a996d127d74d6084900814d2c934fb95518e23
Reviewed-on: http://gerrit.chromium.org/gerrit/5877
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
|
|
Separate all register accesses into accessor functions (taking
care of truncating values of the byte sized registers). Add code
to trace register accesses when compiled with DEBUG defined.
BUG=chrome-os-partner:4547
TEST=manual:
. compile with DEBUG defined in line 14 and boot on Alex
. try a TPM command:
boot > tpm
lpc_tpm: Read reg 0xf00 returns 0xb15d1
lpc_tpm: Found TPM SLB9635 TT 1.2 by Infineon
lpc_tpm: Read reg 0x0 returns 0x81
lpc_tpm: Write reg 0x0 with 0x2
lpc_tpm: Read reg 0x0 returns 0xa1
lpc_tpm: Write reg 0x18 with 0x40
lpc_tpm: Read reg 0x18 returns 0xff000840
lpc_tpm: Read reg 0x0 returns 0xa1
lpc_tpm: Write reg 0x0 with 0x20
lpc_tpm: Read reg 0x0 returns 0x81
Change-Id: I13d14e1bc12e26abfe999c9540bfeee52e8d2f2d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5907
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The W25X40AVSNI SPI flash part can run at 100MHz according to Winbond's
datasheet August 7, 2009, RevF.
The Tegra20 datasheet says it's SPI peripheral can run up to 50Mbps.
The way the Tegra2 clocks are set up we can only do 48MHz.
So this commit doubles the speed from 24MHz to 48MHz.
This reduces onestop boot time by about 15ms, twostop would be more.
BUG=chromium-os:17805
TEST=build and boot on Aebl, Seaboard
Change-Id: I90dd140c5d8d71e9361cd7b881d6931cc6c0bcb3
Reviewed-on: http://gerrit.chromium.org/gerrit/5773
Reviewed-by: Tom Warren <twarren@nvidia.com>
Tested-by: Simon Glass <sjg@chromium.org>
|
|
The newer compiler version is more thorough in detecting code
inconsistencies, and reports warnings in many cases when building
u-boot for kaen and alex.
This change modifies the not yet upstreamed files to get rid of
the warnings. There supposed to be no logical changes, so no
testing other than building the system is being done.
BUG=chromium-os:18862
TEST=manual
. run the following commands
emerge-tegra2_kaen chromeos-u-boot
emerge-x86-alex chromeos-u-boot
. observe them succeed
Change-Id: I7b8f3e7211007537f9e85cfd059174dbb9763bb4
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5771
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The newer compiler version is more thorough in detecting code
inconsistencies, and reports warnings in many cases when building
u-boot for kaen and alex.
This change modifies the code to get rid of the warnings. There
supposed to be no logical changes, so no testing other than
building the system is being done.
The files not yet upstreamed are excluded and will be submitted
separately.
BUG=chromium-os:18862
TEST=manual
. run the following commands
emerge-tegra2_kaen chromeos-u-boot
emerge-x86-alex chromeos-u-boot
. observe them succeed
Change-Id: I4c872d84352539d24a418ba910274d08d02d26a8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/5706
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
The SMSC95XX is a USB hub with a built-in Ethernet adapter. This adds support
for this, using the USB host network framework.
The source is from a prevous commit:
http://lists.denx.de/pipermail/u-boot/2011-June/094243.html
And fix warnings of "Dereferencing type-punned pointer will break
strict-aliasing rules", as:
351c351,352
< u32 addr_lo, addr_hi;
---
> u32 addr_lo;
> u16 addr_hi;
356,357c357,360
< addr_lo = cpu_to_le32(*((u32 *)eth->enetaddr));
< addr_hi = cpu_to_le16(*((u16 *)(eth->enetaddr + 4)));
---
> memcpy(&addr_lo, eth->enetaddr, sizeof(u32));
> addr_lo = cpu_to_le32(addr_lo);
> memcpy(&addr_hi, eth->enetaddr + 4, sizeof(u16));
> addr_hi = cpu_to_le16(addr_hi);
BUG=none
TEST=booted u-boot and detected a SMSC9500 USB Etherenet Adadpter.
Change-Id: I5fc136933d9923e5e446eecbbb7aeb8e2ccc7077
Reviewed-on: http://gerrit.chromium.org/gerrit/5714
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
|
|
BUG=chrome-os-partner:4722
TEST=Built on x86-alex and tegra2_kaen, used grep to look for any other use of
the driver
Change-Id: I59abfd1a1a1c2bbd7b333d1095077f647ac571a7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://gerrit.chromium.org/gerrit/5382
|