Looked around the web, founded I am not alone. I guess that because the device tree is not used yet, the hardware is not initialized, so printk() can not print message to console at this point. Earlyprintk may be a solution, but I don't want to waste the time any more, just use __dbg_buf to debug it.
Founded the following message in the web:
The Nonrobustness of printk()
A **bleep** in the armor of printk()'s robustness does exist. It is unusable before a certain point in the kernel boot process, prior to console initialization. Indeed, if the console is not initialized, where is the output supposed to go?
This is normally not an issue, unless you are debugging issues very early in the boot process (for example, in setup_arch(), which performs architecture-specific initialization). Such debugging is a challenge to begin with, and the absence of any sort of print method only compounds the problem.
There is some hope, but not a lot. Hardcore architecture hackers use the hardware that does work (say, a serial port) to communicate with the outside world. Trust meth is not fun for most people. Some supported architectures do implement a sane solution, however and others (i386 included) have patches available that also save the day.
The solution is a printk() variant that can output to the console very early in the boot process: early_printk(). The behavior is the same as printk(), only the name and its capability to work earlier are changed. This is not a portable solution, however, because not all supported architectures have such a method implemented. It might become your best friend, though, if it does.
Unless you need to write to the console very early in the boot process, you can rely on printk() to always work.