[PATCH v2 8/8] board: add support for Qualcomm SA8155P-ADP board
Sumit Garg
sumit.garg at linaro.org
Wed Mar 6 06:52:58 CET 2024
Hi Volodymyr,
On Wed, 6 Mar 2024 at 06:23, Volodymyr Babchuk
<Volodymyr_Babchuk at epam.com> wrote:
>
> SA8155P Automotive Development Platform is Qualcomm SA8155-based board
> for developers. The nice thing that it has unlocked loaders with test
> keys support, which means that U-Boot for this platform can be
> launched at earlier stages.
>
> This patch adds basic board support with only serial port and
> networking operation. I am using U-Boot to ease up Xen porting onto
> this board, so I am mostly interesting in booting U-Boot in EL2. But
> more conventional setup with Android boot image is supported as well.
>
> Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk at epam.com>
>
> ---
>
> Changes in v2:
> - Rebased onto qcom-next branch
> - Removed unnecessary files thanks to generic qualcomm board support
> - Enabled CONFIG_REMAKE_ELF (this removes one extra step in the
> readme)
Thanks for the rebase.
>
> arch/arm/dts/sa8155p-adp-u-boot.dtsi | 30 +++++++++
> board/qualcomm/sa8155p-adp/MAINTAINERS | 5 ++
> configs/sa8155p_adp_defconfig | 35 +++++++++++
> doc/board/qualcomm/index.rst | 1 +
> doc/board/qualcomm/sa8155p-adp.rst | 87 ++++++++++++++++++++++++++
> 5 files changed, 158 insertions(+)
> create mode 100644 arch/arm/dts/sa8155p-adp-u-boot.dtsi
> create mode 100644 board/qualcomm/sa8155p-adp/MAINTAINERS
> create mode 100644 configs/sa8155p_adp_defconfig
> create mode 100644 doc/board/qualcomm/sa8155p-adp.rst
>
> diff --git a/arch/arm/dts/sa8155p-adp-u-boot.dtsi b/arch/arm/dts/sa8155p-adp-u-boot.dtsi
> new file mode 100644
> index 0000000000..ffbf0933c7
> --- /dev/null
> +++ b/arch/arm/dts/sa8155p-adp-u-boot.dtsi
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Qualcomm SA8155P-ADP device tree fixups for U-BOot
> + *
> + * Volodymyr Babchuk <volodymyr_babchuk at epam.com>
> + * Copyright (c) 2024 EPAM Systems.
> + */
> +
> +/ {
> + /* Populate memory node with actual memory configuration */
> + memory at 80000000 {
> + reg = <0x00 0x80000000 0x00 0x39900000>,
> + <0x02 0x0 0x1 0x7fd00000>,
> + <0x00 0xC0000000 0x1 0x40000000>;
> + };
> +};
> +
> +ðernet {
> + /* Ethernet driver tries to find reset by name */
> + reset-names = "emac";
This deserves to be pushed upstream in Linux kernel DT. In the
meantime we can carry it here.
> +};
> +
> +&tlmm {
> + /* U-Boot pinctrl driver does not understand multiple tiles */
> + reg = <0x0 0x03000000 0x0 0x1000000>;
> + /delete-property/ reg-names;
This won't be needed if we can make the tiles offset in the pinctrl
driver compatible:
#define WEST 0x00000000
#define EAST 0x00400000
#define NORTH 0x00800000
#define SOUTH 0x00C00000
> +
> + /* U-Boot ethernet driver wants to drive reset as GPIO */
> + /delete-node/ phy-reset-pins;
I suppose this is not needed as phy-reset-pins also configures the pin
as GPIO only.
> +};
> diff --git a/board/qualcomm/sa8155p-adp/MAINTAINERS b/board/qualcomm/sa8155p-adp/MAINTAINERS
> new file mode 100644
> index 0000000000..03fac84f51
> --- /dev/null
> +++ b/board/qualcomm/sa8155p-adp/MAINTAINERS
> @@ -0,0 +1,5 @@
> +Qualcomm SA8155P Automotive Development Platform
> +M: Volodymyr Babchuk <volodymyr_babchuk at epam.com>
> +S: Maintained
> +F: board/qualcomm/sa8155p-adp/
> +F: configs/sa8155p-adp_defconfig
> diff --git a/configs/sa8155p_adp_defconfig b/configs/sa8155p_adp_defconfig
> new file mode 100644
> index 0000000000..b6969767f8
> --- /dev/null
> +++ b/configs/sa8155p_adp_defconfig
> @@ -0,0 +1,35 @@
> +CONFIG_ARM=y
> +CONFIG_SKIP_LOWLEVEL_INIT=y
> +CONFIG_COUNTER_FREQUENCY=19000000
> +CONFIG_POSITION_INDEPENDENT=y
> +CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK=y
> +CONFIG_ARCH_SNAPDRAGON=y
> +CONFIG_TEXT_BASE=0x85710000
Being position independent shouldn't require a hardcoded U-Boot text
base. Can you try if we can get rid of this?
> +CONFIG_DEFAULT_DEVICE_TREE="qcom/sa8155p-adp"
> +CONFIG_IDENT_STRING="\nQualcomm SA8155P-ADP"
> +CONFIG_SYS_LOAD_ADDR=0x85710000
Ditto.
> +CONFIG_REMAKE_ELF=y
> +CONFIG_BOOTDELAY=3
> +CONFIG_SYS_CBSIZE=512
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_HUSH_PARSER=y
> +CONFIG_OF_UPSTREAM=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> +CONFIG_NET_RANDOM_ETHADDR=y
> +CONFIG_CLK=y
> +CONFIG_CLK_QCOM_SM8150=y
> +CONFIG_MSM_GPIO=y
> +CONFIG_PHY_MICREL=y
> +CONFIG_PHY_MICREL_KSZ90X1=y
> +CONFIG_DM_MDIO=y
> +CONFIG_DM_ETH_PHY=y
> +CONFIG_DWC_ETH_QOS=y
> +CONFIG_DWC_ETH_QOS_QCOM=y
> +CONFIG_PHY=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINCONF=y
> +CONFIG_PINCTRL_QCOM_SM8150=y
> +CONFIG_POWER_DOMAIN=y
> +CONFIG_MSM_GENI_SERIAL=y
> +CONFIG_SPMI_MSM=y
> +CONFIG_LMB_MAX_REGIONS=64
Apart from above, I think this platform should be able to reuse
qcom_defconfig as you can find most of the config options there. Can
you try to reuse it?
> diff --git a/doc/board/qualcomm/index.rst b/doc/board/qualcomm/index.rst
> index 4955274a39..268218b05f 100644
> --- a/doc/board/qualcomm/index.rst
> +++ b/doc/board/qualcomm/index.rst
> @@ -7,5 +7,6 @@ Qualcomm
> :maxdepth: 2
>
> dragonboard410c
> + sa8155p-adp
> board
> debugging
> diff --git a/doc/board/qualcomm/sa8155p-adp.rst b/doc/board/qualcomm/sa8155p-adp.rst
> new file mode 100644
> index 0000000000..66db512b52
> --- /dev/null
> +++ b/doc/board/qualcomm/sa8155p-adp.rst
> @@ -0,0 +1,87 @@
> +.. SPDX-License-Identifier: BSD-3-Clause
> +.. sectionauthor:: Volodymyr Babchuk <volodymyr_babchuk at epam.com>
> +
> +SA8155P Automotive Development Platform
> +=======================================
> +
> +About
> +-----
> +This document describes the information about SA8155P Automotive
> +Development Platform aka SA8155P-ADP.
> +
> +Currently U-Boot can be booted either as Android boot image, or in EL2
> +mode, instead of hypervisor image. In the latter case it is possible
> +to use U-Boot to either boot Linux with KVM support or to boot Xen
> +Hypervisor on this board.
> +
> +Supported HW modules
> +^^^^^^^^^^^^^^^^^^^^
> +Port for this board is in early development state. Right now U-Boot
> +supports serial console and networking. No USB/fastboot or UFS support
> +yet. So it is not possible to save environment variables as
> +well. Nevertheless this is enough for development as user can download
> +all required images via TFTP.
> +
> +Installation
> +------------
> +Build
> +^^^^^
> +Setup ``CROSS_COMPILE`` for aarch64 and build U-Boot for your board::
> +
> + $ export CROSS_COMPILE=<aarch64 toolchain prefix>
> + $ make sa8155p_adp_defconfig
> + $ make
> +
> +This will build ``u-boot.bin`` in the configured output directory.
> +
> +Boot in EL1 mode instead of Android boot image
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Create a dummy ramdisk image:::
> +
> + $ echo "This is not a ramdisk" > ramdisk.img
> +
> +Compress u-boot binary:::
> +
> + $ gzip -c u-boot.bin > u-boot.bin.gz
> +
> +Append DTB again (binary we use already have DTB embedded in, but
> +Android boot image format requires another DTB at the end of the
> +archive):::
> +
> + $ cat u-boot.bin.gz u-boot.dtb > u-boot.bin.gz-dtb
> +
> +Now we've got everything to build android boot image:::
> +
> + $ mkbootimg --kernel u-boot.bin.gz-dtb \
> + --ramdisk ramdisk.img --pagesize 4096 \
> + --base 0x80000000 -o boot.img
> +
> +Finally you can flash new boot image with fastboot:::
> +
> + $ fastboot flash boot boot.img
> +
> +Or just boot U-Boot without flashing anything:::
> +
> + $ fastboot boot boot.img
> +
> +Boot in EL2 mode instead of Qualcomm's hypervisor stub
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +This approach ensures that U-Boot is booted in EL2 and it is possible
> +to run virtualization software (like Xen or KVM) on the board. You
> +must understand that this approach breaks Qualcomm's boot chain. You
> +will not be able to call all subsequent loaders, so you will not be
> +able to use fastboot for example. Use this approach only if you want
> +to experiment with virtualization on SA8155P-ADP.
> +
> +U-Boot ELF file needs to be signed with test keys. `qtestsign
> +<https://github.com/msm8916-mainline/qtestsign>`_ tool can be used ::
> +
> + $ ../qtestsign/qtestsign.py -v6 hyp u-boot.elf
> +
> +Resulting ``u-boot-test-signed.mbn`` then can be written to the
> +board. Easiest way is to use ``edl`` tool: ::
> +
> + $ ../edl/edl w hyp_a u-boot-test-signed.mbn --memory=ufs --lun=4
> +
Can you provide reference to the EDL tool and its usage so that people
can recover their board if it gets bricked?
-Sumit
> +Be sure to backup existing hyp_a loader before flashing U-Boot.
> --
> 2.43.0
More information about the U-Boot
mailing list