summaryrefslogtreecommitdiff
path: root/src/soc/samsung/exynos5250/include
AgeCommit message (Collapse)Author
2020-10-19src/soc/samsung: Move common headers to "common/include/soc"Elyes HAOUAS
Change-Id: I8d54e157e4f0065fa0fd3df9df81a5b336031a99 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/46332 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Julius Werner <jwerner@chromium.org>
2020-09-21soc/samsung: Drop unneeded empty linesElyes HAOUAS
Change-Id: Ib2843c40de8e4607b8b9d665761a689227878bc0 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44600 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
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-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-04-06soc/samsung: Use SPDX for GPL-2.0-only filesAngel Pons
Done with sed and God Lines. Only done for C-like code for now. Change-Id: I25b9bbe320be891985e5fb42a0c3f1c763a833db Signed-off-by: Angel Pons <th3fanbus@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/40136 Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2020-03-31security/vboot: Decouple measured boot from verified bootBill XIE
Currently, those who want to use measured boot implemented within vboot should enable verified boot first, along with sections such as GBB and RW slots defined with manually written fmd files, even if they do not actually want to verify anything. As discussed in CB:34977, measured boot should be decoupled from verified boot and make them two fully independent options. Crypto routines necessary for measurement could be reused, and TPM and CRTM init should be done somewhere other than vboot_logic_executed() if verified boot is not enabled. In this revision, only TCPA log is initialized during bootblock. Before TPM gets set up, digests are not measured into tpm immediately, but cached in TCPA log, and measured into determined PCRs right after TPM is up. This change allows those who do not want to use the verified boot scheme implemented by vboot as well as its requirement of a more complex partition scheme designed for chromeos to make use of the measured boot functionality implemented within vboot library to measure the boot process. TODO: Measure MRC Cache somewhere, as MRC Cache has never resided in CBFS any more, so it cannot be covered by tspi_measure_cbfs_hook(). Change-Id: I1fb376b4a8b98baffaee4d574937797bba1f8aee Signed-off-by: Bill XIE <persmule@hardenedlinux.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/35077 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-by: Julius Werner <jwerner@chromium.org> Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
2020-03-18soc: 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: I4c110f60b764c97fab2a29f6f04680196f156da5 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/39610 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Reviewed-by: David Hendricks <david.hendricks@gmail.com>
2019-11-14lib/fmap: Add optional pre-RAM cacheJulius Werner
This patch adds an optional pre-RAM cache for the FMAP which most platforms should be able to use, complementing the recently added post-RAM FMAP cache in CBMEM. vboot systems currently read the FMAP about half a dozen times from flash in verstage, which will all be coalesced into a single read with this patch. It will also help future vboot improvements since when FMAP reads become "free" vboot doesn't need to keep track of so much information separately. In order to make sure we have a single, well-defined point where the new cache is first initialized, eliminate the build-time hardcoding of the CBFS section offsets, so that all CBFS accesses explicitly read the FMAP. Add FMAP_CACHEs to all platforms that can afford it (other than the RISC-V things where I have no idea how they work), trying to take the space from things that look like they were oversized anyway (pre-RAM consoles and CBFS caches). Change-Id: I2820436776ef620bdc4481b5cd4b6957764248ea Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://review.coreboot.org/c/coreboot/+/36657 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Joel Kitching <kitching@google.com>
2019-10-27src/soc: change "unsigned" to "unsigned int"Martin Roth
Signed-off-by: Martin Roth <martin@coreboot.org> Change-Id: I9c1228d3f9e7a12fe30c48e3b1f143520fed875c Reviewed-on: https://review.coreboot.org/c/coreboot/+/36332 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2019-03-21vboot: standardize on working data sizeJoel Kitching
Previously, the size of memory made for vboot_working_data through the macro VBOOT2_WORK was always specified in each individual memlayout file. However, there is effectively no reason to provide this customizability -- the workbuf size required for verifying firmware has never been more than 12K. (This could potentially increase in the future if key sizes or algorithms are changed, but this could be applied globally rather than for each individual platform.) This CL binds the VBOOT2_WORK macro to directly use the VB2_WORKBUF_RECOMMENDED_DATA_SIZE constant as defined by vboot API. Since the constant needs to be used in a linker script, we may not include the full vboot API, and must instead directly include the vb2_constants.h header. BUG=b:124141368, b:124192753 TEST=Build locally for eve TEST=util/lint/checkpatch.pl -g origin/master..HEAD TEST=util/abuild/abuild -B -e -y -c 50 -p none -x TEST=make clean && make test-abuild BRANCH=none CQ-DEPEND=CL:1504490 Change-Id: Id71a8ab2401efcc0194d48c8af9017fc90513cb8 Signed-off-by: Joel Kitching <kitching@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/31474 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2019-03-07security/tpm: Fix TCPA log featurePhilipp Deppenwiese
Until now the TCPA log wasn't working correctly. * Refactor TCPA log code. * Add TCPA log dump fucntion. * Make TCPA log available in bootblock. * Fix TCPA log formatting. * Add x86 and Cavium memory for early log. Change-Id: Ic93133531b84318f48940d34bded48cbae739c44 Signed-off-by: Philipp Deppenwiese <zaolin.daisuki@gmail.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/29563 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2019-03-04device/mmio.h: Add include file for MMIO opsKyösti Mälkki
MMIO operations are arch-agnostic so the include path should not be arch/. Change-Id: I0fd70f5aeca02e98e96b980c3aca0819f5c44b98 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/c/31691 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
2018-10-08Move compiler.h to commonlibNico Huber
Its spreading copies got out of sync. And as it is not a standard header but used in commonlib code, it belongs into commonlib. While we are at it, always include it via GCC's `-include` switch. Some Windows and BSD quirk handling went into the util copies. We always guard from redefinitions now to prevent further issues. Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/28927 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2018-07-09src/soc: Use "foo *bar" instead of "foo* bar"Elyes HAOUAS
Change-Id: I21680354f33916b7b4d913f51a842b5d6c2ecef3 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/27408 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2017-07-13Rename __attribute__((packed)) --> __packedStefan Reinauer
Also unify __attribute__ ((..)) to __attribute__((..)) and handle ((__packed__)) like ((packed)) Change-Id: Ie60a51c3fa92b5009724a5b7c2932e361bf3490c Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/15921 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-01-18header files: Fix guard name comments to match guard namesMartin Roth
This just updates existing guard name comments on the header files to match the actual #define name. As a side effect, if there was no newline at the end of these files, one was added. Change-Id: Ia2cd8057f2b1ceb0fa1b946e85e0c16a327a04d7 Signed-off-by: Martin Roth <martinroth@google.com> Reviewed-on: https://review.coreboot.org/12900 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-09-09verstage: use common program.ld for linkingAaron Durbin
There's no reason to have a separate verstage.ld now that there is a unified stage linking strategy. Moreover verstage support is throughout the code base as it is so bring in those link script macros into the common memlayout.h as that removes one more specific thing a board/chipset needs to do in order to turn on verstage. BUG=chrome-os-partner:44827 BRANCH=None TEST=None Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd Signed-off-by: Aaron Durbin <adubin@chromium.org> Reviewed-on: http://review.coreboot.org/11516 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-08-09samsung/exynos5250: Add vboot2 memory regionPatrick Georgi
Change-Id: Ia7d2cafc958859be782f63c956dbd632e28bcf11 Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/11101 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-05-26coreboot: introduce boot_deviceAaron Durbin
The boot_device is a region_device that represents the device from which coreboot retrieves and boots its stages. The existing cbfs implementations use the boot_device as the intermediary for accessing the CBFS region. Also, there's currently only support for a read-only view of the boot_device. i.e. one cannot write to the boot_device using this view. However, a writable boot_device could be added in the future. Change-Id: Ic0da796ab161b8025c90631be3423ba6473ad31c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/10216 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-04-14timer: Reestablish init_timer(), consolidate timer initialization callsJulius Werner
We have known for a while that the old x86 model of calling init_timer() in ramstage doesn't make sense on other archs (and is questionable in general), and finally removed it with CL:219719. However, now timer initialization is completely buried in the platform code, and it's hard to ensure it is done in time to set up timestamps. For three out of four non-x86 SoC vendors we have brought up for now, the timers need some kind of SoC-specific initialization. This patch reintroduces init_timer() as a weak function that can be overridden by platform code. The call in ramstage is restricted to x86 (and should probably eventually be removed from there as well), and other archs should call them at the earliest reasonable point in their bootblock. (Only changing arm for now since arm64 and mips bootblocks are still in very early state and should sync up to features in arm once their requirements are better understood.) This allows us to move timestamp_init() into arch code, so that we can rely on timestamps being available at a well-defined point and initialize our base value as early as possible. (Platforms who know that their timers start at zero can still safely call timestamp_init(0) again from platform code.) BRANCH=None BUG=None TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit. Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/234062 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9606 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-10gpio: Extend common GPIO header, simplify function namesJulius Werner
We've had gpiolib.h which defines a few common GPIO access functions for a while, but it wasn't really complete. This patch adds the missing gpio_output() function, and also renames the unwieldy gpio_get_in_value() and gpio_set_out_value() to the much easier to handle gpio_get() and gpio_set(). The header is renamed to the simpler gpio.h while we're at it (there was never really anything "lib" about it, and it was presumably just chosen due to the IPQ806x include/ conflict problem that is now resolved). It also moves the definition of gpio_t into SoC-specific code, so that different implementations are free to encode their platform-specific GPIO parameters in those 4 bytes in the most convenient way (such as the rk3288 with a bitfield struct). Every SoC intending to use this common API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most 4 bytes in length. Files accessing the API only need to include <gpio.h> which may pull in additional things (like a gpio_t creation macro) from <soc/gpio.h> on its own. For now the API is still only used on non-x86 SoCs. Whether it makes sense to expand it to x86 as well should be separately evaluated at a later point (by someone who understands those systems better). Also, Exynos retains its old, incompatible GPIO API even though it would be a prime candidate, because it's currently just not worth the effort. BUG=None TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and Veyron_Pinky. Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/220975 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9400 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-07exynos5250: Change all SoC headers to <soc/headername.h> systemJulius Werner
This patch aligns exynos5250 to the new SoC header include scheme. Also alphabetized headers in affected files since we touch them anyway. BUG=None TEST=Tested with whole series. Compiled Daisy. Change-Id: I39805c0346e117a0f9b2667763ecaa428f0f55a8 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: db6762f0c8425371d9860f908a5cefdeee8d1abc Original-Change-Id: Ic358061ddcbbe7d83a95ca11247b8b505b20491d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/224500 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9323 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>