Age | Commit message (Collapse) | Author |
|
Move SeaBIOS' build directory out of build/
This allows the user to delete build/ in the top dir
and keep the built binary in payloads/external/SeaBIOS/seabios/out/
Change-Id: Ia7d515cd7e349beebcd9b62c9d956137acb73c82
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/6460
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
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.
Change-Id: Icceab99fa266cdf441847627087eaa5de9b88ecc
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169209
(cherry picked from commit 9e55204e92adca0476d273565683f211d6803e7a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6647
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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.
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>
(cherry picked from commit 1d3d535db83ff478c512e37f37015b43927b3efc)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6646
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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.
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>
(cherry picked from commit 4c413b007aa23da830877127dd556c4c38b43042)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6636
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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 and Pit
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.
Change-Id: Ia9c249249e936bbc3eb76e7b4822af2230ffb186
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167155
(cherry picked from commit d142ccdcd902a9d6ab4d495fbe6cbe85c61a5f01)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6622
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
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.
Change-Id: Idd46c2199dc6c240bd9ef068fbe70cccc88bac42
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168098
(cherry picked from commit f7f6f008f701ab3e4a4f785032d8024d676e11cb)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6617
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
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, and run into a HostSystemError. This patch explicitly sets the
Terminate bit on those pointers to mark them invalid.
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>
(cherry picked from commit c575a5c958ce88732d28044352c89418bcd5ea86)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6608
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The USB bulk and control transfer functions in libpayload currently
always return 0 for success and 1 for all errors. This is sufficient for
current use cases (essentially just mass storage), but other classes
(like certain Ethernet adapters) need to be able to tell if a transfer
reached the intended amount of bytes, or if it fell short.
This patch slightly changes that USB API to return -1 on errors, and the
amount of transferred bytes on successes. All drivers in the current
libpayload mainline are modified to conform to the new error detection
model. Any third party users of this API will need to adapt their
if (...<controller>->bulk/control(...)) checks to
if (...<controller>->bulk/control(...) < 0) as well.
The host controller drivers for OHCI and EHCI correctly implement the
new behavior. UHCI and the XHCI stub just comply with the new API by
returning 0 or -1, but do not actually count the returned bytes.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48308
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Updated the patch to support XHCI as well.
Change-Id: Ic2ea2810c5edb992cbe185bc9711d2f8f557cae6
(cherry picked from commit e39e2d84762a3804653d950a228ed2269c651458)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6390
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The current XHCI code only sets IOC on the last TRB of a TD, and
doesn't set ISP anywhere. On my Synopsys DesignWare3 controller, this
won't generate an event at all when we have a short transfer that is not
on the last TRB of a TD, resulting in event ring desync and everyone
having a bad time. However, just setting ISP on other TRBs doesn't
really make for a nice solution: we then need to do ugly special casing
to fish out the spurious second transfer event you get for short
packets, and we still need a way to figure out how many bytes were
transferred. Since the Short Packet transfer event only reports
untransferred bytes for the current TRB, we would have to manually walk
the rest of the unprocessed TRB chain and add up the bytes. Check out
U-Boot and the Linux kernel to see how complicated this looks in
practice.
Now what if we had a way to just tell the HC "I want an event at exactly
*this* point in the TD, I want it to have the right completion code for
the whole TD, and to contain the exact number of bytes written"? Enter
the Event Data TRB: this little gizmo really does pretty much exactly
what any sane XHCI driver would want, and I have no idea why it isn't
used more often. It solves both the short packet event generation and
counting the transferred bytes without requiring any special magic in
software.
Change-Id: Idab412d61edf30655ec69c80066bfffd80290403
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170980
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit e512c8bcaa5b8e05cae3b9d04cd4947298de999d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6516
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This new version is used to implement the version which doesn't take the
input and output buffer sizes.
Old-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>
(cherry picked from commit 465d167ad2f6a67d0b2c91fb6c68c8f9a09dd395)
libpayload: Make lzma truncation non-fatal.
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.
Old-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>
(cherry picked from commit 30c628eeada274fc8b94f8f69f9df4f33cbfc773)
Squashed two related commits and updated the commit message to be
more clear.
Change-Id: I484b5c1e3809781033d146609a35a9e5e666c8ed
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6408
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
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.
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>
(cherry picked from commit 20b0ba479b01755fbdc7f3dd9214e8af923402ba)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6539
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
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.
Change-Id: Id148b2737d442e0636d2c05e74efa1fdf844a0d3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167154
(cherry picked from commit 22d82ffa3f5500fbc1b785e343add25e61f4f194)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6456
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
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!).
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>
(cherry picked from commit d0db2f5e938200e3f5899c5e1f1606ab2dd5b334)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6538
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Representing a (non-negative) length with a signed integer is not
optimal, so change its type to `size_t`.
Change-Id: Ic0c2b7e081ba32d917409568ee53007d9ab7f8f3
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/4768
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
You might want to use the serial hardware for something other than a console,
or you might want to intercede in the serial stream to wrap it in another
protocol. This is what you'd do to send output to GDB while using it to debug
the payload.
Change-Id: I2218c0dbb988dacb64e5bdaf5d92138828eff8b6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179559
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit da9ab46d974745125fe7d8b29ce43336c3586cd5)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6547
Tested-by: build bot (Jenkins)
|
|
This script is used by 'make menuconfig', but being non executable it
fails to run, causing the make invocation failure.
Setting 'x' mode bits fixes the problem.
Change-Id: I925ca4ee056937b6c38ad34f5520fd621f9d9eb0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173564
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 3ddb9d221ecc3df968853d765b566cf0648a7525)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6540
Tested-by: build bot (Jenkins)
|
|
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_.
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>
(cherry picked from commit 23e866da20862cace0ed2a67d6fb74056bc9ea9a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6427
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This adds a wrapper for data cache clean (without invalidate)
by set/way.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I09ee1563890350a6c1d04f1b96ac5d0c042e2af2
Reviewed-on: https://gerrit.chromium.org/gerrit/66118
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
(cherry picked from commit 05bc4f8564c547eacb9cc840a03b916b3c1c6001)
armv7: clean but do not invalidate caches between stages
This cleans the caches without invalidating them between stages. The
dcache content should still be valid when the next stage begins, so
we should see a small performance gain.
(thanks to gabeblack for pointing this out)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: Ie18d163f3a78e2786e9fbc7479c8bd896b8ac3aa
Reviewed-on: https://gerrit.chromium.org/gerrit/66119
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
(cherry picked from commit 619bfe4cf9b93847e38d03d7076beb78fbfa1d1d)
armv7: Make coreboot and libpayload cache files the same
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>
Old-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>
(cherry picked from commit 0c92f694034f1e94a8aa7811251738c9dc3db2c6)
ARM: Fix cache cleaning operation.
There was no behavior defined for OP_DCCSW in dcache_op_set_way, so it
silently did nothing. Since we started using that to clean the cache between
stages and I have a change that enables caches earlier on, this was preventing
booting on pit.
Old-Change-Id: I3615b6569bf8de195d19d26b62f02932322b7601
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66234
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 99241468cb9dcc86fcca9266ffe72baa88a1f79f)
libpayload: Fix data cache cleaning on ARM.
A similar fix was made to coreboot where OP_DCCSW was silently not doing
anything in dcache_op_set_way.
Old-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>
(cherry picked from commit 6f6596a182a6780a2e997ac320733722697990c5)
Squashed five related commits.
Change-Id: I763d42bd5dd9f58734e1e21eb7c8ce3ce2ea56ee
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6418
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Set up the serial console on SeaBIOS to match coreboot's settings.
Previously, we were just forcing it on, and setting it to 0x3f8.
Change-Id: I107245c8bd1ba2cf948c6671337c6169226aaaaf
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6363
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Instead of creating the SeaBIOS .config file for QEMU, then changing
things to be coreboot specific, create a default config for coreboot,
then run olddefconfig to use the SeaBIOS defaults as they're set for
coreboot. This leads to a cleaner config.
Note that CONFIG_THREAD_OPTIONROMS defaults to enabled for SeaBIOS if
we're building for coreboot, so I reversed the logic.
I *ASSUMED* that leaving CONFIG_QEMU_HARDWARE=y and CONFIG_DEBUG_IO=y
previously was an oversight. If this is not correct, please let me
know and I'll add them it back in. SeaBIOS disables these by default
if building for coreboot.
Change-Id: I42c6a56205bb15c6693a5f3a716b7876a4d78abe
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6362
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
The generic cbfs code relies on the libpayload_init_default_cbfs_media
symbol. However, none was provided for ARM. Provide an empty
implementation that returns an error as there is no generic way
to locate the default cbfs media.
Old-Change-Id: Ie0d06fbe6fc790c9d92434cd2d60922908acdc69
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56805
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit d3410c28ef9f37b832e2fa2d18351dda332bc9f7)
libpayload: place dummy_media.c in correct object list
The commit introducing dummy_media.c was placed in the
libc object list. This wasn't correct. It should be in the
libcbfs object list as well as guarded by CONFIG_CBFS.
Old-Change-Id: Iace43fff8f85f60ecac5e6eb8350cd1f3ee9d35e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56925
(cherry picked from commit 7937c7c5e95a934593bc0cedd5f4496b4770c303)
Squashed two related commits.
Change-Id: I84cd132b44cc2ea5b29acf109a3562baaeede9c6
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6411
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
This change makes it possible for vboot to avoid an
exploit that could cause involuntary switch to dev mode.
It gives depthcharge/vboot some information on the
type of input device that generated a key.
BUG=chrome-os-partner:21729
TEST=manually tested for panther
BRANCH=none
CQ-DEPEND=CL:182420,CL:182241,CL:182946
Change-Id: I87bdac34bfc50f3adb0b35a2c57a8f95f4fbc35b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/182357
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: http://review.coreboot.org/6003
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
(Panther clone of Ia41af8425ab6c24746253abd025acd3365dd5a18 by reinauer)
BUG=chrome-os-partner:23563
TEST=emerge-panther chromeos-coreboot-panther
[pg: Drop configs/, which is chromeos stuff, adapted
libpayload's config.panther to work with upstream]
[pm: Add HAVE_IFD_BIN and HAVE_ME_BIN Kconfig options]
[pm: rebase to master branch of coreboot upstream]
[md: don't use FMAP to get MAC address if CONFIG_CHROMEOS not set]
Change-Id: I50fd5c02da154e424dfefbe2020f4ce7ef9a4f8f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/174555
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@chromium.org>
Tested-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: http://review.coreboot.org/5990
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Setting of `controller->reg_base` is of no use here, as it is never read
(in another function) later. Looks like this pattern originated from uhci.c
where it makes sense.
By removing the indirection through `reg_base` we also fix a possible
truncation to u32.
Change-Id: I5c99c5bf1f5b1d6c04bd84d87fd3e275fd7d0411
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6251
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Fix a possible null-pointer dereference (hopefully) before anyone runs
into this. Also don't switch ports to xHCI if initialization failed.
Change-Id: I5dbaeb435a98ead0b50d27fde13c9f1433ea3e81
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6245
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
As the controller structure is never fully cleared, this one wasn't
initialized for non-pci controllers (but checked for non-null later).
Change-Id: I852671c5f55650bdb6cd97f4ec74b1f95ee894c7
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6246
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Using void* for physical addresses leads to much casting and confuses
developers when to convert from physical to virtual addresses or
the other way around. When using plain integers for physical addresses
and pointers for virtual addresses things become much cleaner and we
won't ever end up dereferencing a physical address.
Change-Id: I24cd53b81c7863b6d14f0cbb4ce8937728b37c1c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6244
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
Like done in FILO, libpayload's console drivers might be initialized
before a relocation. So keep physical pointers in there which won't
break on relocation.
Change-Id: I52e5d9d26801a53fd6a5f3c7ee03f61d6941d736
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6247
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Remove a redundant phys_to_virt() that sneaked in the initialization of
PCI xHCI controllers. The use of casts from void* to u32 (and vice versa)
prompts for things going wrong here. That will be addressed in a later
commit.
Change-Id: Ibc71ed6ee7016529c0e3a51559aaec07aaaba315
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6243
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
SeaBIOS 1.7.4 was released in December 2013 [1] and, besides other
things, supports writing debug messages to CBMEM console.
The new SeaBIOS Kconfig option `DEBUG_COREBOOT` has to be added to the
SeaBIOS configuration file `.config` as otherwise the SeaBIOS build
from within coreboot (`PAYLOAD_SEABIOS`) is interrupted as it is
detected as a new option.
This option was already added and enabled in commit 7c1a49bc [1]
SeaBIOS: have coreboot pass the choice to run optionroms in parallel
so SeaBIOS messages are now written to the CBMEM console.
Successfully tested on the Asus M2V-MX SE.
[1] http://seabios.org/Releases
[2] http://review.coreboot.org/5443
Change-Id: I675a50532735b4921a664e4b24d98be17b9a1002
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5093
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Stylistic fix-up's.
Change-Id: I0cad7c860280d0d8dcb16d052846c72f690e2b65
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5731
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
|
|
With coreboot builds with serial console disabled, there is no
CB_TAG_SERIAL entry in coreboot tables. We ended up with
lib_sysinfo.serial == NULL and serial_hardware_is_present == 1.
Change-Id: I9a2fc0b55bf77769f2f2bfbb2b5476bee8083f7d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5723
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Payloads using Kconfig get confused by coreboot Kconfig
configuration in environment variables. Prune them.
Change-Id: I63da2af0a15dca35d70cd65b2f74a1564aab9483
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/5710
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
|
|
Change-Id: Ic1a9f2f01c26ee97cd7183fcf1755cb916f1b02e
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5704
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Alignment-agnostic encode/decode bytestream to/from little/big endian.
The le16enc(), le16dec(), le32enc(), le32dec() functions encode and
decode integers to/from byte strings on any alignment in big/little
endian format. See BYTEORDER(9).
Change-Id: I73a174b9c02c467bc60590c5cd894dac58b8683a
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5198
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Also strip down the config that's set since these are actually
SeaBIOS options, not FILO...
Change-Id: I5dbe6255996f9e115699ff2a83fb3450533520ee
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4647
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Introduce the tunable CONFIG_SEABIOS_THREAD_OPTIONROMS.
Change-Id: Ifd4d9fca7316eb739ff184e54bdc1cdb0262f0c6
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/5443
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
Decompartmentalise AHCI driver into two parts, ATA and ATAPI. Add a few
superficial comments while here. This also fixes a compiler warning.
Change-Id: Ia1fd545b39868a81cbc311f6ffc786f9f1f61415
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/4783
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5016
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
|
|
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>
Reviewed-on: http://review.coreboot.org/4942
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
This reverts commit 1287d1cc80c52ff2598f2bae235fc42d8456f44a.
This commit has the side-effect of making abuild fail, and as such is
reverted until a safe solution can be found.
Change-Id: Ib8cb78468c2922322b490e0b52c0bd24f3de7ef9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3269
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
If xcompile can't find out suitable GCC compiler for i386/armv7, it
will not set $CC_i386/$CC_armv7 variable. Makefile sets $CC variable
from xcompile, and will print strange error messages when executing
$CC program if $CC is empty.
Add checking to avoid this problem. If $CC is empty, also delete
invalid .xcompile file, so Make can recreate this file next time.
Change-Id: Ia8d481d76ca52f3351cb99f05779d06947161c5d
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3905
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Values get space-padded by curses and then enum search fails to match them.
Rtrim to compensate for curses.
Change-Id: Iecf095f21cfade9425eaa039b67625615eb80481
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4692
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins)
|
|
Without it payloads that need curses fail to build.
Change-Id: I4533238b547e4c2d9e0778fb7d314db35a9559df
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4689
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
It resulted in garbage in upper bytes of numeric options.
Change-Id: I5e5d8b770ed93c7e8a1756a5ce32444b6a045bac
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4691
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Code is using it...
Change-Id: I6894b45cbbf70c8e7ce37ce18d93cadf0ea9fbfc
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4649
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
|
|
Change-Id: I5b93e5321e470f19ad22ca2cfdb1ebf3b340b252
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4659
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
|
|
It builds all defconfigs/* and logs the results
in junit.xml, suitable for consumption by jenkins
Change-Id: I86c4022851b47820c95359b2ea9b735a77b1bc2c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4551
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Just clean out stuff we don't even have anymore
Change-Id: I2b4128c6496b4400d52d87680bedc3cece3d444c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4550
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
being a good citizen on the box, libpayload tries to return to EHCI
mode on shutdown, so a non-XHCI capable USB driver after it (eg. in
the OS) finds something to work with.
Change-Id: Id227d646e08a258b841c644263112f0815dd486c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4547
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|