An earlier change modified the serial port configuration option name
and updated most board configurations, but Bayleybay was left behind.
BUG=None
TEST=Baylebay builds smoothly again
Change-Id: I8b779c1fb24820ca5ff95dcd6641ae1df94f7e1b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170961
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This config is based on the pit config but has been tuned somewhat to be
appropriate for the hardware on the nyan board.
BUG=None
TEST=With this and other changes, built for the nyan board.
BRANCH=None
Change-Id: Ide209a05a311d475151253d45f9315a6c35da565
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170835
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
While the 8250 compatible serial port driver is primarily useful on x86
systems because it works with the legacy x86 com ports, some devices which
aren't x86 based have 8250 compatible UARTs as well. This change renames the
CONFIG_X86_SERIAL_CONSOLE option to the more general and direct
CONFIG_8250_SERIAL_CONSOLE and fixes up the dependencies so that non-x86
systems can enable the driver, although it will default to on on x86 and off
otherwise.
Also, the default IO port address that's added to the sysinfo structure on x86
and which is intended to be overwritten by a value in the coreboot tables is
not used on ARM. That variable is adjusted so that it's more clear it's a
default value, and made dependent on x86 since that's the only place its value
is actually used.
BUG=None
TEST=With this and other changes, built for an ARM board which has an ns16550
(and essentially 8250) compatible UART. Built for pit and for link.
BRANCH=None
Change-Id: Ifeaade0e7bd76d382426e947275a9c933da4930e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170834
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The USB MSC device structure contains a "ready" state that can be either
"ready", "not ready" or "detached". The last one can only be assigned
when the device is completely unresponsive and gets forcefully logically
detached via usb_detach_device(). This call (at least in the current
version) also calls all destructors and frees the complete usbdev_t
structure (including the MSC specific part), which unfortunately makes
storing the "detached" state in that very structure a little pointless.
This patch reduces the "ready" value to a simple boolean and makes sure
that all detachment cases immediately return from the MSC driver,
carefully avoiding any use-after-free opportunities.
BUG=None
TEST=Unplug a USB stick from a Pit/Kirby in depthcharge and make sure
the machine doesn't crash.
Change-Id: Iff1c0849f9ce7c95d399bb9a1a0a94469951194d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170667
This is a copy of falco configuration with XHCI enabled and {E,O,U}HCI
disabled.
BUG=none
TEST=manual
$ emerge-bayleybay libpayload
now succeeds
Change-Id: I25db5ac203344abc090f3f195284df88195f25b0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170553
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This patch enhances the armv7 exception handlers in Coreboot and
libpayload to show the correct SP and LR registers from the aborted
context, and also dump a part of the current stack. Since we cannot
access the banked registers of SVC mode from a different exception mode,
it changes Coreboot (and its payloads) to run in System mode instead. As
both modes can execute all privileged instructions, this should not have
any noticeable effect on firmware operation (please correct me if I'm
wrong!).
BUG=None
TEST=Cause a data_abort in Coreboot or depthcharge. Marvel at the
beautifully displayed stack dump that helps you debug the abort.
Change-Id: I0e04f47619e55308f7da4a3a99c9cae6ae35cc30
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170045
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The readwrite_chunk was private to the usb mass storage driver, but wasn't
marked as static which was upsetting the compiler.
BUG=None
TEST=Built for kirby, snow and pit.
BRANCH=None
Change-Id: I0ef5c5f96a29f793dd43ff672a939902bad13c45
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169816
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Currently, we wait for up to 30 seconds for a device to become ready to
respond to a TEST_UNIT_READY command. In practice, all media devices become
ready much sooner. But, certain devices do not function with libpayload's
USB driver, and always timeout. To provide a better user experience when
booting with such devices, reduce the timeout to 5 seconds.
BUG=chrome-os-partner:22345
TEST=Manual on Peppy w/ FCR-HS3 SD card reader. Verify that timeout is
reduced to ~5 seconds. Also verify that various external media devices
continue to boot.
Change-Id: Icceab99fa266cdf441847627087eaa5de9b88ecc
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169209
When bringing up media, we claim to wait for up to 30 seconds for a
device to respond to our TEST_UNIT_READY command. Actually, we can wait
far longer because we do not take into account execution delay.
To improve timeout accuracy, make use of gettimeofday(), which calculates
time based upon a CPU counter. This improves the user experience
slightly when certain non-working USB devices are used.
BUG=chrome-os-partner:22345
TEST=Manual on Peppy w/ FCR-HS3 SD card reader. Verify that command
timeout occurs in ~30 seconds, rather than ~10,000 seconds.
Change-Id: Id9605ecfc0a522d7a0b039fd8eac541232605082
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169208
Reviewed-by: Julius Werner <jwerner@chromium.org>
Since the DMA memory is allocated by Coreboot (outside of the payload's
linker script), it won't get zeroed upon loading like the heap.
Therefore, a warm reboot that doesn't reset memory may leave stale
malloc cookies lying around and misinterpret them as memory that is
still in use on the next boot. After several boots this may fill up the
whole DMA memory and lead to OOM conditions.
Therefore, this patch explicitly wipes the first cookie in
init_dma_memory() to prevent that from happening. It also expands the
existing memory allocator debugging code to cover the DMA parts, which
was very helpful in identifying this particular problem.
BUG=chrome-os-partner:21969
TEST=None
Change-Id: I6e2083c286ff8ec865b22dd922c39c456944b451
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169455
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The existing USB_MEMORY mechanism to instantiate non-PCI host
controllers is clunky and inflexible... most importantly, it doesn't
allow multiple host controllers of the same kind. This patch replaces it
with a function that allows payloads to directly instantiate as many
host controllers of whatever type they need.
CQ-DEPEND=CL:169541
BUG=chrome-os-partner:21969
TEST=Manual
Change-Id: Ic21d2016a4ef92c67fa420bdc0f0d8a6508b69e5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169454
Reviewed-by: Stefan Reinauer <reinauer@google.com>
This patch updates the libpayload XHCI stack to run on ARM CPUs (tested
with the DWC3 controller on an Exynos5420). Firstly, it adds support for
64-byte Slot/Endpoint Context sizes. Since the existing context handling
code represented the whole device context as a C struct (whose size has
to be known at compile time), it was necessary to refactor the input and
device context structures to consist of pointers to the actual contexts
instead.
Secondly, it moves all data structures that the xHC accesses through DMA
to cache-coherent memory. With a similar rationale as in the ARM patches
for EHCI, using explicit cache maintenance functions to correctly handle
the actual transfer buffers in all cases is presumably impossible.
Instead this patch also chooses to create a DMA bounce buffer in the
XHCI stack where transfer buffers which are not already cache-coherent
will be copied to/from.
BUG=chrome-os-partner:21969
TEST=Snow/Pit/Kirby correctly boot from XHCI ports.
Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169453
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The current USB hub code always clears the port status change after
checking it, regardless of whether it was set in the first place. Since
this check runs on every poll, it might create a race condition where
the port status changes right between the GET_PORT_STATUS and the
CLEAR_FEATURE(C_PORT_CONNECT), thus clearing the statrus change flag
before it was ever read. Let's add one extra if() to avoid that possible
headache.
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Idd46c2199dc6c240bd9ef068fbe70cccc88bac42
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168098
Well, it turned out to be more as some gaps ;)
but we finally have xHCI running. It's well tested against a QM77 Ivy
Bridge board.
We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not
advertised and USB 3 devices will just work at HighSpeed.
There are still some bit fields in xhci_private.h, so this might need
little more work to run on ARM.
Original-Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3452
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit 9029265cf5)
Cherry-picked from upstream/master, resolved conflicts with 95b7b79c3
BUG=chrome-os-partner:21969
TEST=None
Change-Id: I413283bea0b2482b284d03bbab750ffc88ea6acf
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168097
This is mostly a rewrite, don't even try to read a diff.
Tested with an internal rate matching hub on a QM77 board and three hubs
integrated into DELL monitors.
Original-Change-Id: Ib12fa2aa90af4e0f37143d2ed92c4a1705b6d774
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3451
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit 5736fab4be)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Idec16258a5b7286de48b5d3974eeefcab45a7e50
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168096
The current drivers for external usb hubs and root hubs all follow
the same pattern. Before adding another one with 90% of the same code,
extract the common parts and rewrite them with a simple interface.
This also adds debouncing of new attachments. Current drivers just
waited 100ms before they reset the device. However, we should check
if the device becomes disconnected and reconnected during this period.
Porting of the current hub drivers will take place in separate
commits (when I have time to test the older HCIs).
Original-Change-Id: I0c0ce0ac1b1cc51fb4cd009b3f9fcd1b9d2ba8fe
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3450
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit 0b78de2ee9)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: I97b97c310a59b400cff8c9c245b5b24cfec3a109
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168095
Read bInterval from endpoint descriptors and store it in our endpoint_t
struct. The interval is encoded dependently on the device' speed and the
endpoint's type. Therefore, it will be normalized to the binary logarithm
of the number of microframes, i.e.
t = 125us * 2^interval
The interval attribute will be used in the xHCI driver.
Original-Change-Id: I65a8eda6145faf34666800789f0292e640a8141b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3449
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit aee44fa37d)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Ic42ad3c193390d5838b563346604b1ef9f385b52
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168094
xHCI requires special treatment of set_address since it determines
the device number itself (instead of the driver, as with the other
controllers). The controller also wants to validate a chosen device
configuration and we need to setup additional structures for the
device and the endpoints.
Therefore, we add three functions to the hci_t structure, namely:
set_address()
finish_device_config()
destroy_device()
Current implementation for the Set Address request moved into
generic_set_address() which is set_address() for the UHCI, OCHI and
EHCI drivers. The latter two are only provided as hooks for the xHCI
driver.
The Set Configuration request is moved after endpoint enumeration.
For all other controller drivers nothing changes, as there is no other
device communication between the lines where the set_configuration()
call moved.
Original-Change-Id: I6127627b9367ef573aa1a1525782bc1304ea350d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3447
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit 482af6d15c)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Ieb3af316a8d9aadb55a204b9f86281a511d14abd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168093
These values are already used in this usb stack.
Original-Change-Id: If96f1dc2b67fbc13dfc4ae2d84e8f9945aa03163
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3448
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit 4fc7b6c994)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: I203f4adbdb74a9274014531037bda7d073e155f6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168092
During device initialization, skip any non-endpoint descriptor before
reading the endpoint descriptors. By now, only HID descriptors were
skipped.
Original-Change-Id: I190f3ae44b864aa71d5f32c3738097cf8f33a61b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
(cherry picked from commit 735f55c29c)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: I74dac90d7acc858bd82dd410a93396f3bf873eea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168091
The compiler gets mad when the types are equivalent size but not necessarily
interchangeable because of strict aliasing checks. Since uint32_t is likely to
be used when trying to read 32 bit data, it makes sense for them to be the
compatible.
This change was originally written for ARM but applies to x86 as well.
BUG=None
TEST=Built and booted on link.
BRANCH=None
Change-Id: I91b5e39f40e516405b9802032c87d3b15ed52c23
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169121
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
It turns out that my previous commit to make the EHCI stack cache aware
on ARM devices wasn't quite correct, and the problem is actually much
trickier than I thought. After having some fun with more weird transfer
problems that appear/disappear based on stack alignment, this is my
current worst-case threat model that any cache managing implementation
would need to handle correctly:
Some upper layer calls ehci_bulk() with a transfer buffer on its stack.
Due to stack alignment, it happens to start just at the top of a cache
line, so up to 64 - 4 bytes of ehci_bulk's stack will share that line.
ehci_bulk() calls dcache_clean() and initializes the USB transfer.
Between that point and the call to dcache_invalidate() at the end of
ehci_bulk(), any access to the stack variables in that cache line (even
a speculative prefetch) will refetch the line into the cache. Afterwards
any other access to a random memory location that just happens to get
aliased to the same cache line may evict it again, causing the processor
to write out stale data to the transfer buffer and possibly overwrite
data that has already been received over USB.
In short, any dcache_clean/dcache_invalidate-based implementation that
preserves correctness while allowing any arbitrary (non cache-aligned)
memory location as a transfer buffer is presumed to be impossible.
Instead, this patch causes all transfer data to be copied to/from a
cache-coherent bounce buffer. It will still transfer directly if the
supplied buffer is already cache-coherent, which can be used by callers
to optimize their transfers (and is true by default on x86).
CQ-DEPEND=CL:169170
BUG=chrome-os-partner:21969
TEST=Make sure Snow still boots from the USB 2.0 port.
Change-Id: I112908410bdbc8ca028d44f2f5d388c529f8057f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169231
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
keyboard_init attempts to read the existing mode register, set the
'XLATE' bit, and write it back. The implementation is buggy because the
keyboard may be active at the time we read the mode, and we can
misinterpret scancode data as the reply to our command. It leads to
problems where the KB gets disabled in firmware.
In fact, setting the 'XLATE' bit is completely unnecessary, even if we
desire QEMU keyboard support. We already set this bit when we initialize
the keyboard in pc_keyboard_init. Basically, this code does nothing
(or worse), so just remove it.
BUG=chrome-os-partner:22134
TEST=Manual on Peppy. Spam keyboard going into recovery mode, verify the
keyboard still remains functional. Verify keyboard functions in dev
mode, recovery mode, and verified boot.
BRANCH=FalcoPeppy
Change-Id: Ia3f953d66eaa0c120d2371955a3ad73a2326cc88
Original-Change-Id: Iab23f03fa8bced74842c33a7d263de5f449bb983
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168515
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Add a new function to split transfer requests into chunks of
64KB in order to be as compatible as possible with devices that
choke when sent large transfer requests.
BUG=chrome-os-partner:22297
BRANCH=falco,peppy,wolf,leon
TEST=manual: successfully boot from various USB3 sticks on Falco
Change-Id: Id11990bd149af14af5535de4af47bda21d1ab51e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169170
Reviewed-by: Julius Werner <jwerner@chromium.org>
Now that we're enabling 3.5GB...
BUG=chrome-os-partner:22144
BRANCH=none
TEST=loaded depthcharge on kirby
Change-Id: Ic21d0efbf1fe7593737e010e3ad2dc81edc3b276
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167666
Reviewed-by: ron minnich <rminnich@chromium.org>
This patch makes the EHCI driver work on ARM platforms which usually do
not support automatic cache snooping. It uses the new DMA memory
mechanism (which needs to be correctly set up in the Coreboot mainboard
code) to allocate all EHCI-internal communication structures in
cache-coherent memory, and cleans/invalidates the externally supplied
transfer buffers in Bulk and Control functions with explicit calls as
necessary.
BUG=chrome-os-partner:21969
TEST=Make sure booting from the EHCI port now works without any
additional tweaks.
Change-Id: Ie8a62545d905b7a4fdd2a56b9405774be69779e5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167339
This minor refactoring patch changes the signature of all limited cache
invalidation functions in Coreboot and libpayload from unsigned long to
void * for the address argument, since that's really what you have in
95% of the cases and I think it's ugly to have casting boilerplate all
over the place.
CQ-DEPEND=CL:167358
BUG=chrome-os-partner:21969
TEST=Make sure all payloads still compile cleanly when this and
dependent changes are in.
Change-Id: Ic9d3b2ea70b6aa8aea6647adae43ee2183b4e065
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167338
This patch adds a mechanism to set aside a region of cache-coherent
(i.e. usually uncached) virtual memory, which can be used to communicate
with DMA devices without automatic cache snooping (common on ARM)
without the need of explicit flush/invalidation instructions in the
driver code.
This works by setting aside said region in the (board-specific) page
table setup, as exemplary done in this patch for the Snow, Pit and Kirby
boards. It uses a new mechanism for adding board-specific Coreboot table
entries to describe this region in an entry with the LB_DMA tag.
Libpayload's memory allocator is enhanced to be able to operate on
distinct types/regions of memory. It provides dma_malloc() and
dma_memalign() functions for use in drivers, which by default just
operate on the same heap as their traditional counterparts. However, if
the Coreboot table parsing code finds a CB_DMA section, further requests
through the dma_xxx() functions will return memory from the region
described therein instead.
BUG=chrome-os-partner:21969
TEST=Manual
Change-Id: Ia9c249249e936bbc3eb76e7b4822af2230ffb186
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167155
There are three Coreboot table tags that all define some kind of memory
region, and each has their own homologous struct. I'm about to add a
fourth so I'll just clean this up and turn it into a generic struct
lb_range instead.
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Id148b2737d442e0636d2c05e74efa1fdf844a0d3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167154
The EHCI host controllers in Samsung Exynos SoC seem to be a little more
picky than Intel ones. When they reach the dummy_qh in the periodic
frame list, they try to access the next qTD pointer even though it's
NULL, an run into a HostSystemError. This patch explicitly sets the
Terminate bit on those pointers to mark them invalid.
BUG=chrome-os-partner:18635
TEST=Fix all the other issues with EHCI on ARM, then make sure it works.
Change-Id: I50fa79bbf1c5fab306d7885c01efd66b13e279b8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66884
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
A similar fix was made to coreboot where OP_DCCSW was silently not doing
anything in dcache_op_set_way.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit and snow.
BRANCH=None
Change-Id: Ia0798aef0cd02da7d1a14b7affa05038a002ab3b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66236
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
If the size the lzma header claims it needs is bigger than the space we have,
print a message and continue rather than erroring out. Apparently the encoder
is lazy sometimes and just puts a large value there regardless of what the
actual size is.
This was the original intention for this code, but an outdated version of the
patch ended up being submitted.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit. Saw the recovery screen come up where it had
not before.
BRANCH=None
Change-Id: Ibcf7ac0fd4b65ce85377421a4ee67b82d92d29d3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66235
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
A bootblock overwalk was occuring when deriving the actual
length, the bootblock size was not taken into account and bootblock
size was not aligned.
Resolved merge conflict.
BUG=chrome-os-partner:21841
BRANCH=peppy
TEST=execute on DUT: "localhost ~ # sudo suspend_stress_test",
verfify there is no CBFS: ERROR
Change-Id: I7eb42f8deaaf223dcf07b37bb7dde4643acd508f
Signed-off-by: Steven Sherk <steven.sherk@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65989
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Steve Sherk <ssherk70@gmail.com>
Tested-by: Steve Sherk <ssherk70@gmail.com>
This merges the difference between the ARM version of cache.c and
cache.h for libpayload and coreboot.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=built and booted on pit
Change-Id: I246d2ec98385100304266f4bb15337a8fcf8df93
Reviewed-on: https://gerrit.chromium.org/gerrit/66120
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
This version is used to implement the version which doesn't.
BUG=chromium:270897
TEST=Built into depthcharge and booted on pit.
BRANCH=None
Change-Id: I8935024aca0849bc939263d7fc3036c586e63c68
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65510
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
When libpayload header files are included in the payload itself, it's possible
that the payloads config settings will conflict with the ones in libpayload.
It's also possible for the libpayload config settings to conflict with the
payloads. To avoid that, the libpayload config settings have _LP_ (for
libpayload) added to them. The symbols themselves as defined in the Config.in files
are still the same, but the prefix added to them is now CONFIG_LP_ instead of just
CONFIG_.
BUG=chrome-os-partner:19420
TEST=Built and booted on pit. Built libpayload and depthcharge on all
supported platforms.
BRANCH=None
Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65303
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The hexdump function was added to libpayload recently, but its source file was
never added to the Makefile so it wasn't compiled or linked in.
BUG=None
TEST=Built and booted into a firmware that called hexdump in the payload.
Before this change the build would fail because the hexdump symbol wasn't
defined.
BRANCH=None
Change-Id: Ic3c12a5b8a6ea631b83c10a6e4210544ff00b5bf
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64878
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
This adds inline wrappers to read the L2 cache auxiliary control
register (L2ACTLR).
Signed-off-by: David Hendricks <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=it builds (tested more thoroughly w/ follow-up patches)
Change-Id: Iec603d7c738426232f7ce3a4a474d01c85fa3f2f
Reviewed-on: https://gerrit.chromium.org/gerrit/64861
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
BUG=chrome-os-partner:18637
BRANCH=none
TEST=boot on Snow, see depthcharge boot the system
Change-Id: I1f9e3ff795caa7f881ca4e9975258395ef6fee50
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62189
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
BUG=None
TEST=With other changes, emerged libpayload for kirby.
BRANCH=None
Change-Id: I365a38a5621be1d42d2675d96acfdc133ec2d04d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63876
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Add a function to disable and clear the keyboard controller.
BUG=chrome-os-partner:20758
TEST=Verified Code flow in normal boot/S3 resume with print statements.
Verified Keyboard was correctly disabled and flushed by booting
to recovery mode screen while pressing keys on the integrated
keyboard.
BRANCH=none
Change-Id: I3e1f011c3436fee5ce10993c6c26a3c8597c6fca
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63627
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
- prints hex and ascii
- detects duplicate all zero lines
BUG=none
TEST=none
BRANCH=none
Change-Id: I084b3072bc05725b23c5c3ca0dbf1533f164a08c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63660
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
The cache.h header uses standard int types but doesn't include stdint.h itself.
BUG=chrome-os-partner:19420
TEST=Built for pit.
BRANCH=None
Change-Id: If470978164b0cd1f05c27c2c8eda365133cc47ff
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63190
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The EHCI driver defines a maximum transfer timeout of two seconds. The
comments state that during tests the maximum amount of required transfer
time was for the SCSI TEST_UNIT_READY command on certain devices. We
have now observed a USB device (Patriot Memory 13fe:3100) that can NAK
this command for slightly more than two seconds. It will also completely
fail if the timeout hits, since it gets confused by the subsequent CSW
retry/recovery mechanism and starts producing babble errors. This patch
increases the timeout to three seconds to circumvent this problem.
BUG=chrome-os-partner:20988
TEST=Boot a Falco from a red-black RageXT USB stick.
Change-Id: I3c4fef468fb16eacc5a487d76d025a78fb450e27
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63095
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
BUG=None
TEST=Built for falco, snow, link.
BRANCH=None
Change-Id: I7252925ef5c4efb69cad6b6fa179031162cf8e74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61058
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
When dealing with DMA, we need a function to invalidate cache without corrupting
contents on main memory (clean).
BUG=none
TEST=emerge-peach_pit libpayload
BRANC=NONE
Change-Id: I28e632ae57a7b7ed1accee74e76045b92f92a699
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61078
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The OP assigned by dcache_clean_by_mva must be handled in
dcache_op_mva.
BUG=none
TEST=emerge-peach_pit libpayload
BRANCH=none
Change-Id: Ib32262f0419453b2690d7c1a1c6602380b46a37f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61077
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
In some header shuffling stdint.h no longer included a definition
for NULL. Pull in string.h for the proper definition. Also, disable
the xHCI controller in libpayload as the firmware leaves control
of the USB 3.0 ports to the EHCI controller.
BUG=None
BRANCH=None
TEST=Was able to boot in in non-dev mode. In dev mode there were no
longer errors about the xHCI controller.
Change-Id: Iabf15b3b17d88784e0718dc9f0fd885e6551e0b1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/60874
Reviewed-by: Sameer Nanda <snanda@chromium.org>
