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>
In the process of getting rid of compiler includes during in coreboot
and libpayload, we defined size_t and ssize_t ourselves, using a GCC
macro for size_t: __SIZE_TYPE__. Unfortunately, there is no
__SSIZE_TYPE__, so we temporarily redefine unsigned to signed to make
__SIZE_TYPE__ __SSIZE_TYPE__.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I4cf4eb0fdaa4db64277c2585fe2c1bdc0acdf02b
Reviewed-on: https://gerrit.chromium.org/gerrit/49947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4156
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I3235f42c7faaf28a63455162ea55dc1a6bebd1f5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Hung-Te Lin <hungte@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48290
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4128
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This imports the cache/MMU code from coreboot as of 1877cee.
Change-Id: I97ec8b9640921a94a4b27d89e4ae6185e9f96f18
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48288
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4134
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Not all platforms !x86 are big endian, hence actually look
at the CONFIG_LITTLE_ENDIAN flag instead of CONFIG_ARCH_X86.
Change-Id: Ibbd8f48b377a1121dd1e045834a94a2d67eda2ab
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56066
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4236
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Since a long time GRUB 2 is a viable payload alternative to SeaBIOS and
FILO. So make it easy for coreboot users to use GRUB 2 as a payload by
integrating it into coreboot’s build system, so it can be selected in
Kconfig.
As the last GRUB 2 release 2.00 is too old and has several bugs when
used as a coreboot payload only allow to build GRUB 2 master until a new
GRUB release is done. The downside is, that accidental breakage in
GRUB’s upstream does not affect coreboot users.
Currently the GRUB 2 payload is built with the default modules which
results in an uncompressed size of around 730 kB. Compressed it has a
size of 340 kB, so it should be useable with 512 kB flash ROMs.
Tested with QEMU.
Change-Id: Ie75d5a2cb230390cd5a063d5f6a5d5e3fab6b354
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4058
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It is for crossgcc.
Change-Id: Ia1d676adfea340b6b80858215459491c9338d614
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3955
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
On Intel's Panther Point the xHCI ports are shared with an EHCI
controller. Our xHCI driver switches them to xHCI, naturally. But
we forgot to switch them back on shutdown, which left them
unusable by a non-xHCI aware operating system.
Change-Id: I70ef08655a603b42ee939935d50cf77ea97878a3
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3791
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
keyboard_init attempts to read the existing mode register, set the
'XLATE' bit, and write it back. The implementation is buggy because the
keyboard may be active at the time we read the mode, and we can
misinterpret scancode data as the reply to our command. It leads to
problems where the KB gets disabled in firmware.
In fact, setting the 'XLATE' bit is completely unnecessary, even if we
desire QEMU keyboard support. We already set this bit when we initialize
the keyboard in pc_keyboard_init. Basically, this code does nothing
(or worse), so just remove it.
Change-Id: Iab23f03fa8bced74842c33a7d263de5f449bb983
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/3883
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For libpayload clients with larger memory needs (eg. FILO with integrated
flashrom) the current configuration isn't enough.
Change-Id: Ic82d6477c53da62a1325400f2e596d7d557d5d1e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3889
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Change-Id: Ie69ceb343494b7dd309847b7d606cb47925f68b6
Reviewed-on: http://review.coreboot.org/3888
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Prettier in real-world payloads (ie. FILO)
Change-Id: I9ed968fe527c5d46090e707e2d89b7406a43662e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3887
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
flashrom has started to use revision IDs to distinguish AMD chipsets
and fails (even more) to build with libpayload since then because
PCI_REVISION_ID is undefined in libpayload's pci header.
Change-Id: If7440a48c1005a4ba4fc09303f47cdfa9f408ad1
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3884
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
For reasons explained in a previous CL, it might be necessary to "load" a file
from CBFS in place. The loading code in CBFS was, however, zeroing the area of
memory the stage was about to be loaded into. When the CBFS data is located
elsewhere this works fine, but when it isn't you end up clobbering the data
you're trying to load. Also, there's no reason to zero memory we're about to
load something into or have just loaded something into. This change makes it
so that we only zero out the portion of the memory between what was
loaded/decompressed and the final size of the stage in memory.
Change-Id: If34df16bd74b2969583e11ef6a26eb4065842f57
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3579
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Instead of returning 0 on success and -1 on error, return the decompressed
size of the data on success and 0 on error. The decompressed size is useful
information to have that was being thrown away in that function.
Change-Id: If787201aa61456b1e47feaf3a0071c753fa299a3
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3578
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The memset and memcpy functions are assembled as ARM code, likely because
that's the default of the assembler. Without special annotation, the assembler
and linker don't know that those symbols are functions which need special
handling so that ARM/thumb issues are handled properly. This change adds that
annotation which gets those functions working in Coreboot which is compiled as
thumb. Libpayload and depthcharge are compiled as ARM so they don't *need* the
annotation since it just works out in ARM mode, but it's the safe thing to do
in case we change that in the future.
We should explicitly select ARM vs. thumb when assembling assembly files to be
consistent across builds and toolchains.
Change-Id: I814b137064cf46ae9e2744ff6c223b695dc1ef01
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3672
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The counted delay of 1ms was shorter than the time usb_poll() took
(~30ms observed). So with a given timeout of 100ms it actually took 3s.
We can lower the problem if we delay 10ms per loop iteration.
Change-Id: I6e084bdd05332111cc8adcd13493a5dfb4bc8b28
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3533
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Teach lpgcc to look in the in-coreboot tree directory structure, too.
Change-Id: I3809456d072ce2f91542b0edb3fd39f536298cc2
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3530
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We can't read the drives signature before it's ready, i.e. spun up.
So set the timeout to the standard 30s. Also put a notice on the
console, so the user knows why the signature reading failed.
Change-Id: I2148258f9b0eb950b71544dafd95776ae70afac8
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3493
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A timeout while waiting for a device' signature has shown that our
error path wasn't correct. The shutdown of the ports command engine
always timed out. Fix that by waiting for FR (FIS Receive Running)
to be cleared independently from CR (Command List Running) and after
clearing FRE (FIS Receive Enable).
Change-Id: I50edf426ef0241424456f1489a7fc86a2cfc5753
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3494
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Well, it turned out to be more as some gaps ;)
but we finally have xHCI running. It's well tested against a QM77 Ivy
Bridge board.
We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not
advertised and USB 3 devices will just work at HighSpeed.
There are still some bit fields in xhci_private.h, so this might need
little more work to run on ARM.
Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3452
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is mostly a rewrite, don't even try to read a diff.
Tested with an internal rate matching hub on a QM77 board and three hubs
integrated into DELL monitors.
Change-Id: Ib12fa2aa90af4e0f37143d2ed92c4a1705b6d774
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3451
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current drivers for external usb hubs and root hubs all follow
the same pattern. Before adding another one with 90% of the same code,
extract the common parts and rewrite them with a simple interface.
This also adds debouncing of new attachments. Current drivers just
waited 100ms before they reset the device. However, we should check
if the device becomes disconnected and reconnected during this period.
Porting of the current hub drivers will take place in separate
commits (when I have time to test the older HCIs).
Change-Id: I0c0ce0ac1b1cc51fb4cd009b3f9fcd1b9d2ba8fe
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3450
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Read bInterval from endpoint descriptors and store it in our endpoint_t
struct. The interval is encoded dependently on the device' speed and the
endpoint's type. Therefore, it will be normalized to the binary logarithm
of the number of microframes, i.e.
t = 125us * 2^interval
The interval attribute will be used in the xHCI driver.
Change-Id: I65a8eda6145faf34666800789f0292e640a8141b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3449
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
xHCI requires special treatment of set_address since it determines
the device number itself (instead of the driver, as with the other
controllers). The controller also wants to validate a chosen device
configuration and we need to setup additional structures for the
device and the endpoints.
Therefore, we add three functions to the hci_t structure, namely:
set_address()
finish_device_config()
destroy_device()
Current implementation for the Set Address request moved into
generic_set_address() which is set_address() for the UHCI, OCHI and
EHCI drivers. The latter two are only provided as hooks for the xHCI
driver.
The Set Configuration request is moved after endpoint enumeration.
For all other controller drivers nothing changes, as there is no other
device communication between the lines where the set_configuration()
call moved.
Change-Id: I6127627b9367ef573aa1a1525782bc1304ea350d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3447
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These values are already used in this usb stack.
Change-Id: If96f1dc2b67fbc13dfc4ae2d84e8f9945aa03163
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3448
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
During device initialization, skip any non-endpoint descriptor before
reading the endpoint descriptors. By now, only HID descriptors were
skipped.
Change-Id: I190f3ae44b864aa71d5f32c3738097cf8f33a61b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Add the Mobile Panther Point (PPT) AHCI controller (DEVID 0x1e03) to
the list of tested controllers. Also comment the only other listed
controller (Mobile ICH9).
The PPT AHCI controller was tested with a QM77 chipset on a Kontron
KTQM77 board.
Change-Id: Ia396761411f4f9289af11ec8e1b144512b2fc126
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3361
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This fixes the configuration where serial console output is
being sent to non-existant hardware to be captured with I/O
trapping. In this configuration where there isn't serial
hardware present we still want to init the consoles. We just
never want to read non-existant hardware.
Change-Id: Ic51dc574b9c0df3f6ed071086b0fb2119afedc44
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3249
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The cbfs core code would print out the name of the file it is
searching for and when it is found would print out the name
again. This contributes to a lot of unnecessary messages in a
functioning payload’s output. Change this message to a DEBUG one
so that it will only be printed when CONFIG_DEBUG_CBFS is enabled.
Change-Id: Ib238ff174bedba8eaaad8d1d452721fcac339b1a
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3208
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The cbfs core code would print out all unmatched file
names when searching for a file. This contributes to a lot
of unnecessary messages in the boot log. Change this
message to a DEBUG one so that it will only be printed when
CONFIG_DEBUG_CBFS is enabled.
Change-Id: I34c747e0d3406351318abf70994dbc0bb3fa6c01
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3164
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
Because pointers can be 32bit or 64bit big,
using them in the coreboot table requires the
OS and the firmware to operate in the same mode
which is not always the case. Hence, use 64bit
for all pointers stored in the coreboot table.
Guess we'll have to fix this up once we port to
the first 128bit machines.
Change-Id: I46fc1dad530e5230986f7aa5740595428ede4f93
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3115
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The way we got to include the compiler includes was kind of whacky.
Instead of mixing in potentially problematic headers, make libpayload
self-contained by adding some missing header files. Also clean up
conflicting definitions of size_t throughout the tree.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I0ad1194de1a00b7133c5477c00eb167d63a2ee85
Reviewed-on: https://gerrit.chromium.org/gerrit/47608
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3058
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reading commit »libpayload: New AHCI, ATA and ATAPI drivers«
(1f6bd94f) [1], the spelling error was found and is now fixed.
[1] http://review.coreboot.org/1622
Change-Id: Id418bcb99c1a9a400a49fc04078e465bd0908074
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3071
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This change modifies the code in libpayload that scans the PCI hierarchy for
USB controllers. Previously, if a devices primary function (function 0) was a
bridge, then none of the other functions, if any, would be looked at. If one
of the other functions was a bridge, that wouldn't be handled either. The new
version looks at each function that's present no matter what, and if it
discovers that it's a bridge it scans the other side.
Change-Id: I37f269a4fe505fd32d9594e2daf17ddd78609c15
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2517
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Nico Huber spotted [1], that commit (4d6ab4e2) [1] updating
superiotools’s `README` with the Git command line
superiotool: Update README with Git repository URL and directory location
missed, that after `git clone` one sitll has to change into
the cloned directory.
So prepend the path with `coreboot/` to fix that. The same error
happened in the commit (e1ea5151) for libpayload [2]
libpayload: Update README with Git repository URL and directory location
and is fixed in this patch too.
[1] http://review.coreboot.org/#/c/3019/
[2] http://review.coreboot.org/2228
Change-Id: Ib6e8b678af6276556a40ccfd52ae35ca7e674455
Reported-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3021
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Building libpayload with the PDCurses backend the following warning
is shown.
/src/coreboot/payloads/libpayload(master) $ make clean
/src/coreboot/payloads/libpayload(master) $ make
[…]
CC curses/pdcurses-backend/pdcscrn.libcurses.o
curses/pdcurses-backend/pdcscrn.c: In function 'PDC_scr_open':
curses/pdcurses-backend/pdcscrn.c:75:5: warning: "CONFIG_SPEAKER" is not defined [-Wundef]
[…]
The GCC documentation states [1]
In some contexts this shortcut is undesirable. The -Wundef option
causes GCC to warn whenever it encounters an identifier which is
not a macro in an ‘#if’.
and therefore use `#ifdef` [2] to silence this warning. No functional
change is done, as `CONFIG_SPEAKER` is assigned the value `Y` when
defined.
There was some discussion going on the list [3], but my points in there
turned out to be incorrect.
[1] http://gcc.gnu.org/onlinedocs/cpp/If.html
[2] http://gcc.gnu.org/onlinedocs/cpp/Ifdef.html
[3] http://www.coreboot.org/pipermail/coreboot/2013-March/075561.html
Change-Id: I8e9c9b5d01985b21ad05018986d614cf9bf2b439
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2934
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
This imports the newest cache and MMU code from coreboot. This
time it's so new that it hasn't even been checked in to coreboot.
However, this version at least allows DMA to work properly for the
MSHC driver. So even if we rebase a few more times, this version is
at least a step in the right direction.
Note: This omits the stuff that sets up dcache policy since
libpayload should not need to worry about that and it depends
on cbmem stuff.
Change-Id: Idd42b083e8019634aaaa44d5bf5b51db6c3912f5
Signed-off-by: David Hendricks <dhendrix@google.com>
Reviewed-on: http://review.coreboot.org/2975
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This imports the new cache maintenance API from coreboot at
commit bba8090. This is a BSD-licensed implementation which
exposes cache maintenance opertaions necessary for payloads
for things such as DMA transfers.
Change-Id: I554676db89517bebc6edae4f7ab7e5882e6f986d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2974
Tested-by: build bot (Jenkins)
On x86, coreboot may allocate a variable range MTRR for enabling caching
of the system ROM. Add the ability to parse this structure and add the
result to the sysinfo structure.
An example usage implementation would be to obtain the variable MTRR
index that covers the ROM from the sysinfo structure. Then one would
disable caching and change the MTRR type from uncacheable to
write-protect and enable caching. The opposite sequence is required
to tearn down the caching.
Change-Id: I3bfe2028d8574d3adb1d85292abf8f1372cf97fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2920
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This fixes the following PDCurses warnings:
CC curses/pdcurses-backend/pdcsetsc.libcurses.o
curses/pdcurses-backend/pdcsetsc.c: In function 'PDC_curs_set':
curses/pdcurses-backend/pdcsetsc.c:17:9: warning: implicit declaration of function 'serial_cursor_enable' [-Wimplicit-function-declaration]
curses/pdcurses-backend/pdcsetsc.c:22:9: warning: implicit declaration of function 'video_console_cursor_enable' [-Wimplicit-function-declaration]
CC curses/pdcurses-backend/pdcutil.libcurses.o
curses/pdcurses-backend/pdcutil.c:30:6: warning: no previous prototype for 'curses_enable_serial' [-Wmissing-prototypes]
curses/pdcurses-backend/pdcutil.c:35:6: warning: no previous prototype for 'curses_enable_vga' [-Wmissing-prototypes]
curses/pdcurses-backend/pdcutil.c:40:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
curses/pdcurses-backend/pdcutil.c:45:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
Change-Id: If0d4d475d3006f1a77f67ec46c6bdf4ee2906981
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2908
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There were a number of type issues in libpayload that sneaked in
with 903f8e0.
- size_t and ssize_t were conflicting with gcc builtins
- some stdint types were used in libpayload but not defined
in our stdint.h
With this patch it's possible to compile libpayload with the
reference toolchain again.
Change-Id: Idd5ccfdd9f3536b36bceca2d101e7405883b10bc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2903
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
libcbfs was using printf for size_t typed variables. However, printf
did not support printing those. This patch fixes the issue, removing
the warning when compiling ram_media.c
libcbfs/ram_media.c:52:10: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat]
libcbfs/ram_media.c:52:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat]
Change-Id: Iaf6e723f9a5b0a61a39d3125036fee9853e37ba8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2904
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The keyname() and termname() functions were creating a whole lot of warnings of
the style
curses/PDCurses-3.4/pdcurses/keyname.c:41:9: warning: initialization discards 'const' qualifier from pointer target type [enabled by default]
This patch fixes them.
Change-Id: Iae3c4e5201b48c2d2033cac48577e0462a34f309
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2905
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
PDCurses has a function called overlay() and also uses
overlay as a variable name in some functions.
This patch fixes the ambiguity that caused warnings like
curses/PDCurses-3.4/pdcurses/overlay.c: In function '_copy_win':
curses/PDCurses-3.4/pdcurses/overlay.c:51:39: warning: declaration of 'overlay' shadows a global declaration [-Wshadow]
In file included from curses/PDCurses-3.4/curspriv.h:16:0,
from curses/PDCurses-3.4/pdcurses/overlay.c:3:
curses/PDCurses-3.4/curses.h:1014:9: warning: shadowed declaration is here [-Wshadow]
Change-Id: I907653df0c8bb32c98bdcbc6476e94d2da6e0e90
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2906
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Xinitscr is only used internally in PDCurses, unless XCURSES
is defined. This patch fixes a warning that is produced because
of that.
Change-Id: I211f75717276cf028e0b435f328d1687d3536eb7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2907
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The function dump_qh() was added a while back but never used.
Hide it behind USB_DEBUG so it doesn't cause warnings when not
debugging the USB stack.
Change-Id: Idb3c7bb214895ef82676d181836a578bf161e8e0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2909
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
PDcurses is already default. Hence drop the additional attempt
that is not supported by Kconfig.
Config.in:123:warning: defaults for choice values not supported
Change-Id: I12cb5ea0bef2f146cf237c7a3cc9293a600d736b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2902
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The controller's shutdown function free()s the controller structure so
we shouldn't access it any more after calling shutdown.
As all controllers detach themself, i.e. unchain themself from usb_hcs,
just keep iterating over usb_hcs until it's NULL.
Change-Id: Ie85caba0f685494c3fe04c550a5a14bc4158a94e
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/2900
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
It shouldn't be used any more as we're about to free() the memory behind
the controller -- therefore detach it.
Change-Id: I875322a9940570c51d412a7f3bfb6af4ea3b3764
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/2899
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
After another incident related to virtual pointers in lib_sysinfo (and
resulting confusion), I decided to put some comments on the matter into
the code.
Remember, we decided to always use virtual pointers in lib_sysinfo, but
it's not always obvious from the code, that they are.
See also:
425973c libpayload: Always use virtual pointers in struct sysinfo_t
593f577 libpayload: Fix use of virtual pointers in sysinfo
Change-Id: I886c3b1d182cba07f1aab1667e702e2868ad4b68
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/2878
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds a test case for using CBFS images that reside in RAM
and a Makefile to run it (and maybe other tests in the future).
The test concerns an issue in libcbfs when using x86 style CBFS
images in non-canonical locations (eg. when loading CBFS images
for processing).
Use with "make run" inside the tests directory.
Change-Id: I1af3792a1451728ff9594ba7f0410027cdecb59d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2623
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change "ERROR" to "WARNING" -- not finding the indicated file is usually
not a fatal error.
Change-Id: I0600964360ee27484c393125823e833f29aaa7e7
Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-on: http://review.coreboot.org/2833
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The template had a dependency on config.h which was correct for coreboot,
where this build system originally came from, but not for libpayload which
uses the differently named libpayload-config.h, presumably to avoid colliding
with a config.h used by the actual payload. Because libpayload-config.h is now
effectively a dependency of everything, it doesn't have to be added piecemeal
in Makefile.inc.
Change-Id: I01f20d363cb1393fa1cdcf0dc916670db90294e9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2763
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
And include the new, split out version in drivers/keyboard.c and
drivers/usb/usbhid.c. Those files were including curses.h just for those
definitions, but the include path was only fixed up to to point to the
libpayload versions of those files if one of the variants of curses was
compiled in. If neither was, gcc would fall back to the system version of that
header which is wrong.
Change-Id: I8c2ee0baf5f0702bd8c713c8dd4613a4bb269ce5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2762
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vboot_handoff structure needs to be parsed from the coreboot tables.
Add a placeholder in sysinfo as well as the ability to parse the
coreboot table entry concering the vboot_handoff structure.
Built with unified boot loader and ebuild changes. Can find and use
the VbInitParams for doing kernel selection.
Change-Id: If40a863b4a445fa5f7814325add03355fd0ac647
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2720
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In their current macro form, any arguments that are expressions will be
evaluated multiple times. That can cause problems if they have side effects,
and might not even compile if the overall expression is ambiguous, for
instance if you pass in foo++.
Built with code that previously wouldn't compile because the macros
expanded to ambiguous expressions.
Change-Id: I378c04d7aff5b4ad40581930ce90e49ba7df1d3e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The timekeeping code in libpayload was dependent on rdtsc, and when it was
split up by arch, that code was duplicated even though it was mostly the same.
This change factors out actually reading the count from the timer and the
speed of the timer and puts the definitions of ndelay, udelay, mdelay and
delay into generic code. Then, in x86, the timer_hz and timer_get_raw_value
functions which used to be in depthcharge were moved over to libpayload's
arch/x86/timer.c. In ARM where there isn't a single, canonical timer, those
functions are omitted with the intention that they'll be implemented by a
specific timer driver chosen elsewhere.
Change-Id: I9c919bed712ace941f417c1d58679d667b2d8269
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2717
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This function is static and not used in that file. To avoid the compiler
complaining about that fact, put the two functions and the call to dump_ed
(currently #if 0) behind #ifdef USB_DEBUG
Change-Id: Ic373313b5fff81f09800f286b32238350ab699c6
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2716
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
'for' loop initial declarations are only allowed in C99 mode
I didn't realize we don't enable 14 year old features when building
libpayload, and I must have accidentally not rebuilt everything when making my
final tweaks to my earlier change.
Change-Id: I6caeeffad177b6d61fa30175f767e85084c061f4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2718
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Use memcpy to access a uint32_t that's inherently unaligned due to the layout
of the LZMA header format.
Built and booted on Daisy and saw a data abort go away. Built and booted
into developer mode on Link and verified that bitmaps were
decompressed/displayed correctly.
Change-Id: Id3ae746c04d23bcb0345cb71797bfa219479cc8f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2670
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some new TPM drivers in depthcharge require that type. I added it to
arch/types.h which seemed appropriate, but I'm not sure that's exactly the
right header to use, or in other words if you'd get that type from libpayload
the same way you'd get it if you were building a standard Linux program.
Also, I attempted to determine what underlying types gcc would use, and while
I think I picked the right ones I'm not 100% certain of that either.
Change-Id: Ic5c0b4173c8565ede3bfce8870976d596d69e51d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2669
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Don't keep using the coreboot stack on ARMv7.
Change-Id: I734c5d77f8584e30ee0c720d41e21e3040f56db4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2668
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: Ia85a7cd6a0b85119cce6b2f9c42a7fc31ffd9f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2654
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It might be useful to provide a USB driver in the payload itself instead of in
libpayload. For example there are multiple payloads being built and linked
against the same libpayload, and they might not need or even want to have the
same set of drivers installed.
This change adds two new functions, usb_generic_create and usb_generic_remove,
which behave like the usbdisk_create and usbdisk_remove functions which are
defined for USB mass storage devices. If a USB device isn't recognized and
claimed by one of the built in USB class drivers (currently hub, hid, and msc)
and the create function is defined, then it will be called to give the payload
a chance to use the device. Once it's removed, if usb_generic_remove is
defined it will be called, effectively giving the payload notice.
Built and booted depthcharge on Link. Built depthcharge for Daisy. Built
a netbooting payload, called usb_poll() with those functions implemented, and
verified that they were called and that the devices they were told about were
reasonable and the same as what was reported by lsusb in the booted system.
Change-Id: Ief7c0a513b60849fbf2986ef4ae5c9e7825fef16
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2666
Tested-by: build bot (Jenkins)
Reviewed-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
EHCI controllers see transfers as a queue of transfer descriptors
(qTDs), each of which can represent an aligned area of up to 20KB. Each
qTD is processed separately, which means that a single USB packet cannot
span multiple qTDs.
While this should not be a problem according to the specification, some
USB storage devices seem to get confused when a packet in the middle of
a transfer is smaller than the maximum packet size (512 bytes) due to
falling on a qTD boundary. This patch aligns the total transfer length
per qTD to 512 bytes to avoid that problem (any excess bytes will simply
roll over to the next qTD).
Change-Id: I0b5db07507699a3861b30c1a5ee774c45dda7fdd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/2651
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Initialize the high part of the address
and use 64-bit compatible descriptors.
(waste a few bytes on 32-bit but should be harmless)
Read USB stick on a SandyBridge system which has 64-bit EHCI.
Change-Id: I59cc842459acecdde8f8bdd4795ebfeccb842c8f
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2650
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These were currently stubbed out for PowerPC but not for ARM.
Change-Id: I08f45174877bf5751d972078b8c53d82898b7f2b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2655
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I56f810dfa6654ac1e9d1696ad15e7f1b8bfe59bd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2652
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I01b1fa42139af925716cd5d57f96dc24da6df5a7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2660
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I36c750d520ff034c9ca9b9af46bd99bd49af7355
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2659
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This way we won't have two copies of the hardware init function, and three
copies of the putchar, havechar, and getchar functions.
Change-Id: Ifda7fec5d582244b0e163ee93ffeedeb28ce48da
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2657
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Default it to no to be consistent with the other architecture wide options
(endianness), and turn it on explicitly for x86 and PowerPC.
Change-Id: Idda26d580156bbbf08ea11b28abe75cfa6b594b2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2658
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When building other payloads with lpgcc the -nostdinc flag was injected into
CFLAGS, but when building libpayload itself some headers were being used from
the host system. This change puts -nostdinc into the Makefile and xcompile
script, fixes up one include path in include/inttypes.h, adds the compiler
provided include directory to the include search path, and deletes the two now
redundant stdint.h files.
BUG=None
TEST=With this and other changes, built libpayload and depthcharge for Daisy,
Link, and Fox.
BRANCH=None
Change-Id: Ia7817fceab5297cd82ccc0d392330de0df61980e
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2710
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There weren't enough parenthesis in the macros so operations might only apply
to the last part of an expression passed in as an argument.
Change-Id: I5afb406f9409986e45bbbc598bcbd0dd8507ed35
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2665
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9a16331dedc97f17af94bf2cf535a9c93d1729a0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2667
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The functions in endian.h (betoh{l,w,ll} and others) were named differently from
the well-known BSD/glibc style endian functions (ex, betoh{16,32,64}). We should
provide the BSD/glibc style functions to prevent confusion.
Change-Id: Ia3bee481ba7989ac25b79ddb89bc6819d52fd8c3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2705
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The functions defined in that header aren't used anywhere in the actual code,
and that include breaks things on ARM.
Built for ARM with COREBOOT_VIDEO_CONSOLE turned on and saw compiler
errors go away.
Change-Id: I56d6fe5e00c8fccda6e31ef8752326bd36398e74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2656
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
That way when it's treated as a u32 when its value is extracted for numblocks
and blocksize below, it doesn't make the compiler unhappy, and it ensures that
the buffer will be properly aligned on architectures where that sort of thing
matters.
Built and saw warnings about type punning go away.
Change-Id: I254e0b5e70847112d660675b7df0ac9cb52e4051
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2653
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Three issues:
1. the hardcoded dereferenced pointer at 0xfffffffc
2. "RAM media" has no idea about ROM relative addresses
3. off-by-one in RAM media: it's legal to request 4 bytes from 0xfffffffc
Change-Id: I671ac12d412c71dc8e8e6114f2ea13f58dd99c1d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2624
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Things work better with it turned on, and the overhead should be negligable.
Built and booted into depthcharge on Snow. Verified that calling between
various bits of thumb and ARM code worked correctly.
Change-Id: I08d1006e113d2cca08634bf19240aca138a449d9
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2567
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Give some indication what happened instead of just crashing.
As part of setup, cause an exception and make sure that we get
the right one, and that we recover correctly. Hence we have
some assurance that if they really happen we can handle them.
Built and booted into test payload on Snow. Saw the built in test function
worked correctly. Artificially added code which got an exception and saw that
the error information prints correctly.
Change-Id: I2e0d022f090ee422fb988074fbb197afa2485caa
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2569
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Update coreboot to use SeaBIOS' tag rel-1.7.2.1
Change-Id: I01969407964a7cf64f7c4800b59c6aed845b24f9
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/2575
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The linker uses that info so interworking can work correctly.
Built and booted into depthcharge on Snow and saw interworking start to
work correctly.
Change-Id: I0ac54f1c424ec70f8244edf6541a10b089ce47b4
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2568
Tested-by: build bot (Jenkins)
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Gabe Black