OE4T / meta-tegra

BSP layer for NVIDIA Jetson platforms, based on L4T
MIT License
389 stars 219 forks source link

linux-tegra devtool workflow problems #369

Closed mozcelikors closed 3 years ago

mozcelikors commented 4 years ago

I generally use devtool to see if I need to add patches or kernel configs. However, for reasons I have yet to discover, when using devtool (when devtool is active and you are building linux-tegra) if you bitbake an SD card image, configs/patches added to layer are not reflected to the build.

To give an example, I have a .cfg in my layer with CONFIG_CAN_MCP251X=y, however I see the resulting config does not have this. If I build without devtool, the resulting config has it. This is an issue I came across only with meta-tegra / dunfell branch. With NXP or Raspberry Pi Yocto sources, there is no such issue.

To add more, devtool created workspace layer has DEVTOOL_DISABLE_MENUCONFIG variable in layer.conf , do not yet know how it affects my problem.


do_patch[noexec] = "1"

do_configure_append() {
    cp ${B}/.config ${S}/.config.baseline
    ln -sfT ${B}/.config ${S}/.config.new
}

do_configure_append() {
    if [ ! ${DEVTOOL_DISABLE_MENUCONFIG} ]; then
        cp ${B}/.config ${S}/.config.baseline
        ln -sfT ${B}/.config ${S}/.config.new
    fi
}

Anybody has the same issue or knows how to fix this? Thank you.

madisongh commented 4 years ago

In the dunfell branch, the kernel configurations are supplied in full as a defconfig in the metadata layer, which may negate the effect of using config fragments. That shouldn't affect patches, though, assuming you're directly adding the patches to the SRC_URI. (The L4T R32.4.2-based branches (dunfell-l4t-r32.4.2 and master, currently) switched over to using the in-tree base configuration, which should be more friendly to using the linux-yocto configuration mechanism.)

Do you see the config changes and patches getting applied when you're not using devtool?

mozcelikors commented 4 years ago

Hi, I see config changes and patches applied when not using devtool. I seem to have fixed this issue by commenting the following lines on the devtool-generated file build/workspace/appends/linux_tegra_4.9.bbappend:

#SRCTREECOVEREDTASKS = "do_validate_branches do_kernel_checkout do_fetch do_unpack do_kernel_configme do_kernel_configcheck"
#do_patch[noexec] = "1"

I didn't encounter the error since then, but not sure if I will encounter in the future, since it is non deterministic.

I have another question though: In general, I would like a quick kernel/config/devicetree modification and deploy mechanism. For kernel+config bitbake linux-tegra && bitbake core-image-minimal && scp tmp/work/core-image-minimal/rootfs/boot/ to /boot on Jetson Nano works, But for devicetree, this does not work. Do you happen to know how would I quickly deploy devicetree to a live image, to save the time of running entire tegraflash and dd'ing to SD card? Thanks

madisongh commented 4 years ago

I seem to have fixed this issue by commenting the following lines on the devtool-generated file build/workspace/appends/linux_tegra_4.9.bbappend

Those lines get inserted by devtool for any recipe that inherits the kernel bbclass, from what I see in the sources. I did notice that my config fragments and patches got applied during devtool modify rather than during the build, when I looked at this.

In general, I would like a quick kernel/config/devicetree modification and deploy mechanism.

You could try including tegra-redundant-boot in your image, which will (on the Nano) install the l4t_payload_updater_t210 tool. You would then bitbake u-boot-bup-payload to generate the OTA updater payloads, scp u-boot-jetson-nano-qspi-sd.bin.kernel_only.bup-payload to the target and use l4t_payload_updater_t210 u-boot-jetson-nano-qspi-sd.bin.kernel_only.bup-payload to install it, then reboot. The kernel_only payload has just the U-Boot binary and the kernel device tree in it.

madisongh commented 3 years ago

Closing this now, as I think the questions here have been answered.