[PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default
When trying to build the imx8mm-cl-iot-gate_defconfig target there is a build error due to the missing 'fip.bin'.
To make the build process more consistent with other i.MX8M boards, do not build fip.bin by default.
Signed-off-by: Fabio Estevam festevam@denx.de --- arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi index 3226a244a97e..00927c157449 100644 --- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi @@ -217,18 +217,6 @@ }; };
- fip { - description = "Trusted Firmware FIP"; - type = "firmware"; - arch = "arm64"; - compression = "none"; - load = <0x40310000>; - - fip_blob: blob-ext{ - filename = "fip.bin"; - }; - }; - fdt { description = "NAME"; type = "flat_dt"; @@ -246,7 +234,7 @@ conf { description = "NAME"; firmware = "uboot"; - loadables = "atf", "fip"; + loadables = "atf"; fdt = "fdt"; }; };
Add documentation for building and flashing mainline U-Boot in the IOT-GATE-iMX8 board.
Signed-off-by: Fabio Estevam festevam@denx.de --- doc/board/compulab/imx8mm-cl-iot-gate.rst | 84 +++++++++++++++++++++++ doc/board/index.rst | 1 + 2 files changed, 85 insertions(+) create mode 100644 doc/board/compulab/imx8mm-cl-iot-gate.rst
diff --git a/doc/board/compulab/imx8mm-cl-iot-gate.rst b/doc/board/compulab/imx8mm-cl-iot-gate.rst new file mode 100644 index 000000000000..b63b8d61f13f --- /dev/null +++ b/doc/board/compulab/imx8mm-cl-iot-gate.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +IOT-GATE-iMX8 +============= + +U-Boot for Compulab i.MX8MM IoT Gateway board. + +Quick Start +----------- + +- Build the ARM Trusted firmware binary +- Get the DDR firmwares +- Build U-Boot +- Flash U-Boot into the eMMC + +Get and build the ARM Trusted firmware +-------------------------------------- + +Note: builddir is U-Boot build directory (source directory for in-tree builds). + +Get mainline ATF: + +.. code-block:: bash + + $ git clone https://github.com/ARM-software/arm-trusted-firmware.git + $ cd arm-trusted-firmware + $ git checkout v2.5 + +Generate the bl31.bin ATF binary: + +.. code-block:: bash + + $ export CROSS_COMPILE=aarch64-poky-linux- + $ make PLAT=imx8mm IMX_BOOT_UART_BASE=0x30880000 bl31 + $ cp build/imx8mm/release/bl31.bin $(builddir) + +Get the DDR firmwares +--------------------- + +.. code-block:: bash + + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin + $ chmod +x firmware-imx-8.9.bin + $ ./firmware-imx-8.9 + $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir) + +Build U-Boot +------------ + +.. code-block:: bash + + $ export CROSS_COMPILE=aarch64-poky-linux- + $ make imx8mm-cl-iot-gate_defconfig + $ export ATF_LOAD_ADDR=0x920000 + $ make + +This will result in two binaries: flash.bin and u-boot.itb. + +Flash U-Boot into the eMMC +-------------------------- + +Make sure to have access to the IOTG-ACC-M2SD adapter to recover +the board in case something goes wrong. More details at: +https://mediawiki.compulab.com/w/index.php?title=IOT-GATE-iMX8_and_SBC-IOT-i... + +The flash.bin and u-boot.itb binaries need to be flashed into the eMMC at +offset 33K and 384K, respectively. + +These binaries can be transferred from the host PC to the board running +U-Boot via TFTP: + +.. code-block:: bash + + => mmc dev 2 + => mmc partconf 2 1 7 0 (This is only needed to be done for the first time) + + => tftp $loadaddr flash.bin + => setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200 + => mmc write $loadaddr 0x42 $blkcnt + + => tftp $loadaddr u-boot.itb + => setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200 + => mmc write $loadaddr 0x300 $blkcnt diff --git a/doc/board/index.rst b/doc/board/index.rst index 9e9097889161..5c5420f3d75a 100644 --- a/doc/board/index.rst +++ b/doc/board/index.rst @@ -11,6 +11,7 @@ Board-specific doc AndesTech/index amlogic/index atmel/index + compulab/index congatec/index coreboot/index emulation/index
Hi Fabio,
Did you use the boot partition?
I mean, why don't we use "mmc partconf 0 0 1 0" So that we can flash u-boot to partition 1 and leave partition 0 for distro install.
The following sequence should work.
init setup 1. mmc dev 2 2. mmc partconf 0 0 1 0
flash u-boot 1. tftp ${loadaddr} flash.bin 2. setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200 3. mmc dev 2 1 4. mmc write $loadaddr 0x42 $blkcnt 5. tftp ${loadaddr} u-boot.itb 6. setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200 7. mmc dev 2 1 8. mmc write $loadaddr 0x300 $blkcnt
Yours, Paul
On Fri, 13 Aug 2021 at 08:59, Fabio Estevam festevam@denx.de wrote:
Add documentation for building and flashing mainline U-Boot in the IOT-GATE-iMX8 board.
Signed-off-by: Fabio Estevam festevam@denx.de
doc/board/compulab/imx8mm-cl-iot-gate.rst | 84 +++++++++++++++++++++++ doc/board/index.rst | 1 + 2 files changed, 85 insertions(+) create mode 100644 doc/board/compulab/imx8mm-cl-iot-gate.rst
diff --git a/doc/board/compulab/imx8mm-cl-iot-gate.rst b/doc/board/compulab/imx8mm-cl-iot-gate.rst new file mode 100644 index 000000000000..b63b8d61f13f --- /dev/null +++ b/doc/board/compulab/imx8mm-cl-iot-gate.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0+
+IOT-GATE-iMX8 +=============
+U-Boot for Compulab i.MX8MM IoT Gateway board.
+Quick Start +-----------
+- Build the ARM Trusted firmware binary +- Get the DDR firmwares +- Build U-Boot +- Flash U-Boot into the eMMC
+Get and build the ARM Trusted firmware +--------------------------------------
+Note: builddir is U-Boot build directory (source directory for in-tree builds).
+Get mainline ATF:
+.. code-block:: bash
- $ git clone https://github.com/ARM-software/arm-trusted-firmware.git
- $ cd arm-trusted-firmware
- $ git checkout v2.5
+Generate the bl31.bin ATF binary:
+.. code-block:: bash
- $ export CROSS_COMPILE=aarch64-poky-linux-
- $ make PLAT=imx8mm IMX_BOOT_UART_BASE=0x30880000 bl31
- $ cp build/imx8mm/release/bl31.bin $(builddir)
+Get the DDR firmwares +---------------------
+.. code-block:: bash
- $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.9.bin
- $ chmod +x firmware-imx-8.9.bin
- $ ./firmware-imx-8.9
- $ cp firmware-imx-8.9/firmware/ddr/synopsys/lpddr4*.bin $(builddir)
+Build U-Boot +------------
+.. code-block:: bash
- $ export CROSS_COMPILE=aarch64-poky-linux-
- $ make imx8mm-cl-iot-gate_defconfig
- $ export ATF_LOAD_ADDR=0x920000
- $ make
+This will result in two binaries: flash.bin and u-boot.itb.
+Flash U-Boot into the eMMC +--------------------------
+Make sure to have access to the IOTG-ACC-M2SD adapter to recover +the board in case something goes wrong. More details at:
https://mediawiki.compulab.com/w/index.php?title=IOT-GATE-iMX8_and_SBC-IOT-i...
+The flash.bin and u-boot.itb binaries need to be flashed into the eMMC at +offset 33K and 384K, respectively.
+These binaries can be transferred from the host PC to the board running +U-Boot via TFTP:
+.. code-block:: bash
- => mmc dev 2
- => mmc partconf 2 1 7 0 (This is only needed to be done for the first
time)
- => tftp $loadaddr flash.bin
- => setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200
- => mmc write $loadaddr 0x42 $blkcnt
- => tftp $loadaddr u-boot.itb
- => setexpr blkcnt $filesize + 0x1ff && setexpr blkcnt $blkcnt / 0x200
- => mmc write $loadaddr 0x300 $blkcnt
diff --git a/doc/board/index.rst b/doc/board/index.rst index 9e9097889161..5c5420f3d75a 100644 --- a/doc/board/index.rst +++ b/doc/board/index.rst @@ -11,6 +11,7 @@ Board-specific doc AndesTech/index amlogic/index atmel/index
- compulab/index congatec/index coreboot/index emulation/index
-- 2.25.1
Hi Fabio,
Can we think of a way to keep this fip.bin feature? This is part of the SystemReady IR certificate for this Compulab board. [1]
[1] https://developer.arm.com/architectures/system-architectures/arm-systemready...
Yours, Paul
On Fri, 13 Aug 2021 at 08:59, Fabio Estevam festevam@denx.de wrote:
When trying to build the imx8mm-cl-iot-gate_defconfig target there is a build error due to the missing 'fip.bin'.
To make the build process more consistent with other i.MX8M boards, do not build fip.bin by default.
Signed-off-by: Fabio Estevam festevam@denx.de
arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi | 14 +------------- 1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi index 3226a244a97e..00927c157449 100644 --- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi +++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi @@ -217,18 +217,6 @@ }; };
fip {description = "Trusted FirmwareFIP";
type = "firmware";arch = "arm64";compression = "none";load = <0x40310000>;fip_blob: blob-ext{filename = "fip.bin";};};fdt { description = "NAME"; type = "flat_dt";@@ -246,7 +234,7 @@ conf { description = "NAME"; firmware = "uboot";
loadables = "atf", "fip";
loadables = "atf"; fdt = "fdt"; }; };-- 2.25.1
Hi Paul,
On 13/08/2021 06:59, Paul Liu wrote:
Hi Fabio,
Can we think of a way to keep this fip.bin feature? This is part of the SystemReady IR certificate for this Compulab board. [1]
[1] https://developer.arm.com/architectures/system-architectures/arm-systemready...
i.MX8MM EVK is also listed there and we don't use fip.bin on this platform (and not on any other i.MX8MM platform in mainline U-Boot).
If you really want to use fip.bin, could you please let me know the exact build procedure for AT-F? Do you use mainline ATF?
As a user of the IOT-GATE-iMX8, I would just like to be able to flash mainline U-Boot and move forward. Even better if I could use the same procedure that has been used on other i.MX8MM boards.
Regards,
Fabio Estevam
Hi Fabio,
No. I think they actually use fip.bin but just not upstreamed yet. Please see the "Firmware version" in the list. For Compulab we are using mainline U-boot. But for imx8mm-evk it is NXP released firmware.
And yes we do use mainline ATF and mainline OPTEE. I'll explain how to build all of them.
# OPTEE
1. export ARCH=arm 2. export CROSS_COMPILE=arm-linux-gnueabihf- 3. export CROSS_COMPILE64=aarch64-linux-gnu- 4. make PLATFORM=imx PLATFORM_FLAVOR=mx8mm_cl_iot_gate O=build.mx8mmevk \ CFG_TEE_CORE_LOG_LEVEL=2 \ CFG_TEE_TA_LOG_LEVEL=2 \ CFG_TEE_CORE_DEBUG=y \ CFG_EXTERNAL_DTB_OVERLAY=y \ CFG_DT=y \ CFG_DT_ADDR=0x52000000 \ CFG_DEBUG_INFO=y
And we got tee-header_v2.bin tee-pager_v2.bin and tee-pageable_v2.bin. These files will be used in the TF-A stage.
Then we start building U-boot (BL31).
# U-boot (BL31)
1. export ARCH=arm64 2. export CROSS_COMPILE=aarch64-linux-gnu- 3. export ATF_LOAD_ADDR=0x920000 4. make O=/tmp/uboot-imx8 imx8mm-cl-iot-gate_defconfig 5. make O=/tmp/uboot-imx8
We got u-boot.bin at this stage. u-boot.bin is needed for the next stage.
# TF-A
make ARCH=aarch64 CROSS_COMPILE=aarch64-linux-gnu- PLAT=imx8mm \ SPD=opteed BL32_BASE=0x7e000000 IMX_BOOT_UART_BASE=0x30880000 \ NEED_BL32=yes NEED_BL33=yes NEED_BL2=yes \ LOG_LEVEL=50 \ USE_TBBR_DEFS=1 GENERATE_COT=1 TRUSTED_BOARD_BOOT=1 \ MBEDTLS_DIR=../mbedtls \ BL32=../optee_os/build.mx8mmevk/core/tee-header_v2.bin \ BL32_EXTRA1=../optee_os/build.mx8mmevk/core/tee-pager_v2.bin \ BL32_EXTRA2=../optee_os/build.mx8mmevk/core/tee-pageable_v2.bin \ BL33=/tmp/uboot-imx8/u-boot.bin BL2_CFLAGS=-DIMX8M_FIP_MMAP \ fip bl2 bl31
Now we have bl2.bin and fip.bin in build/imx8mm/release for the next stage.
# U-boot (generate flash.bin and u-boot.itb)
1. export NXP_FIRMWARE=firmware-imx-8.8.bin 2. wget -c http://www.freescale.com/lgfiles/NMG/MAD/YOCTO/$%7BNXP_FIRMWARE%7D 3. bash -x ${NXP_FIRMWARE} --auto-accept 4. cp -v $(find firmware* | awk '/train|hdmi_imx8|dp_imx8/' ORS=" ") /tmp/uboot-imx8 5. cp -v ../trusted-firmware-a/build/imx8mm/release/bl2.bin /tmp/uboot-imx8/bl31.bin 6. cp -v ../trusted-firmware-a/build/imx8mm/release/fip.bin /tmp/uboox-imx8/fip.bin 7. export ARCH=arm64 8. export CROSS_COMPILE=aarch64-linux-gnu- 9. export ATF_LOAD_ADDR=0x920000 10. make O=/tmp/uboot-imx8
So now it shouldn't complain about missing images.
Yours, Paul
On Fri, 13 Aug 2021 at 20:15, Fabio Estevam festevam@denx.de wrote:
Hi Paul,
On 13/08/2021 06:59, Paul Liu wrote:
Hi Fabio,
Can we think of a way to keep this fip.bin feature? This is part of the SystemReady IR certificate for this Compulab board. [1]
[1]
https://developer.arm.com/architectures/system-architectures/arm-systemready...
i.MX8MM EVK is also listed there and we don't use fip.bin on this platform (and not on any other i.MX8MM platform in mainline U-Boot).
If you really want to use fip.bin, could you please let me know the exact build procedure for AT-F? Do you use mainline ATF?
As a user of the IOT-GATE-iMX8, I would just like to be able to flash mainline U-Boot and move forward. Even better if I could use the same procedure that has been used on other i.MX8MM boards.
Regards,
Fabio Estevam
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-60 Fax: (+49)-8142-66989-80 Email: festevam@denx.de
Hi Paul,
On Sun, Aug 15, 2021 at 4:27 PM Paul Liu paul.liu@linaro.org wrote:
No. I think they actually use fip.bin but just not upstreamed yet. Please see the "Firmware version" in the list. For Compulab we are using mainline U-boot. But for imx8mm-evk it is NXP released firmware.
And yes we do use mainline ATF and mainline OPTEE. I'll explain how to build all of them.
# OPTEE
- export ARCH=arm
- export CROSS_COMPILE=arm-linux-gnueabihf-
- export CROSS_COMPILE64=aarch64-linux-gnu-
- make PLATFORM=imx PLATFORM_FLAVOR=mx8mm_cl_iot_gate O=build.mx8mmevk \ CFG_TEE_CORE_LOG_LEVEL=2 \ CFG_TEE_TA_LOG_LEVEL=2 \ CFG_TEE_CORE_DEBUG=y \ CFG_EXTERNAL_DTB_OVERLAY=y \ CFG_DT=y \ CFG_DT_ADDR=0x52000000 \ CFG_DEBUG_INFO=y
And we got tee-header_v2.bin tee-pager_v2.bin and tee-pageable_v2.bin. These files will be used in the TF-A stage.
Then we start building U-boot (BL31).
# U-boot (BL31)
- export ARCH=arm64
- export CROSS_COMPILE=aarch64-linux-gnu-
- export ATF_LOAD_ADDR=0x920000
- make O=/tmp/uboot-imx8 imx8mm-cl-iot-gate_defconfig
- make O=/tmp/uboot-imx8
We got u-boot.bin at this stage. u-boot.bin is needed for the next stage.
# TF-A
make ARCH=aarch64 CROSS_COMPILE=aarch64-linux-gnu- PLAT=imx8mm \ SPD=opteed BL32_BASE=0x7e000000 IMX_BOOT_UART_BASE=0x30880000 \ NEED_BL32=yes NEED_BL33=yes NEED_BL2=yes \ LOG_LEVEL=50 \ USE_TBBR_DEFS=1 GENERATE_COT=1 TRUSTED_BOARD_BOOT=1 \ MBEDTLS_DIR=../mbedtls \ BL32=../optee_os/build.mx8mmevk/core/tee-header_v2.bin \ BL32_EXTRA1=../optee_os/build.mx8mmevk/core/tee-pager_v2.bin \ BL32_EXTRA2=../optee_os/build.mx8mmevk/core/tee-pageable_v2.bin \ BL33=/tmp/uboot-imx8/u-boot.bin BL2_CFLAGS=-DIMX8M_FIP_MMAP \ fip bl2 bl31
Sorry, but I found this overly complicated.
Makefile:1112: warning: overriding recipe for target '/home/fabio/arm-trusted-firmware/build/imx8mm/release/lib' plat/imx/imx8m/imx8mm/platform.mk:114: warning: ignoring old recipe for target '/home/fabio/arm-trusted-firmware/build/imx8mm/release/lib' Makefile:1112: warning: overriding recipe for target '/home/fabio/arm-trusted-firmware/build/imx8mm/release/romlib' plat/imx/imx8m/imx8mm/platform.mk:114: warning: ignoring old recipe for target '/home/fabio/arm-trusted-firmware/build/imx8mm/release/romlib' Makefile:1112: warning: overriding recipe for target '/home/fabio/arm-trusted-firmware/build/imx8mm/release/libwrapper' plat/imx/imx8m/imx8mm/platform.mk:114: warning: ignoring old recipe for target '/home/fabio/arm-trusted-firmware/build/imx8mm/release/libwrapper' CC services/spd/opteed/opteed_common.c CC services/spd/opteed/opteed_main.c CC services/spd/opteed/opteed_pm.c AS services/spd/opteed/opteed_helpers.S CC /home/fabio/mbedtls/library/aes.c In file included from include/drivers/auth/mbedtls/mbedtls_config.h:114, from /home/fabio/mbedtls/include/mbedtls/build_info.h:59, from /home/fabio/mbedtls/library/common.h:26, from /home/fabio/mbedtls/library/aes.c:26: /home/fabio/mbedtls/include/mbedtls/check_config.h:593:2: error: #error "MBEDTLS_SHA256_C defined without MBEDTLS_SHA224_C" 593 | #error "MBEDTLS_SHA256_C defined without MBEDTLS_SHA224_C"
What about having two defconfigs for this board?
imx8mm-cl-iot-gate_defconfig for the regular users. This one can be simply be built by following the README I wrote and it matches the way used on other i.MX8MM boards.
imx8mm-cl-iot-gate_optee_defconfig for the users that want to use fip/optee, etc?
Would you agree with such an approach?
Thanks,
Fabio Estevam
On Mon, Aug 16, 2021 at 06:09:34PM -0300, Fabio Estevam wrote:
Hi Paul,
On Sun, Aug 15, 2021 at 4:27 PM Paul Liu paul.liu@linaro.org wrote:
No. I think they actually use fip.bin but just not upstreamed yet. Please see the "Firmware version" in the list. For Compulab we are using mainline U-boot. But for imx8mm-evk it is NXP released firmware.
And yes we do use mainline ATF and mainline OPTEE. I'll explain how to build all of them.
# OPTEE
- export ARCH=arm
- export CROSS_COMPILE=arm-linux-gnueabihf-
- export CROSS_COMPILE64=aarch64-linux-gnu-
- make PLATFORM=imx PLATFORM_FLAVOR=mx8mm_cl_iot_gate O=build.mx8mmevk \ CFG_TEE_CORE_LOG_LEVEL=2 \ CFG_TEE_TA_LOG_LEVEL=2 \ CFG_TEE_CORE_DEBUG=y \ CFG_EXTERNAL_DTB_OVERLAY=y \ CFG_DT=y \ CFG_DT_ADDR=0x52000000 \ CFG_DEBUG_INFO=y
And we got tee-header_v2.bin tee-pager_v2.bin and tee-pageable_v2.bin. These files will be used in the TF-A stage.
Then we start building U-boot (BL31).
# U-boot (BL31)
- export ARCH=arm64
This is actively wrong and breaks building U-Boot in some cases. You do not ever need to set ARCH in the environment, and setting it to the wrong one (it would be arm, not arm64) causes invalid symlinks to be made in some cases. I see that, sigh, this mistake has made it in to the docs twice, again.
Hi Paul,
On Mon, Aug 16, 2021 at 6:09 PM Fabio Estevam festevam@gmail.com wrote:
What about having two defconfigs for this board?
imx8mm-cl-iot-gate_defconfig for the regular users. This one can be simply be built by following the README I wrote and it matches the way used on other i.MX8MM boards.
imx8mm-cl-iot-gate_optee_defconfig for the users that want to use fip/optee, etc?
Would you agree with such an approach?
Here is my proposal: https://pastebin.com/raw/PGKZvCGR
If you are happy with this, I can submit it formally.
Thanks
Hi Fabio,
It looks good to me. Thanks a lot.
BTW. mbedtls version might not always work. In my local directory the mbedtls commit is bd21b18a1faa08705ac6d9980794c181e645f53a. Which is a commit in the development branch.
Based on Tom's correction I'll write more detailed steps.
Yours, Paul
On Tue, 17 Aug 2021 at 06:41, Fabio Estevam festevam@gmail.com wrote:
Hi Paul,
On Mon, Aug 16, 2021 at 6:09 PM Fabio Estevam festevam@gmail.com wrote:
What about having two defconfigs for this board?
imx8mm-cl-iot-gate_defconfig for the regular users. This one can be simply be built by following the README I wrote and it matches the way used on other i.MX8MM boards.
imx8mm-cl-iot-gate_optee_defconfig for the users that want to use fip/optee, etc?
Would you agree with such an approach?
Here is my proposal: https://pastebin.com/raw/PGKZvCGR
If you are happy with this, I can submit it formally.
Thanks
Hi Paul,
On Mon, Aug 16, 2021 at 9:50 PM Paul Liu paul.liu@linaro.org wrote:
Hi Fabio,
It looks good to me. Thanks a lot.
I have sent a v2 with such a proposal.
I would appreciate it if you could review and test booting the two defconfigs.
Thanks,
Fabio Estevam
Hi Fabio,
Can I know your Compulab's hardware PN? Something like "IOTG-IMX8-D2-NA16-WB-FATPM".
Yours, Paul
On Wed, 18 Aug 2021 at 02:32, Fabio Estevam festevam@gmail.com wrote:
Hi Paul,
On Mon, Aug 16, 2021 at 9:50 PM Paul Liu paul.liu@linaro.org wrote:
Hi Fabio,
It looks good to me. Thanks a lot.
I have sent a v2 with such a proposal.
I would appreciate it if you could review and test booting the two defconfigs.
Thanks,
Fabio Estevam
Hi Paul,
On Tue, Aug 17, 2021 at 9:09 PM Paul Liu paul.liu@linaro.org wrote:
Hi Fabio,
Can I know your Compulab's hardware PN? Something like "IOTG-IMX8-D2-NA16-WB-FATPM".
I only have remote access to the board, so I can't tell you the part number at the moment.
Anything in particular that you are concerned about?
Thanks,
Fabio Estevam
Hi Fabio,
I got several boards. With all different PN. But all of them are 2GB memory. And the recent master doesn't boot on one of my board. I haven't tried all of the combinations. After bisect, I found commit e27bddff breaks the boot. It just hang there.
But if I change PHYS_SDRAM_SIZE to 1GB then it can boot. However this is not the solution because it limits the memory usage. So I might need to take some time look into what happened and spend more time to test on other PN. Before start testing your patches. And because you can boot the master branch fine so I'm not sure what happened on my side.
Yours, Paul
On Wed, 18 Aug 2021 at 20:24, Fabio Estevam festevam@gmail.com wrote:
Hi Paul,
On Tue, Aug 17, 2021 at 9:09 PM Paul Liu paul.liu@linaro.org wrote:
Hi Fabio,
Can I know your Compulab's hardware PN? Something like "IOTG-IMX8-D2-NA16-WB-FATPM".
I only have remote access to the board, so I can't tell you the part number at the moment.
Anything in particular that you are concerned about?
Thanks,
Fabio Estevam
Hi Paul,
On Wed, Aug 18, 2021 at 6:32 PM Paul Liu paul.liu@linaro.org wrote:
Hi Fabio,
I got several boards. With all different PN. But all of them are 2GB memory. And the recent master doesn't boot on one of my board. I haven't tried all of the combinations.
With the U-Boot from Compulab, it reports 4GB. With mainline U-Boot it reports 2GB, so yes, there is an issue indeed.
However, I don't see a hang.
After bisect, I found commit e27bddff breaks the boot. It just hang there.
Adding Frieder as the author of the patch.
But if I change PHYS_SDRAM_SIZE to 1GB then it can boot. However this is not the solution because it limits the memory usage. So I might need to take some time look into what happened and spend more time to test on other PN. Before start testing your patches. And because you can boot the master branch fine so I'm not sure what happened on my side.
Yes, please fix the memory issue first. Thanks!
[Adding Marek]
On Wed, Aug 18, 2021 at 6:39 PM Fabio Estevam festevam@gmail.com wrote:
Hi Paul,
On Wed, Aug 18, 2021 at 6:32 PM Paul Liu paul.liu@linaro.org wrote:
Hi Fabio,
I got several boards. With all different PN. But all of them are 2GB memory. And the recent master doesn't boot on one of my board. I haven't tried all of the combinations.
With the U-Boot from Compulab, it reports 4GB. With mainline U-Boot it reports 2GB, so yes, there is an issue indeed.
However, I don't see a hang.
After bisect, I found commit e27bddff breaks the boot. It just hang there.
Adding Frieder as the author of the patch.
Marek objected to this change, which is now: e27bdd ff4b97 ("imx8m: Restrict usable memory to space below 4G boundary")
As this causes a regression on Paul's i.MX8MM IoT Gateway board, should this be reverted?
On 19.08.21 02:27, Fabio Estevam wrote:
[Adding Marek]
On Wed, Aug 18, 2021 at 6:39 PM Fabio Estevam festevam@gmail.com wrote:
Hi Paul,
On Wed, Aug 18, 2021 at 6:32 PM Paul Liu paul.liu@linaro.org wrote:
Hi Fabio,
I got several boards. With all different PN. But all of them are 2GB memory. And the recent master doesn't boot on one of my board. I haven't tried all of the combinations.
With the U-Boot from Compulab, it reports 4GB. With mainline U-Boot it reports 2GB, so yes, there is an issue indeed.
However, I don't see a hang.
After bisect, I found commit e27bddff breaks the boot. It just hang there.
Adding Frieder as the author of the patch.
Marek objected to this change, which is now: e27bdd ff4b97 ("imx8m: Restrict usable memory to space below 4G boundary")
Yes, Marek objected and it was still pulled in for some reason.
As this causes a regression on Paul's i.MX8MM IoT Gateway board, should this be reverted?
Maybe, yes. I'll leave that decision to the maintainers.
For the failure: The change in e27bddff4b97 assumes that gd->ram_size was set during initialization/detection of the DDR. Could it be that the Compulab board doesn't do this and gd->ram_size is 0 or differs from the actual DDR size? That would probably cause some kind of issue.
Paul, maybe you could check if gd->ram_size is set properly. Other boards do this by implementing board_phys_sdram_size() [1], which also makes sure that the memory map is updated with the detected size in dram_init() [2].
[1] https://elixir.bootlin.com/u-boot/latest/source/board/gateworks/venice/imx8m... [2] https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-imx/imx8m/soc....
Hi Frieder,
I'll confirm it. But I guess you are correct. I'll send a patch soon when I implement this right.
Yours, Paul
On Thu, 19 Aug 2021 at 15:14, Frieder Schrempf frieder.schrempf@kontron.de wrote:
On 19.08.21 02:27, Fabio Estevam wrote:
[Adding Marek]
On Wed, Aug 18, 2021 at 6:39 PM Fabio Estevam festevam@gmail.com
wrote:
Hi Paul,
On Wed, Aug 18, 2021 at 6:32 PM Paul Liu paul.liu@linaro.org wrote:
Hi Fabio,
I got several boards. With all different PN. But all of them are 2GB
memory. And the recent master doesn't boot on one of my board. I haven't tried all of the combinations.
With the U-Boot from Compulab, it reports 4GB. With mainline U-Boot it reports 2GB, so yes, there is an issue indeed.
However, I don't see a hang.
After bisect, I found commit e27bddff breaks the boot. It just hang
there.
Adding Frieder as the author of the patch.
Marek objected to this change, which is now: e27bdd ff4b97 ("imx8m: Restrict usable memory to space below 4G
boundary")
Yes, Marek objected and it was still pulled in for some reason.
As this causes a regression on Paul's i.MX8MM IoT Gateway board, should this be reverted?
Maybe, yes. I'll leave that decision to the maintainers.
For the failure: The change in e27bddff4b97 assumes that gd->ram_size was set during initialization/detection of the DDR. Could it be that the Compulab board doesn't do this and gd->ram_size is 0 or differs from the actual DDR size? That would probably cause some kind of issue.
Paul, maybe you could check if gd->ram_size is set properly. Other boards do this by implementing board_phys_sdram_size() [1], which also makes sure that the memory map is updated with the detected size in dram_init() [2].
[1] https://elixir.bootlin.com/u-boot/latest/source/board/gateworks/venice/imx8m... [2] https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-imx/imx8m/soc....
Hi Frieder,
I think I might have found a reason. The problem might be that the board_get_usable_ram_top() doesn't subtract the memory used by optee. Optee on imx8m uses the end of the memory. It is passed by arguments. VERBOSE: Argument #1 = 0x7e000000 VERBOSE: Argument #2 = 0x2000000
So if I extract 0x80000000 by 0x2000000 then the board boots. That also explains why Fabio can boot his board because he doesn't use OPTEE.
What I'm doing is I implemented a board_phys_sdram_size(). However because all of my boards are 2G memory. And I did set PHYS_SDRAM_SIZE to 2G when upstreaming Compulab's support previously. That means with or without board_phys_sdram_size() the board just doesn't boot on the master branch because the gd->ram_size is the same, 2GB. But you are correct, we do need to have board_phys_sdram_size() implemented because on Compulab's page we know that they have multiple choices. The memory could be 1G/2G/4G. So this function is needed to tell how much memory we have. But the hang problem is just not related to this function. The problem I think is we need to deal with rom_pointer that contains the OPTEE address in board_get_usable_ram_top().
Yours, Paul
On Fri, 20 Aug 2021 at 04:51, Paul Liu paul.liu@linaro.org wrote:
Hi Frieder,
I'll confirm it. But I guess you are correct. I'll send a patch soon when I implement this right.
Yours, Paul
On Thu, 19 Aug 2021 at 15:14, Frieder Schrempf < frieder.schrempf@kontron.de> wrote:
On 19.08.21 02:27, Fabio Estevam wrote:
[Adding Marek]
On Wed, Aug 18, 2021 at 6:39 PM Fabio Estevam festevam@gmail.com
wrote:
Hi Paul,
On Wed, Aug 18, 2021 at 6:32 PM Paul Liu paul.liu@linaro.org wrote:
Hi Fabio,
I got several boards. With all different PN. But all of them are 2GB
memory. And the recent master doesn't boot on one of my board. I haven't tried all of the combinations.
With the U-Boot from Compulab, it reports 4GB. With mainline U-Boot it reports 2GB, so yes, there is an issue indeed.
However, I don't see a hang.
After bisect, I found commit e27bddff breaks the boot. It just hang
there.
Adding Frieder as the author of the patch.
Marek objected to this change, which is now: e27bdd ff4b97 ("imx8m: Restrict usable memory to space below 4G
boundary")
Yes, Marek objected and it was still pulled in for some reason.
As this causes a regression on Paul's i.MX8MM IoT Gateway board, should this be reverted?
Maybe, yes. I'll leave that decision to the maintainers.
For the failure: The change in e27bddff4b97 assumes that gd->ram_size was set during initialization/detection of the DDR. Could it be that the Compulab board doesn't do this and gd->ram_size is 0 or differs from the actual DDR size? That would probably cause some kind of issue.
Paul, maybe you could check if gd->ram_size is set properly. Other boards do this by implementing board_phys_sdram_size() [1], which also makes sure that the memory map is updated with the detected size in dram_init() [2].
[1] https://elixir.bootlin.com/u-boot/latest/source/board/gateworks/venice/imx8m... [2] https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-imx/imx8m/soc....
participants (5)
-
Fabio Estevam -
Fabio Estevam -
Frieder Schrempf -
Paul Liu -
Tom Rini