- Mar 21, 2018
-
-
Eugeniy Paltsev authored
Implement specialized function to clenup caches (and therefore sync instruction and data caches) which can be used for cleanup before linux launch or to sync caches during U-Boot self-relocation. Signed-off-by:
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com>
-
Eugeniy Paltsev authored
If L1 D$ is disabled SLC is bypassed for data and all load/store requests are sent directly to main memory. If L1 I$ is disabled SLC is NOT bypassed for instructions and all instruction requests are fetched through SLC. Signed-off-by:
-
Eugeniy Paltsev authored
Implement icache_enabled() and dcache_enabled() as separate functions which can be used with "inline" attribute. This is a preparation to make them always_inline. Signed-off-by:
-
Eugeniy Paltsev authored
Use CONFIG_ARC_DBG_IOC_ENABLE Kconfig option instead of ioc_enable global variable. Signed-off-by:
-
Eugeniy Paltsev authored
Move check for PAE existence into slc_upper_region_init() instead of its caller as more appropriate place. Signed-off-by:
-
Eugeniy Paltsev authored
There is a problem with current implementation if we start U-Boot from ROM, as we use global variables before ther initialization, so these variables get overwritten when we copy .data section from ROM. Instead we move these global variables into our "global data" structure so that we may really start from ROM. Signed-off-by:
-
Eugeniy Paltsev authored
There is a problem with current implementation if we start U-Boot from ROM, as we use global variables before ther initialization, so these variables get overwritten when we copy .data section from ROM. Instead we'll use icache_exists(), dcache_exists(), slc_exists(), pae_exists() functions which directly check BCRs every time. In U-Boot case ops are used only during self-relocation and DMA so we shouldn't be hit by noticeable performance degradation. Signed-off-by:
-
Eugeniy Paltsev authored
As of today we check SLC status before each call of __slc_rgn_op() or __slc_entire_op(). So move status check into __slc_rgn_op() and __slc_entire_op(). As we need to check status before *each* function execution and we call slc_entire_op() and slc_rgn_op() from different places we add this check directly into SLC entire/line functions instead of their callers to avoid code duplication. Signed-off-by:
-
Eugeniy Paltsev authored
Use is_isa_arcv2() function where it is possible instead of CONFIG_ISA_ARCV2 define check to make code cleaner at the same time keeping pretty much the same functionality - code in branches under "if (is_isa_arcv2())" won't be compiled if CONFIG_ISA_ARCV2 is not defined, still we need a couple of CONFIG_ISA_ARCV2 ifdefs to make compiler happy. That's because code in !is_isa_x() branch gets compiled and only then gets optimized away. Signed-off-by:
-
Eugeniy Paltsev authored
As we are planning to get rid of dozens of ifdef's in cache.c we would better check D$ status before each entire/line operation then check CONFIG_SYS_DCACHE_OFF config option. This makes the code cleaner as well as D$ entire/line functions remain functional even if we enable or disable D$ in run-time. As we need to check status before *each* function execution and we call D$ entire/line functions from different places we add this check directly into D$ entire/line functions instead of their callers to avoid code duplication. Signed-off-by:
-
Eugeniy Paltsev authored
We're starting to use more and more BCRs and having their definitions in-lined in sources becomes a bit annoying so we move it all to a separate header. Signed-off-by:
-
Eugeniy Paltsev authored
Move IOC initialization from cache_init() to a separate function. This is the preparation for the next patch where we'll switch to is_isa_arcv2() function usage instead of "CONFIG_ISA_ARCV2" ifdef. Also it makes cache_init function a bit cleaner. Signed-off-by:
-
Eugeniy Paltsev authored
We don't implement separate flush_dcache_all() intentionally as entire data cache invalidation is dangerous operation even if we flush data cache right before invalidation. There is the real example: We may get stuck in the following code if we store any context (like BLINK register) on stack in invalidate_dcache_all() function. BLINK register is the register where return address is automatically saved when we do function call with instructions like 'bl'. void flush_dcache_all() { __dc_entire_op(OP_FLUSH); // Other code // } void invalidate_dcache_all() { __dc_entire_op(OP_INV); // Other code // } void foo(void) { flush_dcache_all(); invalidate_dcache_all(); } Now let's see what really happens during that code execution: foo() |->> call flush_dcache_all [return address is saved to BLINK register] [push BLINK] (save to stack) ![point 1] |->> call __dc_entire_op(OP_FLUSH) [return address is saved to BLINK register] [flush L1 D$] return [jump to BLINK] <<------ [other flush_dcache_all code] [pop BLINK] (get from stack) return [jump to BLINK] <<------ |->> call invalidate_dcache_all [return address is saved to BLINK register] [push BLINK] (save to stack) ![point 2] |->> call __dc_entire_op(OP_FLUSH) [return address is saved to BLINK register] [invalidate L1 D$] ![point 3] // Oops!!! // We lose return address from invalidate_dcache_all function: // we save it to stack and invalidate L1 D$ after that! return [jump to BLINK] <<------ [other invalidate_dcache_all code] [pop BLINK] (get from stack) // we don't have this data in L1 dcache as we invalidated it in [point 3] // so we get it from next memory level (for example DDR memory) // but in the memory we have value which we save in [point 1], which // is return address from flush_dcache_all function (instead of // address from current invalidate_dcache_all function which we // saved in [point 2] !) return [jump to BLINK] <<------ // As BLINK points to invalidate_dcache_all, we call it again and // loop forever. Fortunately we may do flush and invalidation of D$ with a single one instruction which automatically mitigates a situation described above. And because invalidate_dcache_all() isn't used in common U-Boot code we implement "flush and invalidate dcache all" instead. Signed-off-by: -
Eugeniy Paltsev authored
Introduce is_isa_arcv2() and is_isa_arcompact() functions. These functions only check configuration options and return compile-time constant so they can be used instead of #ifdef's to to write cleaner code. Now we can write: -------------->8--------------- if (is_isa_arcv2()) ioc_configure(); -------------->8--------------- instead of: -------------->8--------------- ifdef CONFIG_ISA_ARCV2 ioc_configure(); endif -------------->8--------------- Signed-off-by:
-
Eugeniy Paltsev authored
As of today __dc_line_op() and __dc_entire_op() support only separate flush (OP_FLUSH) and invalidate (OP_INV) operations. Add support of combined flush and invalidate (OP_FLUSH_N_INV) operation which we planing to use in subsequent patches. Signed-off-by:
-
Eugeniy Paltsev authored
__cache_line_loop() function was copied from Linux kernel where per-line instruction cache operations are really used. In U-Boot we use only entire I$ ops, so we can drop support of per-line I$ ops from __cache_line_loop() because __cache_line_loop() is never called with OP_INV_IC parameter. Signed-off-by:
-
Eugeniy Paltsev authored
Move instruction cache entire operation to a separate function because we are planing to use it in other places like sync_icache_dcache_all(). Signed-off-by:
-
Alexey Brodkin authored
We improve on 2 things: 1. Only ARC HS family has "dmb" instructions so do compile-time check for automatically defined macro __ARCHS__. Previous check for ARCv2 ISA was not good enough because ARC EM family is v2 ISA as well but still "dmb" instaruction is not supported in EM family. 2. Still if there's no dedicated instruction for memory barrier let's at least insert compile-time barrier to make sure compiler deosn't reorder critical memory operations. Signed-off-by: -
Alexey Brodkin authored
Disabling relocation might be useful on ARC for 2 reasons: a) For advanced debugging with Synopsys proprietary MetaWare debugger which is capable of accessing much more specific hardware resources compared to gdb. For example it may show contents of L1 and L2 caches, internal states of some hardware blocks etc. But on the downside MetaWare debugger still cannot work with PIE. Even though that limitation could be work-arounded with change of ELF's header and stripping down all debug info but with it we won't have debug info for source-level debugging which is quite inconvenient. b) Some platforms which might benefit from usage of U-Boot basically don't have enough RAM to accommodate relocation of U-Boot so we keep code in flash and use as much of RAM as possible for more interesting things. Signed-off-by: -
Alexey Brodkin authored
Finally GCC's garbage collector works on ARC so let's use it. That's what I may see for HSDK: Before: text data bss dec hex filename 290153 10068 222616 522837 7fa55 u-boot After: text data bss dec hex filename 261999 9460 222360 493819 788fb u-boot Overall ~5% of memory footprint saved. Signed-off-by: -
Alexey Brodkin authored
This commit basically reverts two commits: 1. cf628f77 ("arc: arcv1: Disable master/slave check") 2. 6cba327b ("arcv2: Halt non-master cores") With mentioned commits in-place we experience more trouble than benefits. In case of SMP Linux kernel this is really required as we have all the cores running from the very beginning and then we need to allow master core to do some preparatory work while slaves are not getting in the way. In case of U-Boot we: a) Don't really run more than 1 core in parallel b) We may use whatever core for that Signed-off-by:
-
Alexey Brodkin authored
U-Boot is a bit special piese of software because it is being only executed once on power-on as compared to operating system for example. That's why we don't care much about performance optimizations instead we're more concerned about size. And up-to-date compilers might produce much smaller code compared to performance-optimized routines copy-pasted from the Linux kernel. Here's an example: ------------------------------->8-------------------------- --- size_asm_strings.txt +++ size_c_strings.txt @@ -1,2 +1,2 @@ text data bss dec hex filename - 121260 3784 3308 128352 1f560 u-boot + 120448 3784 3308 127540 1f234 u-boot ------------------------------->8-------------------------- See we were able to shave off ~800 bytes of .text section. Also usage of string routines implemented in C gives us an ability to support more HW flavors for free: generated instructions will match our target as long as correct compiler option is used. Signed-off-by:
-
- Mar 20, 2018
-
-
-
Vinitha V Pillai authored
Fix NOR, SD and QSPI fallback option in case of secure boot failure. Signed-off-by:
Vinitha V Pillai <vinitha.pillai@nxp.com> Reviewed-by:
York Sun <york.sun@nxp.com>
-
Ashish Kumar authored
IFC-NOR and QSPI-NOR pins are multiplexed on SoC, so they cannot be accessed simultaneously. IFC-NOR can be accessed along with SD-BOOT. Ls1088aqds_sdcard_ifc_defconfig is default config for SD boot and IFC-NOR to be used as flash. This allows writing to IFC-NOR flash. QSPI and DSPI cannot be accessed in this defconfig. IFC-NOR image is generated using ls1088aqds_defconfig. Signed-off-by:
Ashish Kumar <Ashish.Kumar@nxp.com> Reviewed-by:
-
Ashish Kumar authored
This function is required for enabling access to early i2c function for correct usage of QIXIS_READ and QIXIS_WRITE. Signed-off-by:
-
Ashish Kumar authored
get_board_ddr_clk(), get_board_sys_clk() and if_board_diff_clk() is now available for SPL build. Signed-off-by:
-
Ashish Kumar authored
Signed-off-by:
-
git://git.denx.de/u-boot-usbTom Rini authored
-
- Mar 19, 2018
-
-
git://git.denx.de/u-boot-sunxiTom Rini authored
-
Bryan O'Donoghue authored
This patch makes it possible to verify the contents and location of an OPTEE image in DRAM prior to handing off control to that image. If image verification fails we won't try to boot any further. Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Suggested-by:
Andrew F. Davis <afd@ti.com> Cc: Harinarayan Bhatta <harinarayan@ti.com> Cc: Andrew F. Davis <afd@ti.com> Cc: Tom Rini <trini@konsulko.com> Cc: Kever Yang <kever.yang@rock-chips.com> Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Cc: Peng Fan <peng.fan@nxp.com>
-
Bryan O'Donoghue authored
This patch adds a new type IH_OS_TEE. This new OS type will be used for chain-loading to Linux via a TEE. With this patch in-place you can generate a bootable OPTEE image like this: mkimage -A arm -T kernel -O tee -C none -d tee.bin uTee.optee where "tee.bin" is the input binary prefixed with an OPTEE header and uTee.optee is the output prefixed with a u-boot wrapper header. This image type "-T kernel -O tee" is differentiated from the existing IH_TYPE_TEE "-T tee" in that the IH_TYPE is installed by u-boot (flow control returns to u-boot) whereas for the new IH_OS_TEE control passes to the OPTEE firmware and the firmware chainloads onto Linux. Andrew Davis gave the following ASCII diagram: IH_OS_TEE: (mkimage -T kernel -O tee) Non-Secure Secure BootROM | ------------- | v SPL | v U-Boot ------> <----- OP-TEE | V Linux IH_TYPE_TEE: (mkimage -T tee) Non-Secure Secure BootROM | ------------- | v SPL -------> <----- OP-TEE | v U-Boot | V Linux Signed-off-by: -
Bryan O'Donoghue authored
When encountering an error in OPTEE verification print out various details of the OPTEE header to aid in further debugging of encountered errors. Signed-off-by:
Peng Fan <peng.fan@nxp.com>
-
Bryan O'Donoghue authored
This patch adds optee_verify_bootm_image() which will be subsequently used to verify the parameters encoded in the OPTEE header match the memory allocated to the OPTEE region, OPTEE header magic and version prior to handing off control to the OPTEE image. Signed-off-by: -
Bryan O'Donoghue authored
This patch adds optee_image_get_load_addr() a helper function used to calculate the load-address of an OPTEE image based on the lower entry-point address given in the OPTEE header. Signed-off-by:
-
Bryan O'Donoghue authored
Add a helper function for extracting the least significant 32 bits from the OPTEE entry point address, which will be good enough to load OPTEE binaries up to (2^32)-1 bytes. We may need to extend this out later on but for now (2^32)-1 should be fine. Signed-off-by:
-
Bryan O'Donoghue authored
CONFIG_OPTEE_LOAD_ADDR is used to tell u-boot where to load the OPTEE binary into memory prior to handing off control to OPTEE. We need to pull this value out of u-boot in order to produce an IMX IVT/CSF signed pair for the purposes of secure boot. The best way to do that is to have CONFIG_OPTEE_LOAD_ADDR appear in u-boot.cfg. Adding new CONFIG entires to u-boot should be kconfig driven so this patch does just that. Signed-off-by:
Ryan Harkin <ryan.harkin@linaro.org>
-
Bryan O'Donoghue authored
OPTEE is currently linked to a specific area of memory called the TrustZone DRAM. This patch adds a CONFIG entry for the default address of TrustZone DRAM that a board-port can over-ride. The region that U-Boot sets aside for the OPTEE run-time should be verified before attempting to hand off to the OPTEE run-time. Each board-port should carefully ensure that the TZDRAM address specified in the OPTEE build and the TZDRAM address specified in U-Boot match-up. Further patches will use TZDRAM address with other defines and variables to carry out a degree of automated verification in U-Boot prior to trying to boot an OPTEE image. Signed-off-by: -
Bryan O'Donoghue authored
OPTEE is currently linked to a specific area of memory called the TrustZone DRAM. This patch adds a CONFIG entry for the default size of TrustZone DRAM that a board-port can over-ride. The region that U-Boot sets aside for the OPTEE run-time should be verified before attempting to hand off to the OPTEE run-time. Each board-port should carefully ensure that the TZDRAM size specified in the OPTEE build and the TZDRAM size specified in U-Boot match-up. Further patches will use TZDRAM size with other defines and variables to carry out a degree of automated verification in U-Boot prior to trying to boot an OPTEE image. Signed-off-by:
-
Bryan O'Donoghue authored
This patch adds code to lib to enable sharing of useful OPTEE code between board-ports and architectures. The code on lib/optee/optee.c comes from the TI omap2 port. Eventually the OMAP2 code will be patched to include the shared code. The intention here is to add more useful OPTEE specific code as more functionality gets added. Signed-off-by:
-
