The LZMA compression algorithm, currently the only one available, will fail
if you ask it to write more data to the output than you've given it space for.
The code that calls into LZMA allocates an output buffer the same size as the
input, so if compression increases the size of the output the call will fail.
The caller(s) were written to assume that the call succeeded and check the
returned length to see if the size would have increased, but that will never
happen with LZMA.
Rather than try to rework the LZMA library to dynamically resize the output
buffer or try to guess what the maximal size the data could expand to is, this
change makes the caller simply print a warning and disable compression if the
call failed for some reason.
This may lead to images that are larger than necessary if compression fails
for some other reason and the user doesn't notice, but since compression
errors were ignored entirely until very recently that will hopefully not be
a problem in practice, and we should be guarnateed to at least produce a
correct image.
BUG=chrome-os-partner:26060
TEST=Built for link and saw that a segment whos size had been set to 0 now has
the correct size and is loaded correctly. Booted into RW depthcharge which had
been broken before this change.
BRANCH=None
Change-Id: I5f59529c2d48e9c4c2e011018b40ec336c4fcca8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187365
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
When compression fails for whatever reason, the caller should know about it
rather than blindly assuming it worked correctly. That can prevent half
compressed data from ending up in the image.
This is currently happening for a segment of depthcharge which is triggering
a failure in LZMA. The size of the "compressed" data is never set and is
recorded as zero, and that segment effectively isn't loaded during boot.
BUG=chrome-os-partner:26060
TEST=Built with this change and saw that cbfstool no longer seems to succeed
or inserts a broken payload.
BRANCH=None
Change-Id: Idbff01f5413d030bbf5382712780bbd0b9e83bc7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/187364
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
After removing a file sandwiched between two other files, that file
could no longer be re-added at the same location. cbfstool tried to
add the file, and a new "empty" entry, which, together, would no
longer fit, so it continued checking for the next available space.
Change the behavior to add the file if there is enough space for the
file alone, then only add the "empty" entry if there is enough space
for it.
Change-Id: I885bb574bb230905bd42ca0fb6d4a6ef9b0cae03
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186983
This change adds a header serialization function. Programmers can thus just
set up a header as needed, without worrying about forgetting if and how to
use the [hn]to[hn]* functions.
BUG=None
TEST=Build a peppy image and verify that it's bit for bit the same.
BRANCH=None
Change-Id: I0f9b8e7cac5f52d0ea330ba948650fa0803aa0d5
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181552
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
This completes the improvements to the ELF file parsing code. We can
now parse section headers too, across all 4 combinations of word size
and endianness. I had hoped to completely remove the use of htonl
until I found it in cbfs_image.c. That's a battle for another day.
There's now a handy macro to create magic numbers in host byte order.
I'm using it for all the PAYLOAD_SEGMENT_* constants and maybe
we can use it for the others too, but this is sensitive code and
I'd rather change one thing at a time.
To maximize the ease of use for users, elf parsing is accomplished with
just one function:
int
elf_headers(const struct buffer *pinput,
Elf64_Ehdr *ehdr,
Elf64_Phdr **pphdr,
Elf64_Shdr **pshdr)
which requires the ehdr and pphdr pointers to be non-NULL, but allows
the pshdr to be NULL. If pshdr is NULL, the code will not try to read
in section headers.
BUG=None
TEST=Build a peppy image (known to boot) with old and new versions and verify they are bit-for-bit the same
BRANCH=None
Change-Id: I54dad887d922428b6175fdb6a9cdfadd8a6bb889
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/181272
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
The aarch64 is not really an arm variant, it's sufficiently
different that it can be considered (for purposes of cbfs, certainly)
to be a new architecture.
Add a constant in cbfs.h and strings to correspond to it.
Note that with the new cbfstool support that we added earlier,
the actual use of aarch64 ELF files actually "just works" (at
least when tested earlier).
BUG=None
TEST=It builds an image for nyan, and no new code is added.
BRANCH=None
Change-Id: Ib4900900d99c9aae6eef858d8ee097709368c4d4
Reviewed-on: https://chromium-review.googlesource.com/180221
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Add XDR functions and use them to convert the ELF headers
to native headers, using the Elf64 structs to ensure we accomodate
all word sizes. Also, use these XDR functions for output.
This may seem overly complex but it turned out to be much the easiest
way to do this. Note that the basic elf parsing function
in cbfs-mkstage.c now works over all ELF files, for all architectures,
endian, and word size combinations. At the same time, the basic elf parsing
in cbfs-mkstage.c is a loop that has no architecture-specific conditionals.
Add -g to the LDFLAGS while we're here. It's on the CFLAGS so there is no
harm done.
BUG=None
TEST=Build and boot for Peppy; works fine. Build and boot for nyan, works fine. Build for qemu targets and armv8 targets.
BRANCH=None
Change-Id: I5a4cee9854799189115ac701e22efc406a8d902f
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178606
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Install the BL1 and set up the checksum in the Makefile instead of relying on
post processing. Import the exynos checksum script, split it in two and
simplify it significantly. Stop putting the CBFS header in the midst of the
bootblock so that it can be checksummed before CBFS is put together. Stop
saving space for it and leaving an anchor in the bootblock which nobody looks
for.
BUG=None
TEST=Built and booted on pit. Built for snow, but it doesn't boot on ToT so I
couldn't test it more than that.
BRANCH=None
Change-Id: Icbb5a5914ece60b2827433b6dc29d80db996ea6c
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179229
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
In the process of rewriting cbfstool for ARM and using
a new internal API a regression was introduced that would
silently let you add an ARM payload into an x86 CBFS image
and the other way around. This patch fixes cbfstool to
produce an error in that case again.
BRANCH=none
BUG=none
TEST=emerge-peach_pit with and without my other CL that fixes
the cbfs image type and see it fail without that CL.
Change-Id: I37ee65a467d9658d0846c2cf43b582e285f1a8f8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/176711
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
The introduction of the buffer and cbfs_image api also
brought in some regressions, such as broken architecture
detection, that went undetected. This patch prepares
cbfstool for a fix.
- There has been a significant amount of dead code that
went undetected. Remove it!
- Fix a few shadowed variables
- Compile cbfstool with more warnings
BRANCH=none
TEST=build and boot coreboot on peach_pit and beltino
BUG=none
Change-Id: Ib6d02abd3ea404ec1e90f2acab6d7c67cac19220
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/176710
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
When compiling coreboot for x86 on gcc the compiler is
free to pick whatever defaults it is using at the time of
gcc's compile/configuration when no -march is specified.
Not properly specifying -march then opens up the use of SSE
instructions for copmilation units it should not be used such
as the SMM module as this module doesn't save/restore SSE
registers.
BUG=chrome-os-partner:22991
BRANCH=None
TEST=Built and confirmed -march=i686 was used on command line. Also
noted not xmm registers were produced grep'ing through objdump
output.
Change-Id: I64d4a6c5fa9fadb4b35bc7097458e992a094dcba
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/172640
Reviewed-by: Stefan Reinauer <reinauer@google.com>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
BUG=chrome-os-partner:23009
TEST=Built libpayload and coreboot for link, pit and nyan. Booted into the
bootblock on nyan.
BRANCH=None
Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The ARM linker scripts work fine with the gold linker.
This also requires to enhance the LINKER_SUFFIX variable
with a platform suffix so that it can be different on
ARMv7 and x86
BUG=none
BRANCH=none
TEST=boot tested on pit
Change-Id: I7d3b57991b1e40d0305be3fc4bc63d322392d98e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168771
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BUG=chrome-os-partner:18637
BRANCH=none
TEST=see timestamp names in cbmem -t output
Change-Id: Ie32d3e7ca759bd15e7c160bdd829dec19943e6cb
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65333
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
If the cbmem console buffer isn't zero filled before it's used, there won't be
a terminator at the end. We need to put one at the cursor position manually.
BUG=chrome-os-partner:19420
TEST=Booted and ran cbmem -c on pit. No longer saw lots of garbage printed
after the actual console output.
BRANCH=None
Change-Id: I69870c2b24b67ce3cbcd402b62f3574acb4c2a8f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65300
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
On ARM the timestamps are already in micro seconds, so
no need to convert them.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
BRANCH=none
TEST=cbmem -t prints more reasonable timestamps.
Change-Id: If7363b0703e144bde62d9dab4ba845e1ace5bd18
Reviewed-on: https://gerrit.chromium.org/gerrit/63991
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
This also adds an option -x/--hexdump to dump the whole
CBMEM area for debugging.
BRANCH=none
BUG=chrome-os-partner:18637
TEST=cbmem -l works on snow
Change-Id: I244955394c6a2199acf7af78ae4b8b0a6f3bfe33
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/62287
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=chrome-os-partner:18637
TEST=Run sudo cbmem -l on Snow w/ coreboot, observe that it finds
CBMEM
BRANCH=none
Change-Id: If5f961afb23791af6f32dd4fc9a837a1aa41b70e
Reviewed-on: https://gerrit.chromium.org/gerrit/59322
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
As choice dependency are now fully checked, it's quite easy to add support
for named choices. This lifts the restriction that a choice value can only
appear once, although it still has to be within the same group,
but multiple choices can be joined by giving them a name.
While at it I cleaned up a little the choice type logic to simplify it a
bit.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
BUG=None
TEST=Built for Pit, Link, Fox.
BRANCH=None
Change-Id: I3b03b9992094d0a21fb768597e0afddd664e946d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51056
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Properly check the dependency of choices as a group.
Also fix that sym_check_deps() correctly terminates the dependency loop
error check (otherwise it would continue printing the dependency chain).
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
BUG=None
TEST=Built for Pit, Link, Fox.
BRANCH=None
Change-Id: I71eba60a4124232dc825e924d0424b52f80d2928
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51055
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Fix reversal of dlg.border.atr and dlg.dialog.atr for draw_box()
Makes the inputbox look like expected
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
=======
Cherry-picked from the Linux kernel.
BUG=None
TEST=Built for Pit, Link, Fox.
BRANCH=None
Change-Id: Id1d0bbc7a06515f1f5a4acb904b188dcbaf0f191
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/51054
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The update-fit command takes in a parameter for number of slots
in the FIT table. It then processes the microcobe blob in cbfs
adding those entries to the FIT table. However, the tracking of
the number of mircocode updates was incremented before validating
the update. Therefore, move the sanity checking before an increment
of the number of updates.
BUG=chrome-os-partner:19035
BRANCH=none
TEST=emerge-fox_wtm2 chromeos-coreboot-fox and inspected microcode
FIT entries.
Change-Id: Ie8290f53316b251e500b88829fdcf9b5735c1b0e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50319
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit b8ad224 changed the memory address in lb_cbmem_ref coreboot
table entries from a pointer to a uint64_t. This change was introduced
to make the cbmem utility work on both 32bit and 64bit userland.
Unfortunately, this broke the cbmem utility running on older versions
of coreboot because they were still providing a 32bit only field for
the address while the cbmem utility would now take the following 4
bytes as upper 32bits of a pointer that can obviously not be
mmapped. This change checks if the size of the lb_cbmem_ref structure
provided by coreboot is smaller than expected, and if so, ignore the
upper 32bit of the address read.
BUG=chrome-os-partner:18638
TEST=Build image, boot image on Link with original firmware,
See it not rebooting.
BRANCH=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I9dff766a89663322b1854b425ca5fd32e9e502d7
Reviewed-on: https://gerrit.chromium.org/gerrit/48725
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CPPFLAGS was split off, but not taken into regard in dependency
generation. Somewhat cosmetic.
BUG=chrome-os-partner:18638
TEST=emerge-stout32 chromeos-coreboot-stout32 shows no
cbmem.c:36:34: fatal error: boot/coreboot_tables.h: No such file or directory
anymore.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ia9d2e10a3ef122f30d681d16c2291eb108ead835
Reviewed-on: https://gerrit.chromium.org/gerrit/48322
Reviewed-by: David James <davidjames@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Right now, these offsets are not declared with the correct printf
specifiers. Fix that.
BUG=none
TEST=launch trybots on all platforms
Change-Id: Ic6ac0afe047ab7b61b5753cc5bab261d1a860ba6
Reviewed-on: https://gerrit.chromium.org/gerrit/48321
Reviewed-by: David James <davidjames@chromium.org>
Tested-by: David James <davidjames@chromium.org>
We're using these scripts to clean up some of the files in 3rdparty.
Moving 3rdparty out of the coreboot repository and into the private
overlays would have required to duplicate these scripts in every
overlay. Instead, move them to coreboot's util/ directory.
BUG=none
TEST=none needed.
BRANCH=none
Change-Id: Ia914a2e23b97381c0490a8a03441caf8d2a0532d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/47685
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The LZMA glue code in cbfstool was recently rewritten from C++
to plain C code in:
commit aa3f7ba36e
Author: Stefan Reinauer <reinauer@chromium.org>
Date: Thu Mar 28 16:51:45 2013 -0700
cbfstool: Replace C++ code with C code
Reviewed-on: http://review.coreboot.org/3010
In the progress of doing so, the stream position for the
input stream and output stream was not reset properly. This
would cause LZMA producing corrupt data when running the
compression function multiple times.
Change-Id: I096e08f263aaa1931517885be4610bbd1de8331e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3040
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This fixes at least one warning on my machine where "llx" is replaced by PRIx64.
Change-Id: Iee3e5027d327d4d5f8e6d8b2d53d051f74bfc354
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3024
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Cppcheck [1], a static code analysis tool, warns about the
following.
$ cppcheck --version
Cppcheck 1.59
$ cppcheck --enable=all .
[…]
Checking cpu.c...
[cpu.c:951]: (warning) %d in format string (no. 1) requires a signed integer given in the argument list.
[cpu.c:962]: (warning) %d in format string (no. 1) requires a signed integer given in the argument list.
[…]
And indeed, `core` is an unsigned integer and `man 3 printf` tells
the following about conversion specifiers.
d, i The int argument is converted to signed decimal notation. […]
o, u, x, X
The unsigned int argument is converted to unsigned octal (o), unsigned decimal (u), or unsigned hexadecimal (x and X)
notation.
So use `u` and Cppcheck does not complain anymore.
[1] http://cppcheck.sourceforge.net/
Change-Id: If8dd8d0efe75fcb4af2502ae5100e3f2062649e4
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3026
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
When building inteltool under x86-32, the following warnings are
shown.
$ gcc --version
gcc-4.7.real (Debian 4.7.2-15) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
[…]
amb.c: In function ‘amb_read_config32’:
amb.c:31:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:31:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config16’:
amb.c:45:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:45:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config8’:
amb.c:60:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:60:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[…]
Nico Huber commented the following [1].
I don't see those warnings because I build for x86-64. I guess
they could be fixed by casting to `ptrdiff_t` (from stddef.h)
instead of `uint64_t`.
And indeed, using `ptrdiff_t` fixes the warning. But as Stefan
Reinauer commented in [2], `intptr_t` is more appropriate as this
is just a pointer and no pointer difference.
So `intptr_t` is taken, which fixes these issues warned about too.
These warnings were introduced in commit »inteltool: Add support for
dumping AMB registers« (4b7b320f) [3].
[1] http://review.coreboot.org/#/c/2996/1//COMMIT_MSG
[2] http://review.coreboot.org/#/c/3002/1/util/inteltool/amb.c
[3] http://review.coreboot.org/525
Change-Id: I2ea1a31dc1e3db129e767d6a9e0433fd75a77d0f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3002
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
When buidling inteltool with GCC, the following warning is printed.
$ make
[…]
gcc -O2 -g -Wall -W -c -o memory.o memory.c
memory.c: In function ‘print_mchbar’:
memory.c:287:7: warning: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ [-Wformat]
[…]
This was introduced in commit »inteltool: Add support for H65 Express
chipset« (c7fc4422) [1].
Address this warning, by using `%llx` instead of `%lx`.
[1] http://review.coreboot.org/1258
Change-Id: I4f714edce7e8b405e1a7a417d02fa498322c88a8
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2994
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Tested-by: build bot (Jenkins)
cbfstool was using a C++ wrapper around the C written LZMA functions.
And a C wrapper around those C++ functions. Drop the mess and rewrite
the functions to be all C.
Change-Id: Ieb6645a42f19efcc857be323ed8bdfcd9f48ee7c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3010
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The help text says --machine, but the code
actually checked for --arch. Fix it!
Change-Id: Ib9bbf758b82ef070550348e897419513495f154b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3009
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Allow to override the variables `CC`, `INSTALL`, `PREFIX`,
`CFLAGS` and `LDFLAGS`. Though append `-lpci -lz` to `LDFLAGS`.
This way for example a different compiler can easily be used.
CC=clang make
As a side note, Clang in contrast to GCC does *not* issue the
following warnings.
$ clang --version
Debian clang version 3.2-1~exp6 (tags/RELEASE_32/final) (based on LLVM 3.2)
Target: i386-pc-linux-gnu
Thread model: posix
$ gcc --version
gcc-4.7.real (Debian 4.7.2-15) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make
[…]
amb.c: In function ‘amb_read_config32’:
amb.c:31:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:31:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config16’:
amb.c:45:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:45:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
amb.c: In function ‘amb_read_config8’:
amb.c:60:22: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
amb.c:60:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[…]
These are only shown under 32-bit and not 64-bit
$ uname -m
i686
and are going to be fixed in a separate patch.
Change-Id: Id75dea081ecb35390f283520a7e5dce520f4c98d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2996
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds the power management register definitions for Intel's Cougar
Point and Panther Point platform controller hubs (PCH). The definitions
are actually a subset of the older ICH10R registers: I've added just
those that are mentioned in the public specifications in [1] and [2].
I've tested dumping with an H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: Ia6945fe96cd96b568ed5191e91dbba5556e1ee95
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2985
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds the PCI IDs of Intel's Cougar Point and Panther Point platform
controller hubs (PCH) to the dumping of the root complex configuration
under the root complex base address (RCBA). Those PCHs are handled exactly
as the older ICHs which can be seen in [1] and [2]. I've tested dumping
with an H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: I2296caae57e614171300362d41715deecec77762
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2986
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This way for example a different compiler can easily be used.
CC=clang make
Change-Id: I50b83554fd4826d00d87e60a30eb1f6a88834397
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2935
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This adds the GPIO register definitions for Intel's Cougar Point and
Panther Point platform controller hubs (PCH). All information is taken
from the public specifications in [1] and [2]. I've tested it with an
H77 PCH.
NM70 is missing in [1]. Therefore, I didn't add it here.
[1] Intel 6 Series Chipset and Intel C200 Series Chipset - Datasheet
Document-Number: 324645-006
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH) -
Datasheet
Document-Number: 326776-003
Change-Id: I31711e24f852e68b3c113e3bd9243dc7e89ac197
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2961
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds correspondings #defines for the PCI IDs of the LPC device on
Intel's Cougar Point and Panther Point platform controller hubs. Those
will be used more in later commits.
I've checked all those IDs against the specification updates [1] and [2].
[1] Intel 6 Series Chipset and Intel C200 Series Chipset Specification
Update
Document-Number: 324646-019
[2] Intel 7 Series / C216 Chipset Family Platform Controller Hub (PCH)
Family - Datasheet Specification Update
Document-Number: 326777-010
Change-Id: Ibef5a30d283c568c345eb8d8149723e7a3049272
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2960
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If you have a recent version of texinfo installed, building the reference
toolchain fails with the following error:
(in util/crossgcc/build-gcc/crossgcc-build.log)
[...]/gcc-4.7.2/gcc/doc/cppopts.texi:806: @itemx must follow @item
Looks like a warning-became-an-error problem in texinfo, to me. Fix that by
making every erroneous @itemx an @item.
Change-Id: I685ae1ecfee889b7c857b148cfab7411a10e7ecd
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/2939
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Add support for filling in the Firmware Interface Table.
For now it only supports adding microcode entries.
It takes 2 options:
1. Name of file in cbfs where the mircocode is located
2. The number of empty entries in the table.
Verified with go firmware tools. Also commented out updating
microcode in the bootblock. When romstage runs, the CPUs indicate
their microcode is already loaded.
Change-Id: Iaccaa9c226ee24868a5f4c0ba79729015d15bbef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2712
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
- The read-only structures are const now
- cosmetic fixes
- put { on a new line for functions
- move code after structures
Change-Id: Ib9131b80242b91bd5105feaebdf8306a844da1cc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2922
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
