Pull the ACPI GNVS pointer from CBMEM and expose it in
the sysinfo structure for use by payloads.
BUG=chrome-os-partner:24380
BRANCH=none
TEST=build and boot rambi with emmc in ACPI mode
Change-Id: I47c358f33c464a4a01080268fb553705218c940c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179900
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The C standard considers it legal to return a NULL pointer for zero
length memory allocations, and our malloc implementation does in fact
make use of that. xmalloc() and xzmalloc() should therefore not consider
this case a failure.
Also fixed a minor formatting issue.
BUG=None
TEST=Made sure xmalloc(0) and xmalloc(1000) succeed and
xmalloc(0xffffffff) still dies.
Change-Id: Ib9b75df9458ce2ba75fd0bc0af9814a3323298eb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178725
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The xmalloc wrapper checks whether the malloc succeeded, and if not stops
execution and prints a message. xmalloc always returns a valid pointer. The
xzalloc wrapper does the same thing, but also zeroes the memory before
returning it.
BUG=None
TEST=Used this function in nyan, built and booted on it.
BRANCH=None
Change-Id: I00e7de04a5c368ab3603530b98bd3e3596e10632
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178001
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
If a programming error is detected, die can be used to print a message and
stop execution similar to failing an assert. There's also a "die_if" function
which is conditional.
die functions, like asserts, should be used to trap programming errors and not
when the hardware does something wrong. If all code was written perfectly, no
die function would ever be called. In other words, it would be appropriate to
use die if a function was called with a value that was out of bounds or if
malloc failed. It wouldn't be appropriate if an external device doesn't
respond.
In the future, the die family of functions might print a stack trace or show
other debugging info.
BUG=None
TEST=Used the die_if function in other code and verified that it stops
execution, prints messages like printf, shows file, line, and function
information, and is correctly gated by its condition.
BRANCH=None
Change-Id: I653fc8cb0b4e459522f1b86f7fac280836d57916
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178000
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Rambi currently has more than 16 memory ranges. Because of
this libpayload is silently dropping them and the full amount
of memory is not being properly wiped. Correct this by bumping
the number of ranges to 32.
BUG=None
BRANCH=None
TEST=Built and booted rambi. Noted that the full amount of memory
was being properly wiped.
Change-Id: Ida456decf2498cb1547c0ceef23df446a975606b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175792
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
This exposes the function that obtains cache line size so that it can
be used by drivers in DMA-related functions.
BUG=none
BRANCH=none
TEST=built and booted on nyan, nothing obvious broke
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9b0ddc36aa39084f0d621af064487d1b2ef3d023
Reviewed-on: https://chromium-review.googlesource.com/174099
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
This patch represents a major overhaul of the USB enumeration code in
order to make it cleaner and much more robust to weird or malicious
devices. The main improvement is that it correctly parses the USB
descriptors even if there are unknown descriptors interspersed within,
which is perfectly legal and in particular present on all SuperSpeed
devices (due to the SuperSpeed Endpoint Companion Descriptor).
In addition, it gets rid of the really whacky and special cased
get_descriptor() function, which would read every descriptor twice
whether it made sense or not. The new code makes the callers allocate
descriptor memory and only read stuff twice when it's really necessary
(i.e. the device and configuration descriptors).
Finally, it also moves some more responsibilities into the
controller-specific set_address() function in order to make sure things
are initialized at the same stage for all controllers. In the new model
it initializes the device entry (which zeroes the endpoint array), sets
up endpoint 0 (including MPS), sets the device address and finally
returns the whole usbdev_t structure with that address correctly set.
Note that this should make SuperSpeed devices work, but SuperSpeed hubs
are a wholly different story and would require a custom hub driver
(since the hub descriptor and port status formats are different for USB
3.0 ports, and the whole issue about the same hub showing up as two
different devices on two different ports might present additional
challenges). The stack currently just issues a warning and refuses to
initialize this part of the hub, which means that 3.0 devices connected
through a 3.0 hub may not work correctly.
BUG=chrome-os-partner:22139
TEST=Manual
Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170666
Reviewed-by: Kees Cook <keescook@chromium.org>
This patch removes the confusing concept of a special "xhci_speed" with
a different numeric value from the usual speed used throughout the USB
core (except for the places directly interacting with the xHC, which are
explicitly marked). It also moves the MPS0 decoding function into the
core and moves some definitions around in preparation of later changes
that will make the stack SuperSpeed-ready. It makes both set_address
implementations share a constant for the specification-defined
SetAddress() recovery delay and removes pointless additional delays from
the non-XHCI version.
BUG=chrome-os-partner:22139
TEST=Manual
Change-Id: I422379d05d4a502b12dae183504e5231add5466a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170664
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
BUG=chrome-os-partner:23009
TEST=Built libpayload and coreboot for link, pit and nyan. Booted into the
bootblock on nyan.
BRANCH=None
Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@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>
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
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>
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
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>
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>
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>
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>
So far this is used by the USB driver, and instead of
having ifdefs all throughout that code, implement the same
API on x86 and ARM.
BUG=chrome-os-partner:18635
TEST=Boot from USB on Snow
BRANCH=none
Change-Id: I8093ad818ad2e38a0901787aa8674faf591d580c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56105
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
On ARMv7 we need to carefully add memory barriers to
all memory read and write operations. This change
brings libpayload in sync with what coreboot is doing.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
BRANCH=none
TEST=no functional change
Change-Id: Ie9c30b0f0d30531c5f9d99c2729246a86b8cec26
Reviewed-on: https://gerrit.chromium.org/gerrit/59294
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
This was used by Ron 13ys ago and was never used again
ever since.
BUG=chrome-os-partner:18637
BRANCH=none
TEST=none
Change-Id: I8ae8a570d67fa0b34b17c9e3709845687f73c724
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59320
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
This was never completed / working and we have the working
ARMv7 port for an architecture template, so get rid of this
dead code.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ic2c1267ee5546dd6e1b63220c263b2fa86c8ae33
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56065
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Mass storage devices such as card readers show up as
as USB devices. However the media not be inserted. In those
situations the previous code would just fake a disk and
call usbcreate_disk. This is inappropriate because it forms
a 1:1 mapping of USB device to disk leading to the inability
to remove the disk and/or handle "hot plug" card insertion
and removals.
To alleviate this issue introduce the notion of ready to the
usbmsc structure. It tracks detached, not ready, and ready
states. The polling routine is then used to track not ready
to ready transitions thereby creating and removing disks
appropriately. This handles the case of inserting and removing
a card that shows up as a new disk.
BUG=chrome-os-partner:19596
BUG=chrome-os-parnter:20014
BRANCH=None
TEST=Booted recovery mode. Able to observe inerstion and removal
of sdcard. Also able to insert valid USB flash drive to boot
as well.
Change-Id: I3eefbe537ec1b9c975744b8984b06c17ae236f40
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57948
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The ram_media.c file is being compiled, however the
global functions were not exposed through a header.
BUG=chrome-os-partner:19691
BRANCH=none
TEST=Built depthcharge with including cbfs_ram.h and
calling the exposed functions.
Change-Id: I4588fbe320c29051566cef277bf4d20a83abf853
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56642
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Restructure USB stack to not depend on PCI, and
make PCI stub available on x86, but provide fixed
BARs for ARM (Exynos 5)
BUG=chrome-os-partner:18635
TEST=Boot from USB in depthcharge on Snow
Change-Id: Iee7c8b134c22b661a9a515e24943470c9dbadd1f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49970
In the process of getting rid of compiler includes during in coreboot
and libpayload, we defined size_t and ssize_t ourselves, using a GCC
macro for size_t: __SIZE_TYPE__. Unfortunately, there is no
__SSIZE_TYPE__, so we temporarily redefine unsigned to signed to make
__SIZE_TYPE__ __SSIZE_TYPE__.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18638
TEST=emerge-daisy libpayload depthcharge builds with ToT coreboot
Change-Id: I4cf4eb0fdaa4db64277c2585fe2c1bdc0acdf02b
Reviewed-on: https://gerrit.chromium.org/gerrit/49947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
This imports the cache/MMU code from coreboot as of 1877cee.
BUG=none
BRANCH=none
TEST=built and booted into the kernel (which still crashes) on snow
Change-Id: I97ec8b9640921a94a4b27d89e4ae6185e9f96f18
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48288
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Because pointers can be 32bit or 64bit big,
using them in the coreboot table requires the
OS and the firmware to operate in the same mode
which is not always the case. Hence, use 64bit
for all pointers stored in the coreboot table.
Guess we'll have to fix this up once we port to
the first 128bit machines.
BUG=chrome-os-partner:18638
TEST=USE=depthcharge emerge-link libpayload depthcharge chromeos-coreboot-link chromeos-bootimage
produces working image
BRANCH=none
Change-Id: I46fc1dad530e5230986f7aa5740595428ede4f93
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48723
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The way we got to include the compiler includes was kind of whacky.
Instead of mixing in potentially problematic headers, make libpayload
self-contained by adding some missing header files. Also clean up
conflicting definitions of size_t throughout the tree.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
TEST=emerge-link libpayload depthcharge works fine
BRANCH=none
Change-Id: I0ad1194de1a00b7133c5477c00eb167d63a2ee85
Reviewed-on: https://gerrit.chromium.org/gerrit/47608
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
This imports the newest cache and MMU code from coreboot. This
time it's so new that it hasn't even been checked in to coreboot.
However, this version at least allows DMA to work properly for the
MSHC driver. So even if we rebase a few more times, this version is
at least a step in the right direction.
Note: This omits the stuff that sets up dcache policy since
libpayload should not need to worry about that and it depends
on cbmem stuff.
Change-Id: Idd42b083e8019634aaaa44d5bf5b51db6c3912f5
Signed-off-by: David Hendricks <dhendrix@google.com>
Reviewed-on: http://review.coreboot.org/2975
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This imports the new cache maintenance API from coreboot at
commit bba8090. This is a BSD-licensed implementation which
exposes cache maintenance opertaions necessary for payloads
for things such as DMA transfers.
Change-Id: I554676db89517bebc6edae4f7ab7e5882e6f986d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2974
Tested-by: build bot (Jenkins)
On x86, coreboot may allocate a variable range MTRR for enabling caching
of the system ROM. Add the ability to parse this structure and add the
result to the sysinfo structure.
An example usage implementation would be to obtain the variable MTRR
index that covers the ROM from the sysinfo structure. Then one would
disable caching and change the MTRR type from uncacheable to
write-protect and enable caching. The opposite sequence is required
to tearn down the caching.
Change-Id: I3bfe2028d8574d3adb1d85292abf8f1372cf97fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2920
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There were a number of type issues in libpayload that sneaked in
with 903f8e0.
- size_t and ssize_t were conflicting with gcc builtins
- some stdint types were used in libpayload but not defined
in our stdint.h
With this patch it's possible to compile libpayload with the
reference toolchain again.
Change-Id: Idd5ccfdd9f3536b36bceca2d101e7405883b10bc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2903
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
After another incident related to virtual pointers in lib_sysinfo (and
resulting confusion), I decided to put some comments on the matter into
the code.
Remember, we decided to always use virtual pointers in lib_sysinfo, but
it's not always obvious from the code, that they are.
See also:
425973c libpayload: Always use virtual pointers in struct sysinfo_t
593f577 libpayload: Fix use of virtual pointers in sysinfo
Change-Id: I886c3b1d182cba07f1aab1667e702e2868ad4b68
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/2878
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
And include the new, split out version in drivers/keyboard.c and
drivers/usb/usbhid.c. Those files were including curses.h just for those
definitions, but the include path was only fixed up to to point to the
libpayload versions of those files if one of the variants of curses was
compiled in. If neither was, gcc would fall back to the system version of that
header which is wrong.
Change-Id: I8c2ee0baf5f0702bd8c713c8dd4613a4bb269ce5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2762
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vboot_handoff structure needs to be parsed from the coreboot tables.
Add a placeholder in sysinfo as well as the ability to parse the
coreboot table entry concering the vboot_handoff structure.
Built with unified boot loader and ebuild changes. Can find and use
the VbInitParams for doing kernel selection.
Change-Id: If40a863b4a445fa5f7814325add03355fd0ac647
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2720
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In their current macro form, any arguments that are expressions will be
evaluated multiple times. That can cause problems if they have side effects,
and might not even compile if the overall expression is ambiguous, for
instance if you pass in foo++.
Built with code that previously wouldn't compile because the macros
expanded to ambiguous expressions.
Change-Id: I378c04d7aff5b4ad40581930ce90e49ba7df1d3e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The timekeeping code in libpayload was dependent on rdtsc, and when it was
split up by arch, that code was duplicated even though it was mostly the same.
This change factors out actually reading the count from the timer and the
speed of the timer and puts the definitions of ndelay, udelay, mdelay and
delay into generic code. Then, in x86, the timer_hz and timer_get_raw_value
functions which used to be in depthcharge were moved over to libpayload's
arch/x86/timer.c. In ARM where there isn't a single, canonical timer, those
functions are omitted with the intention that they'll be implemented by a
specific timer driver chosen elsewhere.
Change-Id: I9c919bed712ace941f417c1d58679d667b2d8269
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2717
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some new TPM drivers in depthcharge require that type. I added it to
arch/types.h which seemed appropriate, but I'm not sure that's exactly the
right header to use, or in other words if you'd get that type from libpayload
the same way you'd get it if you were building a standard Linux program.
Also, I attempted to determine what underlying types gcc would use, and while
I think I picked the right ones I'm not 100% certain of that either.
Change-Id: Ic5c0b4173c8565ede3bfce8870976d596d69e51d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2669
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
