summaryrefslogtreecommitdiff
path: root/src/soc/imgtec/pistachio/Kconfig
AgeCommit message (Collapse)Author
2016-12-23spi: Get rid of SPI_ATOMIC_SEQUENCINGFurquan Shaikh
SPI_ATOMIC_SEQUENCING was added to accomodate spi flash controllers with the ability to perform tx and rx of flash command and response at the same time. Instead of introducing this notion at SPI flash driver layer, clean up the interface to SPI used by flash. Flash uses a command-response kind of communication. Thus, even though SPI is duplex, flash command needs to be sent out on SPI bus and then flash response should be received on the bus. Some specialized x86 flash controllers are capable of handling command and response in a single transaction. In order to support all the varied cases: 1. Add spi_xfer_vector that takes as input a vector of SPI operations and calls back into SPI controller driver to process these operations. 2. In order to accomodate flash command-response model, use two vectors while calling into spi_xfer_vector -- one with dout set to non-NULL(command) and other with din set to non-NULL(response). 3. For specialized SPI flash controllers combine two successive vectors if the transactions look like a command-response pair. 4. Provide helper functions for common cases like supporting only 2 vectors at a time, supporting n vectors at a time, default vector operation to cycle through all SPI op vectors one by one. BUG=chrome-os-partner:59832 BRANCH=None TEST=Compiles successfully Change-Id: I4c9e78c585ad95c40c0d5af078ff8251da286236 Signed-off-by: Furquan Shaikh <furquan@chromium.org> Reviewed-on: https://review.coreboot.org/17681 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-05-09drivers/uart: Use uart_platform_refclk for all UART modelsLee Leahy
Allow the platform to override the input clock for the UART by implementing the routine uart_platform_refclk and setting the Kconfig value UART_OVERRIDE_REFCLK. Provide a default uart_platform_refclk routine which is disabled when UART_OVERRIDE_REFCLK is selected. This works around ROMCC not supporting weak routines. Testing on Galileo: * Edit the src/mainboard/intel/galileo/Makefile.inc file: * Add "select ADD_FSP_PDAT_FILE" * Add "select ADD_FSP_RAW_BIN" * Add "select ADD_RMU_FILE" * Place the FSP.bin file in the location specified by CONFIG_FSP_FILE * Place the pdat.bin files in the location specified by CONFIG_FSP_PDAT_FILE * Place the rmu.bin file in the location specified by CONFIG_RMU_FILE * Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate UEFIPAYLOAD.fd * Testing is successful when CorebootPayloadPkg is able to properly initialize the serial port without using built-in values. Change-Id: If4afc45a828e5ba935fecb6d95b239625e912d14 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/14612 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2015-12-17Drop src/cpu/ indirection for MIPSStefan Reinauer
Change-Id: I406166e650e07851ab1b293450fa29da8af075d9 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/12724 Tested-by: build bot (Jenkins) Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2015-12-17soc/imgtec/pistachio: Implement hard_reset()Stefan Reinauer
Verified boot needs hard_reset() now, so offer a dummy implementation for the Imagination chip. Sorry, I don't have the specs for this chip anymore to make a real implementation, but I would like to keep this code from bit rotting. Change-Id: I15aa47f7d248b99901a2ac0e65a46b43d7718717 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/12723 Tested-by: build bot (Jenkins) Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
It encourages users from writing to the FSF without giving an address. Linux also prefers to drop that and their checkpatch.pl (that we imported) looks out for that. This is the result of util/scripts/no-fsf-addresses.sh with no further editing. Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/11888 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-06-21Remove old HAVE_UART_MEMORY_MAPPED select statementsMartin Roth
The HAVE_UART_MEMORY_MAPPED symbol is no longer present, so these don't actually select anything. Change-Id: I6d0eb610e48a4506ac7449ac677ee67981d0ff0d Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/10608 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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
DYNAMIC_CBMEM is only selected a couple of times but never declared or read. Remove it. Change-Id: I5016dac2c935d3f261001e9f388a8989540e93ae Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10255 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Tested-by: build bot (Jenkins)
2015-04-22soc: select generic gpio lib on (almost) all non-x86 SOCsStefan Reinauer
BOARD_ID functionality is not what requires the GPIO lib, but it is the mainboard specific implementations that do. The option essentially says whether the SoC provides <soc/gpio.h> (with the interface required by the common GPIO code). Right now, x86 and Samsung's Exynos SOCs don't have support for this interface. So this should be selected by the SOC, not by BOARD_ID_SUPPORT. Signed-off-by: Stefan Reinauer <reinauer@chromium.org> BUG=none BRANCH=none TEST=emerge-storm coreboot still successfully compiled an image Change-Id: I0ce2bd7ce023f22791d31a6245833b61135504b3 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 0dd4dea521372194eedf11b077d95fd3b15ad9f7 Original-Change-Id: I3dea6c2fb42a23fcb9d384c3bbfa7fc8e217be2d Original-Reviewed-on: https://chromium-review.googlesource.com/262743 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Original-Tested-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Queue: Stefan Reinauer <reinauer@chromium.org> Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9899 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-14CBFS: Automate ROM image layout and remove hardcoded offsetsJulius Werner
Non-x86 boards currently need to hardcode the position of their CBFS master header in a Kconfig. This is very brittle because it is usually put in between the bootblock and the first CBFS entry, without any checks to guarantee that it won't overlap either of those. It is not fun to debug random failures that move and disappear with tiny alignment changes because someone decided to write "ORBC1112" over some part of your data section (in a way that is not visible in the symbolized .elf binaries, only in the final image). This patch seeks to prevent those issues and reduce the need for manual configuration by making the image layout a completely automated part of cbfstool. Since automated placement of the CBFS header means we can no longer hardcode its position into coreboot, this patch takes the existing x86 solution of placing a pointer to the header at the very end of the CBFS-managed section of the ROM and generalizes it to all architectures. This is now even possible with the read-only/read-write split in ChromeOS, since coreboot knows how large that section is from the CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be changed on systems that place other data next to coreboot/CBFS in ROM). Also adds a feature to cbfstool that makes the -B (bootblock file name) argument on image creation optional, since we have recently found valid use cases for CBFS images that are not the first boot medium of the device (instead opened by an earlier bootloader that can already interpret CBFS) and therefore don't really need a bootblock. BRANCH=None BUG=None TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco. Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af Original-Signed-off-by: Julius Werner <jwerner@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/229975 Reviewed-on: http://review.coreboot.org/9620 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-04-09pistachio: allow more room for bootblockVadim Bendebury
32K is a more appropriate room for Pistachio bootblock. BRANCH=none BUG=chrome-os-partner:31438 TEST=there is no bootblock overflow even when compiled with -O0. Change-Id: I454746ce0b9daabc93ccbf3316655fac836af8ff Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 56adf22ba12f5a7c69d11c0c720996de32ca9149 Original-Change-Id: I74b6674aea95b1138e2168527239e2cfb4a7ad42 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/232291 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/9190 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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-04-02urara: Fix CBFS header definitionsVadim Bendebury
Urara CBFS header configuration is broken. CBFS header needs to be right above the bootblock, and the CBFS data - 0x100 bytes above, to allow room for proper CBFS wrapper structures. Ideally only the header offset should be specified (and even that could be derived from the bootblock size). But this is a more generic problem to be addressed with different architectures' image layout requirements in mind. BRANCH=none BUG=chrome-os-partner:31438 TEST=coreboot image passes the integrity check now (it was failing before because CBGS header was overlaying the bootblock) $ FEATURES=noclean emerge-urara coreboot $ /build/urara/tmp/portage/sys-boot/coreboot-9999/work/coreboot-9999/build/util/bimgtool/bimgtool \ /build/urara/firmware/coreboot.rom.serial $ cbfstool /build/urara/firmware/coreboot.rom.serial print coreboot.rom.serial: 1024 kB, bootblocksize 9956, romsize 1048576, offset 0x4100 alignment: 64 bytes, architecture: mips Name Offset Type Size fallback/romstage 0x4100 stage 7100 fallback/ramstage 0x5d00 stage 18995 config 0xa780 raw 2452 (empty) 0xb140 null 1003096 Change-Id: Id615bdcc6261dea9f36a409bd90f1e4764353bb9 Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 8a0115963aa7460e4c7255ab8508d7d52d67fb67 Original-Change-Id: Id200ab5421661ef39b7c7713e931c39153fdc8be Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/227523 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/9187 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-03-27soc/imgtec/pistachio: Add IMGTEC SPI controller driverIonela Voinescu
The Serial Peripheral Flash Interface (SPFI) block allows communication with various devices over the SPI bus. It uses a configurable transaction interface and it clocks the bus according to the configured command, address, gap (aka dummy) and data lengths. This controller requires the SPI_ATOMIC_SEQUENCING flag set (write and read done in the same transaction) as it cannot directly control CS and will assert/de-assert CS at the beginning/end of a transaction itself. Note that the size of any transfer cannot be greater than 64KB - 1, as this is configured in a 16-bit field. The SOC has 2 SPFI interfaces each of them providing 5 slave select lines. SPFI 0 supports single and dual modes, SPFI 1 supports single, dual and quad modes. For SPFI interface 0: - The block needs the system PLL and the following top level SPI clock registers to be set: - CR_cr_top_spi0clkinternal_CTRL[2:0] with division value - CR_MIPS_CLOCK_GATE[19]: bit cr_top_SPI0CLKOUT_MIPS set - CR_cr_top_SPI0CLKOUT_CTRL[6:0] with division value - The following MFIO configuration parameters are also required: Signal name Pad name MFIO mode spim0_d0_txd MFIO_MIPS_10 0 spim0_d1_rxd MFIO_MIPS_9 0 spim0_mclk MFIO_MIPS_8 0 spim0_cs0 MFIO_MIPS_2 1 spim0_cs1 MFIO_MIPS_1 1 spim0_cs2 MFIO_MIPS_55 1 MFIO_MIPS_28 1 spim0_cs3 MFIO_MIPS_56 1 MFIO_MIPS_29 1 spim0_cs4 MFIO_MIPS_57 1 MFIO_MIMPS_30 1 For SPFI interface 1: - The block needs the system PLL and the following top level SPI clock registers to be set: - CR_cr_top_spi1clkinternal_CTRL[2:0] with division value - CR_MIPS_CLOCK_GATE[20]: bit cr_top_SPI1CLKOUT_MIPS set - CR_cr_top_SPI1CLKOUT_CTRL[6:0] with division value - The following MFIO configuration parameters are also required: Signal name Pad name MFIO mode spim1_d0_txd MFIO_MIPS_5 0 spim1_d1_rxd MFIO_MIPS_4 0 spim1_mclk MFIO_MIPS_3 0 spim1_d2 MFIO_MIPS_6 0 spim1_d3 MFIO_MIPS_7 0 spim1_cs0 MFIO_MIPS_0 0 spim1_cs1 MFIO_MIPS_1 0 MFIO_MIPS_58 1 spim1_cs2 MFIO_MIPS_2 0 MFIO_MIPS_55 2 MFIO_MIPS_31 1 spim1_cs3 MFIO_MIPS_56 2 spim1_cs4 MFIO_MIPS_57 2 BUG=chrome-os-partner:31438, chrome-os-partner:32441 TEST=Tested as bare-metal driver on Pistachio FPGA Change-Id: I3b3e4475976e6fba58cef93b12d997ec5cb26341 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 621849942e27f7d6cf2c8ade7f2c4d18d2318b91 Original-Change-Id: Ib257eb6236bd2895281175871b4ab979660f1239 Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com> Original-Reviewed-on: https://chromium-review.googlesource.com/217320 Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: http://review.coreboot.org/9049 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-03-27urara: use proper SOC nameVadim Bendebury
Danube has become Pistachio, let's rename all instances where this SOC is mentioned. BUG=none TEST=board urara still builds Change-Id: Iea91419121eb6ab5665c2f9f95e82f461905268e Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 58696cc7c77a70dca2bfd512d695d143e1097a78 Original-Change-Id: Ie5ede401c4f69ed5d832a9eabac008eeac6db62d Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/220401 Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org> Reviewed-on: http://review.coreboot.org/9048 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>