summaryrefslogtreecommitdiff
path: root/src/arch/arm64
AgeCommit message (Collapse)Author
2018-07-02src: Get rid of unneeded whitespaceElyes HAOUAS
Change-Id: I3873cc8ff82cb043e4867a6fe8c1f253ab18714a Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/27295 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-06-26arm64: Reimplement mmu_disable() in assemblyJulius Werner
Disabling the MMU with proper cache behavior is a bit tricky on ARM64: you can flush the cache first and then disable the MMU (like we have been doing), but then you run the risk of having new cache lines allocated in the tiny window between the two, which may or may not become a problem when those get flushed at a later point (on some platforms certain memory regions "go away" at certain points in a way that makes the CPU very unhappy if it ever issues a write cycle to them again afterwards). The obvious alternative is to first disable the MMU and then flush the cache, ensuring that every memory access after the flush already has the non-cacheable attribute. But we can't just flip the order around in the C code that we have because then those accesses in the tiny window in-between will go straight to memory, so loads may yield the wrong result or stores may get overwritten again by the later cache flush. In the end, this all shouldn't really be a problem because we can do both operations purely from registers without doing any explicit memory accesses in-between. We just have to reimplement the function in assembly to make sure the compiler doesn't insert any stack accesses at the wrong points. Change-Id: Ic552960c91400dadae6f130b2521a696eeb4c0b1 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27238 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-06-26arm64: Switch remaining uses of __ASSEMBLY__ to __ASSEMBLER__Julius Werner
Some arm64 files that were imported from other projects use the __ASSEMBLY__ macro to test whether a header is included from a C or an assembly file. This patch switches them to the coreboot standard __ASSEMBLER__, which has the advantage of being a GCC builtin so that the including file doesn't have to supply it explicitly. Change-Id: I1023f72dd13857b14ce060388e97c658e748928f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27237 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-06-26arm64: Drop dead file stage_entry.SJulius Werner
This file has been dead since commit 7dcf9d51 (arm64: tegra132: tegra210: Remove old arm64/stage_entry.S), I just forgot to remove it. Change-Id: I0dd6666371036ecd42c1b256dbbe22a01ae959b8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/27236 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2018-06-19lib: Add FIT payload supportPatrick Rudolph
* Add support for parsing and booting FIT payloads. * Build fit loader code from depthcharge. * Fix coding style. * Add Kconfig option to add compiletime support for FIT. * Add support for initrd. * Add default compat strings * Apply optional devicetree fixups using dt_apply_fixups Starting at this point the CBFS payload/ can be either SELF or FIT. Tested on Cavium SoC: Parses and loads a Linux kernel 4.16.3. Tested on Cavium SoC: Parses and loads a Linux kernel 4.15.0. Tested on Cavium SoC: Parses and loads a Linux kernel 4.1.52. Change-Id: I0f27b92a5e074966f893399eb401eb97d784850d Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25019 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
2018-06-19lib/prog_loaders: Move argument selection into selfloadPatrick Rudolph
Set the payload argument in selfload, as other (non self) payloads, are going to set a different argument. Change-Id: I994f604fc4501e0e3b00165819f796b1b8275d8c Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25861 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-24src: Add space after 'while'Elyes HAOUAS
Change-Id: I44cdb6578f9560cf4b8b52a4958b95b65e0cd57a Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/26464 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
2018-05-22Introduce bootblock self-decompressionJulius Werner
Masked ROMs are the silent killers of boot speed on devices without memory-mapped SPI flash. They often contain awfully slow SPI drivers (presumably bit-banged) that take hundreds of milliseconds to load our bootblock, and every extra kilobyte of bootblock size has a hugely disproportionate impact on boot speed. The coreboot timestamps can never show that component, but it impacts our users all the same. This patch tries to alleviate that issue a bit by allowing us to compress the bootblock with LZ4, which can cut its size down to nearly half. Of course, masked ROMs usually don't come with decompression algorithms built in, so we need to introduce a little decompression stub that can decompress the rest of the bootblock. This is done by creating a new "decompressor" stage which runs before the bootblock, but includes the compressed bootblock code in its data section. It needs to be as small as possible to get a real benefit from this approach, which means no device drivers, no console output, no exception handling, etc. Besides the decompression algorithm itself we only include the timer driver so that we can measure the boot speed impact of decompression. On ARM and ARM64 systems, we also need to give SoC code a chance to initialize the MMU, since running decompression without MMU is prohibitively slow on these architectures. This feature is implemented for ARM and ARM64 architectures for now, although most of it is architecture-independent and it should be relatively simple to port to other platforms where a masked ROM loads the bootblock into SRAM. It is also supposed to be a clean starting point from which later optimizations can hopefully cut down the decompression stub size (currently ~4K on RK3399) a bit more. NOTE: Bootblock compression is not for everyone. Possible side effects include trying to run LZ4 on CPUs that come out of reset extremely underclocked or enabling this too early in SoC bring-up and getting frustrated trying to find issues in an undebuggable environment. Ask your SoC vendor if bootblock compression is right for you. Change-Id: I0dc1cad9ae7508892e477739e743cd1afb5945e8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/26340 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-16Revert "cbfs/payload type: Fix build warning and whitespace in name"Ronald G. Minnich
This reverts commit 717ba748366cda19b7532897a5b8d59fc2cd25d9. This breaks seabios and a few other payloads. This is not ready for use. Change-Id: I48ebe2e2628c11e935357b900d01953882cd20dd Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: https://review.coreboot.org/26310 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-05-15cbfs/payload type: Fix build warning and whitespace in namePaul Menzel
Currently, adding a payload to CBFS using the build system, the warning below is shown. W: Unknown type 'payload' ignored Update payload type from "simple elf" to "simple_elf" and rename the word "payload" to "simple_elf" in all Makefiles. Fixes: 4f5bed52 (cbfs: Rename CBFS_TYPE_PAYLOAD to CBFS_TYPE_SELF) Change-Id: Iccf6cc889b7ddd0c6ae04bda194fe5f9c00e495d Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/26240 Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-14pci: Fix compilation on non x86Patrick Rudolph
* Introduce pci_devfn_t on all arch * Add PCI function prototypes in arch/pci_ops.h * Remove unused pci_config_default() Change-Id: I71d6f82367e907732944ac5dfaabfa77181c5f20 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25723 Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-05-04lib/bootmem: Add more bootmem tagsPatrick Rudolph
Introduce new bootmem tags to allow more fine grained control over buffer allocation on various platforms. The new tags are: BM_MEM_RAMSTAGE : Memory where any kind of boot firmware resides and that should not be touched by bootmem (by example: stack, TTB, program, ...). BM_MEM_PAYLOAD : Memory where any kind of payload resides and that should not be touched by bootmem. Starting with this commit all bootmem methods will no longer see memory that is used by coreboot as usable RAM. Bootmem changes: * Introduce a weak function to add platform specific memranges. * Mark memory allocated by bootmem as BM_TAG_PAYLOAD. * Assert on failures. * Add _stack and _program as BM_MEM_RAMSTAGE. ARMv7 and ARMv8 specific changes: * Add _ttb and _postram_cbfs_cache as BM_MEM_RAMSTAGE. ARMv7 specific changes: * Add _ttb_subtables as BM_MEM_RAMSTAGE. Change-Id: I0c983ce43616147c519a43edee3b61d54eadbb9a Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25383 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-05-03pci: Add dummy file for ARM64Patrick Rudolph
Add stub files to support compiling the PCI driver on ARCH_ARM64. Change-Id: Iaff20463375d1e3ec573d9486a859a0514b0b390 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/25722 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2018-04-30arm64: Add ARCH TimerT Michael Turney
SoC sdm845 uses ARCH Timer Change-Id: I45e2d4d2c16a2cded3df20d393d2b8820050ac80 Signed-off-by: T Michael Turney <mturney@codeaurora.org> Reviewed-on: https://review.coreboot.org/25612 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-04-30arm64: Add mmu context save/restore APIsT Michael Turney
New API required by sdm845 DDR init/training protocol TEST=build & run Change-Id: I8442442c0588dd6fb5e461b399e48a761f7bbf29 Signed-off-by: T Michael Turney <mturney@codeaurora.org> Reviewed-on: https://review.coreboot.org/25818 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-04-24compiler.h: add __weak macroAaron Durbin
Instead of writing out '__attribute__((weak))' use a shorter form. Change-Id: If418a1d55052780077febd2d8f2089021f414b91 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/25767 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Justin TerAvest <teravest@chromium.org>
2018-03-23arch/arm64/armv8/mmu: Add support for 48bit VAPatrick Rudolph
The VA space needs to be extended to support 48bit, as on Cavium SoCs the MMIO starts at 1 << 47. The following changes were done to coreboot and libpayload: * Use page table lvl 0 * Increase VA bits to 48 * Enable 256TB in MMU controller * Add additional asserts Tested on Cavium SoC and two ARM64 Chromebooks. Change-Id: I89e6a4809b6b725c3945bad7fce82b0dfee7c262 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/24970 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-02-12arm64: Add read64() and write64()David Hendricks
Change-Id: I89cf4b996405af616f54cf2d9fabd4e258352b03 Signed-off-by: David Hendricks <dhendricks@fb.com> Reviewed-on: https://review.coreboot.org/23036 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-02-12armv8: Allow for ARMv8 extensions to be chosenDavid Hendricks
There are now a few architectural extensions available for ARMv8, some of which introduce instructions or other features that may be useful. This allows the user to select an extension implemented on their SoC which will set the -march option passed into the compiler. Change-Id: Ifca50dad98aab130ac04df455bac2cfb65abf82e Signed-off-by: David Hendricks <dhendricks@fb.com> Reviewed-on: https://review.coreboot.org/23641 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2018-02-02arm64: Pass COREBOOT flag to ARM TF, always enable loggingJulius Werner
This patch changes the way coreboot builds ARM TF to pass the new COREBOOT flag introduced with the following pull request: https://github.com/ARM-software/arm-trusted-firmware/pull/1193 Since the new coreboot support code supports the CBMEM console, we need to always enable LOG_LEVEL INFO. Supporting platforms will parse the coreboot table to conditionally enable the serial console only if it was enabled in coreboot as well. Also remove explicit cache flushes of some BL31 parameters. Turns out we never really needed these because we already flush the whole cache when disabling the MMU, and we were already not doing it for most parameters. Change-Id: I3c52a536dc6067da1378b3f15c4a4d6cf0be7ce7 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/23558 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-06-02arch/arm: Correct checkpatch errorsLogan Carlson
Correct whitespace issues in arch/arm and arch/arm64. Enclose complex values in parenthesis. Change-Id: I74b68f485adff1e6f0fa433e51e12b59ccea654b Signed-off-by: Logan Carlson <logancarlson@google.com> Reviewed-on: https://review.coreboot.org/19989 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
2017-05-30arm64: Align cache maintenance code with libpayload and ARM32Julius Werner
coreboot and libpayload currently use completely different code to perform a full cache flush on ARM64, with even different function names. The libpayload code is closely inspired by the ARM32 version, so for the sake of overall consistency let's sync coreboot to that. Also align a few other cache management details to work the same way as the corresponding ARM32 parts (such as only flushing but not invalidating the data cache after loading a new stage, which may have a small performance benefit). Change-Id: I9e05b425eeeaa27a447b37f98c0928fed3f74340 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/19785 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-05-183rdparty/arm-trusted-firmware: Update to upstream masterMartin Roth
Submodule 3rdparty/arm-trusted-firmware 236c27d21f..3944adca59 This brings in 241 new commits from the upstream arm-trusted-firmware repository, merged to the upstream tree between December 30, 2016 and March 18, 2017. 3944adca Merge pull request #861 from soby-mathew/sm/aarch32_fixes .. e0f083a0 fiptool: Prepare ground for expanding the set of images at runtime Also setup ATF builds so that unused functions don't break the build. They're harmless and they don't filter for these like we do. Change-Id: Ibf5bede79126bcbb62243808a2624d9517015920 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/18954 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2017-05-16arch/arm64: Use variables of the right size for msr/mrs opcodesPatrick Georgi
They do 64bit accesses, and gcc does the necessary fix ups to handle 32bit values as zero-padded 64bit values. clang, however, isn't happy with it. Change-Id: I9c8b9fe3a1adc521e393c2e2a0216f7f425a2a3e Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/19661 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2017-03-28Remove libverstage as separate library and source file classJulius Werner
In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are linked directly into the bootblock or the romstage. However, they're still compiled with a separate "libverstage" source file class, linked into an intermediate library and then linked into the final destination stage. There is no obvious benefit to doing it this way and it's unclear why it was chosen in the first place... there are, however, obvious disadvantages: it can result in code that is used by both libverstage and the host stage to occur twice in the output binary. It also means that libverstage files have their separate compiler flags that are not necessarily aligned with the host stage, which can lead to weird effects like <rules.h> macros not being set the way you would expect. In fact, VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86 because their libverstage code that gets compiled into the romstage sets ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to run pre-migration. This patch resolves these problems by removing the separate library. There is no more difference between the 'verstage' and 'libverstage' classes, and the source files added to them are just treated the same way a bootblock or romstage source files in configurations where the verstage is linked into either of these respective stages (allowing for the normal object code deduplication and causing those files to be compiled with the same flags as the host stage's files). Tested this whole series by booting a Kevin, an Elm (both with and without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode. Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18302 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2017-03-28arm64: Fix verstage to use proper assembly versions of mem*()Julius Werner
Due to an unfortunate race between adding verstage support and reverting an earlier hack that disabled the optimized assembly versions of memcpy(), memmove() and memset() on ARM64, it seems that we never enabled the optimized code for the verstage. This should be fixed so that all stages use the same architecture support code. Change-Id: I0bf3245e346105492030f4b133729c4d11bdb3ff Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/18976 Tested-by: build bot (Jenkins)
2017-02-24arm-trusted-firmware: Disable a couple of warnings for GCC 6.2Martin Roth
- Remove warnings about code using deprecated declarations such as: plat/mediatek/mt8173/bl31_plat_setup.c: In function 'bl31_platform_setup': plat/mediatek/mt8173/bl31_plat_setup.c:175:2: warning: 'arm_gic_setup' is deprecated [-Wdeprecated-declarations] include/drivers/arm/arm_gic.h:44:6: note: declared here: void arm_gic_setup(void) __deprecated; - Disable pedantic warnings to get rid of these warnings: In file included from plat/mediatek/mt8173/bl31_plat_setup.c:36:0: plat/mediatek/mt8173/include/mcucfg.h:134:21: error: enumerator value for 'MP1_CPUCFG_64BIT' is not an integer constant expression [-Werror=pedantic] MP1_CPUCFG_64BIT = 0xf << MP1_CPUCFG_64BIT_SHIFT Change-Id: Ibf2c4972232b2ad743ba689825cfe8440d63e828 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/17995 Tested-by: build bot (Jenkins) Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Nico Huber <nico.h@gmx.de>
2017-01-31build system: mark sub-make invocations as parallelizablePatrick Georgi
We rely on gnu make, so we can expect the jobserver to be around in parallel builds, too. Avoids some make warnings and slightly speeds up the build if those sub-makes are executed (eg for arm-trusted-firmware and vboot). Change-Id: I0e6a77f2813f7453d53e88e0214ad8c1b8689042 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/18263 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-12-08buildsystem: Drop explicit (k)config.h includesKyösti Mälkki
We have kconfig.h auto-included and it pulls config.h too. Change-Id: I665a0a168b0d4d3b8f3a27203827b542769988da Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/17655 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2016-11-17arm64: arm_tf: Do not build raw bl31.bin binaryJulius Werner
coreboot's build system picks up the BL31 image as an ELF from the ARM Trusted Firmware submodule and inserts it into CBFS. However, the generic 'bl31' build target we run in the ARM Trusted Firmware build system also generates a raw bl31.bin binary file. We don't need that binary, and with the recently added support for multiple non-contiguous program segments in BL31 it can grow close to 4GB in size (by having one section mapped near the start and one near the end of the address space). To avoid clogging up people's hard drives with 4GB of zeroes, let's only build the target we actually need. BRANCH=gru BUG=chrome-os-partner:56314,chromium:661124 TEST=FEATURES=noclean emerge-kevin coreboot, confirm that there's no giant build/3rdparty/arm-trusted-firmware/bl31.bin file left in the build artifacts, and that we still generate .d prerequisite files. Change-Id: I8e7bd50632f7831cc7b8bec69025822aec5bad27 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 31699820f4c36fd441a3e7271871af4e1474129f Original-Change-Id: Iaa073ec11dabed7265620d370fcd01ea8c0c2056 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/407110 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/17380 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-10-06arm64: Use 'payload' format for ATF instead of 'stage'Simon Glass
Switch the BL31 (ARM Trusted Firmware) format to payload so that it can have multiple independent segments. This also requires disabling the region check since SRAM is currently faulted by that check. This has been tested with Rockchip's pending change: https://chromium-review.googlesource.com/#/c/368592/3 with the patch mentioned on the bug at #13. BUG=chrome-os-partner:56314 BRANCH=none TEST=boot on gru and see that BL31 loads and runs. Im not sure if it is correct though: CBFS: Locating 'fallback/payload' CBFS: Found @ offset 1b440 size 15a75 Loading segment from ROM address 0x0000000000100000 code (compression=1) New segment dstaddr 0x18104800 memsize 0x117fbe0 srcaddr 0x100038 filesize 0x15a3d Loading segment from ROM address 0x000000000010001c Entry Point 0x0000000018104800 Loading Segment: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d lb: [0x0000000000300000, 0x0000000000320558) Post relocation: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d using LZMA [ 0x18104800, 18137d90, 0x192843e0) <- 00100038 Clearing Segment: addr: 0x0000000018137d90 memsz: 0x000000000114c650 dest 0000000018104800, end 00000000192843e0, bouncebuffer ffffffffffffffff Loaded segments BS: BS_PAYLOAD_LOAD times (us): entry 0 run 125150 exit 1 Jumping to boot code at 0000000018104800(00000000f7eda000) CPU0: stack: 00000000ff8ec000 - 00000000ff8f0000, lowest used address 00000000ff8ef3d0, stack used: 3120 bytes CBFS: 'VBOOT' located CBFS at [402000:44cc00) CBFS: Locating 'fallback/bl31' CBFS: Found @ offset 10ec0 size 8d0c Loading segment from ROM address 0x0000000000100000 code (compression=1) New segment dstaddr 0x10000 memsize 0x40000 srcaddr 0x100054 filesize 0x8192 Loading segment from ROM address 0x000000000010001c code (compression=1) New segment dstaddr 0xff8d4000 memsize 0x1f50 srcaddr 0x1081e6 filesize 0xb26 Loading segment from ROM address 0x0000000000100038 Entry Point 0x0000000000010000 Loading Segment: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192 lb: [0x0000000000300000, 0x0000000000320558) Post relocation: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192 using LZMA [ 0x00010000, 00035708, 0x00050000) <- 00100054 Clearing Segment: addr: 0x0000000000035708 memsz: 0x000000000001a8f8 dest 0000000000010000, end 0000000000050000, bouncebuffer ffffffffffffffff Loading Segment: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26 lb: [0x0000000000300000, 0x0000000000320558) Post relocation: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26 using LZMA [ 0xff8d4000, ff8d5f50, 0xff8d5f50) <- 001081e6 dest 00000000ff8d4000, end 00000000ff8d5f50, bouncebuffer ffffffffffffffff Loaded segments INFO: plat_rockchip_pmusram_prepare pmu: code d2bfe625,d2bfe625,80 INFO: plat_rockchip_pmusram_prepare pmu: code 0xff8d4000,0x50000,3364 INFO: plat_rockchip_pmusram_prepare: data 0xff8d4d28,0xff8d4d24,4648 NOTICE: BL31: v1.2(debug): NOTICE: BL31: Built : Sun Sep 4 22:36:16 UTC 2016 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: plat_rockchip_pmu_init(1189): pd status 3e INFO: BL31: Initializing runtime services INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x18104800 INFO: SPSR = 0x8 Change-Id: Ie2484d122a603f1c7b7082a1de3f240aa6e6d540 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 8c1d75bff6e810a39776048ad9049ec0a9c5d94e Original-Change-Id: I2d60e5762f8377e43835558f76a3928156acb26c Original-Signed-off-by: Simon Glass <sjg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/376849 Original-Commit-Ready: Simon Glass <sjg@google.com> Original-Tested-by: Simon Glass <sjg@google.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/16706 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-09-20arm_tf: Fix code style nits and commentsSimon Glass
Tidy up a few things which look incorrect in this file. BUG=chrome-os-partner:56314 BRANCH=none TEST=build for gru Signed-off-by: Martin Roth <martinroth@chromium.org> Original-Commit-Id: 434e9ceb5fce69b28de577cdc3541a439871f5ed Original-Change-Id: Ida7a62ced953107c8e1723003bcb470c81de4c2f Original-Signed-off-by: Simon Glass <sjg@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/376848 Original-Commit-Ready: Simon Glass <sjg@google.com> Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Change-Id: If8c283fe8513e6120de2fd52eab539096a4e0c9b Reviewed-on: https://review.coreboot.org/16584 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-09-12src/arch: Improve code formattingElyes HAOUAS
Change-Id: Ic1ca6c2e1cd06800d7eb2d00ac0b328987d022ef Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/16434 Tested-by: build bot (Jenkins) Reviewed-by: Omar Pakker
2016-08-28src/arch: Capitalize CPU and ACPIElyes HAOUAS
Change-Id: I37dfa853c3dbe93a52f6c37941b17717e22f6430 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/16277 Reviewed-by: Omar Pakker Tested-by: build bot (Jenkins)
2016-08-23arch/arm & arm64: Remove unnecessary whitespace before "\n"Elyes HAOUAS
Change-Id: Ibec78b25c0f330fc8517654761803e8abf203060 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/16282 Tested-by: build bot (Jenkins) Reviewed-by: Omar Pakker Reviewed-by: Martin Roth <martinroth@google.com>
2016-05-24arm64: Add stack dump to exception handlerJulius Werner
Some exceptions (like from calling a NULL function pointer) are easier to narrow down with a dump of the call stack. Let's take a page out of ARM32's book and add that feature to ARM64 as well. Also change the output format to two register columns, to make it easier to fit a whole exception dump on one screen. Applying to both coreboot and libpayload and syncing the output format between both back up. Change-Id: I19768d13d8fa8adb84f0edda2af12f20508eb2db Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/14931 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-10arch/arm64: add FRAMEBUFFER region macros to memlayoutLin Huang
BRANCH=none BUG=chrome-os-partner:51537 TEST=build pass Change-Id: Id3dd3a553370eada1e79708dc71afc2d94d6ce93 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0949b0d9ec12eff7edb3d7de738833f29507c332 Original-Change-Id: I8052f86d4d846e5d544911c5b9e323285083fb5c Original-Signed-off-by: Lin Huang <hl@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/340024 Original-Commit-Ready: Vadim Bendebury <vbendeb@google.com> Original-Tested-by: Shunqian Zheng <zhengsq@rock-chips.com> Original-Reviewed-by: Vadim Bendebury <vbendeb@google.com> Reviewed-on: https://review.coreboot.org/14747 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-05-03build system: remove CBFSTOOL_PRE1_OPTSPatrick Georgi
It isn't used anymore. Change-Id: Ie554d1dd87ae3f55547466e484c0864e55c9d102 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/14567 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-05-02lib/coreboot_table: use the architecture dependent table sizeAaron Durbin
Utilize the architecture dependent coreboot table size value from <arch/cbconfig.h> Change-Id: I80d51a5caf7c455b0b47c380e1d79cf522502a4c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14455 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2016-05-02arch: introduce architecture dependent common variablesAaron Durbin
Stefan and others have discussed their interest in only including options in Kconfig that are directly associated with building a coreboot image. There are variables that are architecture dependent that are utilized in the coreboot infrastructure. To meet that goal, introduce <arch/cbconfig.h> header file which defines variables for the coreboot infrastructure that are architecture dependent but utilized in common infrastructure. Change-Id: Ic4cb9e81bab042797539dce004db0f7ee8526ea6 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14454 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2016-04-21lib: add common write_tables() implementationAaron Durbin
In order to de-duplicate common patterns implement one write_tables() function. The new write_tables() replaces all the architecture-specific ones that were largely copied. The callbacks are put in place to handle any per-architecture requirements. Change-Id: Id3d7abdce5b30f5557ccfe1dacff3c58c59f5e2b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14436 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-04-21lib/coreboot_table: add architecture hooks for adding tablesAaron Durbin
Add a architecture specific function, arch_write_tables(), that allows an architecture to add its required tables for booting. This callback helps write_tables() to be de-duplicated. Change-Id: I805c2f166b1e75942ad28b6e7e1982d64d2d5498 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14435 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-04-21lib/bootmem: allow architecture specific bootmem rangesAaron Durbin
A architecture-specific function, named bootmem_arch_add_ranges(), is added so that each architecture can add entries into the bootmem memory map. This allows for a common write_tables() implementation to avoid code duplication. Change-Id: I834c82eae212869cad8bb02c7abcd9254d120735 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14434 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-04-21arch: only print cbmem entries in one placeAaron Durbin
Each arch was calling cbmem_list() in their own write_tables() function. Consolidate that call and place it in common code in write_coreboot_table(). Change-Id: If0d4c84e0f8634e5cef6996b2be4a86cc83c95a9 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14430 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-04-21arch: use Kconfig variable for coreboot table sizeAaron Durbin
Instead of hard coding a #define in each architecture's tables.c for the coreboot table size in cbmem use a Kconfig varible. This aids in aligning on a common write_tables() implementation instead of duplicating the code for each architecture. Change-Id: I09c0f56133606ea62e9a9c4c6b9828bc24dcc668 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/14429 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-03-09Makefile: Add build-time overlap check for programs loaded after corebootJulius Werner
On non-x86 platforms, coreboot uses the memlayout.ld mechanism to statically allocate the different memory regions it needs and guarantees at build time that there are no dangerous overlaps between them. At the end of its (ramstage) execution, however, it usually loads a payload (and possibly other platform-specific components) that is not integrated into the coreboot build system and therefore cannot provide the same overlap guarantees through memlayout.ld. This creates a dangerous memory hazard where a new component could be loaded over memory areas that are still in use by the code-loading ramstage and lead to arbitrary memory corruption bugs. This patch fills this gap in our build-time correctness guarantees by adding the necessary checks as a new intermediate Makefile target on route to assembling the final image. It will parse the memory footprint information of the payload (and other platform-specific post-ramstage components) from CBFS and compare it to a list of memory areas known to be still in use during late ramstage, generating a build failure in case of a possible hazard. BUG=chrome-os-partner:48008 TEST=Built Oak while moving critical regions in the way of BL31 or the payload, observing the desired build-time errors. Built Nyan, Jerry and Falco without issues for good measure. Change-Id: I3ebd2c1caa4df959421265e26f9cab2c54909b68 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/13949 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2016-02-22die() when attempting to use bounce buffer on non-i386.Vladimir Serbinenko
Only i386 has code to support bounce buffer. For others coreboot would silently discard part of binary which doesn't work and is a hell to debug. Instead just die. Change-Id: I37ae24ea5d13aae95f9856a896700a0408747233 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: https://review.coreboot.org/13750 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-02-19lib/coreboot_table: add function to allow arch code to add recordsAaron Durbin
Add lb_arch_add_records() to allow the architecture code to generically hook into the coreboot table generation. BUG=chrome-os-partner:50214 BRANCH=glados TEST=With all subsequent patches confirmed lb_arch_add_records() is called when a strong symbol is provided. Change-Id: I7c69c0ff0801392bbcf5aef586a48388b624afd4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13669 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com> Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
2016-02-18arch/arm64: Compile arm-trusted-firmware with coreboot timestampPatrick Georgi
Update ATF codebase to a version that supports passing a timestamp and fix the format to what it accepts now (including quotes). This provides reproducible builds. Change-Id: I12a0a2ba1ee7921ad93a3a877ea50309136ab1ab Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13726 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-02-11arches: lib: add main_decl.h for main() declarationAaron Durbin
It is silly to have a single header to declare the main() symbol, however some of the arches provided it while lib/bootblock.c relied on the arch headers to declare it. Just move the declaration into its own header file and utilize it. Change-Id: I743b4c286956ae047c17fe46241b699feca73628 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/13681 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins)
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-25 11:56:20 +0000