summaryrefslogtreecommitdiff
path: root/src/soc/qualcomm/ipq806x/soc.c
AgeCommit message (Collapse)Author
2018-05-28soc/qualcomm: Get rid of device_tElyes HAOUAS
Use of device_t has been abandoned in ramstage. Change-Id: Ib7bcfefaecc053a1ed28d708a614acb81207bccf Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/26536 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.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-05-21Remove address from GPLv2 headersPatrick Georgi
As per discussion with lawyers[tm], it's not a good idea to shorten the license header too much - not for legal reasons but because there are tools that look for them, and giving them a standard pattern simplifies things. However, we got confirmation that we don't have to update every file ever added to coreboot whenever the FSF gets a new lease, but can drop the address instead. util/kconfig is excluded because that's imported code that we may want to synchronize every now and then. $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} + $ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} + $ find * -type f -a \! -name \*.patch \ -a \! -name \*_shipped \ -a \! -name LICENSE_GPL \ -a \! -name LGPL.txt \ -a \! -name COPYING \ -a \! -name DISCLAIMER \ -exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} + Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/9233 Tested-by: build bot (Jenkins) Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
2015-04-18ipq806x: initialize UART even when console is not enabledVadim Bendebury
The ipq806x UART is based on the same universal serial port which can be also configured as i2c or SPI. Configuring it is not a trivial task, so in case the kernel wants to use earlyprintk() the port needs to be configured by the firmware. Invoking uart_init() when the console is not enabled causes include file collisions, which would require changes to more than 100 files. Leaving this to another day, rearranging the ipq806x driver to be able to invoke UART initialization function even when serial console is not configured. Also add a check to avoid initialization if UART has been already set up. BRANCH=storm BUG=chrome-os-partner:35364 TEST=verified that storm console is still fully operational when enabled, and that the kernel boots fine to the serial console login prompt even if the firmware console is disabled. Change-Id: Ibbbab875449f2ac2f0d6c504c18faf0da8251ffa Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: c512d6c1d0c0868137d1213ea84cd4bca58872db Original-Change-Id: I421acba3edf398d960b5058f15d1abb80ebc7660 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/240516 Original-Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/9794 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-09storm: Reserve memory from 0x4000_0000-0x414f_ffffDavid Hendricks
This marks the bottom chunk of memory, which is used by various IP blocks, as reserved so that Depthcharge does not attempt to wipe it. BUG=chrome-os-partner:30067 BRANCH=storm TEST=Built and booted for storm, depthcharge shows: Wipe memory regions: [0x00000041500000, 0x00000051000000) [0x000000510006a0, 0x00000053000000) [0x00000054141260, 0x0000007fffd000) Original-Signed-off-by: David Hendricks <dhendrix@chromium.org> Original-Change-Id: I8f782f16d13620b705e1b3fbeca21dc8705b7e77 Original-Reviewed-on: https://chromium-review.googlesource.com/206516 Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit f66f553f1594c481a74b7f40b4b1088600b1a70a) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I82d118abc86052f5e32f6195a4efd04fe315be5a Reviewed-on: http://review.coreboot.org/8149 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2015-01-03ipq8064: add SOC initialization skeletonVadim Bendebury
The main benefit of adding this skeleton is the addition of the correct memory map to CBMEM. Attempts to load depthcharge do not fail because of unavailability of the bounce buffer. BUG=chrome-os-partner:27784 TEST=boot updated firmware on AP148, observe CPU: Qualcomm 8064 in the ramstage console output as well as not failing to load depthcharge any more. Original-Change-Id: I56c1fa34ce3967852be6eaa0de6e823e64c3ede8 Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/199675 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit a8fdbdd268a2bba1405d585881eb95510ad17a2a) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I7b982f222ac3b93371fe77961f18719c5d269013 Reviewed-on: http://review.coreboot.org/8000 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins)