This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] PROCESSOR-SDK-J784S4:tiboo3.bin 未在 Yocto 构建内重新编译

Guru**** 2473270 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1461809/processor-sdk-j784s4-tiboo3-bin-not-recompiled-inside-yocto-build

器件型号:PROCESSOR-SDK-J784S4

工具与软件:

大家好!

我们目前正在为基于 J784S4的定制电路板准备 SDK 10.0、感谢您指导重新编译 Yocto 构建系统中的所有 SPL 引导加载程序。

目前、只有引导加载程序的 A72部分(即、 tispl.binu-boot.img)已再生。 但是、我们还需要重新生成 R5部分tiboot3.bin()。

我们知道可以选择在 Yocto 外部使用构建 U-Boot  make-uboot但是、出于部署目的、完全在 Yocto 中执行此操作将是有益的。

我们已经尝试执行 论坛链接中提到的命令:  

# Clean tiboot3*.bin in SDK v9.x  
$ MACHINE=am62xx-evm bitbake -c clean mc:k3r5:u-boot  

# Build and deploy tiboot3*.bin in SDK v9.x  
$ MACHINE=am62xx-evm bitbake [-f] -c deploy mc:k3r5:u-boot  

命令执行成功后、不会tiboot3.bin生成新文件。 相反、部署文件夹似乎包含文件的预构建版本。

您能否提供任何更新、更正或资源来帮助我们tiboot3.bin在 Yocto 中正确重新生成?

感谢您的帮助!

