Re: [PATCH 8/8] board: add support for Qualcomm SA8155P-ADP board

2024-03-04 Thread Volodymyr Babchuk


Hi Stephan,

Stephan Gerhold  writes:

[...]
>> +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.
>> +
>> +We need to create ELF file from the u-boot binary. We can't use
>> +existing U-Boot ELF, because it does not include appended DTB
>> +file. Easiest way to do this is to use ``create_elf.py`` from the
>> +following repository: `qtestsign(lorc)
>> +> [github[.]com]>`_: ::
>> +
>> +$ python ../qtestsign/create_elf.py u-boot.bin 0x8571 u-boot.mbn
>> +
>
> Have you tried using CONFIG_REMAKE_ELF in U-Boot? That should
> effectively do the same (build a new ELF based on u-boot.bin with the
> appended device tree). The Qualcomm DragonBoard 410c port is using that
> option to solve the same problem.

I didn't knew that there is a such option. Looks like this is exactly
what I need, thank you. I'll include this in the V2.

> But I'm glad to see that the ELF abstractions in qtestsign worked well
> for your purpose. :-)

Well, I was surprised that pyelf can parse ELF files but can't modify
them. So your tool come in handy. I was going to make a PR that adds
this create_elf.py script, but looks like we don't need it.

-- 
WBR, Volodymyr

Re: [PATCH 8/8] board: add support for Qualcomm SA8155P-ADP board

2024-03-04 Thread Stephan Gerhold
On Thu, Feb 29, 2024 at 02:21:09PM +, Volodymyr Babchuk 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 
> 
> ---
> 
>  arch/arm/dts/sa8155p-adp-u-boot.dtsi | 30 
>  arch/arm/mach-snapdragon/Kconfig | 14 
>  arch/arm/mach-snapdragon/Makefile|  2 +
>  arch/arm/mach-snapdragon/init_sa8155p.c  | 30 
>  arch/arm/mach-snapdragon/sysmap-sm8150.c | 31 
>  board/qualcomm/sa8155p-adp/Kconfig   | 12 +++
>  board/qualcomm/sa8155p-adp/MAINTAINERS   |  6 ++
>  configs/sa8155p_adp_defconfig| 33 +
>  doc/board/qualcomm/index.rst |  1 +
>  doc/board/qualcomm/sa8155p-adp.rst   | 94 
>  include/configs/sa8155p_adp.h| 25 +++
>  11 files changed, 278 insertions(+)
>  create mode 100644 arch/arm/dts/sa8155p-adp-u-boot.dtsi
>  create mode 100644 arch/arm/mach-snapdragon/init_sa8155p.c
>  create mode 100644 arch/arm/mach-snapdragon/sysmap-sm8150.c
>  create mode 100644 board/qualcomm/sa8155p-adp/Kconfig
>  create mode 100644 board/qualcomm/sa8155p-adp/MAINTAINERS
>  create mode 100644 configs/sa8155p_adp_defconfig
>  create mode 100644 doc/board/qualcomm/sa8155p-adp.rst
>  create mode 100644 include/configs/sa8155p_adp.h
> 
> [...]
> diff --git a/doc/board/qualcomm/sa8155p-adp.rst 
> b/doc/board/qualcomm/sa8155p-adp.rst
> new file mode 100644
> index 00..cff68cd55f
> --- /dev/null
> +++ b/doc/board/qualcomm/sa8155p-adp.rst
> @@ -0,0 +1,94 @@
> +.. SPDX-License-Identifier: BSD-3-Clause
> +.. sectionauthor:: Volodymyr Babchuk 
> +
> +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=
> + $ 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 0x8000 -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.
> +
> +We need to create ELF file from the u-boot binary. We can't use
> +existing U-Boot ELF, because it does not include appended DTB
> +file. Easiest way to do this is to use ``create_elf.py`` from the
> +following repository: `qtestsign(lorc)
> +`_: ::
> +
> + $ python ../qtestsign/create_elf.py u-b