summaryrefslogtreecommitdiff
path: root/src/mainboard/emulation/qemu-riscv/Kconfig
AgeCommit message (Collapse)Author
2024-08-20arch/riscv: Remove ram probingMaximilian Brune
Previously RAM probing was necessary for our QEMU-RISCV target in order to find the available amount of memory. Now we get the memory from the devicetree propagated by QEMU, so there is no reason to keep it anymore. Tested: Start QEMU-RISCV and cause an exception to make sure the trap handler still works. Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I9b1e0dc78fc2a66d6085fe99a71245ff46f8e63c Reviewed-on: https://review.coreboot.org/c/coreboot/+/83873 Reviewed-by: Elyes Haouas <ehaouas@noos.fr> Reviewed-by: Nico Huber <nico.h@gmx.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-06-14mainboard/qemu-riscv: Get top of memory from device-tree blobAlper Nebi Yasak
Trying to probe RAM space to figure out top of memory causes an exception on RISC-V virtual machines with recent versions of QEMU, but we temporarily enable exception handlers for that and use it to help detect if a RAM address is usable or not. However, QEMU docs recommend reading device information from the device-tree blob it provides us at the start of RAM. A previous commit adds a library function to parse device-tree blob that QEMU provides us. Use it to determine top of memory in RISC-V QEMU virtual machines, but still fall back to the RAM probing approach as a last-ditch effort. Change-Id: I9e4a95f49ad373675939329eef40d7423a4132ab Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80363 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com>
2024-03-05mb/emulation/qemu-riscv: Change to -bios optionMaximilian Brune
This changes the virt target so that it can be run with the -bios option and a pflash backend for the flash. QEMU can now be run as follows: qemu -M virt -m 1G -nographic -bios build/coreboot.rom \ -drive if=pflash,file=./build/coreboot.rom,format=raw coreboot will start in DRAM, but still have a flash to put CBFS onto and to load subsequent stages and payload from. Tested bootflow: coreboot -> OpenSBI -> Linux -> u-root Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I009d97fa3e13068b91c604e987e50a65e525407d Reviewed-on: https://review.coreboot.org/c/coreboot/+/80746 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: ron minnich <rminnich@gmail.com> Reviewed-by: Philipp Hug <philipp@hug.cx>
2024-03-04riscv/mb/qemu: fix DRAM probingPhilipp Hug
Current version of qemu raise an exception when accessing invalid memory. Modify the probing code to temporary redirect the exception handler like on ARM platform. Also move saving of the stack frame out to trap_util.S to have all at the same place for a future rewrite. TEST=boots to ramstage Change-Id: I25860f688c7546714f6fdbce8c8f96da6400813c Signed-off-by: Philipp Hug <philipp@hug.cx> Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36486 Reviewed-by: ron minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2024-02-22riscv/mb/qemu: fix qemu invocation commentPhilipp Hug
Change-Id: I773fb39801f180fead584942dfb385fcde9d2680 Signed-off-by: Philipp Hug <philipp@hug.cx> Reviewed-on: https://review.coreboot.org/c/coreboot/+/80262 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Maximilian Brune <maximilian.brune@9elements.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: ron minnich <rminnich@gmail.com>
2023-06-28mb/emulation: Enhance ROM_SIZEMaximilian Brune
Some payloads tend to need bigger space than what our current defaults allow. Linuxboot is a good example. Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com> Change-Id: I7029ca3360d936b67ff9873fa13cf9cc60445e56 Reviewed-on: https://review.coreboot.org/c/coreboot/+/76106 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <service+coreboot-gerrit@felixsinger.de>
2022-09-143rdparty/opensbi: Update to latest ToTPatrick Georgi
That's 3 years of development, including adapting to new, shiny, Cascade of Attention-Deficit Teenagers[0] induced incompatible assembler syntaxes. Signed-off-by: Patrick Georgi <patrick@coreboot.org> [0] https://web.archive.org/web/20220824045741/https://www.jwz.org/doc/cadt.html Change-Id: I8606700149ca74e93b85d78546a29df2916d39b2 Reviewed-on: https://review.coreboot.org/c/coreboot/+/67456 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <felixsinger@posteo.net>
2021-07-26mb/*: Specify type of `MAINBOARD_PART_NUMBER` onceAngel Pons
Specify the type of the `MAINBOARD_PART_NUMBER` Kconfig symbol once instead of doing so on each and every mainboard. Change-Id: I3692f9e82fe90af4d0da1d037018a20aa1b45793 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56554 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2021-07-26mb/*: Specify type of `MAINBOARD_DIR` onceAngel Pons
Specify the type of the `MAINBOARD_DIR` Kconfig symbol once instead of doing so on each and every mainboard. Change-Id: If1cc538b0c4938dac193699897b690e402b3c1e8 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/56553 Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Felix Singer <felixsinger@posteo.net> Reviewed-by: Paul Fagerburg <pfagerburg@chromium.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-09-27mb/Kconfig: Drop ROM sizes below 256KiBNico Huber
Not even our emulation targets can build with these anymore. Change-Id: If108a17f824a31c375a43cb4903ee07c65217f6e Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45753 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-06-13treewide: Add Kconfig variable MEMLAYOUT_LD_FILEFurquan Shaikh
This change defines a Kconfig variable MEMLAYOUT_LD_FILE which allows SoC/mainboard to provide a linker file for the platform. x86 already provides a default memlayout.ld under src/arch/x86. With this new Kconfig variable, it is possible for the SoC/mainboard code for x86 to provide a custom linker file as well. Makefile.inc is updated for all architectures to use this new Kconfig variable instead of assuming memlayout.ld files under a certain path. All non-x86 boards used memlayout.ld under mainboard directory. However, a lot of these boards were simply including the memlayout from SoC. So, this change also updates these mainboards and SoCs to define the Kconfig as required. BUG=b:155322763 TEST=Verified that abuild with --timeless option results in the same coreboot.rom image for all boards. Change-Id: I6a7f96643ed0519c93967ea2c3bcd881a5d6a4d6 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/42292 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Raul Rangel <rrangel@chromium.org> Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-18mainboard/*/*/Kconfig*: Remove leading blank lines from SPDX headerElyes HAOUAS
Change-Id: I7089b29e881d74d31477e2df1c5fa043fe353343 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41358 Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-11treewide: Remove "this file is part of" linesPatrick Georgi
Stefan thinks they don't add value. Command used: sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool) The exceptions are for: - crossgcc (patch file) - gcov (imported from gcc) - elf.h (imported from GNU's libc) - nvramtool (more complicated header) The removed lines are: - fmt.Fprintln(f, "/* This file is part of the coreboot project. */") -# This file is part of a set of unofficial pre-commit hooks available -/* This file is part of coreboot */ -# This file is part of msrtool. -/* This file is part of msrtool. */ - * This file is part of ncurses, designed to be appended after curses.h.in -/* This file is part of pgtblgen. */ - * This file is part of the coreboot project. - /* This file is part of the coreboot project. */ -# This file is part of the coreboot project. -# This file is part of the coreboot project. -## This file is part of the coreboot project. --- This file is part of the coreboot project. -/* This file is part of the coreboot project */ -/* This file is part of the coreboot project. */ -;## This file is part of the coreboot project. -# This file is part of the coreboot project. It originated in the - * This file is part of the coreinfo project. -## This file is part of the coreinfo project. - * This file is part of the depthcharge project. -/* This file is part of the depthcharge project. */ -/* This file is part of the ectool project. */ - * This file is part of the GNU C Library. - * This file is part of the libpayload project. -## This file is part of the libpayload project. -/* This file is part of the Linux kernel. */ -## This file is part of the superiotool project. -/* This file is part of the superiotool project */ -/* This file is part of uio_usbdebug */ Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-05-09src/: Replace GPL boilerplate with SPDX headerPatrick Georgi
Command used: perl -i -p0e 's|(\#\#*)[\w*]*.*is[\#\s]*licensed[\#\s]*under[\#\s]*the[\#\s]*terms[\#\s]*of[\#\s]*the[\#\s]*GNU[\#\s]*General[\#\s]*Public[\#\s]*License[\#\s]*version[\#\s]*2,[\#\s]*as[\#\s]*published[\#\s]*by[\#\s]*the[\#\s]*Free[\#\s]*Software[\#\s]*Foundation,[\#\s]*and[\#\s]*may[\#\s]*be[\#\s]*copied,[\#\s]*distributed,[\#\s]*and[\#\s]*modified[\#\s]*under[\#\s]*those[\#\s]*terms.[\#\s]*This[\#\s]*program[\#\s]*is[\#\s]*distributed[\#\s]*in[\#\s]*the[\#\s]*hope[\#\s]*that[\#\s]*it[\#\s]*will[\#\s]*be[\#\s]*useful,[\#\s]*but[\#\s]*WITHOUT[\#\s]*ANY[\#\s]*WARRANTY;[\#\s]*without[\#\s]*even[\#\s]*the[\#\s]*implied[\#\s]*warranty[\#\s]*of[\#\s]*MERCHANTABILITY[\#\s]*or[\#\s]*FITNESS[\#\s]*FOR[\#\s]*A[\#\s]*PARTICULAR[\#\s]*PURPOSE.[\#\s]*See[\#\s]*the[\#\s]*GNU[\#\s]*General[\#\s]*Public[\#\s]*License[\#\s]*for[\#\s]*more[\#\s]*details.\s(#* *\n)*|\1 SPDX-License-Identifier: GPL-2.0-only\n\n|' $(cat filelist) Change-Id: Ia7ce0a78f96563b8dc0f6eb648c4ba4cefb2b838 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/41180 Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-03-18mainboard/[a-f]*: Remove copyright noticesPatrick Georgi
They're listed in AUTHORS and often incorrect anyway, for example: - What's a "Copyright $year-present"? - Which incarnation of Google (Inc, LLC, ...) is the current copyright holder? - People sometimes have their editor auto-add themselves to files even though they only deleted stuff - Or they let the editor automatically update the copyright year, because why not? - Who is the copyright holder "The coreboot project Authors"? - Or "Generated Code"? Sidestep all these issues by simply not putting these notices in individual files, let's list all copyright holders in AUTHORS instead and use the git history to deal with the rest. Change-Id: I57fc98788bb47df16d6aedd0f0701e9991801743 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39606 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com> Reviewed-by: Frans Hendriks <fhendriks@eltan.com> Reviewed-by: Tristan Corrick <tristan@corrick.kiwi>
2019-11-23Kconfig: comply to Linux 5.3's Kconfig language rulesPatrick Georgi
Kconfig became stricter on what it accepts, so accomodate before updating to a new release. Change-Id: I92a9e9bf0d557a7532ba533cd7776c48f2488f91 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/37156 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2019-08-03mb/emulation/qemu-riscv: Add opensbi supportPatrick Rudolph
Tested on qemu-riscv: Boots into Linux until initrd should be loaded. Change-Id: I4aa307c91d37703ad16643e7f8eb7925dede71a8 Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/34143 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
2019-06-28mb/emulation/qemu-riscv: Use generic 8250 uart driverPatrick Rudolph
Drop hacked uart code and use the generic 8250 uart driver for ns16550a. Tested on qemu-system-riscv64: * The UART is still working. Change-Id: I6efda913fa39e0cfa466b52c570572aca90dacdf Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/33735 Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Philipp Hug <philipp@hug.cx> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2019-02-13riscv: Add initial support for 32bit boardsPhilipp Hug
* Adding separate targets for 32bit and 64bit qemu * Using the riscv64 toolchain for 32bit builds requires setting -m elf32lriscv * rv32/rv64 is currently configured with ARCH_RISCV_RV32/RV64 and not per stage. This should probably be changed later. TEST=Boots to "Payload not loaded." on 32bit qemu using the following commands: util/riscv/make-spike-elf.sh build/coreboot.rom build/coreboot.elf qemu-system-riscv32 -M virt -m 1024M -nographic -kernel build/coreboot.elf Change-Id: I35e59b459d1770df10b51fe9e77dcc474d7c75a0 Signed-off-by: Philipp Hug <philipp@hug.cx> Reviewed-on: https://review.coreboot.org/c/31253 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: ron minnich <rminnich@gmail.com>
2019-01-26mb/qemu-riscv: update to match current qemu versionPhilipp Hug
Boots again to payload not found on qemu. Change-Id: Ie107eb882cbaac5a5a06c1ff990e7b9364377640 Signed-off-by: Philipp Hug <philipp@hug.cx> Reviewed-on: https://review.coreboot.org/c/30554 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-11-28mb/*/*/Kconfig: Remove useless commentElyes HAOUAS
Change-Id: Ibdff50761a205d936b0ebe067f418be0a2051798 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/29871 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Hellsenberg <th3fanbus@gmail.com> Reviewed-by: Nico Huber <nico.h@gmx.de> Reviewed-by: David Guckian Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2018-10-22mainboard/: Select MISSING_BOARD_RESET appropriatelyNico Huber
We didn't have a hard_reset() implementation for these boards. So select the board_reset() stub for them. Change-Id: I77651e3844632fb1a347008c96e53d23cc5a2646 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/29170 Reviewed-by: Julius Werner <jwerner@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-10-06mb/emulation/*-riscv: Remove "UCB" from RISC-V board namesJonathan Neuschäfer
RISC-V is not a project of the University of California, Berkeley, anymore; it stands on its own feet now. Remove the "UCB" component from the RISC-V mainboards in the "emulation" directory, and don't set MAINBOARD_VENDOR to UCB, either. Change-Id: I301d9d0091a714e62375052e5af06a9197876688 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/28951 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2017-09-27mb/emu/*-riscv: Remove outdated memory mapJonathan Neuschäfer
Change-Id: I8919719865bc7ae8d13f025999caf8b5836b88ab Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/21656 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2017-02-23mb/emulation/*-riscv: Don't select ARCH_BOOTBLOCK_RISCVJonathan Neuschäfer
It's already selected by SOC_UCB_RISCV. Change-Id: Ic8a14300cdea2a4ab763b2746434891b72843604 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Reviewed-on: https://review.coreboot.org/18390 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Martin Roth <martinroth@google.com>
2016-08-18Kconfig: lay groundwork for not assuming SPI flash boot deviceAaron Durbin
Almost all boards and chipsets within the codebase assume or use SPI flash as the boot device. Therefore, provide an option for the boards/chipsets which don't currently support SPI flash as the boot device. The default is to assume SPI flash is the boot device unless otherwise instructed. This falls in line with the current assumptions, but it also allows one to differentiate a platform desiring SPI flash support while it not being the actual boot device. One thing to note is that while google/daisy does boot with SPI flash part no SPI API interfaces were ever implemented. Therefore, mark that board as not having a SPI boot device. BUG=chrome-os-partner:56151 Change-Id: Id4e0b4ec5e440e41421fbb6d0ca2be4185b62a6e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://review.coreboot.org/16191 Tested-by: build bot (Jenkins) Reviewed-by: Furquan Shaikh <furquan@google.com>
2016-06-17Define RAMTOP for x86 onlyKyösti Mälkki
This Kconfig is deprecated, new platforms need to locate ramstage stack in CBMEM instead. Change-Id: I20ece297302321337cc2ce17fdef0c55242a4fc3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/15189 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14CBFS: Automate ROM image layout and remove hardcoded offsetsJulius Werner
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: Ib715bb8db258e602991b34f994750a2d3e2d5adf Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229975 Reviewed-on: http://review.coreboot.org/9620 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-06New mechanism to define SRAM/memory map with automatic bounds checkingJulius Werner
This patch creates a new mechanism to define the static memory layout (primarily in SRAM) for a given board, superseding the brittle mass of Kconfigs that we were using before. The core part is a memlayout.ld file in the mainboard directory (although boards are expected to just include the SoC default in most cases), which is the primary linker script for all stages (though not rmodules for now). It uses preprocessor macros from <memlayout.h> to form a different valid linker script for all stages while looking like a declarative, boilerplate-free map of memory addresses to the programmer. Linker asserts will automatically guarantee that the defined regions cannot overlap. Stages are defined with a maximum size that will be enforced by the linker. The file serves to both define and document the memory layout, so that the documentation cannot go missing or out of date. The mechanism is implemented for all boards in the ARM, ARM64 and MIPS architectures, and should be extended onto all systems using SRAM in the future. The CAR/XIP environment on x86 has very different requirements and the layout is generally not as static, so it will stay like it is and be unaffected by this patch (save for aligning some symbol names for consistency and sharing the new common ramstage linker script include). BUG=None TEST=Booted normally and in recovery mode, checked suspend/resume and the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies with ToT and looked for red flags. Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614 Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/213370 Reviewed-on: http://review.coreboot.org/9283 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at> Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-12-01Add UCB RISCV support for architecture, soc, and emulation mainboard..Ronald G. Minnich
Works in the RISCV version of QEMU. Note that the lzmadecode is so unclean that it needs a lot of work. A cleanup is in progress. We decided in Prague to do this as one thing, because it forms a nice case study of the bare minimum you need to add to get a new architecture going in qemu. Change-Id: If5af15c3a70733d219973e0d032746f8ab027e4d Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/7584 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-17 09:04:07 +0000