Hi,
In the process of deploying Boot2Qt to an Apalis i.MX6 board, I must have accidentally set the U-boot bootdelay value to 0. I didn’t explicitly do this, but I suspect the following commands had something to do with changing this parameter.
setenv drive 2
setenv setupdate ‘fatload mmc ${drive}:1 ${loadaddr} flash_mmc.img; source’
run setupdate
run update_uboot
I can no longer stop the bootloader from immediately loading and running the kernel, which boots up fine. Unfortunately the bpp HDMI arguments are not optimal, but I haven’t found a way to change these, now that I can’t pause the bootloader.
Can you describe how I can restore the bootdelay to a non-zero value?
Thank you
One can reset the environmental variables to default by using this command:
‘env default -a; saveenv’
I guess that may be rather hard for @trevanian to do @bhuvanchandra.dv as he can’t seem to enter the U-Boot console any longer even though at least our regular BSPs do define CONFIG_ZERO_BOOTDELAY_CHECK which means that even when setting bootdelay to zero one should still be able to stop U-Boot from auto booting by sending any character via serial terminal connected to it.
However maybe the issue at hand is a quite different one and I do suspect it might have to do with UART RX/TX having been swapped in later hardware revisions which this proprietary Boot2Qt stuff might still not quite handle properly.
Could you tell us what exact hardware model/revision of an Apalis iMX6 you have? Do you actually get any UART output at all now when booting?
Hi @marcel.ziswiler,
I have an Apalis IMX6Q 1GB, V1.0B, connected to an Ixora Rev 1.0 carrier board. I connected a serial cable to UART1 (X22), and configured the serial console terminal to 115200 8n1. I only see information appear on the serial console around 2.4 seconds after the kernel boots and onwards. The first message I see is “[2.433399] ipu_init_sync_panel: disp=0, pixel_clk=25175000 25142857”.
I tried to enter recovery mode by shorting the recovery mode pads, but I don’t se any activity on the serial connection. Is 115200 8n1 still correct for recovery mode?
Thanks
I am asking for this information simply so I can re-configure the HDMI framebuffer bpp from 16 to 32. If there is an alternate way to do this, I don’t need to recover the u-boot settings.
I did try ‘fbset -depth 32’, at which point my HDMI screen went blank. I then stopped and restarted lxdm, using ‘/etc/init.d/lxdm stop’ and ‘/etc/init.d/lxdm start’, but that caused the IPU to restore the fb0 bpp to 16.
If you have currently the Toradex image on the module, you can use fw_setenv bootdelay 1 to change the boodelay variable from within Linux…
OK, so you do actually have one of them early samples with swapped UART RX/TX lines. Most possibly you corrupted the factory configuration block which results in U-Boot no longer being able to configure it properly. Later as Linux still uses the proper V1.0 device tree the UART gets reconfigured properly and you get some output.
The recovery mode is actually by means of a USB device connection and has nothing to do with the UART at all. Anyway on a V1.0X module with corrupt factory configuration block that won’ t help you unless you would compile a U-Boot with hard-coded V1.0X settings.
The display configuration would be described in the following article on our developer website.
As @stefan.agner pointed out one could do this from Linux user space as well using fw_setenv which at least in our standard demo images is configured/depolyed by default.
Above you talked about using proprietary Boot2Qt and now you mention LXDM which leaves me a little bit confused. What exactly is it now that you are trying to achieve?
