summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/omap-secure.c
Commit message (Collapse)AuthorAgeFilesLines
* ARM: omap2: hide omap3_save_secure_ram on non-OMAP3 buildsArnd Bergmann2017-12-071-0/+2
| | | | | | | | | | | | | | | | | In configurations without CONFIG_OMAP3 but with secure RAM support, we now run into a link failure: arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram': omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context' The omap3_save_secure_ram() function is only called from the OMAP34xx power management code, so we can simply hide that function in the appropriate #ifdef. Fixes: d09220a887f7 ("ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context") Acked-by: Tony Lindgren <tony@atomide.com> Tested-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_contextTony Lindgren2017-11-281-0/+19
| | | | | | | | | | | | | | | | | | | | | | | With the CMA changes from Joonsoo Kim <iamjoonsoo.kim@lge.com>, it was noticed that n900 stopped booting. After investigating it turned out that n900 save_secure_ram_context does some whacky virtual to physical address translation for the SRAM data address. As we now only have minimal parts of omap3 idle code copied to SRAM, running save_secure_ram_context() in SRAM is not needed. It only gets called on PM init. And it seems there's no need to ever call this from SRAM idle code. So let's just keep save_secure_ram_context() in DDR, and pass it the physical address of the parameters. We can do everything else in omap-secure.c like we already do for other secure code. And since we don't have any documentation, I still have no clue what the values for 0, 1 and 1 for the parameters might be. If somebody has figured it out, please do send a patch to add some comments. Debugged-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* RX-51: Add support for OMAP3 ROM Random Number GeneratorPali Rohár2013-10-081-0/+11
| | | | | | | | | | Adding this driver as platform device and only for RX-51 until somebody test if it working also on other OMAP3 HS devices and until there will be generic ARM way to deal with SMC calls. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> [tony@atomide.com: folded in the clock alias change] Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP3: RX-51: ARM errata 430973 workaroundPali Rohár2013-10-081-0/+65
| | | | | | | | | | | | | | | | | | | | | | | | | Closed and signed Nokia X-Loader bootloader stored in RX-51 nand does not set IBE bit in ACTLR and starting kernel in non-secure mode. So direct write to ACTLR by our kernel does not working and the code for ARM errata 430973 in commit 7ce236fcd6fd45b0441a2d49acb2ceb2de2e8a47 that sets IBE bit is a noop. In order to have workaround for ARM errata 430973 from non-secure world on RX-51 we needs Secure Monitor Call to set IBE BIT in ACTLR. This patch adds RX-51 specific secure support code and sets IBE bit in ACTLR during board init code for ARM errata 430973 workaround. Note that new function rx51_secure_dispatcher() differs from existing omap_secure_dispatcher(). It calling omap_smc3() and param[0] is nargs+1. ARM errata 430973 workaround is needed for thumb-2 ISA compiled userspace binaries. Without this workaround thumb-2 binaries crashing. So with this patch it is possible to recompile and run applications/binaries with thumb-2 ISA on RX-51. Signed-off-by: Ivaylo Dimitrov <freemangordon@abv.bg> Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP: Move plat/omap-secure.h locally to mach-omap2Lokesh Vutla2012-10-181-1/+0
| | | | | | | | Moving plat/omap-secure.h locally to mach-omap2/ as part of single zImage work Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: Round of the carve out memory requested to section_sizeR Sricharan2012-10-081-2/+2
| | | | | | | | | | | | | | | | | | | | | memblock_steal tries to reserve physical memory during boot. When the requested size is not aligned on the section size then, the remaining memory available for lowmem becomes unaligned on the section boundary. There is a issue with this, which is discussed in the thread below. https://lkml.org/lkml/2012/6/28/112 The final conclusion from the thread seems to be align the memblock_steal calls on the SECTION boundary. The issue comes out when LPAE is enabled, where the section size is 2MB. Boot tested this on OMAP5 evm with and without LPAE. Signed-off-by: R Sricharan <r.sricharan@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: Make omap-secure.h localTony Lindgren2012-09-201-1/+1
| | | | | | This can be local to mach-omap2. Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP: add includes for missing prototypesPaul Walmsley2012-04-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several C files in arch/arm/mach-omap* and arch/arm/plat-omap declare functions that are used by other files, but don't include the header file where the prototype is declared. This results in the following warnings from sparse: arch/arm/mach-omap2/irq.c:114:5: warning: symbol 'omap_irq_pending' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:186:13: warning: symbol 'omap2_init_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:191:13: warning: symbol 'omap3_init_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:196:13: warning: symbol 'ti81xx_init_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:233:39: warning: symbol 'omap2_intc_handle_irq' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:242:6: warning: symbol 'omap_intc_save_context' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'omap_intc_restore_context' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:291:6: warning: symbol 'omap3_intc_suspend' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:297:6: warning: symbol 'omap3_intc_prepare_idle' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:306:6: warning: symbol 'omap3_intc_resume_idle' was not declared. Should it be static? arch/arm/mach-omap2/irq.c:312:39: warning: symbol 'omap3_intc_handle_irq' was not declared. Should it be static? arch/arm/mach-omap2/omap-secure.c:59:12: warning: symbol 'omap_secure_ram_reserve_memblock' was not declared. Should it be static? arch/arm/mach-omap2/board-zoom-display.c:133:13: warning: symbol 'zoom_display_init' was not declared. Should it be static? arch/arm/plat-omap/common.c:73:13: warning: symbol 'omap_init_consistent_dma_size' was not declared. Should it be static? arch/arm/mach-omap1/irq.c:61:5: warning: symbol 'omap_irq_flags' was not declared. Should it be static? arch/arm/mach-omap1/irq.c:179:13: warning: symbol 'omap1_init_irq' was not declared. Should it be static? arch/arm/mach-omap1/reset.c:11:6: warning: symbol 'omap1_restart' was not declared. Should it be static? Fix by including the appropriate header files. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Senthilvadivu Guruswamy <svadivu@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* ARM: Add arm_memblock_steal() to allocate memory away from the kernelRussell King2012-01-131-11/+2
| | | | | | | | | | | | | | | | | | | | | | Several platforms are now using the memblock_alloc+memblock_free+ memblock_remove trick to obtain memory which won't be mapped in the kernel's page tables. Most platforms do this (correctly) in the ->reserve callback. However, OMAP has started to call these functions outside of this callback, and this is extremely unsafe - memory will not be unmapped, and could well be given out after memblock is no longer responsible for its management. So, provide arm_memblock_steal() to perform this function, and ensure that it panic()s if it is used inappropriately. Convert everyone over, including OMAP. As a result, OMAP with OMAP4_ERRATA_I688 enabled will panic on boot with this change. Mark this option as BROKEN and make it depend on BROKEN. OMAP needs to be fixed, or 137d105d50 (ARM: OMAP4: Fix errata i688 with MPU interconnect barriers.) reverted until such time it can be fixed correctly. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: OMAP: PM: Add support to allocate the memory for secure RAMSantosh Shilimkar2011-12-081-0/+29
| | | | | | | | | | | | | | | | | | | Allocate the memory to save secure ram context which needs to be done when MPU is hitting OFF mode. The ROM code expects a physical address to this memory and hence use memblock APIs to reserve this memory as part of .reserve() callback. Maximum size as per secure RAM requirements is allocated. To keep omap1 build working, omap-secure.h file is created under plat-omap directory. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* ARM: OMAP: Add Secure HAL and monitor mode API infrastructure.Santosh Shilimkar2011-12-081-0/+52
On OMAP secure/emulation devices, certain APIs are exported by secure code. Add an infrastructure so that relevant operations on secure devices can be implemented using it. While at this, rename omap44xx-smc.S to omap-smc.S since the common APIs can be used on other OMAP's too. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
OpenPOWER on IntegriCloud