No console output when building tinkerboard image on release
clausecker opened this issue · comments
I am trying to build U-Boot for my Tinkerboard. I am on FreeBSD and have typed the following commands to build and flash U-Boot. I am compiling revision e205b79.
CROSS_COMPILE=arm-none-eabi- gmake tinker-rk3288_defconfig all
tools/mkimage -n rk3288 -T rksd -d spl/u-boot-spl-dtb.bin out
cat u-boot-dtb.bin >>out
sudo dd if=out of=/dev/mmcsd0 seek=64 conv=sync
The SD card I am writing to already contains the Debian image distributed by ASUS. When I try to boot the system, U-Boot doesn't print anything to the serial console (this is the bug I want to report) which is different from the U-Boot included in the Debian image. Only once U-Boot loads Linux, output is visible to the serial console. I have configured the serial console to 115200 Baud 8N1. Please fix this issue.
Okay, it turns out that when I use uart1 instead of uart2 in arch/arm/dts/rk3288-tinker.dts, output appears.
we are using uart2 in both u-boot and kernel.
This doesn't match my observations. I didn't get any console output from U-Boot on the Tinkerboard until I swapped uart2 for uart1. On Linux, I observe the system console going to ttyS1 which also matches this observation. It is also clear from the schematics that the UART you expect to access the system console from (on header pins 8 and 10) is UART1. Are you sure that using uart2 is the correct choice for the Tinker Board? Because it also doesn't seem to be they choice made in the Debian image distributed by ASUS. There, serial console output from U-Boot goes to UART1.
We used to use uart2 as the debug port on rockchip platform.
ASUS have change it to uart1 in their u-boot and kernel-cmdline, perhaps they want to keep same with rpi.
OK, my mistake. I am working on upstream u-boot which is using uart2. You can change to upstream u-boot if you want to use uart2.
@eddiecailinux Both mainline u-boot and this repository use uart2 by default for the tinkerboard. However, I believe this is an incorrect default setting.
use uart1 or uart2 doesn't mean correct or incorrect. It is just rockchip's tradition that we use uart2.
And this setting is useless on the Tinker Board as it's not what the user expects. But please, go ahead, make yourself the exception to the convention.
It will be troublesome have a exception. :）
Hi,
I have a question and hope you can answer it!
In order to change the u-boot UART for Tinker Board from 2 to 1, I changed the uart2 with uart1 in rk3288-tinker.dts file.
uart2 was using:
&uart2 {
u-boot,dm-pre-reloc;
reg-shift = <2>;
};
My question is that, should I changed the reg-shift to<1> for uart1 ?
like this:
&uart1 {
u-boot,dm-pre-reloc;
reg-shift = <1>;
};
UPDATE: reg-shift do not need to be changed. Actually, when I changed it tp <2>, board could not boot.
But by just renaming the uart2 to uart1, I could get u-boot output on pin 8 and 10 which is uart1.
It's quite unfortunate that mainline u-boot chose to include a default configuration for the Tinkerboard that directly goes against all documentation for the board.
It makes sense for any dtsi included by the tinkerboard dts to use the rockchip standards, but isn't the purpose of device-specific dts files and defconfigs to help hide the device manufacturer's oddities from end users?
I just spent three days trying to figure out why I couldn't get any output from my own u-boot builds on a tinkerboard, only today to discover that the uart documented as the debug uart in all of Asus's documentation was in fact the wrong uart on which to attach a console, and am back to wondering who sucks the least among rockchip, allwinner, and mainline devs. They all seem to desperately want to make life hell for the folks trying to use these platforms.
Everyone can contribute mainline u-boot... You could ask ASUS guys to patch mainline to use a different debug uart or mention it in their document.
For us, we don't have the motivation to care about manufacturer’s preferences.