I was able to remove TX1 Jetpack 3.0 L4T 24.2.1 boot log and enable default Ubuntu Plymouth splash-screen.
The problem is that it only last for 2 seconds, but the blackscreen last around 20 seconds. The blackscreen last for around 10 seconds before the splash-screen appears, then the splash-screen appears and last around 2 seconds and finally a black-screen show up for around 10 seconds until the Ubuntu desktop is loaded. I configured the system in auto-login.
Is there any way to increase the time that the splas-screen appears and reduce the black-screen time?
I am doing a lot of guessing (this could be way off/wrong), but typically a black screen is when the video driver is configuring or loading. I would guess that it takes 10 seconds to get to loading splash, the splash is 2 seconds by intent, and then the black screen after is probably driver load time beginning when a login starts (or a login chooser). If this is the case black screen cannot be avoided, and the black screen starts with a video load event (such as start of login). FYI, initial console text mode switching to a mode capable of bitmapped graphics of splash could be part of that time.
How do you enable splash? It may be possible to have it “sleep” for a few seconds longer before starting a login.
Someone from NVIDIA may be able to answer if there is a possible means to load a static image into the screen buffer to appear during a graphics mode change…though I have doubts. Perhaps there is a front and back buffer, and the buffer which is front can be pre-loaded while it is still back buffer.
To enable the splash and remove boot log I just added the following line at the end of the APPEND line in the /boot/extlinux/extlinux.conf file:
quite loglevel=0 splash
Also, I created the “/usr/share/plymouth/plymouthd.defaults” file with the following content:
# Distribution defaults. Changes to this file will get overwritten during
# upgrades.
[Daemon]
Theme=ubuntu-logo
ShowDelay=1
From the research I made, the only way to enable a splash-screen on TX1 is through Plymouth, because the u-boot splash approach doesn’t work, due to limitations on the graphics card during boot process. Apparently u-boot doesn’t have access to the specific graphics drivers that resides on kernel, so only Plymouth could be used to display a splash-screen. In fact, the u-boot splash screen is disabled by default, you need to recompile the u-boot src code after enable the boot splash option.
Another thing I noticed is that in the default Ubuntu splash screen, there is no Ubuntu logo image (png), instead there appears “Ubuntu” written in text mode. As I understood, Plymouth should be agnostic of the platform were it is running, but it behaves different between the PC and Tegra Ubuntu versions
Looks like you ran into the “gateway timeout” bug and got tricked into multiple posts (if you get gateway timeout, hit the “back” button, then “refresh”…the timeout isn’t in the forum post, it’s in the read of the updated thread) :P
I believe you are correct about the U-Boot limitations versus Plymouth. What I’m wondering is what specific change you made to get Plymouth to display your graphic, and what format/size the graphic is. A way to reproduce for those testing. Any U-Boot edit information to match what you have might also be of use. I will not necessarily be able to reproduce and offer anything useful, but someone else might.
It is useful to know that in the 3.x series of kernels changes to graphics mode were not done in the kernel itself, but starting with 4.x series of kernels there is kernel mode change instead of user space mode change. This changed the way graphics drivers interacted with user space. This same change will cause information on U-Boot changes for splash screens to be incorrect if the information was written for a 3.x kernel series (and older Ubuntu 10 docs likely qualify).
I also suspect that adapting the NVIDIA video driver to the 4.x series kernel differs in ARM versus desktop x86_64 PC, and results in why information for Plymouth under a 4.x kernel might differ. I have not spent much time researching this though, but I suspect one of the first things you would need to do is see how Plymouth boot screen logo instructions changed between an Ubuntu release using a 3.x kernel versus a newer Ubuntu using a 4.x kernel…whatever the difference in instructions is probably key to debugging your issue.
If anyone from NVIDIA can comment on how initial text mode buffer is set up, and how a logo and Plymouth would work with this specific driver, it would be helpful since much of the information out in the wild is for the Nouveau driver.
Your guess is correct.
The root cause of this “2 second last time” come from fbdev init too late(which is needed for plymouth) and after splash screen is up, it is already time for lightdm to start, so plymouth disable splash screen again… (Black screen is shown when lightdm is starting.)
For splash screen, we are putting effort to make it work in bootloader instead of kernel bootup. Hope it could come out in next release…
Thanks for the information. Please update this post when the bootloader splash-screen support is released.
Do you have any guide on how to display a static CUSTOM wallpaper image as a splash-screen using Plymouth on TX1 Jetpack 3.0 L4T24.2.1 (Kernel 3.10.96)?
I have been trying to do it, but got no success. Also, some weird thing I noticed is that in the default Ubuntu splash screen, there is no Ubuntu logo image (png) displayed, instead there appears “Ubuntu 16.04” written in text mode centered on a purple background color screen, with some loading status bar with dots. I have attached a picture with the default Ubuntu splashscreen on the TX1 and the PC to see the differences.
I do not know why it would use text instead of a graphic. The first possibility is the inability to read the image file. A second possibility is the inability to enter a VGA mode framebuffer used for images when otherwise in console mode. If you know where the image is, then you might check permissions along the full path to see if the image is reachable.
Please try following steps. This is for rel-24.2.1 plymouth to draw a wallpaper.
1. Update the kernel image with below patch because of known issue in console for rel-24.2.1.
2. Please replace following kernel command line in /boot/extlinux/extlinux.conf
APPEND fbcon=map:0 androidboot.modem=none androidboot.serialno=P2180A00P00940c003fd androidboot.security=non-secure tegraid=21.1.2.0.0 ddr_die=2048M@2048M ddr_die=2048M@4096M section=256M memtype=0 usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 debug_uartport=lsport,0 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=${lp0_vec} nvdumper_reserved=${nvdumper_reserved} core_edp_mv=1125 core_edp_ma=4000 gpt android.kerneltype=normal androidboot.touch_vendor_id=0 androidboot.touch_panel_id=63 androidboot.touch_feature=0 androidboot.bootreason=pmc:software_reset,pmic:0x0 net.ifnames=0 root=/dev/mmcblk0p1 rw rootwait splash
It removes the tty0 and ttyS0 which will make plymouth to select framebuffer.
3. the following config file is missing and need to add manually.
cd /usr/share/plymouth
create a file named plymouthd.defaults with following content.
# Distribution defaults. Changes to this file will get overwritten during
# upgrades.
[Daemon]
Theme=ubuntu-logo
ShowDelay=1
The above steps allows to display the default graphical ubuntu-logo splash-screen instead the text mode splash-screen.
What specific issue does the kernel patch fix? I applied it, but got no difference between applying it or not. Steps 2 and 3 for your list were sufficient to display the default graphical ubuntu-logo splash-screen.
I haven’t tested this, but perhaps these observations will help…
I see “/usr/share/plymouth/themes/ubuntu-logo/” has “ubuntu-logi.grub” (apparently a background color is specified), “ubuntu-logo.plymouth” (which appears to name a directory for the logo script (which seems to have some specifications for colors…perhaps in text mode when graphical is not used…and also names the png logo image when graphical mode framebuffer is used), and “ubuntu-logo.png” (which seems to be the actual image displayed when image is named).
I would guess that if you copy “/usr/share/plymouth/themes/ubuntu-logo/” to become “/usr/share/plymouth/themes/custom-logo/”, and substitute your graphic (and references to “ubuntu-log”) to your custom setup it might load yours instead. I would be careful to follow the graphic format of the ubuntu-logo.png while making any new image.
Nevertheless, it still remains a little LOG on the HDMI display during boot, before the splash-screen is displayed.
I tried to remove it by adding this line portion to the end of the APPEND line in the /boot/extlinux/extlinux.conf file:
quite loglevel=0
Also, I edit /etc/sysctl.conf and uncomment the line that contains “printk”. I also replaced the 4 numbers by 0 to make sure no log makes it through. But got no success on removing this few log messages during boot.
According the content of the log messages, they start appearing when the initrd starts and ends when the initrd switches to actual rootfs. I will attach an image of the boot log, to get a better idea of what I am talking about.
I figured out that if I append the following line to the APPEND line of the /boot/extlinux/extlinux.conf file NO boot log appears on HDMI output, but the splash-screen changes to text-mode instead of graphic-mode, so no logo is displayed.
Don’t know if this is just a typo on the forum, or if this actually got into your kernel command line, but “quite” should be “quiet”. If it wasn’t actually “quiet”, then changing to this would likely help.
Those messages seem to be related to the initrd image. Initrd isn’t used in all versions of L4T, but it is in the R24.x versions.
Your initrd is actually a gzip cpio archive, and an example to unpack and explore the initrd is as follows:
sudo -s
cd /tmp
mkdir unpack
cd unpack
gunzip < /boot/initrd > initrd.cpio
cpio -vid < initrd.cpio
rm initrd.cpio
# explore, edit, so on...
# Now repackage...
cd /tmp/unpack
find . -print | cpio -ov > ..initrd.cpio
cd ..
gzip initrd.cpio
mv initrd.cpio initrd.edited
# Move initrd.edit somewhere else...
rm -Rf /tmp/unpack
exit
The initrd is like a mini operating system rootfs (you could probably even replace the sample rootfs with this for an absolutely minimal o/s…I may try that just for fun some day after removing the pivot_root). This unpacks and runs in RAM so it has some severe size limitations, but kernel modules which would otherwise not be found before mounting the file system can exist in this as a means to find things before the file system mounts. E.g., normally you could not enable a file system such as ext4 as a module and then expect to load the module by mounting an ext4 file system…the proverbial chicken and the egg dilemma…but putting it in the initrd works (think of initrd as a cpio/gzip file system understood by the boot loader and kernel). So you will find a number of functions which you may have edited (such as sysctl.conf) which may differ within the initrd and need edit there as well (once pivot_root takes place initrd disappears…until then you may need to make some init setup changes to the initrd to get what you want).
I suspect the messages are due to something in initrd, but you’ll need to do some exploring to figure out exactly where this is from. You will see references in that log picture about initrd…the messages could be generated form the regular init taking over from initrd, or from the initrd itself…most likely it is from the initrd itself, but beware it might be from both.
I believe initrd was used only in the R24.x. There is an initrd of size 0 after this, but it seems to just be a place holder and does not do anything.
That patch is needed if you want to run plymouth after bootup. I remember there would be some problem when trying to access framebuffer after lightdm is up.
