summaryrefslogtreecommitdiff
path: root/src/cpu/samsung/exynos5250
AgeCommit message (Collapse)Author
2013-12-21exynos5250: Implement support to boot with USB A-A firmware uploadJulius Werner
This patch implements the basic infrastructure required to use the USB A-A firmware upload feature on Exynos5 processors with Coreboot. It will require a corresponding host-side script that activates the feature and uploads the correct image parts in the correct order to harcoded target addresses, as described in the comments of alternate_cbfs.c. Also fixes a bug in the Google Snow mainboard where it would not correctly initialize the pinmux configuration for the SPI flash bus. During a normal SPI boot the IROM would already do that for you, but when booting from USB you have to do it yourself. Change-Id: I40a39f8f5d1d70b58dbf258015c1653a27097d67 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/64875 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/4456 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21exynos5xxx: use oscillator clock when changing ARM frequencyDavid Hendricks
Switch ARM clock source when changing the APLL frequency to avoid stability issues. This is ported from https://gerrit.chromium.org/gerrit/#/c/64189/5 Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I923107555e6d3287b3694cbf9e4bb548d3e5f4a8 Reviewed-on: https://gerrit.chromium.org/gerrit/64838 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/4442 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21exynos5250: Add a pinmux function to set up i2s bus 0Gabe Black
This bus is hooked up on snow and, as it's the only bus hooked up on some other boards, having it available in firmware to test is handy. Change-Id: Icb48b9af4a67d382bd6fbce1e4c6a320d811d365 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/64877 Reviewed-by: Ronald G. Minnich <rminnich@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@google.com> Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/4438 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21armv7/exynos: Fix and remove memory reset workaroundsHung-Te Lin
The memory corruption problem in Exynos suspend/resume process is caused by two things together: PHY_RESET and MRS command. After stop sending MRS on resume, we can now remove the workaround of skipping PHY_RESET. Change-Id: I64acc27c1d2bb549ae6ad7d32ecda94b0355972c Reviewed-on: https://gerrit.chromium.org/gerrit/64736 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/4433 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21Snow: correctly disable trust zone hardwareRonald G. Minnich
The kernel assumes that trust zone is disabled. Change-Id: Ia8d6fa69adcb812a747d8b89eb77e57144423eaa Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/64722 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Ronald G. Minnich <rminnich@chromium.org> Tested-by: Ronald G. Minnich <rminnich@chromium.org> Reviewed-on: http://review.coreboot.org/4431 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21exynos5250: Add mct_start to the timer init blob in timer_monotonic_getGabe Black
A previous change removed init_timer from timer_monotonic_get because its old implementation set up the PWM based timer which was going away. It would still be a good idea to initialize the timer at that point, just not the pwm. Change-Id: I4816710ec2c9d5ca53b704c6b9397bcfac183fdc Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/64160 Reviewed-by: Ronald G. Minnich <rminnich@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/4419 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21Exynos 5250: Enable dynamic CBMEMStefan Reinauer
... In order to do this, the graphics memory has to move into the resource allocator and out of CBMEM. Change-Id: I7396da4a7068404b0d2e4d308becab4dd6ea59bb Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/59326 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/4390 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21exynos5250: Get rid of the PWM timer code we shouldn't be using anymoreGabe Black
This code was left over from U-Boot and was superceded by the MCT. Change-Id: Ia85e3b7281dcdd4740238dddd0dfc6f0ba2c94da Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/63778 Commit-Queue: Gabe Black <gabeblack@chromium.org> Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/4401 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-21exynos5250: Fix consts in the pwm codeGabe Black
The code generally intended to make the pointer const instead of the thing it pointed at, but it had const backwards. Sometimes both the pointer and the data could be const, but sometimes there were writes where only the pointer should be. Change-Id: Ifcd5495769b86b47d7b583cce63ed5c2158bec4e Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/63775 Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/4397 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
2013-12-20armv7: Remove SYS_TEXT_BASE config.Hung-Te Lin
SYS_TEXT_BASE is not used by any one. To prevent confusion when changing memory layout, remove it from current configurations. Change-Id: I15012b864bbb9c12003843b9b24ea64c91f4578b Reviewed-on: https://gerrit.chromium.org/gerrit/61853 Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/4371 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-12-12EXYNOS5250: be less chatty at critical momentsRonald G. Minnich
The 5250 DRAM code is *really* chatty. That's not a great idea in time critical code, and DRAM init is generally very sensitive about such things. Finally, for those things that are errors, print them at an error level, not a debug level. Change-Id: Ifa86b019dfd5f8ae6c8a1da2a35b5d0808dc3623 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/60100 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Commit-Queue: Ronald G. Minnich <rminnich@chromium.org> Tested-by: Ronald G. Minnich <rminnich@chromium.org> Reviewed-on: http://review.coreboot.org/4359 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-12-12exynos5250: Correct DDR3 Phy-reset value names.Hung-Te Lin
The name "LPDDR3PHY_CTRL_PHY_RESET_OFF" is not appropriate because the real phy-reset is a low-active pin, so "off(0)" will trigger "start to reset". To prevent confusion, we should rename the constants to "RESET_ENABLE" and "RESET_DISABLE". Change-Id: Iccba5ef3a2e992f877dea90741f0308c161758c9 Reviewed-on: https://gerrit.chromium.org/gerrit/61081 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/4357 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-11cpu: Fix spellingMartin Roth
Change-Id: I69c46648de0689e9bed84c7726906024ad65e769 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10i2c: Change the type of the data parameter to uint8_t.Gabe Black
Data is intended to be a byte array, so it should be described by a type which has a fixed size equal to an 8 bit byte. Also, the data passed to write shouldn't be modified and can be const. Change-Id: I6466303d962998f6c37c2d4006a39c2d79a235c1 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3721 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10arm/exynos: Correct SPI session commands.Hung-Te Lin
Some initialization / shutdown commands should be paired correctly in a SPI I/O session. For example, setting CS should be enabled and disabled in each read; and the bus width (byte or word) should be configured only when opening / closing the SPI device. Change-Id: Ie56b1c3a6df7d542f7ea8f1193ac435987f937ba Signed-off-by: Hung-Te Lin <hungte@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3706 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10snow: Add flush to UART driver.Hung-Te Lin
Wait for UART FIFO to be ready. (Credit to dhendrix for finding the bits to test with.) Change-Id: Ib6733e422cbc1c61b942bd90d85f88a3f412d6ff Signed-off-by: Hung-Te Lin <hungte@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3698 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Exynos5250: Initialize USB PHYStefan Reinauer
... this is needed for libpayload to talk to USB devices. Change-Id: I7eb19003c9e96efb5fa7a3f97c7b15f3ef332687 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3696 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Exynos: Only compile UART in if serial console is selectedStefan Reinauer
Change-Id: I5cddffc2e524aae7a31a8f94f67e03a5b7e15c82 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3695 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Simplify early / bootblock console codeStefan Reinauer
Change-Id: I6b28bb95c7decbe3eed33b5b5a029bee48bbe403 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3691 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Samsung CPUs: Unify KconfigStefan Reinauer
For all other CPUs, we unconditionally include the CPU Kconfig files in the CPU directory, not in the vendor directory. Do the same thing for the Exynos CPUs. This allows us to make CPU dependent changes in the directory of that CPU alone. Also, drop some unused Kconfig variables from the Exynos Kconfig files. Change-Id: I4e4c22a0693988834e619dd33d121bf994ed57e8 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3683 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARM: when setting a GPIO to put, set the value, then the directionRonald G. Minnich
We saw a problem on x86 last year in which setting direction, then value, glitched the output and caused problems. Change this code to set the output, then the direction. Change-Id: I3e1e17ffe82ae270eea539530368a58c6cfe0ebe Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3679 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5250: De-switch-ify the pinmux configuration code.Gabe Black
The pinmux code for the exynos5250 was all bundled into a single, large function which contained a switch statement that would set up the pins for different peripherals within the SOC. There was also a "flags" parameter, the meaning of which, if any, depended on which peripheral was being set up. There are several problems with that approach. First, the code is inefficient in both time and space. The caller knows which peripheral it wants to set up, but that information is encoded in a constant which has to be unpacked within the function before any action can be taken. If there were a function per peripheral, that information would be implicit. Also, the compiler and linker are forced to include the entire function with all its cases even if most of them are never called. If each peripheral was a function, the unused ones could be garbage collected. Second, it would be possible to try to set up a peripheral which that function doesn't know about, so there has to be additional error checking/handling. If each peripheral had a function, the fact that there was a function to call at all would imply that the call would be understood. Third, the flags parameter is fairly opaque, usually doesn't do anything, and sometimes has to have multiple values embedded in it. By having separate functions, you can have only the parameters you actually want, give them names that make sense, and pass in values directly. Fourth, having one giant function pretends to be a generic, portable API, but in reality, the only way it's useful is to call it with constants which are specific to a particular implementation of that API. It's highly unlikely that a bit of code will need to set up a peripheral but have no idea what that peripheral actually is. Call sights for the prior pinmux API have been updated. Also, pinmux initialization within the i2c driver was moved to be in the board setup code where it really probably belongs. The function block that implements the I2C controller may be shared between multiple SOCs (and in fact is), and those SOCs may have different pinmuxes (which they do). Other places this same sort of change can be made are the pinmux code for the 5420, and the clock configuration code for both the 5250 and the 5420. Change-Id: Ie9133a895e0dd861cb06a6d5f995b8770b6dc8cf Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3673 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARM: Separate the early console (romstage) from the bootblock console.Gabe Black
It might be that you want an early console in romstage before RAM is up, but you can't or don't want to support the console all the way back in the bootblock. By making the console in those two different environments configurable seperately that becomes possible. On the 5250 console output as early as the bootblock works, but on the 5420 it only starts working in the ROM stage after clocks have been initialized. Change-Id: I68ae3fcb4d828fa8a328a30001c23c81a4423bb8 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3671 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10armv7: Reserve space BL1 and checksum header by specifying bootblock offset.Hung-Te Lin
Not all ARM systems need "BL1", and the layout of BL* and bootblock may be different (ex, Exynos 5250 may use a new BL1 with variable length checksum header). To support that better, define the real base address (and ROM offset) of boot block, and then we can post-processing ROM image file by filling data / checksum and any other information. Change-Id: I0e3105e52500b6b457371ad33a9aa546acf28928 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3664 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5250: Clear the framebuffer before making it uncacheable.Gabe Black
If we clear the framebuffer and then flush it back to memory using cache operations, the writes are going to be full cachelines at a time. If we make it uncacheable first, the writes will be serialized writes of whatever sized chunks memset uses, probably 4 bytes or less. Change-Id: I1b81731cfed00ae091ba6357451ab186d16f559e Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3655 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5250: Don't disable and re-enable the MMU when uncaching the framebuffer.Gabe Black
At one time it seemed to be necessary to disable and then re-enable the MMU when setting the framebuffer to be uncache-able due to bugs in the MMU management code. Since those bugs have been fixed, this is no longer necessary. Change-Id: I5f7b9bd14dc9929efe1834ec9a258d388b8c94e9 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3654 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5250: Simplify the graphics code by eliminating the unused color map.Gabe Black
The code that allocated space for the framebuffer was adding space for a vestigial color map which was never used. It was also passing around a structure which was used to calculate a single value which was already known when that structure was put together. Eliminate the extra space, and pass the single value instead of the structure. Change-Id: Ia6a41cefdf8b29fe7d68f9596a156eced6eb5df8 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3652 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10exynos5250: When enabling the I2S pins, turn off pull ups/downs.Gabe Black
These pins will be driven by the internal controller which shouldn't have pull ups or downs in the pin fighting with them. Change-Id: I579aed84ace45d8f5f1d3ca64c064d98de842b57 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3649 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: Clean up console codeStefan Reinauer
- Guard console_init() with CONFIG_EARLY_CONSOLE in bootblock - Don't initialize console twice in the bootblock - remove printk in memory init that would mess up the UART - unconditionally run console_init() in romstage, as it is also unconditionally run in the bootblock. Change-Id: I8f0d60877433162367074d0e55e01f935fd81f8e Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3647 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: De-uboot-ify Exynos5250 GPIO codeStefan Reinauer
The Exynos GPIO code has three different APIs that, unfortunately, were widely used throughout the code base. This patch is cleaning up the mess. Change-Id: I09ccc7819fb892dbace9693c786dacc62f3f8eac Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3643 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10ARMv7: De-uboot-ify Exynos5250 codeStefan Reinauer
When starting the Exynos5250 port, a lot of unneeded u-boot code was imported. This is an attempt to get rid of a lot of unneeded code before the port is used as a basis for further ARM ports. There is a lot more that can be done, including cleaning up the 5250's Kconfig file. Change-Id: I2d88676c436eea4b21bcb62f40018af9fabb3016 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3642 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Update 3rdparty hash for latest ARM BL1 binariesStefan Reinauer
Change-Id: Ice28114e5f53f510d305cd85d095044e2f4bd7b2 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3740 Reviewed-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-07-10samsung/exynos5250: unify codeStefan Reinauer
It turns out that the exynos5-common code previously imported from u-boot is not common code at all but very specific to the 5250 and not compatible with the 5450. Hence, unify the directories exynos5250 and exynos5-common. We will try to factor out common code while progressing with the 5450 port. Change-Id: Iab595e66fcd01eda8365c96fb8bef896f7602f03 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3641 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Wield battle axe at ARM portStefan Reinauer
This patch unfortunately incorporates a number of changes, all of which are making future ARM ports easier. - drop cruft that came in with u-boot - move serial console from mainboard Kconfig to Exynos Kconfig - factor out non-board specific wakeup code - move generic bootblock code from mainboard to Exynos - actually call arch_cpu_init() - remove dead code - fix up copyright messages - remove snow_ prefix from a lot of code to reduce the noise when creating a new mainboard based on that code. Change-Id: Ic05326edf5a7e1a691c5ff841a604cb9e351b562 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3640 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-14EXYNOS5250/SNOW: fix the build script. Add a script to get the bl1.Ronald G. Minnich
build-snow got broken when the snow makefile improved. So fix it. While we're at it, create a script like the update-microcode scripts that gets the bl1. I thought about making this a common script but the various names and paths always evolve, leaving me thinking it's not worth it. This script is just a piece of the snow build script. Change-Id: I65c0f8697a978c62fe12533c4f0152d14dbaefda Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3238 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-05-06exynos5250/snow: deprecate time.hDavid Hendricks
This re-introduces 2fde966 (http://review.coreboot.org/#/c/3177/) which was reverted due to unsatisfied dependencies. time.h We Hardly Knew Ye. This deprecates time.h which is currently only used by Exynos5250 and Snow. The original idea was to try and unify some of the various timer interfaces and has been supplanted by the monotonic timer API. timer_us() is now obsolete. timer_start() is now mct_start() and is exposed in exynos5250/clk.h. Change-Id: I8e60105629d9da68ed622e89209b3ef6c8e2445b Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3201 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-05exynos5/5250: Update timer call sites to use monotonic timer APIDavid Hendricks
This goes thru various call sites where we used timer_us() and updates them to use the new monotonic timer API. udelay() changed substantially and now gracefully handles wraparound. Change-Id: Ie2cc86a4125cf0de12837fd7d337a11aed25715c Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3176 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-05-04Revert "exynos5250/snow: deprecate time.h"David Hendricks
This reverts commit 2fde9668b47e74d1bfad2f1688a4481e6b966d04 Somehow this got merged before its dependencies. 3190 must be merged first, followed by 3176. However 3190 will fail while this patch is in. So the situation can't correct itself. Reverting this until the other two go in. Change-Id: I176f37c12711849c96f1889eacad38c00a8142c4 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3195 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-05-03exynos5250/snow: deprecate time.hDavid Hendricks
time.h We Hardly Knew Ye. This deprecates time.h which is currently only used by Exynos5250 and Snow. The original idea was to try and unify some of the various timer interfaces and has been supplanted by the monotonic timer API. timer_us() is now obsolete. timer_start() is now mct_start() and is exposed in exynos5250/clk.h. Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I14ebf75649d101491252c9aafea12f73ccf446b5 Reviewed-on: http://review.coreboot.org/3177 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-03exynos5250: monotonic timer implementation (using MCT)David Hendricks
This implements the new monotonic timer API using the global multi-core timer (MCT). Change-Id: Id56249ff5d3e0f85808f5754954c83c0bc75f1c1 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3175 Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-04-26exynos5250: uncomment $(INTERMEDIATE)David Hendricks
This makes the intermediate rule visible so BL1 gets automatically placed in the final image. Change-Id: Iffb0268e5bbcbe135f2d39863ed64fa302409a22 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3141 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-04-25google/snow: Add "wakeup" module for suspend/resume.Hung-Te Lin
The "wakeup" procedure will be shared by bootblock and romstage for different types of resume processes. Note, this commit does not include changes in romstage/bootblock to enable suspend/resume feature. Simply adding functions to handle suspend/resume. Verified by successfully building and booting Google/Snow firmware image. Change-Id: I17a256afb99f2f8b5e0eac3393cdf6959b239341 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3129 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-25arm/exynos: Allow DRAM controller to be initialized without clearing RAM ↵Hung-Te Lin
content. To support suspend/resume, PHY control must be reset only on normal boot path. So add a new param "mem_reset" to specify that. Verified to boot successfully on Google/Snow. Change-Id: Id49bc6c6239cf71a67ba091092dd3ebf18e83e33 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/3128 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-23GOOGLE/SNOW: get graphics workingRonald G. Minnich
This adds support for display bring-up on Snow. It includes framebuffer initialization and LCD enable functions. Change-Id: I16e711c97e9d02c916824f621e2313297448732b Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3116 Tested-by: build bot (Jenkins)
2013-04-23exynos5250: ungate the product ID registerDavid Hendricks
This makes sure that the product ID (PRO_ID) register can be read when the OS kernel is figuring out what kind of CPU it's running on. For historical reference, the original U-Boot code seems to have worked basically by accident here. The hardware has a quirk where by reading the value before gating the IP block keeps the value persistent. U-Boot reads the chip ID early on to distinguish between chip family, but we do not mix code the same way so we do not read the chip ID. Since the value has been read before the clock gating happens, the value remains available for the kernel to use during the decompression stage. We don't want to rely on that behavior when using coreboot. Instead the kernel should gate unused IPs. (credit to Gabe for finding symptom in the kernel) Change-Id: Iaa21e6e718b9000b5558f568020f393779fd208e Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3121 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-04-22GOOGLE/SNOW: fix stupid paren errorRonald G. Minnich
This simple error led to corrupted graphics. How annoying. Change-Id: I2295c0df0f1d16014a603dc5d66bd4d72f3fb7c9 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3120 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-04-19exynos5250: get xres and yres out of the device tree and into the panel ↵Ronald G. Minnich
descriptor We neglected to copy xres and yres out; now we do. Change-Id: Icc4a8eb35799d156b11274f71bcfb4a1d10e01e3 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3111 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-04-19[2/3] exynos5: modify thermal management unit code for corebootDavid Hendricks
This updates the Exynos TMU code for coreboot: - Remove dependency on device tree - Add Makefile entries Change-Id: I55e1b624d7c7b695b1253ec55f6ae3de8dc671bc Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3107 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-04-19exynos5: move power_enable_hw_thermal_trip() prototypeDavid Hendricks
This moves the prototype for power_enable_hw_thermal_trip() to a generic location so it can be used by generalized thermal management code. The implementation will still be CPU-specific. Change-Id: Iae449cb8c72c8441dedaf65b73db9898b4730cef Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3105 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-04-17armv7/exynos5250: Deprecate sdelay in favor of udelayDavid Hendricks
This gets rid of the clock-tick based sdelay in favor of udelay(). udelay() is more consistent and easier to work with, and this allows us to carry one less variation of timers (and headers and sources...). Every 1 unit in the sdelay() argument was assumed to cause a delay of 2 clock ticks (@1.7GHz). So the conversion factor is roughly: sdelay(N) = udelay(((N * 2) / 1.7 * 10^9) * 10^6) = udelay((N * 2) / (1.7 * 10^3)) The sdelay() periods used were: sdelay(100) --> udelay(1) sdelay(0x10000) --> udelay(78) (rounded up to udelay(100)) There was one instance of sdelay(10000), which looked like sort of a typo since sdelay(0x10000) was used elsewhere. sdelay(10000) should approximate to about 12us, so we'll stick with that for now and leave a note. Change-Id: I5e7407865ceafa701eea1d613bbe50cf4734f33e Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3079 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-17Samsung/exynos5250: convert unsigned {int,char} to u32/u8Ronald G. Minnich
The types are (esp. int) are confusing at times as to size. Make them definite as to size. Change-Id: Id7808f1f61649ec0a3403c1afc3c2c3d4302b7fb Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3103 Tested-by: build bot (Jenkins) Reviewed-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-04-13Exynos5250: add a microsecond timerRonald G. Minnich
Add a microsecond timer, its declaration, the function to start it, and its usage. To start it, one calls timer_start(). From that point on, one can call timer_us() to find microseconds since the timer was started. We show its use in the bootblock. You want it started very early. Finally, the delay.h change having been (ironically) delayed, we create time.h and have it hold one declaration, for the timer_us() and timer_start() prototype. We feel that these two functions should become the hardware specific functions, allowing us to finally move udelay() into src/lib where it belongs. Change-Id: I19cbc2bb0089a3de88cfb94276266af38b9363c5 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3073 Tested-by: build bot (Jenkins)
2013-04-11Exynos5250: Use new chip settings for the cpuRonald G. Minnich
Properly use the chip settings when configuring the CPU, at this point being purely graphics. Change-Id: I9bc2d32c1037653837937b314e4041abc0024835 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3054 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-04-10armv7: replace read/write macros with inlinesDavid Hendricks
This enables type checking for safety as to help prevent errors like http://review.coreboot.org/#/c/3038/ . Now compilation fails if the wrong type is passed into readb/readw/readl/writeb/writew/writel or other macros in io.h. This also deprecates readw/writew. The previous definition was 16-bits which is incorrect since wordsize on ARMv7 is 32-bits and there was only 1 instance of writew (#if 0'd anyway). Going forward we should always use read{8,16,32} and write{8,16,32} where N specifies the exact length rather than relying on ambiguous definition of wordsize. Since many macros relied on __raw_*, which were basically the same (minus data memory barrier instructions), this patch also gets rid of __raw_*. There were parts of the code which ended up using these macros consecutively, for example: setbits_le32(&regs->ch_cfg, SPI_CH_RST); clrbits_le32(&regs->ch_cfg, SPI_CH_RST); In such cases the safe versions of readl() and writel() should be used anyway. Note: This also fixes two dubious casts as to avoid breaking compilation. Change-Id: I8850933f68ea3a9b615d00ebd422f7c242268f1c Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3045 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08exynos5250: add missing address-of operator in UART driverDavid Hendricks
This adds a missing address-of operator. This was a subtle bug that didn't seem to cause problems at first since the serial console appeared to work. However it caused an imprecise external abort which became apparent later on when aborts were unmasked in the kernel via the CPSR_A bit. (credit goes to Gabe Black for finding this) Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Change-Id: I80a33b147d92d559fa8fefbe7d5642235deb9aea Reviewed-on: http://review.coreboot.org/3038 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-08snow/exynos5250: move board-specific power stuff to mainboard dirDavid Hendricks
This moves highly board-specific code out from the Exynos5250 power_init() into Snow's romstage.c. There's no reason the CPU- specific code should care about which PMIC we are using and which bus it is on. Change-Id: I52313177395519cddcab11225fc23d5e50c4c4e3 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3034 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-06exynos5250: add a chip.h file for the display register settingsRonald G. Minnich
Display hardware is part of this SOC, and we need to be able to set certain variables in devicetree.cb. This chip file contains the initial things we think we need to set. Change-Id: I16f2d4228c87116dbeb53a3c9f3f359a6444f552 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3031 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-03-29exynos5250: Add function for configuring L2 cacheDavid Hendricks
This adds a new function to configure L2 cache for the exynos5250 and deprecates the old function. Change-Id: I9562f3301aa1e2911dae3856ab57bb6beec2e224 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2949 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Gabe Black <gabe.black@gmail.com> Tested-by: build bot (Jenkins)
2013-03-27exynos5250: assign RAM resources in cpu_init()David Hendricks
This moves the ram resource allocation into cpu_init() so that we no longer rely on declaring a domain in devicetree.cb (which is kind of weird for this platform). This does not cause any actual changes to the coreboot memory table, and paves the way for further updates to Snow's devicetree. Change-Id: I141277f59b5d48288f409257bf556a1cfa7a8463 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2923 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-26Revert "samsung/exynos5: add resource functions for the display port"David Hendricks
This reverts commit 9427ca151e44644238b1b52138894195a9f5175f Looks like we were a bit too anxious to see this one get in. The devicetree.cb change seems to have broken things. coreboot memory table: 0. 0000000050000000-000000005000ffff: RESERVED 1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES 2. 0000014004000000-00000140044007ff: RESERVED Before this patch: coreboot memory table: 0. 0000000040000000-00000000bfefffff: RAM 1. 00000000bff00000-00000000bfffffff: CONFIGURATION TABLES Change-Id: I618e4f1976265d56cfd6a61d0c5736c55a0f3cec Reviewed-on: http://review.coreboot.org/2914 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-26samsung/exynos5: add resource functions for the display portRonald G. Minnich
This does NOT turn on the graphics. The device tree has been changed enough so that, at the very least, the correct functions are called at the correct time, with the correct paramaters. We decided to yank the I2C entries as they did not obvious function and might not even have been correct. Not working, seemingly, but we need to add a 4M resource for memory, and it seems it needs to be fixed at the address shown. This address was chosen from current hardware. We realized that the display code should be part of the cpu -- that's how the hardware works! Change-Id: Ied65a554f833566be817540702f79a02e7b6cb6e Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2615 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-03-19armv7/exynos/snow: new cache maintenance APIDavid Hendricks
This adds a new API for cache maintenance operations. The idea is to be more explicit about operations that are going on so it's easier to manage branch predictor, cache, and TLB cleans and invalidations. Also, this adds some operations that were missing but required early on, such as branch predictor invalidation. Instruction and sync barriers were wrong earlier as well since the imported API assumed we compield with -march=armv5 (which we don't) and was missing wrappers for the native ARMv7 ISB/DSB/DMB instructions. For now, this is a start and it gives us something we can easily use in libpayload for doing things like cleaning and invalidating dcache when doing DMA transfers. TODO: - Set cache policy explicitly before re-enabling. Right now it's left at default. - Finish deprecating old cache maintenance API. - We do an extra icache/dcache flush when going from bootblock to romstage. Change-Id: I7390981190e3213f4e1431f8e56746545c5cc7c9 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2729 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14exynos5250: add RAM resource beginning at physical addressDavid Hendricks
The original code attempted to reserve a space in RAM for coreboot to remain resident. This turns out not to be needed, and breaks things for the kernel since the exynos5250-smdk5250 kernel device tree starts RAM at 0x40000000. (This patch was originally by Gabe, I'm just uploading it) Change-Id: I4536edaf8785d81a3ea008216a2d57549ce5edfb Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2698 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-13exynos5250/snow: enable branch predictionDavid Hendricks
This enables branch prediction. We can probably find a better place to do this, but for now we'll do it in snow's romstage main(). Change-Id: I86c7b6bc9e897a7a432c490fb96a126e81b8ce72 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2701 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13exynos5250: Don't set PS_HOLD in bootblock_cpu_initDavid Hendricks
PS_HOLD gets set in exynos' power_init(). Change-Id: Ib08e0afcad23cbd07dc7e3727fd958a1bc868b5a Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2700 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-13exynos5250/snow: call PMIC's power_init() functionDavid Hendricks
Call the power_init() function. We appear to have forgotten about it when deprecating lowlevel_init_subsystems(), but it didn't seem to cause problems until we got to doing more interesting stuff recently. There are some clean-ups to do from the original code, such as not attempting to configure I2C from PMIC code, which we'll get around to in follow-up patches. (Credit to Gabe for spotting this) Change-Id: I6a59379e9323277d0b61469de9abe6d651ac5bfb Signed-off-by: Gabe Black <gabeblack@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2699 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-04ARM: remove code that is IMHO a dangerous designRonald G. Minnich
OK, this is tl;dr. But I need to write this in hopes we make sure we don't put code like this into coreboot. Ever. Our excuse in this case is that it was imported, not obviously wrong, and easily changed. It made sense to get it in, make it work, then do a cleanup pass, because changing everything up front is almost impossible to debug. The exynos code has bunch of base register values, e.g. These are base addresses of things that look like a memory-mapped struct. To get these to a pointer, they created the following macro, which creates an inline function. static inline unsigned int samsung_get_base_##device(void) \ { \ return cpu_is_exynos5() ? EXYNOS5_##base : 0; \ } And then invoke it 31 times in a .h file, e.g.: SAMSUNG_BASE(clock, CLOCK_BASE) to create 31 functions. And then use it: struct exynos5_clock *clk = (struct exynos5_clock *)samsung_get_base_clock(); OK, what's wrong with this? It's easier to ask what's right with it. Answer: nothing. I have a long list of what's wrong, and I may leave some things out, but here goes: 1. the "function" can return a NULL if we're not on exynos5. Most uses of the code don't check the return value. 2. And why would this function be running, if we're not on an exynos5? Why compile it in? 3. Note the cast everywhere a samsung_get_base_xxx is used. The function returns an untyped variable, requiring the *user* to get two things right: the cast, and the function invocation. One can replace that _clock(); with _power(); in the code above, and they will be referencing the wrong registers, and they'll never get an error! We have a C compiler; use it to type data. 4. You're generating 31 functions using cpp each and every time the file is included. The C compiler has to parse these each time. It's not at all like a simple cpp macro which is only generated on use. 5. You can't tags or etags this code 6. In fact, any kind of analysis tool will be unable to do anything with this cpp magic. That's only a partial list. So what's the right way to do it? Just make typed constants, viz: Or, since I expect people will want the lower case function syntax, I've left it that way: Now we've got something that is efficient, and we don't even need to protect with any more. Hence this change. We've got something that is type checked, does not require users to cast on each use, will catch simple programming errors, can be analyzed with standard tools, and builds faster. So if we make a mistake: struct exynos5_clock *clk = samsung_get_base_adc(); We'll see it: src/cpu/samsung/exynos5250/clock.c: In function 'get_pll_clk': src/cpu/samsung/exynos5250/clock.c:183:3: error: initialization from incompatible pointer type [-Werror] which we would not have seen before. As a minor benefit, it shaves most of a second off the compilation. Change-Id: Ie67bc4bc038a8dd1837b977d07332d7d7fd6be1f Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2582 Tested-by: build bot (Jenkins)
2013-03-01GPLv2 notice: Unify all files to just use one space in »MA 02110-1301«Paul Menzel
In the file `COPYING` in the coreboot repository and upstream [1] just one space is used. The following command was used to convert all files. $ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/' [1] http://www.gnu.org/licenses/gpl-2.0.txt Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2490 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-02-20Whitespace: Replace tab character in license text with two spacesPaul Menzel
For whatever reason tabs got inserted in the license header text. Remove one occurrence of that with the following command [1]. $ git grep -l 'MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.'$'\t' | xargs sed -i 's,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.[ ]*,MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\ \ ,' [1] http://sed.sourceforge.net/grabbag/tutorials/sedfaq.txt Change-Id: Iaf4ed32c32600c3b23c08f8754815b959b304882 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2460 Tested-by: build bot (Jenkins) Reviewed-by: Jens Rottmann <JRottmann@LiPPERTembedded.de> Reviewed-by: Cristian Măgherușan-Stanciu <cristi.magherusan@gmail.com>
2013-02-20armv7: Don't let users set ram parameters that are fixed in hardware.Ronald G. Minnich
The SDRAM base is fixed in hardware. It makes no sense to make it configurable. The TEXT start is a magic number that should also be fixed, not settable. Change-Id: Ie44cc5c8da1dc38fc00eb602c4a295b045ca5364 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2465 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-20ARMV7: minor tweaks to inter-stage calling and payload handling.Ronald G. Minnich
Payloads, by design, can return. There's lots of mechanism in the payload code to support it, and the chooser payload relies on it. Hence, we should not mark the function call in exit_stage as noreturn. Not all ARM have unified caches, and it's not always easy to tell what to do. So we are very paranoid. Before we call between stages, we should carefully flush the dcache to memory and invalidate the icache. This may be more than is necessary on all architectures but it doesn't really hurt for the most part. So compile cache management code into all stages, and call the flush dcache/invalidate icache from all stages. Change-Id: Ib9cc625c4dfd2d7d4b3c69a74686cc655a9d6484 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2462 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-19exynos5250: add uartmem_getbaseaddr() in uart driverDavid Hendricks
Change-Id: I76545ad3fca3cc0997050253be77ea83b5d74cb2 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2423 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-19armv7/snow: add CPU and RAM resources via allocatorDavid Hendricks
This adds necessary device operations to add CPU and RAM resources. Change-Id: Ief8f66627ef37f4fa786bfc3f7899529d3e5b037 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2419 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-16exynos5250: clean out some stale IRAM-related config variablesDavid Hendricks
This cleans out some obsolete Kconfig variables pertaining to IRAM usage. Change-Id: Ie53f5f7204eadc3a3dddc739d2b4b6237242b198 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2417 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-02-16armv7/exynos5250: fix usage of _stack and _estackDavid Hendricks
This patch fixes up the usage of stack pointer and regions. The current approach only works by coincidence, so this fixes a few things at once to get it into a working state and allow us to use checkstack() again: - Add a STACK_SIZE Kconfig variable. Earlier on it was evaluated to 0. - Assign _stack and _estack using CPU-specific Kconfig variables since it may reside elsewhere in memory (not necessarily DRAM). - Make the existing IRAM stack variables more useful in this context. Change-Id: I4ca5b5680c9ea7e26b1b2b6b3890e028188b51c2 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2416 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-02-15Exynos5250: Drop unused file ehci-s5p.hStefan Reinauer
Change-Id: I39014377af718766ef86c149e2d2da3d97eaa728 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2407 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-02-15Exynos5: Drop S5P directory and merge filesStefan Reinauer
s5p-common mostly contained duplicate files, drop the whole directory and merge the few pieces that we are using into exynos5-common. Change-Id: I5f18e8a6d2379d719ab6bbbf817fe15bda70d17f Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2405 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-15Exynos: Drop unused include filesStefan Reinauer
Change-Id: Ib533938446a289167725f5beda77c2ee5236e8a5 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2395 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-02-14Exynos: Drop duplicate copy of watchdog.hStefan Reinauer
Change-Id: I4c9bfa9eb7708420dc42c16bc152d761d2bdfee3 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2391 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-14Exynos5250: Drop SHA implementationStefan Reinauer
We don't need SHA in coreboot. Change-Id: I1985d5e2c74fac39ff9dcdba4c23bb34fa857ec7 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2390 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins)
2013-02-13armv7/exynos: remove some stale files leftover from initial importDavid Hendricks
This removes some files leftover from the initial port. Some are leftover from U-Boot and some were leftover from the skeleton code derived from x86. There's a bit more that we'll get in another sweep. Change-Id: I325793ecb902b3b9430dcf531714ce025d201de6 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2380 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-11armv7/exynos5250/snow: deprecate CONFIG_{RAMBASE,RAMTOP}David Hendricks
RAMBASE and RAMTOP are leftovers from the x86 port and do not apply the same way on ARM platforms. On x86 they refer to the low memory region where coreboot tables reside. However on ARM we don't have such a region which is architecturally defined. So instead we'll use the CPU-defined DRAM base address and the mainboard-defined DRAM size. This also has the pleasant side-effect of fixing the coreboot tables to not clobber ramstage code... Change-Id: I5548ecf05e82f9d9ecec8548fabdd99cc1e39c3b Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2351 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-10armv7/snow: Remove unused modules in bootblock and romstage.Hung-Te Lin
For Exynos/snow, cpu_info and power modules and also some parts of the GPIO API (which require timer and pwm modules) are not used in the current bootblock. Clock init only needs to be used if early console is enabled. Now our bootblock is 22420 bytes with early serial console and 11192 bytes without. Those include the 8KB BL1 region. Change-Id: I9c958dafb9cf522df0dcfbef373ce741aa162544 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2322 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-10armv7/exynos5250: place .id between .start and bootblock mainDavid Hendricks
This places the .id section toward the lower region of the coreboot image, before the bootblock. It's easier for humans to find by dumping the image and it also eliminates ID_SECTION_OFFSET which is currently the upper bound on our image size. Change-Id: I7d737b901dac659ddf9aa437cee5dc32f1080546 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2345 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-09armv7/exynos: make BL1_SIZE_KB consistent with numbers used...David Hendricks
The Kconfig variable indicates KB, but the number used was bytes. Let's just assume KB is correct for now. Change-Id: I910c126104f0222fc48b70a18df943f2afddeca3 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2341 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-09armv7/snow: add BL1_SIZE_KB and get rid of magic constantsDavid Hendricks
This adds a BL1_SIZE_KB config variable so that we can get rid of some magic constants. Change-Id: I9dbcfb407d3f8e367be5d943e95b032ce88b0ad0 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2332 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-08armv7: Use same console initialization procedure for all ARM stagesHung-Te Lin
Use same console initialization procedure for all ARM stages (bootblock, romstage, and ramstage): #include <console/console.h> ... console_init() ... printk(level, format, ...) Verified to boot on armv7/snow with console messages in all stages. Change-Id: Idd689219035e67450ea133838a2ca02f8d74557e Signed-off-by: Hung-Te Lin <hungte@chromium.org> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2301 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-08exynos/snow: Configure UART peripheral during console initialization.Hung-Te Lin
For Exynos platforms, the UART component on pinmux must be first selected and configured. This should be done as part of UART console initialization. Note, that the current implementation hard-codes the device index as UART3, while the base port can be assigned to different device in Kconfig. This will be fixed later. Verified to work on armv7/snow. Change-Id: Ie63e76e2dac09fec1132573d1b0027fce55333a1 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2315 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-07armv7/snow: Remove power_init from bootblock.Hung-Te Lin
The power_init is not required on Exynos 5250 (snow) in bootblock stage. To get a cleaner and faster bootblock, we can remove it. Note, power_init internally calls max77686 and s3c24x0_i2c, so both files are also removed. Verified to boot on armv7/snow. Change-Id: I5b15dfe5ac7bf4650565fea0afefc94a228ece29 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2317 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-07armv7: Clean up arm/snow bootblock build process.Hung-Te Lin
Remove duplicated / testing code and share more driver for bootblock, romstage and ramstage. The __PRE_RAM__ is now also defined in bootblock build stage, since bootblock is executed before RAM is initialized. Change-Id: I4f5469b1545631eee1cf9f2f5df93cbe3a58268b Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2282 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-06armv7: Clean up: remove deprecated SPL.Hung-Te Lin
"SPL" from U-Boot is deprecated by bootblock in coreboot/arm, so we don't need it anymore. Change-Id: Id16877075d0b870839a10160073ad70777a2af0a Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2297 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-06armv7: Prevent CBFS data overlapping bootblock.Hung-Te Lin
For arm/snow, current bootblock is larger than previously assigned CBFS offset and will fail to boot. To prevent this happening again in future, cbfstool now checks if CBFS will overlap bootblock. A sample error message: E: Bootblock (0x0+0x71d4) overlap CBFS data (0x5000) E: Failed to create build/coreboot.pre1.tmp. arm/snow offset is also enlarged and moved to Kconfig variable. Change-Id: I4556aef27ff716556040312ae8ccb78078abc82d Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: http://review.coreboot.org/2295 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-02-06exynos/snow: Move core/memory clock-related and board ID codeDavid Hendricks
This patch moves ARM core and DRAM timing functions around to simplify the dependencies for system_clock_init(). The original code was architected such that the system_clock_init() function called other functions to obtain core and memory timings. Due to the way memory timing information must be obtained on Snow, which entails decoding platform-specific board straps, the bottom- up approach resulted in having the low-level clock init code implicitly depend on board and vendor-specific info: main() ->system_clock_init() -> get_arm_ratios() -> CPU-specific code -> clock_get_mem_timings() -> board_get_revision() -> read GPIOs (3-state logic) -> Decode GPIOs in a vendor-specific manner -> Choose memory timings from module-specific look-up table ...then proceed to init clocks ...come back to main() The new approach gathers all board and vendor-specific info in a more appropriate location and passes it into system_clock_init(): main() -> get_arm_ratios() -> CPU-specific code -> get_mem_timings() -> board_get_config() -> read GPIOs (3-state logic) -> Decode GPIOs in a vendor-specific manner -> Choose memory timings from module-specific look-up table -> system_clock_init() ...back to main() Change-Id: Ie237ebff76fc2d8a4d2f4577a226ac3909e4d4e8 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2271 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-06snow: use bootblock build class for GPIODavid Hendricks
This gets rid of a bunch of copy + pasted GPIO code. Change-Id: I548b2b5d63642a9da185eb7b34f80cbebf9b124f Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2288 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-06exynos5250: Move the ID section againDavid Hendricks
Move the ID section again due to bootblock bloat. So long as it's within the first 32K of our address space, we're good. TODO: 1. Place ID section near start of ROM to avoid this issue. 2. Reduce bootblock bloat. 3. Make bootblock debugging a Kconfig option. Change-Id: I3f0764a3345a8cbbafcc15e4d06c38cd6327758c Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2287 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-05snow: use bootblock build class for UART codeDavid Hendricks
This gets rid of a bunch of copy + pasted code from Exynos UART files. Change-Id: I9fbb6d79a40a338c9fdecd495544ff207909fd37 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2286 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2013-02-05exynos: de-duplicate UART header contentDavid Hendricks
Some header content got duplicated during the initial porting effort. This moves generic UART header stuff to exynos5-common and leaves exynos5250 #defines in the AP-specific UART header. Change-Id: Ifb6289d7b9dc26c76ae4dfcf511590b3885715a3 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2285 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-02-04exynos5250: make lowlevel_init_c.c benignDavid Hendricks
This file has mostly (but not entirely) been replaced by coreboot stage files. We'll keep it around for a bit longer as a reference, but in the meantime we'll stop compiling it as to avoid comptilation issues as we change other parts of the code. Change-Id: I669fb1e5a1517f35979590957d581bd33df53d29 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2269 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-04exynos/snow: partial clean-up of snow bootblock using build classDavid Hendricks
This removes some duplicate code from Snow's mainboard bootblock by utilizing the bootblock build class. Change-Id: I153247370a8c5127260082dcdca3ebdc5e104fb8 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2270 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-04exynos/s5p: Add helper function for reading a single MVL3 GPIODavid Hendricks
This adds a helper function to read only a single GPIO which uses 3-state logic. Examples of this typically include board straps which are used to provide mainboard-specific information at the hardware- level, such as board revision or configuration options. This is part of a larger clean-up effort for Snow. We may want to genericise this for other CPUs in the future. Change-Id: Ic44f5e589cda89b419a07eca246847e9ce7dcd8d Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2266 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>