2018-05-06 21:58:06 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ */
|
2013-12-14 03:47:37 +00:00
|
|
|
/*
|
|
|
|
* Configuration for Versatile Express. Parts were derived from other ARM
|
|
|
|
* configurations.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __VEXPRESS_AEMV8A_H
|
|
|
|
#define __VEXPRESS_AEMV8A_H
|
|
|
|
|
|
|
|
#define CONFIG_REMAKE_ELF
|
|
|
|
|
|
|
|
/* Link Definitions */
|
2019-08-27 10:56:49 +00:00
|
|
|
#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
|
2014-06-09 18:12:59 +00:00
|
|
|
/* ATF loads u-boot here for BASE_FVP model */
|
|
|
|
#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x03f00000)
|
2015-01-23 13:41:10 +00:00
|
|
|
#elif CONFIG_TARGET_VEXPRESS64_JUNO
|
|
|
|
#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x7fff0)
|
2014-06-09 18:12:59 +00:00
|
|
|
#endif
|
2013-12-14 03:47:37 +00:00
|
|
|
|
2015-10-09 16:18:01 +00:00
|
|
|
#define CONFIG_SYS_BOOTM_LEN (64 << 20) /* Increase max gunzip size */
|
|
|
|
|
2013-12-14 03:47:37 +00:00
|
|
|
/* CS register bases for the original memory map. */
|
|
|
|
#define V2M_PA_CS0 0x00000000
|
|
|
|
#define V2M_PA_CS1 0x14000000
|
|
|
|
#define V2M_PA_CS2 0x18000000
|
|
|
|
#define V2M_PA_CS3 0x1c000000
|
|
|
|
#define V2M_PA_CS4 0x0c000000
|
|
|
|
#define V2M_PA_CS5 0x10000000
|
|
|
|
|
|
|
|
#define V2M_PERIPH_OFFSET(x) (x << 16)
|
|
|
|
#define V2M_SYSREGS (V2M_PA_CS3 + V2M_PERIPH_OFFSET(1))
|
|
|
|
#define V2M_SYSCTL (V2M_PA_CS3 + V2M_PERIPH_OFFSET(2))
|
|
|
|
#define V2M_SERIAL_BUS_PCI (V2M_PA_CS3 + V2M_PERIPH_OFFSET(3))
|
|
|
|
|
|
|
|
#define V2M_BASE 0x80000000
|
|
|
|
|
|
|
|
/* Common peripherals relative to CS7. */
|
|
|
|
#define V2M_AACI (V2M_PA_CS3 + V2M_PERIPH_OFFSET(4))
|
|
|
|
#define V2M_MMCI (V2M_PA_CS3 + V2M_PERIPH_OFFSET(5))
|
|
|
|
#define V2M_KMI0 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(6))
|
|
|
|
#define V2M_KMI1 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(7))
|
|
|
|
|
2015-01-23 13:41:10 +00:00
|
|
|
#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
|
|
|
|
#define V2M_UART0 0x7ff80000
|
|
|
|
#define V2M_UART1 0x7ff70000
|
|
|
|
#else /* Not Juno */
|
2013-12-14 03:47:37 +00:00
|
|
|
#define V2M_UART0 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(9))
|
|
|
|
#define V2M_UART1 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(10))
|
|
|
|
#define V2M_UART2 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(11))
|
|
|
|
#define V2M_UART3 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(12))
|
2015-01-23 13:41:10 +00:00
|
|
|
#endif
|
2013-12-14 03:47:37 +00:00
|
|
|
|
|
|
|
#define V2M_WDT (V2M_PA_CS3 + V2M_PERIPH_OFFSET(15))
|
|
|
|
|
|
|
|
#define V2M_TIMER01 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(17))
|
|
|
|
#define V2M_TIMER23 (V2M_PA_CS3 + V2M_PERIPH_OFFSET(18))
|
|
|
|
|
|
|
|
#define V2M_SERIAL_BUS_DVI (V2M_PA_CS3 + V2M_PERIPH_OFFSET(22))
|
|
|
|
#define V2M_RTC (V2M_PA_CS3 + V2M_PERIPH_OFFSET(23))
|
|
|
|
|
|
|
|
#define V2M_CF (V2M_PA_CS3 + V2M_PERIPH_OFFSET(26))
|
|
|
|
|
|
|
|
#define V2M_CLCD (V2M_PA_CS3 + V2M_PERIPH_OFFSET(31))
|
|
|
|
|
|
|
|
/* System register offsets. */
|
|
|
|
#define V2M_SYS_CFGDATA (V2M_SYSREGS + 0x0a0)
|
|
|
|
#define V2M_SYS_CFGCTRL (V2M_SYSREGS + 0x0a4)
|
|
|
|
#define V2M_SYS_CFGSTAT (V2M_SYSREGS + 0x0a8)
|
|
|
|
|
|
|
|
/* Generic Timer Definitions */
|
2020-06-11 11:03:15 +00:00
|
|
|
#define COUNTER_FREQUENCY 24000000 /* 24MHz */
|
2013-12-14 03:47:37 +00:00
|
|
|
|
|
|
|
/* Generic Interrupt Controller Definitions */
|
2014-03-14 06:26:27 +00:00
|
|
|
#ifdef CONFIG_GICV3
|
|
|
|
#define GICD_BASE (0x2f000000)
|
|
|
|
#define GICR_BASE (0x2f100000)
|
|
|
|
#else
|
2014-06-09 18:12:59 +00:00
|
|
|
|
2019-08-27 10:56:49 +00:00
|
|
|
#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
|
2014-06-09 18:12:59 +00:00
|
|
|
#define GICD_BASE (0x2f000000)
|
|
|
|
#define GICC_BASE (0x2c000000)
|
2015-01-23 13:41:10 +00:00
|
|
|
#elif CONFIG_TARGET_VEXPRESS64_JUNO
|
|
|
|
#define GICD_BASE (0x2C010000)
|
|
|
|
#define GICC_BASE (0x2C02f000)
|
2014-06-09 18:12:59 +00:00
|
|
|
#endif
|
2015-03-23 10:06:14 +00:00
|
|
|
#endif /* !CONFIG_GICV3 */
|
2013-12-14 03:47:37 +00:00
|
|
|
|
|
|
|
/* Size of malloc() pool */
|
2014-08-14 10:42:37 +00:00
|
|
|
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (8 << 20))
|
2013-12-14 03:47:37 +00:00
|
|
|
|
2017-09-05 20:20:44 +00:00
|
|
|
#ifndef CONFIG_TARGET_VEXPRESS64_JUNO
|
2015-02-17 10:35:25 +00:00
|
|
|
/* The Vexpress64 simulators use SMSC91C111 */
|
2014-01-16 15:47:40 +00:00
|
|
|
#define CONFIG_SMC91111 1
|
|
|
|
#define CONFIG_SMC91111_BASE (0x01A000000)
|
2015-02-17 10:35:25 +00:00
|
|
|
#endif
|
2013-12-14 03:47:37 +00:00
|
|
|
|
|
|
|
/* PL011 Serial Configuration */
|
2015-01-23 13:41:10 +00:00
|
|
|
#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
|
2020-04-27 18:18:00 +00:00
|
|
|
#define CONFIG_PL011_CLOCK 7372800
|
2015-01-23 13:41:10 +00:00
|
|
|
#else
|
2013-12-14 03:47:37 +00:00
|
|
|
#define CONFIG_PL011_CLOCK 24000000
|
2015-01-23 13:41:10 +00:00
|
|
|
#endif
|
2013-12-14 03:47:37 +00:00
|
|
|
|
|
|
|
/* BOOTP options */
|
|
|
|
#define CONFIG_BOOTP_BOOTFILESIZE
|
|
|
|
|
|
|
|
/* Miscellaneous configurable options */
|
|
|
|
#define CONFIG_SYS_LOAD_ADDR (V2M_BASE + 0x10000000)
|
|
|
|
|
|
|
|
/* Physical Memory Map */
|
|
|
|
#define PHYS_SDRAM_1 (V2M_BASE) /* SDRAM Bank #1 */
|
2015-05-11 08:03:57 +00:00
|
|
|
/* Top 16MB reserved for secure world use */
|
|
|
|
#define DRAM_SEC_SIZE 0x01000000
|
|
|
|
#define PHYS_SDRAM_1_SIZE 0x80000000 - DRAM_SEC_SIZE
|
|
|
|
#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
|
|
|
|
|
2015-11-18 10:39:07 +00:00
|
|
|
#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
|
|
|
|
#define PHYS_SDRAM_2 (0x880000000)
|
|
|
|
#define PHYS_SDRAM_2_SIZE 0x180000000
|
|
|
|
#endif
|
|
|
|
|
2015-05-11 08:03:57 +00:00
|
|
|
/* Enable memtest */
|
2013-12-14 03:47:37 +00:00
|
|
|
|
|
|
|
/* Initial environment variables */
|
2015-04-04 23:48:32 +00:00
|
|
|
#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
|
|
|
|
/*
|
|
|
|
* Defines where the kernel and FDT exist in NOR flash and where it will
|
|
|
|
* be copied into DRAM
|
|
|
|
*/
|
|
|
|
#define CONFIG_EXTRA_ENV_SETTINGS \
|
2015-10-09 16:18:07 +00:00
|
|
|
"kernel_name=norkern\0" \
|
|
|
|
"kernel_alt_name=Image\0" \
|
arm: juno: Fix Juno address variables
The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-04-27 18:17:58 +00:00
|
|
|
"kernel_addr_r=0x80080000\0" \
|
|
|
|
"ramdisk_name=ramdisk.img\0" \
|
|
|
|
"ramdisk_addr_r=0x88000000\0" \
|
2016-03-04 00:10:11 +00:00
|
|
|
"fdtfile=board.dtb\0" \
|
2015-10-09 16:18:07 +00:00
|
|
|
"fdt_alt_name=juno\0" \
|
arm: juno: Fix Juno address variables
The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-04-27 18:17:58 +00:00
|
|
|
"fdt_addr_r=0x80000000\0" \
|
2015-04-04 23:48:32 +00:00
|
|
|
|
2021-01-20 18:54:53 +00:00
|
|
|
#ifndef CONFIG_BOOTCOMMAND
|
2015-04-04 23:48:32 +00:00
|
|
|
/* Copy the kernel and FDT to DRAM memory and boot */
|
arm: juno: Fix Juno address variables
The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-04-27 18:17:58 +00:00
|
|
|
#define CONFIG_BOOTCOMMAND "afs load ${kernel_name} ${kernel_addr_r} ;"\
|
2015-10-09 16:18:07 +00:00
|
|
|
"if test $? -eq 1; then "\
|
|
|
|
" echo Loading ${kernel_alt_name} instead of "\
|
|
|
|
"${kernel_name}; "\
|
arm: juno: Fix Juno address variables
The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-04-27 18:17:58 +00:00
|
|
|
" afs load ${kernel_alt_name} ${kernel_addr_r};"\
|
2015-10-09 16:18:07 +00:00
|
|
|
"fi ; "\
|
arm: juno: Fix Juno address variables
The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-04-27 18:17:58 +00:00
|
|
|
"afs load ${fdtfile} ${fdt_addr_r} ;"\
|
2015-10-09 16:18:07 +00:00
|
|
|
"if test $? -eq 1; then "\
|
|
|
|
" echo Loading ${fdt_alt_name} instead of "\
|
2016-03-04 00:10:11 +00:00
|
|
|
"${fdtfile}; "\
|
arm: juno: Fix Juno address variables
The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-04-27 18:17:58 +00:00
|
|
|
" afs load ${fdt_alt_name} ${fdt_addr_r}; "\
|
2015-10-09 16:18:07 +00:00
|
|
|
"fi ; "\
|
arm: juno: Fix Juno address variables
The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-04-27 18:17:58 +00:00
|
|
|
"fdt addr ${fdt_addr_r}; fdt resize; " \
|
|
|
|
"if afs load ${ramdisk_name} ${ramdisk_addr_r} ; "\
|
2015-10-09 16:18:06 +00:00
|
|
|
"then "\
|
arm: juno: Fix Juno address variables
The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-04-27 18:17:58 +00:00
|
|
|
" setenv ramdisk_param ${ramdisk_addr_r}; "\
|
|
|
|
" else setenv ramdisk_param -; "\
|
2015-10-09 16:18:06 +00:00
|
|
|
"fi ; " \
|
arm: juno: Fix Juno address variables
The U-Boot documentation explains that variables ending with "_r" hold
addresses in DRAM, while those without that ending point to flash/ROM.
The default variables for the Juno board pointing to the kernel and DTB
load addresses were not complying with this scheme: they lack the
extension, but point to DRAM. This is particularly confusing since the
Juno board features parallel NOR flash, so there *is* a memory mapped
NOR address holding a DTB, for instance.
Fix the variables to use the proper names, changing initrd_addr to
ramdisk_addr_r on the way, which seems to be more prevelant and
documented. On the way adjust the FDT load address to be situated
*before* the kernel, since users happened to overwrite the DTB by the
kernel clearing its .BSS section during initialisation.
Also remove the fdt_high and initrd_high variables (which were set
to -1), to allow U-Boot moving those images around.
This should avoid many problems in the future, but breaks loading
Linux kernels < v4.2, since they expect the DTB to be loaded in the same
512MB region as the kernel. If you need to load such an old kernel,
please set fdt_high to either 0xffffffffffffffff or 0xa0000000 (if you
load the kernel to the beginning of DRAM).
That fixes loading debug kernels, which happened to overwrite the DTB on
certain setups.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2020-04-27 18:17:58 +00:00
|
|
|
"booti ${kernel_addr_r} ${ramdisk_param} ${fdt_addr_r}"
|
2021-01-20 18:54:53 +00:00
|
|
|
#endif
|
2015-04-04 23:48:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
#elif CONFIG_TARGET_VEXPRESS64_BASE_FVP
|
2014-06-09 18:12:59 +00:00
|
|
|
#define CONFIG_EXTRA_ENV_SETTINGS \
|
2015-05-27 07:45:39 +00:00
|
|
|
"kernel_name=Image\0" \
|
2016-01-04 15:43:36 +00:00
|
|
|
"kernel_addr=0x80080000\0" \
|
2014-06-09 18:12:59 +00:00
|
|
|
"initrd_name=ramdisk.img\0" \
|
2015-03-23 10:06:12 +00:00
|
|
|
"initrd_addr=0x88000000\0" \
|
2016-03-04 00:10:11 +00:00
|
|
|
"fdtfile=devtree.dtb\0" \
|
2015-03-23 10:06:12 +00:00
|
|
|
"fdt_addr=0x83000000\0" \
|
2020-04-04 02:58:24 +00:00
|
|
|
"boot_name=boot.img\0" \
|
|
|
|
"boot_addr=0x8007f800\0"
|
|
|
|
|
2021-01-20 18:54:53 +00:00
|
|
|
#ifndef CONFIG_BOOTCOMMAND
|
2020-04-04 02:58:24 +00:00
|
|
|
#define CONFIG_BOOTCOMMAND "if smhload ${boot_name} ${boot_addr}; then " \
|
|
|
|
" set bootargs; " \
|
|
|
|
" abootimg addr ${boot_addr}; " \
|
|
|
|
" abootimg get dtb --index=0 fdt_addr; " \
|
|
|
|
" bootm ${boot_addr} ${boot_addr} " \
|
|
|
|
" ${fdt_addr}; " \
|
|
|
|
"else; " \
|
|
|
|
" set fdt_high 0xffffffffffffffff; " \
|
|
|
|
" set initrd_high 0xffffffffffffffff; " \
|
|
|
|
" smhload ${kernel_name} ${kernel_addr}; " \
|
|
|
|
" smhload ${fdtfile} ${fdt_addr}; " \
|
|
|
|
" smhload ${initrd_name} ${initrd_addr} "\
|
|
|
|
" initrd_end; " \
|
|
|
|
" fdt addr ${fdt_addr}; fdt resize; " \
|
|
|
|
" fdt chosen ${initrd_addr} ${initrd_end}; " \
|
|
|
|
" booti $kernel_addr - $fdt_addr; " \
|
|
|
|
"fi"
|
2021-01-20 18:54:53 +00:00
|
|
|
#endif
|
2014-06-09 18:12:59 +00:00
|
|
|
#endif
|
2013-12-14 03:47:37 +00:00
|
|
|
|
|
|
|
/* Monitor Command Prompt */
|
|
|
|
#define CONFIG_SYS_CBSIZE 512 /* Console I/O Buffer Size */
|
|
|
|
#define CONFIG_SYS_MAXARGS 64 /* max command args */
|
|
|
|
|
2015-11-18 10:39:09 +00:00
|
|
|
#ifdef CONFIG_TARGET_VEXPRESS64_JUNO
|
|
|
|
#define CONFIG_SYS_FLASH_BASE 0x08000000
|
|
|
|
/* 255 x 256KiB sectors + 4 x 64KiB sectors at the end = 259 */
|
|
|
|
#define CONFIG_SYS_MAX_FLASH_SECT 259
|
|
|
|
/* Store environment at top of flash in the same location as blank.img */
|
|
|
|
/* in the Juno firmware. */
|
2015-02-19 16:19:37 +00:00
|
|
|
#else
|
2015-11-18 10:39:09 +00:00
|
|
|
#define CONFIG_SYS_FLASH_BASE 0x0C000000
|
|
|
|
/* 256 x 256KiB sectors */
|
|
|
|
#define CONFIG_SYS_MAX_FLASH_SECT 256
|
|
|
|
/* Store environment at top of flash */
|
|
|
|
#endif
|
|
|
|
|
2015-05-08 17:07:52 +00:00
|
|
|
#define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_32BIT
|
2015-11-18 10:39:09 +00:00
|
|
|
#define CONFIG_SYS_MAX_FLASH_BANKS 1
|
2015-02-19 16:19:37 +00:00
|
|
|
|
2020-04-27 18:18:03 +00:00
|
|
|
#ifdef CONFIG_USB_EHCI_HCD
|
|
|
|
#define CONFIG_USB_OHCI_NEW
|
|
|
|
#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 1
|
|
|
|
#endif
|
|
|
|
|
2015-02-19 16:19:37 +00:00
|
|
|
#define CONFIG_SYS_FLASH_EMPTY_INFO /* flinfo indicates empty blocks */
|
2015-11-18 10:39:09 +00:00
|
|
|
#define FLASH_MAX_SECTOR_SIZE 0x00040000
|
2015-02-19 16:19:37 +00:00
|
|
|
|
2013-12-14 03:47:37 +00:00
|
|
|
#endif /* __VEXPRESS_AEMV8A_H */
|