Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234063
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With the Storm image layout reworked, the very first blob read out of
NOR SPI flash by the IPQ8064 maskrom is supposed to be a concatenation
of three binaries: one to run on RPM, another one to run on AP, and
the third one - the actual coreboot bootblock.
This layout allows to greatly reduce the size and complexity of the
two first blobs, as they do not need to include the SPI driver.
The first binary in the input file list starts with the combined
header, describing the rest of the blob. This utility copies the first
input file into output, updating the combined header with the total
size of the concatenated binaries.
The second and third binaries in the combined image are required to be
aligned at 256 byte offset in the file as calculated off the end of
the combined header. The new utility allows to concatenate two or
three files, always expecting the first file to be prepended by the
combined header.
For further reference below is the utility's help message:
mbncat.py: [-v] [-h] [-o Output MBN] sbl1 sbl2 [bootblock]
Concatenates up to three mbn files: two SBLs and a coreboot bootblock
-h This message
-v verbose
-o Output file name, (default: sbl-ro.mbn)
BRANCH=none
BUG=chrome-os-partner:34161
TEST=run the new utility and compared the result with the output of
the vendor provided tool. The output files are exactly the same.
Change-Id: I00724f7c75703fc90d7971c3cb337c33ca96f2b5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232047
Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229975
When only one argument is passed on the command line, consider this
argument the name of the BIMG formatted file, and verity its
integrity.
Updated the help/usage text to match new behavior.
BRANCH=none
BUG=none
TEST=when the corrupted coreboot BIMG image is passed as the only
argument, this utility reports the problem. With the build fixed,
the check passes without errors (the second invocation below).
$ build/util/bimgtool/bimgtool /build/urara/firmware/coreboot.rom.serial
Data header CRC mismatch at 0
$ build/util/bimgtool/bimgtool /build/urara/firmware/coreboot.rom.serial
$
Change-Id: Ie56f87f99838891d8e341d7989c614efbcabe0cd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/227522
Reviewed-by: Zdenko Pulitika <zdenko.pulitika@imgtec.com>
Tested-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
This patch adds a missing break statement in cbfstool's option parser.
This should reduce the chance of your bootblock file name suddenly
being a number after you swapped the order of some flags, and might save
you an hour of debugging and growing insanity.
Also removing a nearby empty line that looks out of place
BRANCH=None
BUG=None
TEST=Manual
Change-Id: I9beebdf29e4fc4aa645581146fdc61c659de72df
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229973
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Switched to CRC 16 as it's 40% faster than CRC x25.
Both CRC 16 and CRC x25 are supported and either can be selected through
define directives.
BUG=chrome-os-partner:31438
TEST=built urara bootblock and verified content of bootblock.bin, observed
expected content; ran it on Pistachio FPGA and observed that its
content is read properly by bootrom.
BRANCH=none
Change-Id: If1a78350e0b48d91bfe64ead45f852f44ba3cf9a
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/226840
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Allow add-stage to have an optional parameter for ignoring any section. This is
required to ensure proper operation of elf_to_stage in case of loadable segments
with zero filesize.
BUG=None
BRANCH=None
TEST=Compiles successfully for falco and boots to kernel prompt
Change-Id: Ife0594927e67eca5be6ecba2c93be3b8e517a28a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226168
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Change cbfs-mkstage to use parsed elf instead of calling elf_headers. That
allows us to have access to the complete elf including the string table.
BUG=None
BRANCH=None
TEST=Compiles successfully for falco and creates coreboot.rom image that boots
fine on falco.
Change-Id: I222ef8afa5e1fcbb54ebb45e804bb341a796872d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/226167
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
In the great tradition of LinuxBIOS this allows adding
a kernel as payload. add-payload is extended to also
allow adding an initial ramdisk (-I filename) and a
command line (-C console=ttyS0).
BUG=None
BRANCH=None
TEST=Compiles successfully
Change-Id: Icf09bb2e22e62b38c6332c38e650ec19605b47b8
Signed-off-by: Furquan Shaikh <furquan@google.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3302
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/222623
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
The default mapping size is 1MiB of ram. However, not
all systems allow 1MiB of memory to mapped depending on
the kernel's memory map. Therefore, be explicit about
the sizes to mmap().
The only path that wasn't cleaned up was the coverage path
as that needs to handle dynamic cbmem. The correct way to
fix that is to add a global like the timestamps that is set
while parsing cbtable.
BUG=chrome-os-partner:31355
BRANCH=None
TEST=Can cbmem -ltc on ryu.
Change-Id: I27b70ae8a8fba168d1c1829bbef0135c7b651eac
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221971
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
In some cases the cbmem console can be larger than the default
mapping size of 1MiB. Therefore, add the ability to do a mapping
that is larger than the default mapping using map_memory_size().
The console printing code will unconditionally map the console based
on the size it finds in the cbmem entry.
Change-Id: I016420576b9523ce81195160ae86ad16952b761c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5440
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/221970
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Danube has become Pistachio, let's rename all instances where this SOC
is mentioned.
BUG=none
TEST=board urara still builds
Change-Id: Ie5ede401c4f69ed5d832a9eabac008eeac6db62d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/220401
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built secmon which had this type of relocation.
Change-Id: If170d9e270daf3153e92d16c06516915c727e930
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/218843
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Since coreboot is a third-party project, we use standard copyright
headers instead of the ChromiumOS version which refers to a LICENSE
file we don't have.
BUG=none
BRANCH=none
TEST=none
Change-Id: I6caf0268ab0dd7d1734d4ee98c1321607d2bd66a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216478
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to enumerate CPU devices that are non-x86 (read: no lapic)
provide a generic 'cpu' device.
Upstream patch: http://review.coreboot.org/#/c/6824/
BUG=chrome-os-partner:31761
BRANCH=None
TEST=Built a device tree with 'cpu' entries.
Change-Id: Ic3aa09970e5dd3d175048d698f74e2cce790dff0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/216424
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The upcoming MIPS toolchain inside chroot generates elf images of
elf32-tradlittlemips format, whereas readily available tools outside
of chroot generate images of elf32-littlemips format. Both of these
formats are perfectly fine, but xcompile accepts only one format per
CPU architecture.
This patch allows to specify multiple formats per architecture, any
matching format will suffice.
BUG=chrome-os-partner:31438
TEST=emerged arm, x86 and mips targets inside chroot
Change-Id: I22405e71ac72b985fad51e2f5d7cc014107b8a9e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/214599
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
MIPS targets should be compiled with no position independent code
allowed, as the generated image often does not support short range
components reference.
BUG=chrome-os-partner:31438
TEST=with the rest of the patches included MIPS board urara builds
successfully
Change-Id: I637dd44eb565447c18b2c3cdb022d0933c52fd20
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/215677
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new utility named bimgtool, a simple tool which generates boot
images in the BIMG format. This is the format the Danube boot ROM
expects the user supplied code to be wrapped in, it is described by
struct bimg_header in the code.
This utility will be used to wrap the coreboot bootblock when building
Danube targets.
BUG=chrome-os-partner:31438
TEST=none yet
Change-Id: I63b9f5e09cd1f12765317b38e2a0dd033cdd6d39
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207975
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Apparently when I originally wrote this I confused myself to no end.
The code/data of an rmodule has a set memory size which is associated
with the .payload section. The relocation entries may increase the
overall footprint of the memory size if the rmodule has no bss but
a lot of relocations. Therefore, just compare relocation entries size
plus the file size of the .payload section with the memory size of the
paylod section. The .empty section is added only when we have not met
the final target size.
BUG=chrome-os-partner:31615
BRANCH=None
TEST=Compiles successfully and the elf.rmod created is verified using readelf
and objdump
Change-Id: I67d8c1267b2216786019eadc02f48b6502026602
Author: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214324
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
The sh_flags for a 64-bit section header entry are 64-bit in size. Correct
this.
BUG=chrome-os-partner:31615
BRANCH=None
TEST=Compiles successfully and the elf.rmod created is verified using readelf
and objdump
Change-Id: I3fd2c19116c375f7321ae83d70e8f20509c6f4c1
Author: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/214323
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Specify a CBFS architecture value for MIPS & allow cbfstool to make
use of it.
Change-Id: I604d61004596b65c9903d444e030241f712202bd
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/207971
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch introduces support for building a MIPS cross compiler
targetting little endian machines by default.
Change-Id: I116f6f431cdf80f5f5f58d2743357a9f70a7347d
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-on: https://chromium-review.googlesource.com/207970
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Whatever this variable was intended for, it doesn't appear to have
any purpose now.
BUG=none
BRANCH=none
TEST=buildgcc -p armv7a-eabi still works
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I618c6c05c95face6c902e626a3574700bea12153
Reviewed-on: https://chromium-review.googlesource.com/208145
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Remove the arch check for each stage as the arch for different stages can be
different based on the SoC. e.g.: Rush has arm32-based romstage whereas
arm64-based ramstage
BUG=None
BRANCH=None
TEST=Compiles succesfully for nyan, link and rush
Change-Id: I561dab5a5d87c6b93b8d667857d5e181ff72e35d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/205761
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
For arm64, the machine type is arm64 in cbfstool, however it was displayed as
aarch64 in help message. This patch corrects it.
BUG=None
BRANCH=None
TEST=None
Change-Id: I0319907d6c9d136707ed35d6e9686ba67da7dfb2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/204379
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
This patch brings the cbmem utility in line with the recent change to
coreboot's device tree binding. Since trying to find the right node to
place this binding has been so hard (and still isn't quite agreed upon),
and because it's really the more correct thing to do, this code searches
through the device tree for the 'coreboot' compatible property instead
of looking up a hardcoded path. It also provides bullet-proof
'#address-cells' handling that should work for any endianness and size.
BUG=chrome-os-partner:29311
TEST=Ran cbmem -c and cbmem -t on Nyan_Big. Also straced the to make
sure everything looks as expected. 'time cbmem -t' = ~35ms shows that
there is no serious performance problem from the more thorough lookup
code.
Change-Id: I806a21270ba6cec6e81232075749016eaf18508b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/204274
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
In https://chromium-review.googlesource.com/181272 the payload->type has been
changed to big-endian (network ordering) but the cbfs_image is still parsing
type as host ordering, which caused printing cbfs image verbosely
(cbfstool imge print -v) would fail to find entry field and print numerous
garbage output.
Payload fields should be always parsed in big-endian (network ordering).
BUG=none
TEST=make; cbfstool image.bin print -v -v -v # see payloads correctly
Change-Id: If1ac355b8847fb54988069f694bd2f317ce49a1a
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200158
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Add support for enabling different coreboot stages (bootblock, romstage and
ramstage) to have arm64 architecture. Most of the files have been copied over
from arm/ or arm64-generic work.
BUG=None
BRANCH=None
TEST=Compiled successfully for rush board with bootblock being armv4 and
romstage and ramstage being armv8
Change-Id: Icd59bec55c963a471a50e30972a8092e4c9d2fb2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/197397
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
CBMEM IDs are converted to symbolic names by both target and host
code. Keep the conversion table in one place to avoid getting out of
sync.
BUG=none
TEST=manual
. the new firmware still displays proper CBMEM table entry descriptions:
coreboot table: 276 bytes.
CBMEM ROOT 0. 5ffff000 00001000
COREBOOT 1. 5fffd000 00002000
. running make in util/cbmem still succeeds
Change-Id: I0bd9d288f9e6432b531cea2ae011a6935a228c7a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199791
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CONFIG_ARCH is a property of the cpu or soc rather than a property of the
board. Hence, move ARCH_* from every single board to respective cpu or soc
Kconfigs. Also update abuild to ignore ARCH_ from mainboards.
BUG=None
BRANCH=None
TEST=Compiled successfully for all mainboard/google boards. Successfully booted
link image.
Change-Id: I42323ac33c236d26654a26b591378781aeecabd4
Reviewed-on: https://chromium-review.googlesource.com/195350
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Patch to rename coreboot_ram stage to ramstage. This is done in order to provide
consistency with other stage names(bootblock, romstage) and to allow any
Makefile rule generalization. (Required for patches to be submitted later)
CQ-DEPEND=CL:195101
BUG=None
BRANCH=None
TEST=Compiled successfully for all boards under mainboard/google/. Image booted
successfully on link board
Change-Id: I3e2495fc6a5cc91695ae04ffb438dd4ac265be64
Reviewed-on: https://chromium-review.googlesource.com/195059
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
It turns out that for SBL3 to load the next phase, the sizes int the
MBN header must be 4 byres aligned. This change makes sure that this
requirement is enforced.
BRANCH=None
BUG=chrome-os-partner:28137
TEST=manual
. examined the generated header, observed the size field aligned
. the new image gets successfully started by the SBL3 on ap148
Change-Id: Ia64f04bb281ae772b060d2f7713c98dd348972ba
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196167
Modify the utility to become a Linux executable. While at it, fix the
program name reported by error messages.
BRANCH=None
BUG=chrome-os-partner:27784
TEST=manual
$ ./util/ipqheader/ipqheader.py
ipqheader.py: incorrect number of arguments
Usage: ipqheader.py <base-addr> <input-file> <output-file>
Change-Id: I25061d43fdea72655a696deb9e494e9c7382f670
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193495
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
This is an as is copy of the tool provided by the vendor. It adds a
header which tells the early stage loader where to load the next phase
blob for execution. It is going to be used to encapsulate the
bootblock.
Usage of this tool is as follows:
ipqheader.py <base-addr> <input-file> <output-file>
BRANCH=None
BUG=chrome-os-partner:27784
TEST=none yet
Change-Id: I448c006719f4f3dd5a6716ff2e47f7fc275c805e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193494
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Add support for creating ARM rmodules. There are 3 expected
relocations for an ARM rmodule:
- R_ARM_ABS32
- R_ARM_THM_PC22
- R_ARM_THM_JUMP24
R_ARM_ABS32 is the only type that needs to emitted for relocation
as the other 2 are relative relocations.
BUG=chrome-os-partner:27094
BRANCH=None
TEST=Built vbootstub for ARM device.
Change-Id: I0c22d4abca970e82ccd60b33fed700b96e3e52fb
Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Reviewed-on: https://chromium-review.googlesource.com/190922
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
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>
