Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-11-18 18:59:44 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/arch/arm/include/asm/global_data.h

113 lines
2.6 KiB
C
Raw Normal View History

SPDX: Convert all of our single license tags to Linux Kernel style When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-05-06 21:58:06 +00:00
/* SPDX-License-Identifier: GPL-2.0+ */
Initial revision
2002-10-21 17:04:47 +00:00
/*
Make getenv() work before relocation. So far, getenv() would work before relocation is most cases, even though it was not intended to be used that way. When switching to a hash table based implementation, this would break a number of boards. For convenience, we make getenv() check if it's running before relocation and, if so, use getenv_f() internally. Note that this is limited to simple cases, as we use a small static buffer (32 bytes) in the global data for this purpose. For this reason, it is also not a good idea to convert all current uses of getenv_f() into getenv() - some of the existing use cases need to be able to deal with longer variable values, so getenv_f() is still needed and recommended for use before relocation. Signed-off-by: Wolfgang Denk <wd@denx.de>
2010-07-24 18:22:02 +00:00
* (C) Copyright 2002-2010
Initial revision
2002-10-21 17:04:47 +00:00
* Wolfgang Denk, DENX Software Engineering, wd@denx.de.
*/
#ifndef __ASM_GBL_DATA_H
#define __ASM_GBL_DATA_H
Add architecture-specific global data We plan to move architecture-specific data into a separate structure so that we can make the rest of it common. As a first step, create struct arch_global_data to hold these fields. Initially it is empty. This patch applies to all archs at once. I can split it if this is really a pain. Signed-off-by: Simon Glass <sjg@chromium.org>
2012-12-13 20:48:30 +00:00
/* Architecture-specific global data */
struct arch_global_data {
ppc: arm: Move sdhc_clk into arch_global_data This is used by both powerpc and arm, but I think it still qualifies as architecture-specific. Signed-off-by: Simon Glass <sjg@chromium.org>
2012-12-13 20:49:05 +00:00
#if defined(CONFIG_FSL_ESDHC)
u32 sdhc_clk;
#endif
qe: add u-qe support to arm board ls1021 is arm-core and support qe which is u-qe. add u-qe init for arm board. Signed-off-by: Zhao Qiang <B45475@freescale.com> [York Sun: Fix compiling error caused by u_qe_init()] Reviewed-by: York Sun <yorksun@freescale.com>
2014-09-25 05:52:25 +00:00
#if defined(CONFIG_U_QE)
u32 qe_clk;
u32 brg_clk;
uint mp_alloc_base;
uint mp_alloc_top;
#endif /* CONFIG_U_QE */
at91: Move at91 global data into arch_global_data Move these fields into arch_global_data. Signed-off-by: Simon Glass <sjg@chromium.org>
2012-12-13 20:48:31 +00:00
#ifdef CONFIG_AT91FAMILY
/* "static data" needed by at91's clock.c */
unsigned long cpu_clk_rate_hz;
unsigned long main_clk_rate_hz;
unsigned long mck_rate_hz;
unsigned long plla_rate_hz;
unsigned long pllb_rate_hz;
unsigned long at91_pllb_usb_init;
#endif
arm: Move timer_rate_hz into arch_global_data Move this field into arch_global_data and tidy up. Signed-off-by: Simon Glass <sjg@chromium.org>
2012-12-13 20:48:32 +00:00
/* "static data" needed by most of timer.c on ARM platforms */
unsigned long timer_rate_hz;
arm: change tbu/l type to unsigned int Change tbu/l type to unsigned int. >From the timer file for arm, "(((unsigned long long)gd->arch.tbu) << 32) | gd->arch.tbl;" is used, This piece code is based on tbu/tbl is 32bits, so change the type to unsigned int. Signed-off-by: Peng Fan <peng.fan@nxp.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
2017-05-09 02:32:02 +00:00
unsigned int tbu;
unsigned int tbl;
arm: Move lastinc to arch_global_data Move this field into arch_global_data and tidy up. Signed-off-by: Simon Glass <sjg@chromium.org>
2012-12-13 20:48:35 +00:00
unsigned long lastinc;
arm: Move timer_reset_value to arch_global_data Move this field into arch_global_data and tidy up. Signed-off-by: Simon Glass <sjg@chromium.org>
2012-12-13 20:48:36 +00:00
unsigned long long timer_reset_value;
arm: Move tlb_addr and tlb_size to arch_global_data Move these fields into arch_global_data and tidy up. Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Address tlb_size in this patch as well] Signed-off-by: Tom Rini <trini@ti.com>
2012-12-13 20:48:39 +00:00
#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
unsigned long tlb_addr;
arm64: Make full va map code more dynamic The idea to generate our pages tables from an array of memory ranges is very sound. However, instead of hard coding the code to create up to 2 levels of 64k granule page tables, we really should just create normal 4k page tables that allow us to set caching attributes on 2M or 4k level later on. So this patch moves the full_va mapping code to 4k page size and makes it fully flexible to dynamically create as many levels as necessary for a map (including dynamic 1G/2M pages). It also adds support to dynamically split a large map into smaller ones when some code wants to set dcache attributes. With all this in place, there is very little reason to create your own page tables in board specific files. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-03-04 00:09:47 +00:00
unsigned long tlb_size;
arm64: Remove non-full-va map code By now the code to only have a single page table level with 64k page size and 42 bit address space is no longer used by any board in tree, so we can safely remove it. To clean up code, move the layerscape mmu code to the new defines, removing redundant field definitions. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-03-04 00:09:54 +00:00
#if defined(CONFIG_ARM64)
arm64: Make full va map code more dynamic The idea to generate our pages tables from an array of memory ranges is very sound. However, instead of hard coding the code to create up to 2 levels of 64k granule page tables, we really should just create normal 4k page tables that allow us to set caching attributes on 2M or 4k level later on. So this patch moves the full_va mapping code to 4k page size and makes it fully flexible to dynamically create as many levels as necessary for a map (including dynamic 1G/2M pages). It also adds support to dynamically split a large map into smaller ones when some code wants to set dcache attributes. With all this in place, there is very little reason to create your own page tables in board specific files. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-03-04 00:09:47 +00:00
unsigned long tlb_fillptr;
unsigned long tlb_emerg;
armv8: New MMU setup code allowing to use 48+ bits PA/VA This patch adds code which sets up 2-level page tables on ARM64 thus extending available VA space. CPUs implementing 64k translation granule are able to use direct PA-VA mapping of the whole 48 bit address space. It also adds the ability to reset the SCTRL register at the very beginning of execution to avoid interference from stale mappings set up by early firmware/loaders/etc. Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
2015-10-14 16:55:45 +00:00
#endif
arm: Move tlb_addr and tlb_size to arch_global_data Move these fields into arch_global_data and tidy up. Signed-off-by: Simon Glass <sjg@chromium.org> [trini: Address tlb_size in this patch as well] Signed-off-by: Tom Rini <trini@ti.com>
2012-12-13 20:48:39 +00:00
#endif
armv8: Move secure_ram variable out of generic global data Secure_ram variable was put in generic global data. But only ARMv8 uses this variable. Move it to ARM specific data structure. Signed-off-by: York Sun <york.sun@nxp.com>
2016-06-24 23:46:18 +00:00
#ifdef CONFIG_SYS_MEM_RESERVE_SECURE
#define MEM_RESERVE_SECURE_SECURED 0x1
#define MEM_RESERVE_SECURE_MAINTAINED 0x2
#define MEM_RESERVE_SECURE_ADDR_MASK (~0x3)
/*
* Secure memory addr
* This variable needs maintenance if the RAM base is not zero,
* or if RAM splits into non-consecutive banks. It also has a
* flag indicating the secure memory is marked as secure by MMU.
* Flags used: 0x1 secured
* 0x2 maintained
*/
phys_addr_t secure_ram;
armv8: Add tlb_allocated to arch global data When secure ram is used, MMU tables have to be put into secure ram. To use common MMU code, gd->arch.tlb_addr will be used to host TLB entry pointer. To save allocated memory for later use, tlb_allocated variable is added to global data structure. Signed-off-by: York Sun <york.sun@nxp.com>
2016-06-24 23:46:19 +00:00
unsigned long tlb_allocated;
armv8: Move secure_ram variable out of generic global data Secure_ram variable was put in generic global data. But only ARMv8 uses this variable. Move it to ARM specific data structure. Signed-off-by: York Sun <york.sun@nxp.com>
2016-06-24 23:46:18 +00:00
#endif
armv8: Add global variable resv_ram Use gd->arch.resv_ram to track reserved memory allocation. Signed-off-by: York Sun <york.sun@nxp.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2017-03-06 17:02:24 +00:00
#ifdef CONFIG_RESV_RAM
/*
* Reserved RAM for memory resident, eg. Management Complex (MC)
* driver which continues to run after U-Boot exits.
*/
phys_addr_t resv_ram;
#endif
ARM: OMAP: Correct save_boot_params and replace with 'C' function Currently save_boot_params saves the boot parameters passed from romcode. But this is not stored in a writable location consistently. So the current code would not work for a 'XIP' boot. Change this by saving the boot parameters in 'gd' which is always writable. Also add a 'C' function instead of an assembly code that is more readable. Signed-off-by: Sricharan R <r.sricharan@ti.com>
2013-04-24 00:41:23 +00:00
ARM: omap2+: rename config to ARCH_OMAP2PLUS and consolidate Kconfig In Linux, CONFIG_ARCH_OMAP2PLUS is used for OMAP2 or later SoCs. Rename CONFIG_ARCH_OMAP2 to CONFIG_ARCH_OMAP2PLUS to follow this naming. Move the OMAP2+ board/SoC choice down to mach-omap2/Kconfig to slim down the arch/arm/Kconfig level. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Tom Rini <trini@konsulko.com>
2017-04-25 04:10:11 +00:00
#ifdef CONFIG_ARCH_OMAP2PLUS
omap-common: Common boot code OMAP3 support and cleanup This introduces OMAP3 support for the common omap boot code, as well as a major cleanup of the common omap boot code. First, the omap_boot_parameters structure becomes platform-specific, since its definition differs a bit across omap platforms. The offsets are removed as well since it is U-Boot's coding style to use structures for mapping such kind of data (in the sense that it is similar to registers). It is correct to assume that romcode structure encoding is the same as U-Boot, given the description of these structures in the TRMs. The original address provided by the bootrom is passed to the U-Boot binary instead of a duplicate of the structure stored in global data. This allows to have only the relevant (boot device and mode) information stored in global data. It is also expected that the address where the bootrom stores that information is not overridden by the U-Boot SPL or U-Boot. The save_omap_boot_params is expected to handle all special cases where the data provided by the bootrom cannot be used as-is, so that spl_boot_device and spl_boot_mode only return the data from global data. All of this is only relevant when the U-Boot SPL is used. In cases it is not, save_boot_params should fallback to its weak (or board-specific) definition. save_omap_boot_params should not be called in that context either. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
2015-07-15 14:02:19 +00:00
u32 omap_boot_device;
u32 omap_boot_mode;
u8 omap_ch_flags;
ARM: OMAP: Correct save_boot_params and replace with 'C' function Currently save_boot_params saves the boot parameters passed from romcode. But this is not stored in a writable location consistently. So the current code would not work for a 'XIP' boot. Change this by saving the boot parameters in 'gd' which is always writable. Also add a 'C' function instead of an assembly code that is more readable. Signed-off-by: Sricharan R <r.sricharan@ti.com>
2013-04-24 00:41:23 +00:00
#endif
armv8: LS2080A: Rename LS2085A to reflect LS2080A LS2080A is a prime personality of Freescale’s LS2085A. It is a non-AIOP personality without support of DP-DDR, L2 switch, 1588, PCIe endpoint etc. So renaming existing LS2085A code base to reflect LS2080A (Prime personality) Signed-off-by: Pratiyush Mohan Srivastava <pratiyush.srivastava@freescale.com> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> [York Sun: Dropped #ifdef in cpu.c for cpu_type_list] Reviewed-by: York Sun <yorksun@freescale.com>
2015-11-09 11:12:07 +00:00
#if defined(CONFIG_FSL_LSCH3) && defined(CONFIG_SYS_FSL_HAS_DP_DDR)
armv8/fsl-lsch3: Add support for second DDR clock FSL-LSCH3 platforms can have multiple DDR clocks. LS2085A has one clock for general DDR controlers, and another clock for DP-DDR. DDR driver needs to change to support multiple clocks. Signed-off-by: York Sun <yorksun@freescale.com>
2015-01-06 21:18:49 +00:00
unsigned long mem2_clk;
#endif
Add architecture-specific global data We plan to move architecture-specific data into a separate structure so that we can make the rest of it common. As a first step, create struct arch_global_data to hold these fields. Initially it is empty. This patch applies to all archs at once. I can split it if this is really a pain. Signed-off-by: Simon Glass <sjg@chromium.org>
2012-12-13 20:48:30 +00:00
};
arm: Use generic global_data Signed-off-by: Simon Glass <sjg@chromium.org>
2012-12-13 20:49:14 +00:00
#include <asm-generic/global_data.h>
Initial revision
2002-10-21 17:04:47 +00:00
ARM: make gd a function for clang "clang does not support global register variables; this is unlikely to be implemented soon because it requires additional LLVM backend support" [1] Workaround it by obtaining the value of gd/r9 by an inline asm routine. Note there is no set routine added for ARM at the moment, since most if not all updates of gd from c are actually not needed for ARM. [1] http://clang.llvm.org/docs/UsersManual.html cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
2014-07-30 19:54:52 +00:00
#ifdef __clang__
#define DECLARE_GLOBAL_DATA_PTR
#define gd get_gd()
static inline gd_t *get_gd(void)
{
gd_t *gd_ptr;
#ifdef CONFIG_ARM64
/*
* Make will already error that reserving x18 is not supported at the
* time of writing, clang: error: unknown argument: '-ffixed-x18'
*/
__asm__ volatile("mov %0, x18\n" : "=r" (gd_ptr));
#else
__asm__ volatile("mov %0, r9\n" : "=r" (gd_ptr));
#endif
return gd_ptr;
}
#else
arm64: core support Relocation code based on a patch by Scott Wood, which is: Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: David Feng <fenghua@phytium.com.cn>
2013-12-14 03:47:35 +00:00
#ifdef CONFIG_ARM64
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("x18")
#else
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r9")
#endif
ARM: make gd a function for clang "clang does not support global register variables; this is unlikely to be implemented soon because it requires additional LLVM backend support" [1] Workaround it by obtaining the value of gd/r9 by an inline asm routine. Note there is no set routine added for ARM at the moment, since most if not all updates of gd from c are actually not needed for ARM. [1] http://clang.llvm.org/docs/UsersManual.html cc: Albert ARIBAUD <albert.u.boot@aribaud.net> Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
2014-07-30 19:54:52 +00:00
#endif
Initial revision
2002-10-21 17:04:47 +00:00
#endif /* __ASM_GBL_DATA_H */
Reference in a new issue Copy permalink