Libpayload libc requires timer clock frequency to be at least 1MHz.
Ipq8064 code presently provides a single option of 32kHz. Pretend to
be running at 1 MHz without additional accuracy.
This is a hack which will be reverted as soon as the SOC is configured
to supply a faster running clock.
BUG=chrome-os-partner:27784, chrome-os-partner:28880
TEST=with other changes depthcharge boots to the CLI console
Change-Id: I80ec6652bc5693a549668cd6e824e9cf5c26b182
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201342
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The earlier compilation warning fix (7e4aa17) incorrectly assumed that
selfboot() is a function defined in the cbfs driver. This is a
commonly available function, it should not come from cbfs.h.
BUG=none
TEST=the following command succeeds:
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload || break
done
Change-Id: I3ef49d849168ad9dc24589cbd9ce7382052345bd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201386
This is still using the 32kHz timer coreboot uses. A finer granularity
timer implementation for 806x is in the works.
BUG=chrome-os-partner:27784,chrome-os-partner:28880
TEST=none yet.
Change-Id: Iae206749000d45040090df48199c8d86d76bbae5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198021
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
As the USB driver for storm hardware is not yet available, do not
define it in llibpayload.
BUG=chrome-os-partner:27784
TEST=not much testing yet, just compilation/building
Change-Id: I6aea72cda33b61deb0a7dc69f8295f8c3f61406b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200827
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The -z "${V}" sure must have meant to be -n "${V}", but come to think
of it, this check is not necessary, as the following check will
succeed if and only if V is set to 1.
BUG=none
TEST=verified that adding V=1 to the environment causes the lpgcc
debug statements to show up in the output.
Change-Id: I1eb43ef49aeb4f16aef4fbee3a1037e853f9b40f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200501
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Make sure the build breaks in case of warnings.
BUG=none
TEST=run the following command with the previous patch removed and
then restored:
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload
done
all builds succeed with the restored patch and fail when a
compilation warning is thrown.
Change-Id: I9bdcd8938f59913e4ba86df5e4921b3f821ef920
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200110
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Seems that the 'if (cursor_enabled)' check in
video_console_fixup_cursor() that was removed in commit 1f880bca0 really
meant to check for 'if (console)'. Looks like the whole video console
driver is built extra robust to not fail no matter how screwed up the
console is, so let's add this missing check here as well. Also fixed up
a few other missing 'if (!console)' checks while I'm at it.
However, what payloads should really be doing is check the return value
of video_(console_)init() and not call the other video functions if that
failed. This also adapts video_console_init() to correctly pass through
the return value for that purpose (something that seems to have been
overlooked in the dd9e4e58 refactoring).
BUG=chrome-os-partner:28494
TEST=None. I don't know what Dave did to trigger this in the first
place, but it's pretty straight-forward.
Change-Id: I1b9f09d49dc70dacf20621b19e081c754d4814f7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200688
Reviewed-by: David Hendricks <dhendrix@chromium.org>
When emerging libpayload a warning is generated about selfboot() being
defined without a prior prototype.
Addinf cbfs.h when CBFS use if compiled fixes the warning.
BUG=none
TEST=run the following
$ for b in rambi storm nyan_big; do
cros_workon-$b start libpayload
emerge-$b libpayload
done
verify that there is no compilation warnings thrown any more
Change-Id: Ic9cb5571f708bb006a0d477e451fd1f3b3eb833f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200099
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
ARM processors save the PC value in the Link Register when they handle
and exception, but they store it with an added offset (depending on the
exception type). In order to make crashes easier to read and correctly
support more complicated handlers in libpayload, this patch adjusts the
saved PC value on exception entry to correct for that offset.
(Note: The value that we now store is what ARM calls the "preferred
return address". For most exceptions this is the faulting instruction,
but for software interrupts (SWI) it is the instruction after that. This
is the way most programs like GDB expect the stored PC address to work,
so let's leave it at that.)
Numbers taken from the Architecture Reference Manual at the end of
section B1.8.3.
BRANCH=none
BUG=chrome-os-partner:18390
TEST=Provoked a data abort and an undefined instruction in both coreboot
and depthcharge, confirmed that the PC address was spot on.
Change-Id: Ia958a7edfcd4aa5e04c20148140a6148586935ba
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199844
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The video console runs a video_console_fixup_cursor() function after
every printed character to make sure the cursor is still in the output
window and avoid overflows. For some crazy reason, this function does
not run when cursor_enabled is false... however, that variable is only
about cursor *visibility*, and it's imperative that we still do proper
bounds checking for our output even if the cursor itself doesn't get
displayed (otherwise we can end up overwriting malloc cookies that cause
a panic on the next free() and other fun things like that).
In fact, there seems to be no reason at all to even keep track of the
cursor visibility state in the generic video console framework (the
specific backends already do it, too), so let's remove that code
entirely. Also set the default cursor visibilty in the corebootfb
backend to 0 since that's consistent with what the other backends do.
BUG=None
TEST=Turn on video console on Big, generate enough output to make it
scroll, make sure it does not crash.
Change-Id: I1201a5bccb4711b6ecfc4cf47a8ace16331501b4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196323
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The calling convention of payload entry function is different by architecture.
For example, X86 takes no arguments and ARM needs first param to be a
cb_header_ptr*.
To help payloads load and execute other payloads easily and correctly, we should
provide the selfboot() function in libpayload, using same prototype as defined
in Coreboot environment.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Change-Id: I8f1cb2c0df788794b2f6f7f5500a3910328a4f84
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199503
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
The libpayload build environment has been changed slightly and here are the
minimal changes to compile ubootcli under ebuild system:
- Allow overriding LIBPAYLOAD_DIR.
- Include only single libpayload.a.
- Revise build flags.
- Increase heap/stack size so video console init is fine.
- Remove abort() which may be defined in libpayload.
- Change weak link default function to non-inline (so it will be provided).
BUG=none
TEST=With a crafted ubootcli.ebuild:
emerge-nyan ubootcli # arm pass
emerge-rambi ubootcli # x86 pass
Change-Id: Icd3bd9f29a3682cd1a2c148a2a57ce44efe33664
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199476
Reviewed-by: Julius Werner <jwerner@chromium.org>
Some EABI conformant toolchains like GCC need additional functions like raise.
To prevent payloads adding arch-specific implementations everywhere, we should
provide the default version in libpayload.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Change-Id: Id1e3c29590aa5881aefd944a7551949ce9a47b8f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199686
This is a placeholder for a real libpayload config, it is fairly close
to the real one and will allow building chrome os image for storm in
the meanwhile.
BUG=chrome-os-partner:27784
TEST=manual
. with this and some other patches 'emerge-storm libpayload
depthcharge' does not fail anymore.
Change-Id: Ie1a96310a7b329fac9d869cfe83005ea20c7e235
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198928
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Fix pointer related casts since this can create a problem for 64-bit systems.
BUG=None
BRANCH=None
TEST=Compiled successfully for link, nyan using emerge-* libpayload
Change-Id: I4cbd2d9f1efaaac87c3eba69204337fd6893ed66
Reviewed-on: https://chromium-review.googlesource.com/199564
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
I always thought the support for multiple logical SCSI units in the USB
mass storage class was a dead feature. Turns out that it's actually used
by SD card readers that provide multiple slots (e.g. one regular sized
and one micro-SD). Implementing perfect support for that would require a
major redesign of the whole MSC stack, since the one device -> one disk
assumption is deeply embedded in our data structures.
Instead, this patch implements a poor man's LUN support that will just
cycle through all available LUNs (in multiple calls to usb_msc_poll())
until it finds a connected device. This should be reasonable enough to
allow these card readers to be usable while only requiring superficial
changes.
Also removes the unused 'protocol' attribute of usb_msc_inst_t.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=Alternatively plug an SD or micro-SD card (or both) into my card
reader, confirm that one of them is correctly detected at all times.
Change-Id: I3df4ca88afe2dcf7928b823aa2a73c2b0f599cf2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198101
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
So I was debugging this faulty USB SD card reader that would just fail
it's REQUEST SENSE response for some reason (sending the CSW immediately
without the data), cursing those damn device vendors for building
non-compliant crap like I always do... when I noticed that we do not
actually set the Allocation Length field in our REQUEST SENSE command
block at all! We set a length in the CBW, but the SCSI command still has
its own length field and the SCSI spec specifically says that the device
has to return the exact amount of bytes listed there (even if it's 0). I
don't know what's more suprising: that we had such a blatant bug in this
stack for so long, or that this card reader is really the first device
to actually be spec compliant in that regard.
This patch fixes the bug and changes the command block structures to be
a little easier to read (why that field was called 'lun' before is
beyond me... LUN is a transport level thing and should never appear in
the command block at all, for any command). It also fixes a memcpy() in
wrap_cbw() to avoid a read buffer overflow that might expose stack frame
data to the device.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=The card reader works now (for it's first LUN at least).
Change-Id: I86fdcae2ea4d2e2939e3676d31d8b6a4e797873b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198100
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We recently changed the USB stack to detach devices aggressively that we
don't intend to use. This alone is not really a problem, but it
exarcerbates the fact that our device detachment itself is not very
good. We destroy any local info about the device, but we don't properly
disable the offending port. The device keeps thinking that it's active,
and if we later try to reuse that device address for another device
things become confused.
The real fix would be to properly disable all ports that we don't intend
to use. Unfortunately, this isn't really possible in our current
device/hub polymorphism structure, and I don't want to hack a new
disable_port() callback into usbdev_t that really doesn't belong there.
We will only be able to fix this cleanly after we ported all root hubs
to the generic_hub interface.
Until then, an easy workaround is to just avoid reusing addresses as
long as possible. This is firmware, so the chance that we'll ever run
through 127 devices is really small in practice. Even if we ever fix the
underlying issue, it's probably a smart precaution to keep.
BRANCH=nyan,rambi
BUG=chrome-os-partner:28328
TEST=Boot from a hub that has an "unknown" device in an earlier port
than the stick you want to boot from, make sure you can still boot.
Change-Id: I9b522dd8cbcd441e8c3b8781fcecd2effa0f23ee
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197420
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The console output driver framework in libpayload is currently built on
the putchar primitive, meaning that every driver's function gets called
one character at a time. This becomes an issue when we add drivers that
could output multiple characters at a time, but have a high constant
overhead per invocation (such as the planned GDB stub, which needs to
wrap a special frame around output strings and wait for an
acknowledgement from the server).
This patch adds a new 'write' function pointer to the
console_output_driver structure as an alternative to 'putchar'. Output
drivers need to provide at least one of the two ('write' is preferred if
available). The CBMEM console driver is ported as a proof of concept
(since it's our most performace-critical driver and should in theory
benefit the most from less function pointer invocations, although it's
probably still negligible compared to the big sprawling mess that is
printf()).
Even with this fix, the problem remains that printf() was written with
the putchar primitive in mind. Even though normal text already contains
an optimization to allow multiple characters at a time, almost all
formatting directives cause their output (including things like
padding whitespace) to be putchar()ed one character at a time.
Therefore, this patch reworks parts of the output code (especially
number printing) to all but remove that inefficiency (directives still
invoke an extra write() call, but at least not one per character). Since
I'm touching printf() core code anyway, I also tried to salvage what I
could from that weird, broken "return negative on error" code path (not
that any of our current output drivers can trigger it anyway).
A final consequence of this patch is that the responsibility to prepend
line feeds with carriage returns is moved into the output driver
implementations. Doing this only makes sense for drivers with explicit
cursor position control (i.e. serial or video), and things like the
CBMEM console that appears like a normal file to the system really have
no business containing carriage returns (we don't want people to
accidentally associate us with Windows, now, do we?).
BUG=chrome-os-partner:18390
TEST=Made sure video and CBMEM console still look good, tried printf()
with as many weird edge-case strings as I could find and compared serial
output as well as sprintf() return value.
Change-Id: Ie05ae489332a0103461620f5348774b6d4afd91a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196384
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
If a payload decides not to use a USB device then the device can be
detached. This prevents the device from interfering with normal
operation on some platforms. Also, it aligns the behavior of
usb_generic_init with class-specific init functions such as
usb_msc_init, which will detach unsupported devices.
BUG=None
TEST=Manual on Squawks. Test recovery boot w/ USB 2.0 media, verify
that media boots and no babble error is encountered.
BRANCH=rambi
Change-Id: I8fb30951d273e4144cda214a30a2e86df90f2c1c
Original-Change-Id: Iee522344558749603defb2966e18765aa195dae2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195401
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some kconfig options have changed but the configs haven't been updated. When
make oldconfig is run from the ebuild through emake, that doesn't seem to
causea problem for whatever reason. When run manually, however, kconfig stops
to ask for each config it doesn't have a value for. This change updates the
configs to correct that issue.
BUG=None
TEST=Ran make oldconfig manually for all boards. Built and booted on big.
BRANCH=None
Change-Id: I138f8ad9239a3834d28dc492e0a90a94442b2af1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194908
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
These drivers are needed right away and never really fit into depthcharge's
driver model anyway.
CQ-DEPEND=CL:194064
BUG=None
TEST=Built and booted nyan, link, and peach_pit and verified that timer values
in cbmem were reasonable. Built for nyan_big, nyan_blaze and daisy.
BRANCH=None
Change-Id: Ia7953cfece57524262a6c7d6537082af7a00f4d6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194058
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
These drivers need to be ready right away and never really fit into the
depthcharge driver model anyway.
CQ-DEPEND=CL:194063
BUG=None
TEST=Built and booted on nyan and peach_pit. Built for nyan_big, nyan_blaze,
and daisy.
BRANCH=None
Change-Id: I9570dee53c57d42ef4cd956f66a878ce39a2dc20
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194057
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
I don't even know why these were off (at least the XHCI one)... well,
now they aren't. As far as coreboot is concerned, Snow is just a test
platform anyway, and these are useful to have.
BUG=None
TEST=It works.
Change-Id: Ibef65e8be6cf752276ffc87df6dda04869dd97cd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193733
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
We've recently fixed a problem where an external hard drive would choke
due to one too many CLEAR_FEATURE(HALT) commands in the XHCI stack with
"libpayload: usb: xhci: Fix STALL endpoint handling". Clearing stall
conditions from within the transfer function is wrong in general... this
is really something that is host controller agnostic and should be left
to the higher-level driver to decide. The mass storage driver (the only
one that should really encounter stalls right now) already contains the
proper amount of clear_stall() calls... any more than that is redundant
and as we found out potentially dangerous.
This patch removes automatic clear stalls from UHCI and OHCI drivers as
well to make things consistent between host controllers.
BUG=chromium:192866
TEST=None. I could borrow the original hard drive from Shawn and compile
a Snow to only use the OHCI driver to reproduce/verify this, but alas, I
am lazy (and it's really not that important).
Change-Id: Ie1e4d4d2d70fa4abf8b4dabd33b10d6d4012048a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193732
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This patch combines a few minor fixes and refactoring to the various
host controller and root hub drivers to ensure they all do the right
thing on a call to usb_exit(). It puts a usb_detach_device(0) call
into detach_controller() so that the HCD doesn't need to remember to
tear down the root hub itself, and makes sure all root hubs properly
detach the subtree of devices connected to their ports first (as
generic_hub and by extension XHCI had already been doing).
It also fixes up some missing free() calls and replaces most 'ptr =
malloc(); if (!ptr) fatal()' idioms with the new x(z)alloc().
BUG=chromium:343415
TEST=Tested EHCI on Big and OHCI, EHCI, and XHCI on Snow. Could not test
UHCI (unless anyone volunteers to port coreboot to a ZGB? ;) ), but the
changes are really tame.
Change-Id: I6eca51ff2685d0946fe4267ad7d3ec48ad7fc510
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193731
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This patch enables the OHCI driver to use DMA memory, which is necessary
for ARM systems where DMA devices are not cache coherent. I really only
need this to test some later OHCI changes, but it was easy enough...
copied almost verbatim from ehci.c.
BUG=chromium:343415
TEST=Works on Snow.
Change-Id: Ia717eef28340bd6182a6782e83bfdd0693cf0db1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193730
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Turns out that when you clear 28 bits starting with bit 3, you leave bit
31 standing. Ooops...
This shouldn't really matter since that bit is reserved/SBZ in CLIDR
anyway, but it's still nice to fix it. This whole thing should really be
an AND for clarity anyway in my opinion.
Bug found in upstream NetBSD (who would've thought...).
BUG=None
TEST=Still boots.
Change-Id: Ic826e82d58fd1ce984971afea3dfa9296f746d9f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193300
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
This patch adds the 10ms TRSTRCY delay between a reset and the following
Set Address command that is required by the USB 2.0 specification to the
EHCI root hub driver. The generic_hub driver that's used for XHCI and
external hubs already included this delay. This is such a glaring
violation of the spec that I'm really amazed how many USB 2.0 devices
we tested before seemed perfectly fine with responding to a Set Address
within 2 microframes of the reset...
It also increases the port reset hold delay by one millisecond to avoid
an ugly race condition on Tegra SoCs: they decided to time the 50ms
themselves instead of relying on the CPU to do it (fair enough), and to
automatically transition Port Reset to 0 and Port Enable to 1 after that
(bad idea). If the CPU's read-modify-write to clear Port Reset races
exactly with the host controller setting Port Enable, we may end up
clearing the bit again and going into the companion controller handoff
path later on. The added millisecond shouldn't cause any problems for
other host controllers and is not a big deal compared to other delays in
this code path.
BUG=chrome-os-partner:26749
TEST=Run several dozen reboot loops with The USB Stick of Death (TM) (a
blue Patriot XT 13fe:5200 with bcdDevice = 1.00), make sure it always
gets detected correctly.
Change-Id: Idd3329ae6d7e5e1c07a84a5475549b3459836b31
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189872
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Jim Lin <jilin@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
- Remove the call to clear_stall in xhci_reset_endpoint because we will
call clear_stall from the mass-storage driver.
- Remove the xhci_reset_endpoint call from xhci_bulk on STALL since we
will reset on the next transfer anyway.
- Remove the clear_halt parameter from xhci_bulk since it's now unused.
BUG=chrome-os-partner:26687
TEST=Manual on Rambi w/ USB_DEBUG enabled in libpayload. Boot with SanDisk
Extreme USB 3.0 drive in USB 3.0 port, verify that after STALL is
encountered reset succeeds and device is initialized without extra
delay.
BRANCH=Rambi
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I852b87621861109e596ec24b78a8f036d796ff14
Reviewed-on: https://chromium-review.googlesource.com/192866
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=None
TEST=emerge-nyan_blaze chromeos-coreboot-nyan builds OK
Change-Id: I707a5efdbdbc573ef73cd366bb7c90fa7c4e74c2
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/190722
Reviewed-by: Julius Werner <jwerner@chromium.org>
This creates a new PL011 config variable which avoids the
infinite busy wait on serial_putchar() because the register
mapping is not compatible with current implementation.
BUG=None
BRANCH=none
TEST=printf() works on the PL011 based ARMv8 foundation model
Change-Id: I9feda35a50a3488fc504d1561444161e0889deda
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187020
Reviewed-by: David Hendricks <dhendrix@chromium.org>
If a port is connected before and after an xhci controller reset, the
PORTSC CSC bit may not be asserted. Add an additional check in
xhci_rh_port_status_changed for the PRC bit so we can correctly handle
ports in such a state.
BUG=chrome-os-partner:24090
TEST=Manual on Rambi:
- Boot Chromium OS from USB 3.0 drive
- Issue 'reboot' on command line
- Boot from USB 3.0 drive again successfully
Also --
- Boot Chromium OS from USB 3.0 drive
- Issue 'reboot' on command line
- Boot Chromium OS from eMMC
- Issue 'reboot' on command line
- Boot from USB 3.0 drive again successfully
Also, verify that USB ports continue to function correctly, and USB 3.0
device is always detected in Chromium OS as a superspeed device.
BRANCH=Rambi
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I2d623aae647ab13711badd7211ab467afdc69548
Reviewed-on: https://chromium-review.googlesource.com/189394
Reviewed-by: Julius Werner <jwerner@chromium.org>
The generic roothub reset port function is overly broad and does some
things which may be undesirable, such as issuing multiple resets to a
port if the reset is deemed to have finished too quickly. Remove the
generic function and replace it with a controller-specific function,
currently only implemented for xhci.
BUG=chrome-os-partner:24090
TEST=Manual on Rambi. Verify that USB 3.0 media is found + bootable on
cold boot.
BRANCH=Rambi.
Change-Id: Id46f73ea3341d4d01d2b517c6bf687402022d272
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189495
Reviewed-by: Julius Werner <jwerner@chromium.org>
TEST=Booted nyan in normal and recovery mode. Created a map, filled it with some
chars, then verified they can be read from the pointer returned.
BUG=chrome-os-partner:25587
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Id1f1be4f6d2d5734d87bf3452d4806d0fe3fda88
Reviewed-on: https://chromium-review.googlesource.com/188894
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Use the SPSR to extract and inject CPSR values when an exception happens and
pass that information to exception hooks.
The register structure GDB expects when using its remote protocol has a spot
for the CPSR.
BUG=None
TEST=Built and booted on link, nyan.
BRANCH=None
Change-Id: Id950fb09d72fb0f81e4eef2489c0849ce5dd8aca
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180253
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Pass -ggdb3 to the compiler when building libpayload, -ggdb so that it uses
"the most expressive format available", and 3 so that the debugging level is
set to 3, the highest value currently supported. The debugging information can
be stripped by the payload consuming the library, and will definitely be
stripped by cbfstool when installing that payload into an image.
BUG=None
TEST=Built and booted on link, nyan.
BRANCH=None
Change-Id: Ifd6c4a928fbb0b9fa9b3b2e0ea298abff31baf3b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180252
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
To support a GDB stub, it will be necessary to trap various exceptions which
will be used to implement breakpoints, single stepping, etc.
BUG=None
TEST=Built and booted on Link with hooks installed and saw that they
triggered when exceptions occurred. Built and booted on nyan.
BRANCH=None
Change-Id: Iab659365864a3055159a50b8f6e5c44290d3ba2b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179602
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
To find the coreboot tables, the payload has historically searched for their
signature in a predefined region of memory. This is a little clumsy on x86,
but it works because you can assume certain regions are RAM. Also, there are
areas which are set aside for the firmware by convention. On x86 there's a
forwarding entry which goes in one of those fairly small conventional areas
and which points to the CBMEM area at the end of memory.
On ARM there aren't areas like that, so we've left out the forwarding entry and
gone directly to CBMEM. RAM may not start at the beginning of the address space
or go to its end, and that means there isn't really anywhere fixed you can put
the coreboot tables. That's meant that libpayload has to be configured on a
per board basis to know where to look for CBMEM.
Now that we have boards that don't have fixed amounts of memory, the location
of the end of RAM isn't fixed even on a per board level which means even that
workaround will no longer cut it.
This change makes coreboot pass the location of the coreboot tables to
libpayload using r0, the first argument register. That means we'll be able to
find them no matter where CBMEM is, and we can get rid of the per board search
ranges.
We can extend this mechanism to x86 as well, but there may be more
complications and it's less necessary there. It would be a good thing to do
eventually though.
BUG=None
TEST=Built and booted on nyan. Changed the size of memory and saw that the
payload could still find the coreboot tables where before it couldn't. Built
for pit, snow, and big.
BRANCH=None
Change-Id: I7218afd999da1662b0db8172fd8125670ceac471
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/185572
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
This patch changes the ENTRY() macro in asm.h to create a new section
for every assembler function, thus providing dcache_clean/invalidate_all
and friends with the same --gc-sections goodness that our C functions
have. This requires a few minor changes of moving around data (to make
sure it ends up in the right section) and changing some libgcc functions
(which apparently need to have two names?), but nothing serious.
(You may note that some of our assembly functions have data, sometimes
even writable, within the same .text section. This has been this way
before and I'm not looking to change it for now, although it's not
totally clean. Since we don't enforce read-only sections through paging,
it doesn't really hurt.)
BUG=None
TEST=Nyan and Snow still boot. Confirm dcache_invalidate_all is not
output into any binary anymore since no one actually uses it.
Change-Id: I247b29d6173ba516c8dff59126c93b66f7dc4b8d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183891
This patch changes several cache-related pieces to be cleaner, faster or
more correct. The largest point is removing the old
arm_invalidate_caches() function and surrounding bootblock code to
initialize SCTLR and replace it with an all-assembly function that takes
care of cache and SCTLR initialization to bring the system to a known
state. It runs without stack and before coreboot makes any write
accesses to be as compatible as possible with whatever state the system
was left in by preceeding code. This also finally fixes the dreaded
icache bug that wasted hundreds of milliseconds during boot.
CQ-DEPEND=CL:183877
BUG=None
TEST=Snow and Nyan still boot. Time between entering romstage main() and
the configure_l2ctlr() call on Nyan drops from 390ms to 0.3ms. Even with
icache turned on the old implementation took 7.8ms since it cleared the
cache multiple times with a slow algorithm.
Change-Id: I7bb4995af8184f6383f8e3b1b870b0662bde8bd4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183890
This patch fixes the remaining few bugs in our shiny new cache iteration
by set/way/level algorithm to actually make it work: It makes it start
from cache level 0 (previously it would always start at LoC and be
"done" instantly), fixes up the two shifts that isolate the set bits at
the end (which didn't seem to account for the fact that the first shift
affects the second), and throws an S bit on that last shift so that it
actually affects the conditionals after it.
In addition, also moves the next_level block to the top so that we can
share (and thus eliminate) some code at initialization, and turns the
whole thing into a thrice-instantiated macro to create functions that
fit our existing interface.
BUG=None
TEST=Ran with cache_test code (see separate CL) and closely examined the
resulting output. Made sure results look as expected (iterating through
all sets (inner) and ways (outer) for L1 and then L2 cache, extracting
the right numbers from CLIDR and CCSIDR, not touching anything twice).
Time for a single dcache_clean_invalidate_all() on Nyan drops from 3.7ms
to 0.3ms.
Change-Id: I1338a589cbb37d74ea6e7a3d4f67ff827e24edbe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183879
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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
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>
This code should have been BSD licensed but was checked in with a GPL license.
BUG=chrome-os-partner:24957
TEST=Built libpayload for nyan.
BRANCH=None
Change-Id: Ic939fd21710c1d52b57b84d3038ec0c0ce4443cd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/182344
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
This patch adds another cache invalidation stub to the x86 arch to
make it usable in common code. This whole stuff should probably be
redesigned anyway but I just want to get it working and unblock my CL
for now... more cleanups coming later.
BUG=None
TEST=Builds on Falco.
Change-Id: I2e8bdd8aa0e6723209384c24042f053f2e993fe6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182534
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This patch switches every last part of Coreboot on ARM over to Thumb
mode: libpayload, the internal libgcc, and assorted assembly files. In
combination with the respective depthcharge patch, this will switch to
Thumb mode right after the entry point of the bootblock and not switch
back to ARM until the final assembly stub that jumps to the kernel.
The required changes to make this work include some new headers and
Makefile flags to handle assembly files (using the unified syntax and
the same helper macros as Linux), modifying our custom-written libgcc
code for 64-bit division to support Thumb (removing some stale old files
that were never really used for clarity), and flipping the general
CFLAGS to Thumb (some more cleanup there as well while I'm at it).
BUG=None
TEST=Snow and Nyan still boot.
Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182212
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The memcpy/memset/memmove assembly implementations have been taken from
U-Boot, which originally got them from Linux. I turns out that they are
actually not that bad, but they could use an update. This patch pulls in
the current Linux upstream versions of those files, removing some old
U-Boot cruft such as checking whether the two pointers in a memcpy() are
equal (really now?) or side-stepping the R8 register because it was used
for special purposes. It also returns to the good old Linux
ENTRY/ENDPROC macros since we have them now anyway, and straightens out
the W() macro in preparation for unified thumb support.
BUG=None
TEST=Snow still boots.
Change-Id: I138af269b423bef0a237759ac29f1ee58ca206a0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182179
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
libgcc/macros.h contains some useful assembly macros that are common in
Linux kernel code and facilitate things such as unified ARM/THUMB
assembly. This patch moves it to a more general place where it can be
used by other code as well.
BUG=None
TEST=Snow still boots.
Change-Id: If68e8930aaafa706c54cf9a156fac826b31bb193
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182178
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Some files were accidentally made GPL when they were added to libpayload. This
change changes them over to a BSD license to be in line with the intended
license of libpayload.
BUG=chrome-os-partner:24957
TEST=Built libpayload for nyan.
BRANCH=None
Change-Id: Ia95ac4951b173dcb93cb489705680e7313df3c92
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/182202
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
