brain-hackers_pepepper-mirror/u-boot-brain
1
0
Fork 0
mirror of https://github.com/brain-hackers/u-boot-brain synced 2024-06-09 23:36:03 +09:00
Code Issues Projects Releases Wiki Activity
e8fc0d0cf3
u-boot-brain/board/xilinx/Kconfig

84 lines
2.7 KiB
Plaintext
Raw Normal View History

arm/arm64: zynq/zynqmp: pass the PS init file as a kconfig variable U-Boot needs to link ps7_init_gpl.c on Zynq or psu_init_gpl.c on ZynqMP (PS init for short). The current logic to locate this file for both platforms is: 1. if a board-specific file exists in board/xilinx/zynq[mp]/$(CONFIG_DEFAULT_DEVICE_TREE)/ps?_init_gpl.c then use it 2. otherwise use board/xilinx/zynq/ps?_init_gpl.c In the latter case the file does not exist in the U-Boot sources and must be copied in the source tree from the outside before starting the build. This is typical when it is generated from Xilinx tools while developing a custom hardware. However making sure that a board-specific file is _not_ found (and used) requires some trickery such as removing or overwriting all PS init files (e.g.: the current meta-xilinx yocto layer). This generates a few problems: * if the source tree is shared among different out-of-tree builds, they will pollute (and potentially corrupt) each other * the source tree cannot be read-only * any buildsystem must add a command to copy the PS init file binary * overwriting or deleting files in the source tree is ugly as hell Simplify usage by allowing to pass the path to the desired PS init file in kconfig variable XILINX_PS_INIT_FILE. It can be an absolute path or relative to $(srctree). If the variable is set, the user-specified file will always be used without being copied around. If the the variable is left empty, for backward compatibility fall back to the old behaviour. Since the issue is the same for Zynq and ZynqMP, add one kconfig variable in a common place and use it for both. Also use the new kconfig help text to document all the ways to give U-Boot the PS init file. Build-tested with all combinations of: - platform: zynq or zynqmp - PS init file: from XILINX_PS_INIT_FILE (absolute, relative path, non-existing), in-tree board-specific, in board/xilinx/zynq[mp]/ - building in-tree, in subdir, in other directory Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Nathan Rossi <nathan@nathanrossi.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2018-06-22 19:40:16 +09:00
# SPDX-License-Identifier: GPL-2.0
#
# Copyright (c) 2018, Luca Ceresoli <luca@lucaceresoli.net>
if ARCH_ZYNQ || ARCH_ZYNQMP
config XILINX_PS_INIT_FILE
string "Zynq/ZynqMP PS init file(s) location"
help
On Zynq and ZynqMP U-Boot SPL (or U-Boot proper if
ZYNQMP_PSU_INIT_ENABLED is set) is responsible for some
basic initializations, such as enabling peripherals and
configuring pinmuxes. The PS init file (called
psu_init_gpl.c on ZynqMP, ps7_init_gpl.c for Zynq-7000)
contains the code for such initializations.
U-Boot contains PS init files for some boards, but each of
them describes only one specific configuration. Users of a
different board, or needing a different configuration, can
generate custom files using the Xilinx development tools.
There are three ways to give a PS init file to U-Boot:
1. Set this variable to the path, either relative to the
source tree or absolute, where the psu_init_gpl.c or
ps7_init_gpl.c file is located. U-Boot will build this
file.
2. If you leave an empty string here, U-Boot will use
board/xilinx/zynq/$(CONFIG_DEFAULT_DEVICE_TREE)/ps7_init_gpl.c
for Zynq-7000, or
board/xilinx/zynqmp/$(CONFIG_DEFAULT_DEVICE_TREE)/psu_init_gpl.c
for ZynqMP.
3. If the above file does not exist, U-Boot will use
board/xilinx/zynq/ps7_init_gpl.c for Zynq-7000, or
board/xilinx/zynqmp/psu_init_gpl.c for ZynqMP. This file
is not provided by U-Boot, you have to copy it there
before the build.
endif
arm64: versal: Move common board dtb search Move the exisiting function of getting board dtb from versal to a common Xilinx folder. Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-02 23:57:36 +09:00
arm64: xilinx: Enable generic of_board_dtb Modify the configuration naming to be generic to xilinx rather than specific to Versal. The offset value is different for Zynq and ZynqMP to avoid overlapping with FSBL. Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-02 23:57:37 +09:00
config XILINX_OF_BOARD_DTB_ADDR
board: xilinx: Enable changing default DTB pick up address U-Boot on xilinx boards is checking one address where DTB can be placed as the first location for DTB. Originally this code was developed for Versal where QEMU was putting generated DTB for U-Boot to use. The patch enables changing this address which is necessary for cases where default address is pointing to location (DDR) which is not present. The access to this location can cause exception. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2020-08-20 21:02:47 +09:00
hex "Default DTB pickup address"
arm64: xilinx: Enable generic of_board_dtb Modify the configuration naming to be generic to xilinx rather than specific to Versal. The offset value is different for Zynq and ZynqMP to avoid overlapping with FSBL. Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-02 23:57:37 +09:00
default 0x1000 if ARCH_VERSAL
default 0x100000 if ARCH_ZYNQ || ARCH_ZYNQMP
arm64: zynqmp: Add support for OF_SEPARATE with board DTB OF_BOARD and OF_SEPARATE can use board specific board_fdt_blob_setup(). OF_BOARD option is mostly used for picking up DTB from certain location. OF_SEPARATE option is used when DTB is appended after u-boot binary. This board specific function is aligned with current version in lib/fdtdec.c with checking CONFIG_XILINX_OF_BOARD_DTB_ADDR address first. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-12-20 01:45:15 +09:00
depends on OF_BOARD || OF_SEPARATE
arm64: versal: Move common board dtb search Move the exisiting function of getting board dtb from versal to a common Xilinx folder. Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-10-02 23:57:36 +09:00
help
Offset in the memory where the board configuration DTB is placed.
board: xilinx: Add support for user configurable boot script offset Currently "script_offset_f" env variable is hardcoded, this variable specifies from which offset of the flash boot.scr should be read/write. As flashes are of different sizes having a fixed offset makes it difficult to load other images into the flash which may overwrite the boot script or cannot utilize the full memory. This current fix creates a new config "CONFIG_BOOT_SCRIPT_OFFSET" which holds the offset address, overwrites the "script_offset_f" variable. Also removed existing variable with default values, as the default values are held by CONFIG_BOOT_SCRIPT_OFFSET Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-12-18 19:34:41 +09:00
config BOOT_SCRIPT_OFFSET
hex "Boot script offset"
xilinx: Merge together BOOT_SCRIPT_OFFSET between MB and ARM There is no reason not to use commong Kconfig by Microblaze too. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2020-10-22 18:08:58 +09:00
depends on ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL || MICROBLAZE
default 0xFC0000 if ARCH_ZYNQ || MICROBLAZE
board: xilinx: Add support for user configurable boot script offset Currently "script_offset_f" env variable is hardcoded, this variable specifies from which offset of the flash boot.scr should be read/write. As flashes are of different sizes having a fixed offset makes it difficult to load other images into the flash which may overwrite the boot script or cannot utilize the full memory. This current fix creates a new config "CONFIG_BOOT_SCRIPT_OFFSET" which holds the offset address, overwrites the "script_offset_f" variable. Also removed existing variable with default values, as the default values are held by CONFIG_BOOT_SCRIPT_OFFSET Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-12-18 19:34:41 +09:00
default 0x3E80000 if ARCH_ZYNQMP
default 0x7F80000 if ARCH_VERSAL
help
xilinx: Merge together BOOT_SCRIPT_OFFSET between MB and ARM There is no reason not to use commong Kconfig by Microblaze too. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2020-10-22 18:08:58 +09:00
Specifies distro boot script offset in NAND/QSPI/NOR flash.
xilinx: common: Move ZYNQ_GEM_I2C_MAC_OFFSET to board Kconfig There is no reason to have ZYNQ specific Kconfig macro in generic location to be visible for all other SoCs. That's why move it to Xilinx common location to be visible only for us. Also introduce new bool entry ZYNQ_MAC_IN_EEPROM to have also an option to disable it or enable. This has connection to code which is reading the whole content of i2c and also work with the rest of date not just with MAC address. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2020-10-15 00:08:14 +09:00
config ZYNQ_MAC_IN_EEPROM
bool "Reading MAC address from EEPROM"
help
Enable this option if your MAC address is saved in eeprom and
xlnx,eeprom DT property in chosen node points to it.
if ZYNQ_MAC_IN_EEPROM
config ZYNQ_GEM_I2C_MAC_OFFSET
hex "Set the I2C MAC offset"
default 0x0
depends on DM_I2C
help
Set the MAC offset for i2C.
endif
xilinx: cmd: Add support for FRU commands This patch adds support for fru commands "fru capture" and "fru display". The fru capture parses the FRU table present at an address and stores in a structure for later use. The fru display prints the content of captured structured in a readable format. As of now, it supports only common header and board area of FRU. Also, it supports only English language code and ASCII8/BINARY formats. fru_data variable is placed to data section because fru parser can be called very early before bss is initialized. And also information needs to be shared that's why it is exported via header. Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-04-10 16:08:10 +09:00
config CMD_FRU
bool "FRU information for product"
help
This option enables FRU commands to capture and display FRU
information present in the device. The FRU Information is used
to primarily to provide "inventory" information about the boards
that the FRU Information Device is located on.
Reference in New Issue Copy Permalink