Because, first you have to debug your uboot code. While you are doing this, if you silent your UART, you don’t know what it will happen when uboot met problem. But of course you can do this in your own risk.
I really don’t mind u-boot to barf on the uart if something is wrong, in that case nothing will work anyway so the confusion on my peripheral is not really of any impact. The silent option for u-boot will only generate output when you send something on the uart first during booting as far as I can understand, and that would be just fine for my purpose.
Thanks for the link, i’ll check whether this version of u-boot honors the silent option.
One thing comes to my mind is that, if you connect some devices to the UART and it output some info during uboot booting, uboot could just stop. Because in uboot console, if you press any key, uboot will stop.
I am not using GLI, but I have same problem with openwrt and I could not silence the the boot messages printed by kernel, I tried bootargs, early printk and other options but still it prints kernel messages. kernel.printk= 0 4 7 1 in /etc/sysctl.conf makes some later messages silenced by not the early ones.