summaryrefslogtreecommitdiff
path: root/src/cpu/ti
AgeCommit message (Collapse)Author
2015-06-02cbfs: new API and better program loadingAaron Durbin
A new CBFS API is introduced to allow making CBFS access easier for providing multiple CBFS sources. That is achieved by decoupling the cbfs source from a CBFS file. A CBFS source is described by a descriptor. It contains the necessary properties for walking a CBFS to locate a file. The CBFS file is then decoupled from the CBFS descriptor in that it's no longer needed to access the contents of the file. All of this is accomplished using the regions infrastructure by repsenting CBFS sources and files as region_devices. Because region_devices can be chained together forming subregions this allows one to decouple a CBFS source from a file. This also allows one to provide CBFS files that came from other sources for payload and/or stage loading. The program loading takes advantage of those very properties by allowing multiple sources for locating a program. Because of this we can reduce the overhead of loading programs because it's all done in the common code paths. Only locating the program is per source. Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9134 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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-05-19Remove Kconfig variable that has no effectPatrick Georgi
CPU_HAS_BOOTBLOCK_INIT is only declared once and selected elsewhere (with no overlap), and never read. Remove it. Change-Id: I3f294b0724a87876a7e2f274e6933fe10321a69d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10253 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-04-21arm(64): Globally replace writel(v, a) with write32(a, v)Julius Werner
This patch is a raw application of the following spatch to src/: @@ expression A, V; @@ - writel(V, A) + write32(A, V) @@ expression A, V; @@ - writew(V, A) + write16(A, V) @@ expression A, V; @@ - writeb(V, A) + write8(A, V) @@ expression A; @@ - readl(A) + read32(A) @@ expression A; @@ - readb(A) + read8(A) BRANCH=none BUG=chromium:444723 TEST=None (depends on next patch) Change-Id: I5dd96490c85ee2bcbc669f08bc6fff0ecc0f9e27 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 64f643da95d85954c4d4ea91c34a5c69b9b08eb6 Original-Change-Id: I366a2eb5b3a0df2279ebcce572fe814894791c42 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254864 Reviewed-on: http://review.coreboot.org/9836 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-21arm(64): Replace write32() and friends with writel()Julius Werner
This patch is a raw application of the following spatch to the directories src/arch/arm(64)?, src/mainboard/<arm(64)-board>, src/soc/<arm(64)-soc> and src/drivers/gic: @@ expression A, V; @@ - write32(V, A) + writel(V, A) @@ expression A, V; @@ - write16(V, A) + writew(V, A) @@ expression A, V; @@ - write8(V, A) + writeb(V, A) This replaces all uses of write{32,16,8}() with write{l,w,b}() which is currently equivalent and much more common. This is a preparatory step that will allow us to easier flip them all at once to the new write32(a,v) model. BRANCH=none BUG=chromium:451388 TEST=Compiled Cosmos, Daisy, Blaze, Pit, Ryu, Storm and Pinky. Change-Id: I16016cd77780e7cadbabe7d8aa7ab465b95b8f09 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 93f0ada19b429b4e30d67335b4e61d0f43597b24 Original-Change-Id: I1ac01c67efef4656607663253ed298ff4d0ef89d Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/254862 Reviewed-on: http://review.coreboot.org/9834 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-17uart: pass register width in the coreboot tableVadim Bendebury
Some SOCs (like pistachio, for instance) provide an 8250 compatible UART, which has the same register layout, but mapped to a bus of a different width. Instead of adding a new driver for these controllers, it is better to have coreboot report UART register width to libpayload, and have it adjust the offsets accordingly when accessing the UART. BRANCH=none BUG=chrome-os-partner:31438 TEST=with the rest of the patches integrated depthcharge console messages show up when running on the FPGA board Change-Id: I30b742146069450941164afb04641b967a214d6d Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 2c30845f269ec6ae1d53ddc5cda0b4320008fa42 Original-Change-Id: Ia0a37cd5f24a1ee4d0334f8a7e3da5df0069cec4 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240027 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9738 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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-13ti/am335x: switch to generic udelayPatrick Georgi
Change-Id: Iac1ddbb95768dea98917211aa995f4111bf82647 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9617 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>
2015-01-27CBMEM: Always use DYNAMIC_CBMEMKyösti Mälkki
Drop the implementation of statically allocated high memory region for CBMEM. There is no longer the need to explicitly select DYNAMIC_CBMEM, it is the only remaining choice. Change-Id: Iadf6f27a134e05daa1038646d0b4e0b8f9f0587a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7851 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Aaron Durbin <adurbin@google.com>
2015-01-27vboot2: add verstageStefan Reinauer
This reverts the revert commit 5780d6f3876723b94fbe3653c9d87dad6330862e and fixes the build issue that cuased it to be reverted. Verstage will host vboot2 for firmware verification. It's a stage in the sense that it has its own set of toolchains, compiler flags, and includes. This allows us to easily add object files as needed. But it's directly linked to bootblock. This allows us to avoid code duplication for stage loading and jumping (e.g. cbfs driver) for the boards where bootblock has to run in a different architecture (e.g. Tegra124). To avoid name space conflict, verstage symbols are prefixed with verstage_. TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze. BUG=None BRANCH=none Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac Original-Reviewed-on: https://chromium-review.googlesource.com/204376 Original-Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf Reviewed-on: http://review.coreboot.org/8224 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-01-03ARMv7: Always has DYNAMIC_CBMEMKyösti Mälkki
The static allocator only worked for x86 anyway. Change-Id: I0d2b63465620512e62334d7aa0c885fc5ab3e589 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/8030 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-12-30ipq/arm: Redesign hooks for bootblockVadim Bendebury
The following patches had to be squashed to properly build all the different ARM boards. ipq8064: storm: re-arrange bootblock initialization The recent addition of the storm bootblock initialization broke compilation of Exynos platforms. The SOC specific code needs to be kept in the respective source files, not in the common CPU code. As of now coreboot does not provide a separate SOC initialization API. In general it makes sense to invoke SOC initialization from the board initialization code, as the board knows what SOC it is running on. Presently all what's need initialization on 8064 is the timer. This patch adds the SOC initialization framework for 8064 and moves there the related code. BUG=chrome-os-partner:27784 TEST=manual . nyan_big, peach_pit, and storm targets build fine now. Original-Change-Id: Iae9a021f8cbf7d009770b02d798147a3e08420e8 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/197835 (cherry picked from commit 3ea7307b531b1a78c692e4f71a0d81b32108ebf0) Signed-off-by: Marc Jones <marc.jones@se-eng.com> arm: Redesign mainboard and SoC hooks for bootblock This patch makes some slight changes to the way bootblock_cpu_init() and bootblock_mainboard_init() are used on ARM. Experience has shown that nearly every board needs either one or both of these hooks, so having explicit Kconfigs for them has become unwieldy. Instead, this patch implements them as a weak symbol that can be overridden by mainboard/SoC code, as the more recent arm64_soc_init() is also doing. Since the whole concept of a single "CPU" on ARM systems has kinda died out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had already been done on Storm/ipq806x, which is now adjusted to directly use the generic hook.) Also add a proper license header to bootblock_common.h that was somehow missing. Leaving non-ARM32 architectures out for now, since they are still using the really old and weird x86 model of directly including a file. These architectures should also eventually be aligned with the cleaner ARM32 model as they mature. BRANCH=None BUG=chrome-os-partner:32123 TEST=Booted on Pinky. Compiled for Storm and confirmed in the disassembly that bootblock_soc_init() is still compiled in and called right before the (now no-op) bootblock_mainboard_init(). Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79 Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/231940 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 257aaee9e3aeeffe50ed54de7342dd2bc9baae76) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Id055fe60a8caf63a9787138811dc69ac04dfba57 Reviewed-on: http://review.coreboot.org/7879 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-12-19arm/ti/am335x: use new arm bootblock infrastructureAlexander Couzens
commit 8b685398 (ARM: Overhaul the ARM Makefile.) changes config flags for cpu and mainboard bootblock initialization. Tested on beaglebone black. Change-Id: I70cbe3abad8443c5dc71c8ba76a35973a5284477 Signed-off-by: Alexander Couzens <lynxis@fe80.eu> Reviewed-on: http://review.coreboot.org/7189 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-10-16uarts: 32/64 cleanupRonald G. Minnich
We had lots of casts that caused warnings when compiling on RISCV. Clean them up. Change-Id: I46fcb33147ad6bf75e49ebfdfa05990e8c7ae4eb Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/7066 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-08ARM: Generalize armv7 as arm.Gabe Black
There are ARM systems which are essentially heterogeneous multicores where some cores implement a different ARM architecture version than other cores. A specific example is the tegra124 which boots on an ARMv4 coprocessor while most code, including most of the firmware, runs on the main ARMv7 core. To support SOCs like this, the plan is to generalize the ARM architecture so that all versions are available, and an SOC/CPU can then select what architecture variant should be used for each component of the firmware; bootblock, romstage, and ramstage. Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/171338 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> ARM: Split out ARMv7 code and make it possible to have other arch versions. We don't always want to use ARMv7 code when building for ARM, so we should separate out the ARMv7 code so it can be excluded, and also make it possible to include code for some other version of the architecture instead, all per build component for cases where we need more than one architecture version at a time. The tegra124 bootblock will ultimately need to be ARMv4, but until we have some ARMv4 code to switch over to we can leave it set to ARMv7. Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7 Reviewed-on: https://chromium-review.googlesource.com/171400 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483) Squashed two related patches for splitting ARM support into general ARM support and ARMv7 specific pieces. Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6782 Tested-by: build bot (Jenkins)
2014-05-06Introduce stage-specific architecture for corebootFurquan Shaikh
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-05-03Move ARCH_* from board/Kconfig to cpu or soc Kconfig.Furquan Shaikh
CONFIG_ARCH is a property of the cpu or soc rather than a property of the board. Hence, move ARCH_* from every single board to respective cpu or soc Kconfigs. Also update abuild to ignore ARCH_ from mainboards. Change-Id: I6ec1206de5a20601c32d001a384a47f46e6ce479 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5570 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-04-30console: Drop EARLY_CONSOLE optionKyösti Mälkki
We have means to easily disable a specific console in romstage if necessary, so this global option makes little sense. The option was initially introduced as a work-around for build issues around CACHE_AS_RAM, ROMCC and ARCH_ARMV7 dependencies for UARTs. Change-Id: I797bdd11a48ddd813d3ee7ccef9a0c050f16f669 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5607 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-04-30uart: Support multiple portsKyösti Mälkki
The port for console remains to be a compile time constant. The Kconfig option is changed to select an UART port with index to avoid putting map of UART base addresses in Kconfigs. With this change it is possible to have other than debug console on different UART port. Change-Id: Ie1845a946f8d3b2604ef5404edb31b2e811f3ccd Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5342 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-04-09uart: Redefine Kconfig optionsKyösti Mälkki
Option DRIVERS_UART builds with support for UART hardware. Option CONSOLE_SERIAL enables the console output for UART. Those x86 boards that do not have serial port on SuperIO should select NO_UART_ON_SUPERIO to disable 8250 UART for the default configuration. Removes: CONSOLE_SERIAL_UART HAVE_UART_IO_MAPPED HAVE_UART_MEMORY_MAPPED Renames: CONSOLE_SERIAL8250 -> DRIVERS_UART_8250IO CONSOLE_SERIAL8250MEM -> DRIVERS_UART_8250MEM Change-Id: Id3afa05f85c0d6849746886db8b6c2ed6c846b61 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5311 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-04-09console uart: Fill coreboot table entriesKyösti Mälkki
Also fixes the reported baudrate to take get_option() into account. Change-Id: Ieadad70b00df02a530b0ccb6fa4e1b51526089f3 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5310 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-04-09uart: Prepare to support multiple base addressesKyösti Mälkki
Prepare low-level register access to take UART base address as a parameter. This is done to support a list of base addresses defined in the platform. Change-Id: Ie630e55f2562f099b0ba9eb94b08c92d26dfdf2e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5309 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-03-04console: Use single driver entry for UARTsKyösti Mälkki
UARTs now have unified prototypes and can use a single entry in the list of drivers for ramstage. Change-Id: I315daaf9a83cfa60f1a270146c729907a1d6d45b Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5308 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-03-04console: Fix includesKyösti Mälkki
Do not pull in console hw-specific prototypes everywhere with console.h as those are not needed for higher levels. Move prototypes for UARTs next to other consoles. Change-Id: Icbc9cd3e5bdfdab85d7dccd7c3827bba35248fb8 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5232 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-03-04ti/am335x: Fix baudrate calculationKyösti Mälkki
UART input clock is platform dependent. Also account for possible use of get_option() where baudrate is not compile-time constant. The hardware reference on BeagleBone is from a 48 MHz oscillator input. With pre-divisor of 16 we get same register values as in table 19-25. Change-Id: I89aee27c958f8618ce79a968ae7520a867e7e8a2 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5290 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-02-24TI am335x: Apply Kconfig use conventionsKyösti Mälkki
Change-Id: Ic3c26fd7b1dd8a6731abc9a63b9ca17e084074b2 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5291 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2014-02-06ARMv7: Remove static CBMEM allocationKyösti Mälkki
The calculations for static allocation are no longer valid. Change-Id: I6740cdcec789abddf78485a0edaf24882ef8c2a5 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4569 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-09-17am335x: Update the config vars selected by CPU_TI_AM335X.Gabe Black
The way those variables work has changed twice since this file was last changed, and console output was no longer working. Now that they're up to date there's serial output from beaglebone again. Change-Id: I5167fd8c0a8c33438d7f056fdf5951bd054010ed Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3923 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-15am335x: Make the default media for the bootblock sram instead of NAND flash.Gabe Black
The SOC's built in ROM loads the bootblock and the ROM stage into the on chip memory before handing over control to the bootblock. To avoid having to add one or more driver to the bootblock so that it can re-load the ROM stage from whatever media Coreboot is stored on, we can just take advantage of the copy that's already there. Loading the RAM stage/payloads won't be so simple, so the ROM stage and the RAM stage will have to have different media drivers. Change-Id: Id74ed4bc3afd2063277a36e666080522af2305dd Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3583 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-15am335x: Add the config variable ROMSTAGE_BASE to the CPU's Kconfig.Gabe Black
This variable wasn't being defined and was defaulting to zero when used in the ROM stage's linker script. This change defines it as a variable, and gives it a value which is slightly beyond the end of the bootblock. By making the ROM stage request to be loaded slightly farther into memory than it was loaded by the SOC's masked ROM, we ensure that it's moved away from the stage's metadata instead of on top of it. When it moves the other way, it clobbers important values like the entry point vefore the bootblock has had a chance to use them. Change-Id: I027a1365d05f1d79d7fc1e1349965ccb7d4e81b9 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3582 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-06am335x: Implement support for the UART.Gabe Black
This patch was started by Dave Hendricks and implements the procedure for setting up the UART as described in the manual. Some unused code was removed. Change-Id: If26a424cac401ef3eafaec081147f41184fbcee9 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3490 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-07-01am335x: Fix the address of the pinmux registers.Gabe Black
The pinmux register data structure describes a subset of the control module registers, but the address which pointed to the base of the pinmux registers was actually being set to the beginning of all the control module registers, not just those having to do with the pinmux. With this address fixed, the UART now works on the beaglebone black. Change-Id: I7c99b6f37d7da359af074127cd0c1a86fda2d9a0 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3574 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-17am335x: Add pinmux support based on the functions in U-BootGabe Black
I was unable to find documentation that said what mode numbers correspond to what functionality, so I translated over what U-Boot does. Change-Id: I34fab0f024fa2322d6bb66106aed75224e67354d Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3489 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-12am335x: Add struct `am335x_uart` for uart registersDavid Hendricks
Add a struct for referencing UART registers. The layout is quite strange on this chip, as the entire register space can take on three different meanings depending on the line control settings (in the LCR register) And to make things more confusing, some offsets reference different registers depending on if a read or a write operation is used. Change-Id: Ie62af9c0e0edafd01b81686a0fe5c5c1d4fa06c4 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/3319 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-11am335x: Revert how the header load size is calculated to an earlier method.Gabe Black
The current method will treat hex values as 0 and would calculate the wrong size. This change switches back to an earlier method which used shell syntax to add the offset and size. Change-Id: I9fb2d9b323f113cc56a5ad2e38b47d2d22084f08 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3432 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-11am335x: Make the iROM load only the bootblock and ROM stage.Gabe Black
The bootblock and ROM stages are the only ones that are really required to be loaded in the quite limited on chip RAM during startup. Rather than load the whole image which requires everything to be small, load just the bootblock and the ROM stage, allowing the rest of the image to be arbitrarily large. Loading a minimal amount of stuff should also improve boot performance a little bit. Change-Id: I2fede63b8d3d8f0d880e4a692ae423021f8232b6 Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3421 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-10am335x: Build an omap style header and an image with it at the front.Gabe Black
Loading on an OMAP SOC requires that the first sector of the image have a configuration header, and, when not an execute in place image, an additional header which describes how big the image is and where it should be loaded. This change adds some infrastructure to statically build that header using C code, and to paste the header onto the front of coreboot.rom in a new top level target file called MLO. The configuration header we're using is as inert as possible, in line with what U-Boot is doing. I think it could be used to give additional configuration parameters to the built-in ROM on the SOC, but we don't need to do that, and there didn't seem to be any actual documentation how to do that. Because the header is built from C and is defined per CPU, it would be possible to include extra settings in other CPUs if desired. Adding a new top level build target is a bit disruptive, but should be contained to the am335x directory and not interfere with other mainboards. Change-Id: I06d346a4050c20963b3c7c6e8a152070bf2d145a Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3332 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-03am335x: Clean up/fix some settings in the am335x Kconfig.Gabe Black
Some settings in the am335x Kconfig weren't actually used for anything, some where place holders, and some where left over from another CPU. The memory addresses are in the internal RAM in the SOC as described in the reference manual. The stack is put where the internal ROM had its stack, and the bootblock is put at the bottom of that region as the manual suggests. The ROM stage offset is set to 10K which is a bit bigger than the ~7.5K the bootblock currently takes up. Change-Id: I1a117d789a791d7e3db1118823f8216b3361433c Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3327 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-05-26beaglebone: initial Kconfig and MakefilesGabe Black
Initial structure of Beaglebone port Change-Id: Ia255ab207f424dcd525990cdc0d74953e012c087 Signed-off-by: David Hendricks <dhendrix@chromium.org> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3279 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>