此致、
Dušan μ A

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、 Dušan

    您如何编辑 tiboot3.bin 的源文件?

    文件的预编译版本有多旧? 它不仅仅是 tiboot3.bin 的缓存版本?

    此致!
    Jared

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jared:

    我们主要致力于编辑 DTS 文件和修改j784s4_evm_a72_defconfig U-Boot 的内核配置(例如)。 这些更新通过通过 bbappend 文件添加的增补程序来应用。

    关于tiboot3.bin、我怀疑部署文件夹中的版本与初始 Yocto 映像构建(在12月)期间生成的版本相同。 从那时起、我已多次重新构建 U-Boot、但仅tispl.binu-boot.img反映了在 Yocto 中所做的更改。

    我还测试了结合tiboot3.bin(在 Yocto 之外tispl.binu-boot.img构建)与 Yocto 的结合以及从 Yocto 构建的结合。 不幸的是、此设置停止在上tispl.bin。 目前、唯一的功能配置是使用tiboot3.bintispl.binu-boot.img完全在 Yocto 外部生成的所有引导加载程序文件(、和)。

    您能建议如何确保tiboot3.bin正确地重新生成并与 Yocto 中所做的更改对齐吗?

    此致、
    Dušan μ A

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、 Dušan

    如果您仅编辑 a72文件、则 Yocto 没有理由重新编译 tiboot3.bin、因为没有任何更改。 您将需要编辑 R5文件。

    此致!
    Jared

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    尊敬的 Jared:

    感谢您的答复。

    我们已经编辑了以下包含与 USB 相关的更改的 DTS 文件、我们认为这些文件与 R5内核相关、并会影响 tiboot3.bin:

    • arch/arm/dts/k3-j784s4-r5-evm.dts
    • arch/arm/dts/k3-j784s4-r5.dtsi

    我在前面没有提到、但我们使用 DFU 引导模式进行调试。 当我尝试将tiboot3.bin初始版本 Yocto 加载到 RAM 中时、DFU 过程会立即断开连接。 但是、当我使用在 Yocto 之外生成的所有三个引导加载程序二进制文件时、DFU 过程运行良好。

    通过这一点、我可以推断出 Yocto 内置的 R5引导加载程序在某种程度上不同。

    此致、
    Dušan μ A

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、 Dušan

    我刚刚对我的个人设置进行了测试、以查看我的 tiboot3.bin 是否正在重建。 我在 deploy-ti 目录中的原始文件是从12月19日起、但编辑 DTS 后、新的 tiboot3.bin 从今天开始。

    我如何编辑 DTS:

    $ MACHINE=j784s4-evm devtool modify u-boot
    $ vi workspace/sources/u-boot-ti-staging/arch/arm/dts/k3-j784s4-r5-evm.dts
    # added a comment to the dts
    $ MACHINE=j784s4-evm bitbake -c deploy mc:k3r5:u-boot

    tiboot3.bin 肯定会更新。 您是否能够在您的终端验证这些步骤是否有效?

    此致!
    Jared

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jared:

    正确;上面提到的步骤可以重新编译 R5引导加载程序。 但是、我发现了一些异常行为。

    似乎只有通过做出的更改才devtool会触发mc:k3r5:u-boot Yocto 方法重新构建。 当我使用应用更改时 devtool、它正确应用了所有修补程序并成功重建tiboot3.bin。 但是、当我在.bbappend 文件中添加另一个补丁来修改 R5引导加载程序(特别是在中k3-j784s4-r5-evm.dts)时、tiboot3.bin未重建。 有趣的是、直接在通过devtool触发重建而下载的源代码中添加注释行。

    这让我认为、.bbappend 中作为补丁应用的更改不会触发相应mc:k3r5:u-boot方法(我认为不应该是这样)、而是仅影响 U-Boot 的 A72引导加载程序部分。

    您是否对导致此问题的原因有任何见解? 请注意、虽然devtool工作正常、但不适合部署。

    此致、
    Dušan μ A

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、 Dušan

    我不确定您的问题是什么。 我有一个自定义 层(名为 meta-Jared) 、其中我添加了一个补丁来编辑 k3-j784s4-r5-evm.dts 、并看到了 tiboot3.bin 的重新构建。 您的设置是否与我的设置类似?

    .
    ├── conf
    │   ├── distro
    │   │   └── jared.conf
    │   └── layer.conf
    └── recipes-bsp
        └── u-boot
            ├── u-boot-ti-staging-2024.04
            │   └── 0001-add-comment.patch
            └── u-boot-ti-staging_2024.04.bbappend

    0001-add-comment.patch 的内容:

    From 334e9c5f8ded3b1624f21eb879eb6b342dfcfb34 Mon Sep 17 00:00:00 2001
    From: Jared McArthur <j-mcarthur@ti.com>
    Date: Fri, 17 Jan 2025 15:22:37 -0600
    Subject: [PATCH] add comment
    
    Signed-off-by: Jared McArthur <j-mcarthur@ti.com>
    ---
     arch/arm/dts/k3-j784s4-r5-evm.dts | 2 ++
     1 file changed, 2 insertions(+)
    
    diff --git a/arch/arm/dts/k3-j784s4-r5-evm.dts b/arch/arm/dts/k3-j784s4-r5-evm.dts
    index 8a107b74a4..de71420e7b 100644
    --- a/arch/arm/dts/k3-j784s4-r5-evm.dts
    +++ b/arch/arm/dts/k3-j784s4-r5-evm.dts
    @@ -11,6 +11,8 @@
     #include "k3-j784s4-evm-u-boot.dtsi"
     #include "k3-j784s4-r5.dtsi"
     
    +/* this is a test of our emergency broadcast system */
    +
     &wkup_pmx2 {
            bootph-pre-ram;
            wkup_gpio_pins_default: wkup_gpio_pins_default {
    -- 
    2.34.1

    u-boot-ti-stage_2024.04.bbappend 的内容:

    FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}-2024.04:"
    
    SRC_URI += "\
            file://0001-add-comment.patch \
    "

    您的层是否具有优先级?

    此致!
    Jared

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Jared:

    对于延迟的响应很抱歉、但我认为我已经确定了问题的根本原因。

    首先,在我们的情况下,文件名  bbappend 必须包含, %而不是指定配方的确切版本。

    例如:
    u-boot-ti-staging_2024.04.bbappend→μ A u-boot-ti-staging_%.bbappend.

    此更改确保应用了修补程序。 我通过查看发现了这一点 log.do_patch文件位于:
    yocto-build/build/arago-tmp-default-glibc/work/j784s4_evm-oe-linux/u-boot-ti-staging/2024.04+git/temp/、如果已清除、则附加部分根本没有应用修补程序。

    其次、我们复制了用于在中应用 Linux 修补程序的机制bbappend。 对于 Linux、我们有如下代码:

    SRC_URI:append:j784s4 = "\  
        file://0001-Linux-test.patch \  
        (bunch of other Linux patches) \  
    "  

    添加 :j784s4确保按正确的顺序应用补丁、首先应用 TI 补丁。

    然而、在 U-Boot 的情况下、附加:j784s4SRC_URI会导致 U-Boot 的 R5部分(tiboot3.bin)无法重新编译、即使在进行了更改之后也是如此。 删除:j784s4解决了该问题、我们发现tiboot3.bin正在部署文件夹中重新编译。 我已经对其进行了测试、现在一切似乎都能按预期正常工作。

    此致、
    Dušan μ A