So I’ve been trying for a while now to change the splash screen on boot. I’ve seen the various threads regarding this but I am still having trouble and I need some clarification on a few things so that I can understand what I am doing wrong.
I have followed the instructions in Linux_for_Tegra/tools/bmp-splash/bmp-blob-README.txt to generate a new bmp.blob file and placed it into Linux_for_Tegra/bootloader/bmp.blob. However, when I get to the last step to flash I skip it, because I am building my own custom image using the L4T/BSP tools and a minimal Ubuntu rootfs. So instead I use the Linux_for_Tegra/tools/jetson-disk-image-creator.sh script to create a new image and I am flashing it to an sd card using etcher.
So I run this script and I can see that it writing my custom bmp.blob to the BMP partition and everything looks like it’s working as designed. I flash it to the sd card and I have explored the partitions to make sure that it is my image, based on the bytes written (about 50Kb). So I expect at this point when I put it in the Jetson Nano it will use my new splash screen on boot.
This doesn’t happen though.
It still boots with the Nvidia Logo. So here is my confusion. If I remove the SD card completely and try to boot the device it still shows the Nvidia logo (and then a no SD Card graphic in the corner), so clearly this logo is coming from somewhere else on the device itself.
- Is this Nvidia logo always present?
- Is this bmp.blob image supposed to just come after the Nvidia Logo?
- Is it just falling back to a default because of an error (no sd card, improper formating of my bmp.blob)?
- Is there another step that is supposed to occurs that flashes the bmp.blob from the SD card to the actual device firmware?
- Is the flashing step at the end of
Linux_for_Tegra/tools/bmp-splash/bmp-blob-README.txt some how different than the one Linux_for_Tegra/tools/jetson-disk-image-creator.sh uses to create a bootable image?
I’ve checked the output from the serial console and it doesn’t really make it any clearer. The logs from boot without SD card and with SD card look identical right up to the part where it loads the SD card. When the SD card is present it doesn’t say there is anything wrong with my bmp.blob.
With SD card:
...
[0003.721] SD-card IS present ...
[0003.724] load_and_boot_kernel: SD card detected OK
[0003.730] load_bmp_blob: panelresolution=1080 type=3
[0004.224] display bmp image done
Without SD card:
...
[0003.692] SD-card NOT present ...
[0003.695] load_and_boot_kernel: SD card not detected!
[0003.701] load_bmp_blob: panelresolution=1080 type=3
[0004.197] display bmp image done
Both show the same Nvidia logo at this point.
Which jetpack release are you using?
Thanks for taking the time to help me. I’m using JetPack 32.5.1. I’m going through the document linked now and I will share the boot log as soon as I can.
I think the cause of this problem is: the BMP partition is actually on the QSPI of the module but not the sdcard. You can check the partition table from Linux_for_Tegra/bootloader.
Since the BMP blob is on device, no matter what you install on the sdcard, it won’t change the logo. You need to sue the driver package (flash.sh) to directly update the bmp on QSPI.
Ok that makes sense but then I am wondering why the jetson-disk-image-creator.sh creates this partition? I mean I know why, because it’s in the partition configuration file, but are any of the other partitions besides not used with the sd card variant?
The docs here seem to imply that it will read this partition from the SD card.
It seems to me, that if it’s not used, this partition should be removed from the configuration file for the sd card variant.
After reading the config file more, I guess the bmp.blob parition should just be moved to the spi section then?
It is a little bit complicated. I will try to explain this.
Actually, before rel-32.5.1, this partition is still on sdcard. It is moving to SPI after rel-32.5 as a new feature.
Start from a scenario that the board is still on jetpack4.4.1 state. When you insert a rel-32.5 sdcard image to the board, it will detect the bootloader on the QSPI and find out it is still a jetpack4.4.1 version, then it will copy the partitions from sdcard to the QSPI. And remove the partitions on sdcard. In next reboot, the bootloader shall read the partition from QSPI instead of sdcard.
To make this process works fine, sdcard image will still have BMP partition so that it will have ability to re-fresh other old jetson modules.
I see. So I can fix this by flashing the QSPI directly using flash.sh for this board specifically. But what happens if I do this with a brand new board and my image (with JetPack 32.5.1+) is the first to boot? Will it sill copy over the partition?
If the brand new board’s QSPI version is < 32.5, then your completed sdcard image will copy those partition to the QSPI. For such case, I think your BMP blob on sd will be copied to the QSPI too and thus your change in sdcard will take effect.
Honestly, I didn’t do such test by myself before. If you have interest to this, you can try.
Ok that’s fair enough. I will have to buy a fresh board to test it out. I was just trying to understand the development workflow here. It seems like it’s a one time copy from the 32.5.1+ via the sd card. And after that it requires direct flashing to the QSPI to make any changes to the boot screen. Which is fine I just do most of my development and then burn the resulting image via Etcher because it’s easier.
Thank you for your help, I will try the direct flashing now and come back if it doesn’t work.
You don’t really need to buy a fresh new board. Just flash the board with jetpack4.4.1 sdkmanager and the QSPI will be installed back to old version. That is the difference between sdcard image and sdkmanager. That is also why I suggest user to flash sdkmanager when they hit problem instead of changing sdcard image.
Ah right, ok that makes sense. Thank you.
I just wanted to update this post to say that flashing the board directly using flash.sh worked.
I had a few errors at first due to the bmp format but I was able to generate a proper bmp file using imagemagick and the following command:
convert -resize 1920x1080 +compress +matte splash.png splash1080.bmp
Then using this splash1080.bmp to generate my bmp.blob. The +matte and +compress were required to get it to accept it. +compress apparently means turn off compression.