AGX Xavier boot logo update

[slip76]

Hi Folks,

I've create bmp.blob using the information found on Tegra forums (custom tool). Not sure if this blob is correct but now I'm trying to integrate it in my custom distro which is based on meta-tegra. I've created layers/meta-/recipes-custom/tegra-binaries/tegra-binaries_%.bbappend file with the following contents:

FILESEXTRAPATHS_prepend_tegra194 := "${THISDIR}/files:"

SRC_URI_prepend_tegra194 += " \
    file://bmp.blob \
"

do_preconfigure_append_tegra194() {
    mkdir -p ${S}/bootloader/${NVIDIA_BOARD}/
    cp ${WORKDIR}/bmp.blob ${S}/bootloader/${NVIDIA_BOARD}/
}

bitbake created the build without errors but when I've flashed it I got boot process stuck on this point:

[  134.767516] extcon-disp-state external-connection:disp-state: cable 47 state 1
[  134.767519] Extcon AUX1(HDMI) enable
[  135.840155] extcon-disp-state external-connection:disp-state: cable 40 state 1
[  135.847278] Extcon HDMI: HPD enabled
[  135.850818] tegradc 15220000.nvdisplay: hdmi: plugged

[lfdmn]

I do it like that in our builds

SRC_URI += " \
    file://custom_bmp.blob \
"

do_preconfigure_append() {
    mv ${S}/bootloader/bmp.blob ${S}/bootloader/bmp.blob_backup
    mv ${WORKDIR}/custom_bmp.blob ${S}/bootloader/bmp.blob
}

There is now a bootlogo-custom_1.0.bb recipe that might be easier to use, I haven't tried.

[slip76]

Solved. The tegra-binaries_%.bbappend file looks like this now (for those who will google it and find this thread in future):

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += " \
    file://bmp.blob \
"

do_preconfigure_append() {
    cp ${WORKDIR}/bmp.blob ${S}/bootloader/
}

[slip76]

No I was wrong - the image shows up as expected (only colors are strange - it is much lighter than my source jpg/png file). But then the boot process still hangs - but now I was more attentive - it fails with FS operations and proposes to go into recovery mode (but due a lot of console messages coming in I haven't noticed this when was writing my first post). So there is place where the boot process gets broken:

[ OK ] Mounted /data
          Mounting /etc...
          Starting Grow File System on /data...
[  33.496821 ] overlayfs: failed to resolve `/data/overlays/etc-upper`: -2
[  33.500192 ] EXT4-fs (mmcblk0p43): resizing filesystem from 1078949 to 1078949 blocks 
[ FAILED] Failed to mount /etc.
See 'systemctl status etc.mount' for details.
[ DEPEND ] Dependency failed for Local File Systems.
....

[madisongh]

It looks like it's trying to mount /etc before the /data partition is fully ready. You probably need to add another dependency for that mount point on mender-systemd-growfs-data.service, since that service apparently is configured to run after /data is mounted (which I'm not sure is really correct). Either that, or dump Mender's mender-growfs-data feature and just add x-systemd.growfs to the fstab entry for /data - systemd should grow the filesystem before it gets mounted.

This isn't related to your boot logo changes, though.

[slip76]

Thank you for your reply, @madisongh .
I've added 'x-systemd.requires=mender-systemd-growfs-data.service' to my mount but it still fails with: overlayfs: failed to resolve /data/overlays/etc-upper: -2

Also tried to add MENDER_FEATURES_ENABLE_remove = " mender-growfs-data" to local.conf - do not see partition growing message in log - but the failure is the same overlayfs: failed to resolve /data/overlays/etc-upper: -2

And yes - this issue probably was introduced earlier - when I've bumped submodules but I haven't noticed it because it was probably not 100% reproducible. Also I've noticed that before the changes my resulting fstab was looking like that:

$ cat /etc/fstab
/dev/root            /                    auto       ro              1  0
proc                 /proc                proc       defaults              0  0
devpts               /dev/pts             devpts     mode=0620,ptmxmode=0666,gid=5      0  0
tmpfs                /run                 tmpfs      mode=0755,nodev,nosuid,strictatime 0  0
tmpfs                /var/volatile        tmpfs      defaults              0  0
overlay              /var/lib             overlay    lowerdir=/var/lib,upperdir=/data/overlays/var-lib-upper,workdir=/data/overlays/var-lib-work,x-systemd.requires-mounts-for=/data,x-systemd.requires=data-overlay-setup.service 0  0
overlay              /home                overlay    lowerdir=/home,upperdir=/data/overlays/home-upper,workdir=/data/overlays/home-work,x-systemd.requires-mounts-for=/data,x-systemd.requires=data-overlay-setup.service 0  0
overlay              /etc    overlay    lowerdir=/etc,upperdir=/data/overlays/etc-upper,workdir=/data/overlays/etc-work,x-systemd.requires-mounts-for=/data,x-systemd.requires=data-overlay-setup.service 0  0
/dev/mmcblk0p43      /data                auto       defaults,data=journal 0  2

And I only introduced /etc overlay mount explicitly in my recipe, Overlays for /home and /var/lib were added by some other recipe - I'm analyzing the code and cannot find by which one for two days already (grep-ing by 'fstab' and 'overlay' keywords). So might be my recipe should now have an explicit dependency on that recipe or might in newer version of that recipe some defaults have changed. I'm new to this stuff - sorry for dump questions and messing all the things together

If I now enter to this recovery mode - fstab is a copy of repos/poky/meta/recipes-core/base-files/base-files/fstab with the added /etc overlay

[madisongh]

Hard to say exactly what's going on, but you could check the output from the data-overlay-setup service to see if it's really running before the mount is attempted, and if so, whether or not it's actually creating the needed directories. You could add some debug output to the script it invokes, for instance.

But I suspect the problem is that systemd has a special relationship with /etc, and you may be running into circular dependency problems with other systemd units and your /etc mount. I've tried doing this sort of thing in the past, and it was difficult to make it work properly.

What I've done instead is to use systemd's volatile-root support, and then selectively persist specific information in /etc that I wanted to keep, using some other means (which vary, depending on the specific config file and how special it is to systemd). There's an example of this in my test distro (search for "semi-stateless" in the files and git history).

[slip76]

Thanks a lot for your input @madisongh! What I'm trying to achieve is to get timedatectl be able to change the timezone by end-user and to store network settings changed by nmcli