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.
BUG=None
TEST=Built with the assembly versions of memcpy and memset turned on and saw
that we could boot after this change where we couldn't before. Disassembled a
function which calls memset and saw that it was using the blx instruction
which can change mode instead of the bl instruction which can't.
BRANCH=None
Change-Id: Ic3ef4faf17d3467b5042c944106b8743d517cce3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/58728
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Not all platforms !x86 are big endian, hence actually look
at the CONFIG_LITTLE_ENDIAN flag instead of CONFIG_ARCH_X86.
BUG=none
TEST=none
BRANCH=none
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>
This was never completed / working and we have the working
ARMv7 port for an architecture template, so get rid of this
dead code.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ic2c1267ee5546dd6e1b63220c263b2fa86c8ae33
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56065
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Mass storage devices such as card readers show up as
as USB devices. However the media not be inserted. In those
situations the previous code would just fake a disk and
call usbcreate_disk. This is inappropriate because it forms
a 1:1 mapping of USB device to disk leading to the inability
to remove the disk and/or handle "hot plug" card insertion
and removals.
To alleviate this issue introduce the notion of ready to the
usbmsc structure. It tracks detached, not ready, and ready
states. The polling routine is then used to track not ready
to ready transitions thereby creating and removing disks
appropriately. This handles the case of inserting and removing
a card that shows up as a new disk.
BUG=chrome-os-partner:19596
BUG=chrome-os-parnter:20014
BRANCH=None
TEST=Booted recovery mode. Able to observe inerstion and removal
of sdcard. Also able to insert valid USB flash drive to boot
as well.
Change-Id: I3eefbe537ec1b9c975744b8984b06c17ae236f40
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57948
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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.
BUG=chrome-os-partner:19596
BRANCH=None
TEST=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>
The commit introducing dummy_media.c was placed in the
libc object list. This wasn't correct. It should be in the
libcbfs object list as well as guarded by CONFIG_CBFS.
BUG=None
BRANCH=None
TEST=Built with USE=depthcharge emerge-daisy depthcharge libpayload
Change-Id: Iace43fff8f85f60ecac5e6eb8350cd1f3ee9d35e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56925
Taken directly from slippy with only constant + string changes.
(Peppy port of I4172460d3b075bfd5bb22013a6225cf0e8f95b9c by dlaurie)
The following changes are required in a subsequent commit:
- Add Elpida SPD data.
- Update GPIO map.
- Remove iSSD power sequencing.
- Update USB port map.
BUG=chrome-os-partner:19636
BRANCH=none
TEST=manual: emerge-peppy chromeos-coreboot-peppy
CQ-DEPEND=I3da8679d5ac9752eca75264589f66451eadad94c
Change-Id: I01dfb841f0e9186cf8a0a23f72e7be986a83be42
Reviewed-on: https://gerrit.chromium.org/gerrit/56513
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dave Parker <dparker@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
The generic cbfs code relies on the libpayload_init_default_cbfs_media
symbol. However, none was provided for ARM. Provide an empty
implementation that returns an error as there is no generic way
to locate the default cbfs media.
BUG=None
BRANCH=None
TEST=emerge-daisy libpayload depthcharge
Change-Id: Ie0d06fbe6fc790c9d92434cd2d60922908acdc69
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56805
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The ram_media.c file is being compiled, however the
global functions were not exposed through a header.
BUG=chrome-os-partner:19691
BRANCH=none
TEST=Built depthcharge with including cbfs_ram.h and
calling the exposed functions.
Change-Id: I4588fbe320c29051566cef277bf4d20a83abf853
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56642
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
The ram_map() handled offsets from 0->size as well as
negative offsets from the top of the region. However,
the cbfs core tries to map a offset that is actually a
pointer within the region itself. Allow for such instances.
This fixes an issue when using ram_media with tthe ebmedded
SeaBIOS cbfs.
BUG=chrome-os-partner:19691
BRANCH=none
TEST=manual: used ram_media to parse embedded SeaBIOS cbfs properly.
Change-Id: I15b0b3b643390d3784ae5887c0f17d420d59c5b6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56641
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
- Only the first two DIMM SPDs are specified so far
- GPIO map is updated
- iSSD power sequencing removed
- USB port map updated
BUG=chrome-os-partner:19637
BRANCH=none
TEST=manual: emerge-falco chromeos-coreboot-falco
Change-Id: I4172460d3b075bfd5bb22013a6225cf0e8f95b9c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56329
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=chrome-os-partner:18635
TEST=compile tested
BRANCH=none
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>
The USB ports are in USB2 mode in firmware and are using
the EHCI driver so we can disable this to save boot time.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=boot from usb on slippy
Change-Id: Ia9ee614281b6eab4dcb2ad098a248e2add5e7521
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56026
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BUG=chrome-os-partner:18635
TEST=Boot from USB in depthcharge on Snow
Change-Id: I472fbb9df22e4e1271d6c3a743744d4ee8a4f659
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49971
Restructure USB stack to not depend on PCI, and
make PCI stub available on x86, but provide fixed
BARs for ARM (Exynos 5)
BUG=chrome-os-partner:18635
TEST=Boot from USB in depthcharge on Snow
Change-Id: Iee7c8b134c22b661a9a515e24943470c9dbadd1f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49970
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.
BUG=chrome-os-partner:18635
TEST=more changes needed
BRANCH=none
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>
BUG=chrome-os-partner:19420
TEST=With this and other changes, built for peach pit.
BRANCH=None
Change-Id: I81a02a3d9329fb7125909d286c670538fcb49fd2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51464
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The libpayload config files are now identified by both the board and variant,
so this config file is no longer needed.
BUG=chrome-os-partner:19420
TEST=Built for wtm2.
BRANCH=None
Change-Id: I97a5cca21ae70b881deb55edc9675a278524d795
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51462
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
It may be necessary to use different config settings for different variants
of the same board. We should make it possible to use different config files
depending on the variant. This might lead to a number of similar or identical
configs if the variants don't actually vary very much, but hopefully if we've
gone to the trouble of identifying them separately there are some meaningful
differences.
The fox boards are the only ones currently supported by libpayload that
actually have variants.
BUG=chrome-os-partner:19420
TEST=Built for wtm2 with a change to the ebuild to use the new names.
BRANCH=None
Change-Id: Ic445e80be26ecdd348dc1de7d6a351ab6f9f2cba
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51461
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
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.
BUG=None
BRANCH=None
TEST=Compiled and booted.
Change-Id: I142166bfdfcb5e7f6dba6c1ecbd13f3c0ff15088
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/50459
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
In the process of getting rid of compiler includes during in coreboot
and libpayload, we defined size_t and ssize_t ourselves, using a GCC
macro for size_t: __SIZE_TYPE__. Unfortunately, there is no
__SSIZE_TYPE__, so we temporarily redefine unsigned to signed to make
__SIZE_TYPE__ __SSIZE_TYPE__.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18638
TEST=emerge-daisy libpayload depthcharge builds with ToT coreboot
Change-Id: I4cf4eb0fdaa4db64277c2585fe2c1bdc0acdf02b
Reviewed-on: https://gerrit.chromium.org/gerrit/49947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
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: https://gerrit.chromium.org/gerrit/49766
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This imports the cache/MMU code from coreboot as of 1877cee.
BUG=none
BRANCH=none
TEST=built and booted into the kernel (which still crashes) on snow
Change-Id: I97ec8b9640921a94a4b27d89e4ae6185e9f96f18
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48288
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Because pointers can be 32bit or 64bit big,
using them in the coreboot table requires the
OS and the firmware to operate in the same mode
which is not always the case. Hence, use 64bit
for all pointers stored in the coreboot table.
Guess we'll have to fix this up once we port to
the first 128bit machines.
BUG=chrome-os-partner:18638
TEST=USE=depthcharge emerge-link libpayload depthcharge chromeos-coreboot-link chromeos-bootimage
produces working image
BRANCH=none
Change-Id: I46fc1dad530e5230986f7aa5740595428ede4f93
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48723
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BUG=None
TEST=Built with ToT upstream Coreboot and saw that the system no longer hangs
when starting depthcharge.
BRANCH=None
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>
The way we got to include the compiler includes was kind of whacky.
Instead of mixing in potentially problematic headers, make libpayload
self-contained by adding some missing header files. Also clean up
conflicting definitions of size_t throughout the tree.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
TEST=emerge-link libpayload depthcharge works fine
BRANCH=none
Change-Id: I0ad1194de1a00b7133c5477c00eb167d63a2ee85
Reviewed-on: https://gerrit.chromium.org/gerrit/47608
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
This 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>
