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>
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>
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>
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>
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 1287d1cc80.
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>
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>
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>
This adds inline wrappers to read the L2 cache auxiliary control
register (L2ACTLR).
Signed-off-by: David Hendricks <dhendrix@chromium.org>
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>
Reviewed-on: http://review.coreboot.org/4437
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The cache.h header uses standard int types but doesn't include stdint.h itself.
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>
Reviewed-on: http://review.coreboot.org/4387
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Add a function to disable and clear the keyboard controller.
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.
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>
Reviewed-on: http://review.coreboot.org/4395
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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.
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>
Reviewed-on: http://review.coreboot.org/4439
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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.
To 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>
Reviewed-on: http://review.coreboot.org/4379
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- prints hex and ascii
- detects duplicate all zero lines
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>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Author: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/4393
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The ram_media.c file is being compiled, however the
global functions were not exposed through a header.
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>
Reviewed-on: http://review.coreboot.org/4194
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
Reviewed-on: http://review.coreboot.org/4346
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When dealing with DMA, we need a function to invalidate cache without corrupting
contents on main memory (clean).
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>
Reviewed-on: http://review.coreboot.org/4345
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The OP assigned by dcache_clean_by_mva must be handled in
dcache_op_mva.
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>
Reviewed-on: http://review.coreboot.org/4344
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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.
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>
Reviewed-on: http://review.coreboot.org/4320
Tested-by: build bot (Jenkins)
- Add -ffreestanding and -fomit-frame-pointer for all
platforms.
- Add ARMv7 specific flags to the armv7 Makefile
Change-Id: I71ab1b096e505940cc20c266bccd43917bcfad3a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56104
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4317
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
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>
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>
Reviewed-on: http://review.coreboot.org/4316
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This was used by Ron 13ys ago and was never used again
ever since.
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>
Reviewed-on: http://review.coreboot.org/4256
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Currently, the exception handling code on ARM in libpayload turns on alignment
checks as an easy way to generate an exception for testing purposes. It was
leaving it on which disabled unaligned accesses for other, unlreated code
running later. This change adjusts the code so the original value of the
alignment bit is restored after the test exception.
Built and booted into depthcharge on pit with an unaligned accesses added
after the call to exception_init in the depthcharge's main. Before this
change, the access caused an exception. After this change, the access
completed successfully.
Change-Id: If92cab3cc8eabca7c5b0560ce88a8796a27fe3b2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59372
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4255
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The address range to scan for the coreboot tables varies from machine to
machine based on the range memory occupies on the SOC being booted and on the
amount of memory installed on the machine. To make libpayload work on
different ARM systems with different needs, this change makes the region to
scan configurable. In the future, we might want to come up with a more
automatic mechanism like on x86, although there's less consistency on ARM as
far as what ranges are even memory in the first place.
Change-Id: Ib50efe25a6152171b0fbd0e324dbc5e89c527d6e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59242
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4254
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Otherwise the code would try to parse GPIOs when encountering
a mainboard entry in the coreboot table. This never caused any
problems because the mainboard entry is parsed before the GPIO
entry.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I1443bda8585a990a39115743d48304ec4b54bccb
Reviewed-on: https://gerrit.chromium.org/gerrit/59292
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4252
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This was never completed / working and we have the working
ARMv7 port for an architecture template, so get rid of this
dead code.
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>
Reviewed-on: http://review.coreboot.org/4235
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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.
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>
Reviewed-on: http://review.coreboot.org/4226
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There is currently a hard-coded 30 sec delay in the mass storage
driver while waiting for each device to become ready. However, mass
storage card readers that are empty return an error code on the
TEST UNIT READY command. A REQUEST SENSE command then needs to be
issued and interrogate the data to determine if no media is present.
If no media determination is found to be true the USB device is no
longer considered a candidate to be a disk.
This code does lead to the fact that the media card reader needs to be
populated at enumeration time. I suspect this is not an issue as it
appears the storage stack in libpayload can't handle removable media
coming online later.
Booted recovery and dev modes. Noted that removable mass storage
devices with no media were ignored without any boot delay.
Change-Id: Ida7a45614d97c6e6fbfc9bb099765aad4df550fd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57828
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4225
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The architecture name for our ARM port is armv7, not arm.
Hence, none of those flags were ever actually used.
Fix the architecture name and remove the flags, they should
not be set in xcompile, but in the Makefile, like in coreboot.
Change-Id: Id9c5db7ebceafddb58a1ce1988417f09c074ba6c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56084
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4179
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Restructure USB stack to not depend on PCI, and
make PCI stub available on x86, but provide fixed
BARs for ARM (Exynos 5)
Change-Id: Iee7c8b134c22b661a9a515e24943470c9dbadd1f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49970
Reviewed-on: http://review.coreboot.org/4175
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Two structures in the USB EHCI stack were pointing
to hardware but not marked attribute((packed)) hence
leaving it to GCC to correctly align the data structures.
Next, the number of reserved bytes in hc_op_t was wrong
(but implicitly aligned to the correct values on x86)
It seems this worked fine on x86, but on ARM it was doing
the wrong thing.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I94bed4850ded7d3f7bbc7ff3079c103c6054c22d
Reviewed-on: https://gerrit.chromium.org/gerrit/55555
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4174
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Gabe Black