Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-01 08:59:33 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/board/armltd/vexpress64/Kconfig

93 lines
2.1 KiB
Text
Raw Normal View History

vexpress64: Kconfig: move board definitions out of arch/arm At the moment we define three "VExpress64" boards in arch/arm/Kconfig, plus have a second Kconfig file in board/armltd/Kconfig. One of those three boards is actually bogus (TARGET_VEXPRESS64_AEMV8A), that stanza looks like being forgotten in a previous cleanup. To remove the clutter from the generic Kconfig file, just define some ARCH_VEXPRESS64 symbol there, enable some common options, and do the board/model specific configuration in the board/armltd Kconfig file. That allows to streamline and fine tune the configuration later, and to also pull a lot of "non user choices" out of the defconfigs. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:09 +00:00
if ARCH_VEXPRESS64
vexpress64: support the Juno Development Platform The Juno Development Platform is a physical Versatile Express device with some differences from the emulated semihosting models. The main difference is that the system is split in a SoC and an FPGA where the SoC hosts the serial ports at totally different adresses. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-23 13:41:10 +00:00
config SYS_BOARD
default "vexpress64"
config SYS_VENDOR
default "armltd"
config SYS_CONFIG_NAME
vexpress64: Refactor header file to make it easier to add new FVPs Rename from vexpress_aemv8a.h -> vepxress_aemv8.h as new FVPs may not be v8-A. No change in behavior. This is towards future work to enable support for the FVP_BaseR. Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2021-11-11 09:26:00 +00:00
default "vexpress_aemv8"
vexpress64: support the Juno Development Platform The Juno Development Platform is a physical Versatile Express device with some differences from the emulated semihosting models. The main difference is that the system is split in a SoC and an FPGA where the SoC hosts the serial ports at totally different adresses. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-23 13:41:10 +00:00
vexpress64: Add ARMv8R-64 board variant The ARMv8-R64 architecture introduces optional VMSA (paging based MMU) support in the EL1/0 translation regime, which makes that part mostly compatible to ARMv8-A. Add a new board variant to describe the "BASE-R64" FVP model, which inherits a lot from the existing v8-A FVP support. One major difference is that the memory map in "inverted": DRAM starts at 0x0, MMIO is at 2GB [1]. * Create new TARGET_VEXPRESS64_BASER_FVP target, sharing most of the exising configuration. * Implement inverted memory map in vexpress_aemv8.h * Create vexpress_aemv8r defconfig * Provide an MMU memory map for the BASER_FVP * Update vexpress64 documentation At the moment the boot-wrapper is the only supported secure firmware. As there is no official DT for the board yet, we rely on it being supplied by the boot-wrapper into U-Boot, so use OF_HAS_PRIOR_STAGE, and go with a dummy DT for now. [1] https://developer.arm.com/documentation/100964/1114/Base-Platform/Base---memory/BaseR-Platform-memory-map Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> [Andre: rebase and add Linux kernel header] Signed-off-by: Andre Przywara <andre.przywara@arm.com> [trini: Add MAINTAINERS entry for Peter]
2022-03-04 16:30:18 +00:00
config VEXPRESS64_BASE_MODEL
bool
vexpress64: Kconfig: move board definitions out of arch/arm At the moment we define three "VExpress64" boards in arch/arm/Kconfig, plus have a second Kconfig file in board/armltd/Kconfig. One of those three boards is actually bogus (TARGET_VEXPRESS64_AEMV8A), that stanza looks like being forgotten in a previous cleanup. To remove the clutter from the generic Kconfig file, just define some ARCH_VEXPRESS64 symbol there, enable some common options, and do the board/model specific configuration in the board/armltd Kconfig file. That allows to streamline and fine tune the configuration later, and to also pull a lot of "non user choices" out of the defconfigs. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:09 +00:00
select SEMIHOSTING
vexpress64: Enable VIRTIO_MMIO and RTC_PL031 in the base model The Arm EBBR (Embedded Base Boot Requirements) require that the time and basic networking EFI interfaces are available and working, so long as the hardware has an RTC and network interface. Arm FVPs typically have a memory-mapped PL031 RTC and a VIRTIO_NET device defined in the device tree, so "imply" these in the Kconfig for the FVP base model to simplify creating EBBR-compliant firmware. Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
2023-03-31 08:58:12 +00:00
imply VIRTIO_MMIO
vexpress64: move hardware setting from defconfig to Kconfig The defconfigs for the Arm Juno board and the FVP model are quite large, setting a lot of platform-fixed variables like SYS_TEXT_BASE. As those values are not really a user choice, let's provide default values for them in our Kconfig file, so a lot of cruft can be removed from the defconfig files. This also moves the driver selection out of there, since this is again not something a user should really decide on. Instead we allow users to enable or disable subsystems, and select the appropriate drivers based on that in the Kconfig file. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:13 +00:00
select VIRTIO_BLK if VIRTIO_MMIO
select VIRTIO_NET if VIRTIO_MMIO
vexpress64: Enable VIRTIO_MMIO and RTC_PL031 in the base model The Arm EBBR (Embedded Base Boot Requirements) require that the time and basic networking EFI interfaces are available and working, so long as the hardware has an RTC and network interface. Arm FVPs typically have a memory-mapped PL031 RTC and a VIRTIO_NET device defined in the device tree, so "imply" these in the Kconfig for the FVP base model to simplify creating EBBR-compliant firmware. Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
2023-03-31 08:58:12 +00:00
select DM_ETH if VIRTIO_NET
imply RTC_PL031
select DM_RTC if RTC_PL031
imply EFI_SET_TIME if DM_RTC
vexpress64: fvp: enable OF_CONTROL The FVP base model is relying on a DT for Linux operation, so there is no reason we would need to rely on hardcoded information for U-Boot. Letting U-Boot use a DT will open up the usage of actual peripherals, beyond the support for semihosting only. Enable OF_CONTROL in the Kconfig, and use the latest dts files from Linux. Depending on whether we use the boot-wrapper or TF-A, there is already a DTB provided or not, respectively. To cover the boot-wrapper, we add an arm64 Linux kernel header, which allows the boot-wrapper to treat U-Boot like a Linux kernel. U-Boot will find the pointer to the DTB in x0, and will use it. Even though TF-A carries a DT, at the moment this is not made available to non-secure world, so to not break users, we use the U-Boot provided DTB copy in that case. For some reason TF-A puts some DT like structure at the address x0 is pointing at, but that is very small and doesn't carry any hardware information. Make the code to ignore those small DTBs. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:11 +00:00
select LINUX_KERNEL_IMAGE_HEADER
select POSITION_INDEPENDENT
vexpress64: Add ARMv8R-64 board variant The ARMv8-R64 architecture introduces optional VMSA (paging based MMU) support in the EL1/0 translation regime, which makes that part mostly compatible to ARMv8-A. Add a new board variant to describe the "BASE-R64" FVP model, which inherits a lot from the existing v8-A FVP support. One major difference is that the memory map in "inverted": DRAM starts at 0x0, MMIO is at 2GB [1]. * Create new TARGET_VEXPRESS64_BASER_FVP target, sharing most of the exising configuration. * Implement inverted memory map in vexpress_aemv8.h * Create vexpress_aemv8r defconfig * Provide an MMU memory map for the BASER_FVP * Update vexpress64 documentation At the moment the boot-wrapper is the only supported secure firmware. As there is no official DT for the board yet, we rely on it being supplied by the boot-wrapper into U-Boot, so use OF_HAS_PRIOR_STAGE, and go with a dummy DT for now. [1] https://developer.arm.com/documentation/100964/1114/Base-Platform/Base---memory/BaseR-Platform-memory-map Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> [Andre: rebase and add Linux kernel header] Signed-off-by: Andre Przywara <andre.przywara@arm.com> [trini: Add MAINTAINERS entry for Peter]
2022-03-04 16:30:18 +00:00
choice
prompt "VExpress64 board variant"
config TARGET_VEXPRESS64_BASE_FVP
bool "Support Versatile Express ARMv8a FVP BASE model"
select VEXPRESS64_BASE_MODEL
vexpress64: Use OF_HAS_PRIOR_STAGE for BASE_FVP variant BASE_FVP now typically uses a devicetree provided by a prior boot stage (typically Arm TF-A), so imply this option by default when TARGET_VEXPRESS64_BASE_FVP is selected. OF_HAS_PRIOR_STAGE selects OF_BOARD so this change is minor, but aligns TARGET_VEXPRESS64_BASE_FVP with TARGET_VEXPRESS64_BASER_FVP. Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
2023-03-31 08:58:11 +00:00
imply OF_HAS_PRIOR_STAGE
vexpress64: Kconfig: move board definitions out of arch/arm At the moment we define three "VExpress64" boards in arch/arm/Kconfig, plus have a second Kconfig file in board/armltd/Kconfig. One of those three boards is actually bogus (TARGET_VEXPRESS64_AEMV8A), that stanza looks like being forgotten in a previous cleanup. To remove the clutter from the generic Kconfig file, just define some ARCH_VEXPRESS64 symbol there, enable some common options, and do the board/model specific configuration in the board/armltd Kconfig file. That allows to streamline and fine tune the configuration later, and to also pull a lot of "non user choices" out of the defconfigs. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:09 +00:00
vexpress64: Add ARMv8R-64 board variant The ARMv8-R64 architecture introduces optional VMSA (paging based MMU) support in the EL1/0 translation regime, which makes that part mostly compatible to ARMv8-A. Add a new board variant to describe the "BASE-R64" FVP model, which inherits a lot from the existing v8-A FVP support. One major difference is that the memory map in "inverted": DRAM starts at 0x0, MMIO is at 2GB [1]. * Create new TARGET_VEXPRESS64_BASER_FVP target, sharing most of the exising configuration. * Implement inverted memory map in vexpress_aemv8.h * Create vexpress_aemv8r defconfig * Provide an MMU memory map for the BASER_FVP * Update vexpress64 documentation At the moment the boot-wrapper is the only supported secure firmware. As there is no official DT for the board yet, we rely on it being supplied by the boot-wrapper into U-Boot, so use OF_HAS_PRIOR_STAGE, and go with a dummy DT for now. [1] https://developer.arm.com/documentation/100964/1114/Base-Platform/Base---memory/BaseR-Platform-memory-map Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> [Andre: rebase and add Linux kernel header] Signed-off-by: Andre Przywara <andre.przywara@arm.com> [trini: Add MAINTAINERS entry for Peter]
2022-03-04 16:30:18 +00:00
config TARGET_VEXPRESS64_BASER_FVP
bool "Support Versatile Express ARMv8r64 FVP BASE model"
select VEXPRESS64_BASE_MODEL
imply OF_HAS_PRIOR_STAGE
vexpress64: Kconfig: move board definitions out of arch/arm At the moment we define three "VExpress64" boards in arch/arm/Kconfig, plus have a second Kconfig file in board/armltd/Kconfig. One of those three boards is actually bogus (TARGET_VEXPRESS64_AEMV8A), that stanza looks like being forgotten in a previous cleanup. To remove the clutter from the generic Kconfig file, just define some ARCH_VEXPRESS64 symbol there, enable some common options, and do the board/model specific configuration in the board/armltd Kconfig file. That allows to streamline and fine tune the configuration later, and to also pull a lot of "non user choices" out of the defconfigs. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:09 +00:00
config TARGET_VEXPRESS64_JUNO
bool "Support Versatile Express Juno Development Platform"
vexpress64: move hardware setting from defconfig to Kconfig The defconfigs for the Arm Juno board and the FVP model are quite large, setting a lot of platform-fixed variables like SYS_TEXT_BASE. As those values are not really a user choice, let's provide default values for them in our Kconfig file, so a lot of cruft can be removed from the defconfig files. This also moves the driver selection out of there, since this is again not something a user should really decide on. Instead we allow users to enable or disable subsystems, and select the appropriate drivers based on that in the Kconfig file. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:13 +00:00
select PCIE_ECAM_GENERIC if PCI
select SATA_SIL
select SMC911X if DM_ETH
select SMC911X_32_BIT if SMC911X
select CMD_USB if USB
select USB_EHCI_HCD if USB
select USB_EHCI_GENERIC if USB
select USB_OHCI_HCD if USB
select USB_OHCI_GENERIC if USB
vexpress64: Kconfig: move board definitions out of arch/arm At the moment we define three "VExpress64" boards in arch/arm/Kconfig, plus have a second Kconfig file in board/armltd/Kconfig. One of those three boards is actually bogus (TARGET_VEXPRESS64_AEMV8A), that stanza looks like being forgotten in a previous cleanup. To remove the clutter from the generic Kconfig file, just define some ARCH_VEXPRESS64 symbol there, enable some common options, and do the board/model specific configuration in the board/armltd Kconfig file. That allows to streamline and fine tune the configuration later, and to also pull a lot of "non user choices" out of the defconfigs. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:09 +00:00
imply OF_HAS_PRIOR_STAGE
endchoice
arm: juno: Enable OF_CONTROL The Arm Juno board was still somewhat stuck in "hardcoded land", even though there are stable DTs around, and one happens to actually be on the memory mapped NOR flash. Enable the configuration options to let the board use OF_CONTROL, and add a routine to find the address of the DTB partition in NOR flash, to use that for U-Boot's own purposes. This can also passed on via $fdtcontroladdr to any kernel or EFI application, removing the need to actually load a device tree. Since the existing "afs" command and its flash routines require flash_init() to be called before being usable, and this is done much later in the boot process, we introduce a stripped-down partition finder routine in vexpress64.c, to scan the NOR flash partitions for the DT partition. This location is then used for U-Boot to find and probe devices. The name of the partition can be configured, if needed, but defaults to "board.dtb", which is used by Linaro's firmware image provided. Signed-off-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-04-27 18:18:01 +00:00
config JUNO_DTB_PART
string "NOR flash partition holding DTB"
default "board.dtb"
help
The ARM partition name in the NOR flash memory holding the
device tree blob to configure U-Boot.
vexpress64: fvp: enable OF_CONTROL The FVP base model is relying on a DT for Linux operation, so there is no reason we would need to rely on hardcoded information for U-Boot. Letting U-Boot use a DT will open up the usage of actual peripherals, beyond the support for semihosting only. Enable OF_CONTROL in the Kconfig, and use the latest dts files from Linux. Depending on whether we use the boot-wrapper or TF-A, there is already a DTB provided or not, respectively. To cover the boot-wrapper, we add an arm64 Linux kernel header, which allows the boot-wrapper to treat U-Boot like a Linux kernel. U-Boot will find the pointer to the DTB in x0, and will use it. Even though TF-A carries a DT, at the moment this is not made available to non-secure world, so to not break users, we use the U-Boot provided DTB copy in that case. For some reason TF-A puts some DT like structure at the address x0 is pointing at, but that is very small and doesn't carry any hardware information. Make the code to ignore those small DTBs. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:11 +00:00
config LNX_KRNL_IMG_TEXT_OFFSET_BASE
Rename CONFIG_SYS_TEXT_BASE to CONFIG_TEXT_BASE The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE and this makes it imposible to use CONFIG_VAL(). Rename it to resolve this problem. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-21 00:22:39 +00:00
default TEXT_BASE
vexpress64: fvp: enable OF_CONTROL The FVP base model is relying on a DT for Linux operation, so there is no reason we would need to rely on hardcoded information for U-Boot. Letting U-Boot use a DT will open up the usage of actual peripherals, beyond the support for semihosting only. Enable OF_CONTROL in the Kconfig, and use the latest dts files from Linux. Depending on whether we use the boot-wrapper or TF-A, there is already a DTB provided or not, respectively. To cover the boot-wrapper, we add an arm64 Linux kernel header, which allows the boot-wrapper to treat U-Boot like a Linux kernel. U-Boot will find the pointer to the DTB in x0, and will use it. Even though TF-A carries a DT, at the moment this is not made available to non-secure world, so to not break users, we use the U-Boot provided DTB copy in that case. For some reason TF-A puts some DT like structure at the address x0 is pointing at, but that is very small and doesn't carry any hardware information. Make the code to ignore those small DTBs. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:11 +00:00
Rename CONFIG_SYS_TEXT_BASE to CONFIG_TEXT_BASE The current name is inconsistent with SPL which uses CONFIG_SPL_TEXT_BASE and this makes it imposible to use CONFIG_VAL(). Rename it to resolve this problem. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-10-21 00:22:39 +00:00
config TEXT_BASE
vexpress64: move hardware setting from defconfig to Kconfig The defconfigs for the Arm Juno board and the FVP model are quite large, setting a lot of platform-fixed variables like SYS_TEXT_BASE. As those values are not really a user choice, let's provide default values for them in our Kconfig file, so a lot of cruft can be removed from the defconfig files. This also moves the driver selection out of there, since this is again not something a user should really decide on. Instead we allow users to enable or disable subsystems, and select the appropriate drivers based on that in the Kconfig file. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:13 +00:00
default 0x88000000 if TARGET_VEXPRESS64_BASE_FVP
default 0xe0000000 if TARGET_VEXPRESS64_JUNO
vexpress64: Add ARMv8R-64 board variant The ARMv8-R64 architecture introduces optional VMSA (paging based MMU) support in the EL1/0 translation regime, which makes that part mostly compatible to ARMv8-A. Add a new board variant to describe the "BASE-R64" FVP model, which inherits a lot from the existing v8-A FVP support. One major difference is that the memory map in "inverted": DRAM starts at 0x0, MMIO is at 2GB [1]. * Create new TARGET_VEXPRESS64_BASER_FVP target, sharing most of the exising configuration. * Implement inverted memory map in vexpress_aemv8.h * Create vexpress_aemv8r defconfig * Provide an MMU memory map for the BASER_FVP * Update vexpress64 documentation At the moment the boot-wrapper is the only supported secure firmware. As there is no official DT for the board yet, we rely on it being supplied by the boot-wrapper into U-Boot, so use OF_HAS_PRIOR_STAGE, and go with a dummy DT for now. [1] https://developer.arm.com/documentation/100964/1114/Base-Platform/Base---memory/BaseR-Platform-memory-map Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> [Andre: rebase and add Linux kernel header] Signed-off-by: Andre Przywara <andre.przywara@arm.com> [trini: Add MAINTAINERS entry for Peter]
2022-03-04 16:30:18 +00:00
default 0x00001000 if TARGET_VEXPRESS64_BASER_FVP
vexpress64: move hardware setting from defconfig to Kconfig The defconfigs for the Arm Juno board and the FVP model are quite large, setting a lot of platform-fixed variables like SYS_TEXT_BASE. As those values are not really a user choice, let's provide default values for them in our Kconfig file, so a lot of cruft can be removed from the defconfig files. This also moves the driver selection out of there, since this is again not something a user should really decide on. Instead we allow users to enable or disable subsystems, and select the appropriate drivers based on that in the Kconfig file. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:13 +00:00
config SYS_MALLOC_LEN
default 0x810000 if TARGET_VEXPRESS64_JUNO
default 0x840000 if TARGET_VEXPRESS64_BASE_FVP
config SYS_MALLOC_F_LEN
default 0x2000
config SYS_LOAD_ADDR
vexpress64: Add ARMv8R-64 board variant The ARMv8-R64 architecture introduces optional VMSA (paging based MMU) support in the EL1/0 translation regime, which makes that part mostly compatible to ARMv8-A. Add a new board variant to describe the "BASE-R64" FVP model, which inherits a lot from the existing v8-A FVP support. One major difference is that the memory map in "inverted": DRAM starts at 0x0, MMIO is at 2GB [1]. * Create new TARGET_VEXPRESS64_BASER_FVP target, sharing most of the exising configuration. * Implement inverted memory map in vexpress_aemv8.h * Create vexpress_aemv8r defconfig * Provide an MMU memory map for the BASER_FVP * Update vexpress64 documentation At the moment the boot-wrapper is the only supported secure firmware. As there is no official DT for the board yet, we rely on it being supplied by the boot-wrapper into U-Boot, so use OF_HAS_PRIOR_STAGE, and go with a dummy DT for now. [1] https://developer.arm.com/documentation/100964/1114/Base-Platform/Base---memory/BaseR-Platform-memory-map Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> [Andre: rebase and add Linux kernel header] Signed-off-by: Andre Przywara <andre.przywara@arm.com> [trini: Add MAINTAINERS entry for Peter]
2022-03-04 16:30:18 +00:00
default 0x10000000 if TARGET_VEXPRESS64_BASER_FVP
vexpress64: move hardware setting from defconfig to Kconfig The defconfigs for the Arm Juno board and the FVP model are quite large, setting a lot of platform-fixed variables like SYS_TEXT_BASE. As those values are not really a user choice, let's provide default values for them in our Kconfig file, so a lot of cruft can be removed from the defconfig files. This also moves the driver selection out of there, since this is again not something a user should really decide on. Instead we allow users to enable or disable subsystems, and select the appropriate drivers based on that in the Kconfig file. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:13 +00:00
default 0x90000000
config ENV_ADDR
default 0x0BFC0000 if TARGET_VEXPRESS64_JUNO
default 0x0FFC0000 if TARGET_VEXPRESS64_BASE_FVP
vexpress64: Add ARMv8R-64 board variant The ARMv8-R64 architecture introduces optional VMSA (paging based MMU) support in the EL1/0 translation regime, which makes that part mostly compatible to ARMv8-A. Add a new board variant to describe the "BASE-R64" FVP model, which inherits a lot from the existing v8-A FVP support. One major difference is that the memory map in "inverted": DRAM starts at 0x0, MMIO is at 2GB [1]. * Create new TARGET_VEXPRESS64_BASER_FVP target, sharing most of the exising configuration. * Implement inverted memory map in vexpress_aemv8.h * Create vexpress_aemv8r defconfig * Provide an MMU memory map for the BASER_FVP * Update vexpress64 documentation At the moment the boot-wrapper is the only supported secure firmware. As there is no official DT for the board yet, we rely on it being supplied by the boot-wrapper into U-Boot, so use OF_HAS_PRIOR_STAGE, and go with a dummy DT for now. [1] https://developer.arm.com/documentation/100964/1114/Base-Platform/Base---memory/BaseR-Platform-memory-map Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com> [Andre: rebase and add Linux kernel header] Signed-off-by: Andre Przywara <andre.przywara@arm.com> [trini: Add MAINTAINERS entry for Peter]
2022-03-04 16:30:18 +00:00
default 0x8FFC0000 if TARGET_VEXPRESS64_BASER_FVP
vexpress64: move hardware setting from defconfig to Kconfig The defconfigs for the Arm Juno board and the FVP model are quite large, setting a lot of platform-fixed variables like SYS_TEXT_BASE. As those values are not really a user choice, let's provide default values for them in our Kconfig file, so a lot of cruft can be removed from the defconfig files. This also moves the driver selection out of there, since this is again not something a user should really decide on. Instead we allow users to enable or disable subsystems, and select the appropriate drivers based on that in the Kconfig file. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
2022-03-04 16:30:13 +00:00
config ENV_SIZE
default 0x10000 if TARGET_VEXPRESS64_JUNO
default 0x40000
config ENV_SECT_SIZE
default 0x10000 if TARGET_VEXPRESS64_JUNO
default 0x40000
vexpress64: support the Juno Development Platform The Juno Development Platform is a physical Versatile Express device with some differences from the emulated semihosting models. The main difference is that the system is split in a SoC and an FPGA where the SoC hosts the serial ports at totally different adresses. Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-01-23 13:41:10 +00:00
endif
Reference in a new issue Copy permalink