#
c62af153 |
|
29-Mar-2023 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: spl: Allow to build SATA kwbimage for 4K Native disks Add a new config option CONFIG_MVEBU_SPL_SATA_BLKSZ for specifying block size of SATA disk. This information is used during building of SATA kwbimage and must be correctly set, otherwise BootROM does not load SPL. For 4K Native disks CONFIG_MVEBU_SPL_SATA_BLKSZ must be set to 4096. Signed-off-by: Pali Rohár <pali@kernel.org> Tested-by: Martin Rowe <martin.p.rowe@gmail.com> |
#
67bd6158 |
|
10-Jan-2023 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: Add support for generating NAND kwbimage Add a new Kconfig option CONFIG_MVEBU_SPL_BOOT_DEVICE_NAND which instruct make to generate kwbimage with NAND header. This image is used for booting from NAND flash (either SPI or parallel). Support is very simple, SPL after finishes DDR training returns back to the BootROM (via CONFIG_SPL_BOOTROM_SUPPORT option) and BootROM then loads and executes U-Boot proper. To generate correct kwbimage NAND header, it is required to set following Kconfig options: CONFIG_SYS_NAND_PAGE_SIZE CONFIG_SYS_NAND_BLOCK_SIZE CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION They are used only by make / mkimage when generating final kwbimage. CONFIG_MVEBU_SPL_NAND_BADBLK_LOCATION is a new mvebu specific Kconfig option which is set into kwbimage NAND_BADBLK_LOCATION header field. Signed-off-by: Pali Rohár <pali@kernel.org> |
#
18d85d6e |
|
12-Jan-2022 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: Enable BootROM output on A38x BootROMs on pre-A38x SoCs enabled its output on UART by default, but A38x' BootROM has its output on UART disabled by default. To enable BootROM output on A38x SoC, it is required to set DEBUG flag (which only enables BootROM output and nothing more) in kwbimage. For UART images this DEBUG flag is ignored by BootROM. Enable kwbimage DEBUG flag for all A38x boards. With this change BootROM prints the following (success) information on UART before booting U-Boot kwbimage: BootROM - 1.73 Booting from SPI flash Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> |
#
a2b1db41 |
|
12-Jan-2022 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: Correctly set LOAD_ADDRESS for U-Boot SPL binary in kwbimage U-Boot SPL for mvebu platform is not compiled as position independent. Therefore it is required to instruct BootROM to load U-Boot SPL at the correct address. Loading of kwbimage binary code at specific address can be now achieved by the new LOAD_ADDRESS token as part of BINARY command in kwbimage config file. Update mvebu Makefile to put value of $(CONFIG_SPL_TEXT_BASE) into LOAD_ADDRESS token when generating kwbimage.cfg from kwbimage.cfg.in. It is required to update regex for sed to find replacement tokens at any position on a line in kwbimage config file and not only at the beginning of the line. This is because LOAD_ADDRESS is specified at the end of line containing the BINARY command. It looks like all Armada boards set CONFIG_SPL_TEXT_BASE to value 0x40004030 or 0x40000030. Why this value? It is because main kwbimage header is at address 0x40004030 or 0x40000000 and it is 32 bytes long. After the main header there is the binary header, which consist of 1 byte for type, 3 bytes for size, 1 byte for number of arguments, 3 reserved bytes and then 4 bytes for each argument. After these arguments comes the executable code. So arguments start at address 0x40004028 or 0x40000028. Before commit e6571f38c943 ("arm: mvebu: Remove dummy BIN header arguments for SPL binary") there were two (dummy) arguments, which resulted in load address of 0x40004030 or 0x40000030, always. After that commit (which removed dummy arguments), load address stayed same due to the 128-bit alignment done by mkimage. This patch now reflects the dependency between $(CONFIG_SPL_TEXT_BASE), load address and dummy kwbimage arguments, and allows the user to adjust $(CONFIG_SPL_TEXT_BASE) config option to some other value. For unsupported values, when mkimage/kwbimage cannot set chosen load address as specified by $(CONFIG_SPL_TEXT_BASE), the build process now fails, instead of silently generating non-working kwbimage. Removal of this alignment between $(CONFIG_SPL_TEXT_BASE) and LOAD_ADDRESS can only be done by compiling U-Boot SPL as position independent. But this currently is not possible for 32-bit ARM version of U-Boot SPL. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> |
#
29c6a9c7 |
|
12-Jan-2022 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: Set CPU for U-Boot SPL binary in kwbimage kwbimage needs to know CPU type, so set it in kwbimage config file. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> |
#
e6571f38 |
|
21-Oct-2021 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: Remove dummy BIN header arguments for SPL binary U-Boot SPL binary does not read BIN header arguments, so passing some dummy values 0000005b and 00000068 has no effect for U-Boot SPL code. Probably these two values comes from old Marvell DDR training code which was separated from U-Boot and used it for some configuration. Seems that two 32-bit values were specified here to ensure SPL code alignment to 128-bit boundary as it is required e.g. for A370 or AXP processors. Main kwbimage header is 64-byte long which is aligned to 128-bit boundary. Optional kwbheader is 32-bit long, number of BIN header arguments is stored in 32-bit number. So for alignment to 128-bit boundary is needed 64-bit padding which exactly these two 32-bit dummy arguments provided. Now when mkimage correctly aligns start of executable code in BIN header to 128-bit boundary, there is no requirement to put dummy argument values into kwbimage. So remove them. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> |
#
ca1a4c86 |
|
18-Jun-2018 |
Baruch Siach <baruch@tkos.co.il> |
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de> |
#
18d85d6e |
|
12-Jan-2022 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: Enable BootROM output on A38x BootROMs on pre-A38x SoCs enabled its output on UART by default, but A38x' BootROM has its output on UART disabled by default. To enable BootROM output on A38x SoC, it is required to set DEBUG flag (which only enables BootROM output and nothing more) in kwbimage. For UART images this DEBUG flag is ignored by BootROM. Enable kwbimage DEBUG flag for all A38x boards. With this change BootROM prints the following (success) information on UART before booting U-Boot kwbimage: BootROM - 1.73 Booting from SPI flash Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> |
#
a2b1db41 |
|
12-Jan-2022 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: Correctly set LOAD_ADDRESS for U-Boot SPL binary in kwbimage U-Boot SPL for mvebu platform is not compiled as position independent. Therefore it is required to instruct BootROM to load U-Boot SPL at the correct address. Loading of kwbimage binary code at specific address can be now achieved by the new LOAD_ADDRESS token as part of BINARY command in kwbimage config file. Update mvebu Makefile to put value of $(CONFIG_SPL_TEXT_BASE) into LOAD_ADDRESS token when generating kwbimage.cfg from kwbimage.cfg.in. It is required to update regex for sed to find replacement tokens at any position on a line in kwbimage config file and not only at the beginning of the line. This is because LOAD_ADDRESS is specified at the end of line containing the BINARY command. It looks like all Armada boards set CONFIG_SPL_TEXT_BASE to value 0x40004030 or 0x40000030. Why this value? It is because main kwbimage header is at address 0x40004030 or 0x40000000 and it is 32 bytes long. After the main header there is the binary header, which consist of 1 byte for type, 3 bytes for size, 1 byte for number of arguments, 3 reserved bytes and then 4 bytes for each argument. After these arguments comes the executable code. So arguments start at address 0x40004028 or 0x40000028. Before commit e6571f38c943 ("arm: mvebu: Remove dummy BIN header arguments for SPL binary") there were two (dummy) arguments, which resulted in load address of 0x40004030 or 0x40000030, always. After that commit (which removed dummy arguments), load address stayed same due to the 128-bit alignment done by mkimage. This patch now reflects the dependency between $(CONFIG_SPL_TEXT_BASE), load address and dummy kwbimage arguments, and allows the user to adjust $(CONFIG_SPL_TEXT_BASE) config option to some other value. For unsupported values, when mkimage/kwbimage cannot set chosen load address as specified by $(CONFIG_SPL_TEXT_BASE), the build process now fails, instead of silently generating non-working kwbimage. Removal of this alignment between $(CONFIG_SPL_TEXT_BASE) and LOAD_ADDRESS can only be done by compiling U-Boot SPL as position independent. But this currently is not possible for 32-bit ARM version of U-Boot SPL. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> |
#
29c6a9c7 |
|
12-Jan-2022 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: Set CPU for U-Boot SPL binary in kwbimage kwbimage needs to know CPU type, so set it in kwbimage config file. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> |
#
e6571f38 |
|
21-Oct-2021 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: Remove dummy BIN header arguments for SPL binary U-Boot SPL binary does not read BIN header arguments, so passing some dummy values 0000005b and 00000068 has no effect for U-Boot SPL code. Probably these two values comes from old Marvell DDR training code which was separated from U-Boot and used it for some configuration. Seems that two 32-bit values were specified here to ensure SPL code alignment to 128-bit boundary as it is required e.g. for A370 or AXP processors. Main kwbimage header is 64-byte long which is aligned to 128-bit boundary. Optional kwbheader is 32-bit long, number of BIN header arguments is stored in 32-bit number. So for alignment to 128-bit boundary is needed 64-bit padding which exactly these two 32-bit dummy arguments provided. Now when mkimage correctly aligns start of executable code in BIN header to 128-bit boundary, there is no requirement to put dummy argument values into kwbimage. So remove them. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> |
#
ca1a4c86 |
|
18-Jun-2018 |
Baruch Siach <baruch@tkos.co.il> |
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de> |
#
e6571f38 |
|
21-Oct-2021 |
Pali Rohár <pali@kernel.org> |
arm: mvebu: Remove dummy BIN header arguments for SPL binary U-Boot SPL binary does not read BIN header arguments, so passing some dummy values 0000005b and 00000068 has no effect for U-Boot SPL code. Probably these two values comes from old Marvell DDR training code which was separated from U-Boot and used it for some configuration. Seems that two 32-bit values were specified here to ensure SPL code alignment to 128-bit boundary as it is required e.g. for A370 or AXP processors. Main kwbimage header is 64-byte long which is aligned to 128-bit boundary. Optional kwbheader is 32-bit long, number of BIN header arguments is stored in 32-bit number. So for alignment to 128-bit boundary is needed 64-bit padding which exactly these two 32-bit dummy arguments provided. Now when mkimage correctly aligns start of executable code in BIN header to 128-bit boundary, there is no requirement to put dummy argument values into kwbimage. So remove them. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Stefan Roese <sr@denx.de> |
#
ca1a4c86 |
|
18-Jun-2018 |
Baruch Siach <baruch@tkos.co.il> |
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de> |
#
ca1a4c86 |
|
18-Jun-2018 |
Baruch Siach <baruch@tkos.co.il> |
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de> |
#
ca1a4c86 |
|
18-Jun-2018 |
Baruch Siach <baruch@tkos.co.il> |
mvebu: select boot device at SoC level Move the gdsys Controlcenter DC specific build time kwbimage.cfg generation code into the mach-mvebu/ directory to be shared by all 32bit mvebu platforms. Remove board specific kwbimage.cfg files, and use the generated one instead. These files are all identical, with two exceptions. Clearfog and Helios4 use the sdio boot device, whereas all others use spi. Update the defconfigs for the exceptional boards to generate the same kwbimage.cfg as before. Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
|