[U-Boot] help with serial on the rockchip64

[Simon South]

On 2019-09-24 9:33 p.m., Sergio de Almeida Lenzi wrote:
> note that NetBSD only uses ONE boot file...

Ah, I'm not familiar with the U-Boot package in NetBSD; I've been 
working from the main U-Boot repository. So I'm don't know how pkgsrc 
builds that image or what it contains.

> So the binary-only loader is it within the rockchip or makes part of the 
> u-boot code???

Neither. It's a separate, binary-only file released by Rockchip [1] 
that, until recently, U-Boot relied on to perform the initial system 
setup ahead of U-Boot's own secondary program loader (SPL) running.

Now U-Boot has its own, open-source tertiary program loader (TPL) that's 
meant to take the place of Rockchip's loader to initialize the system 
and launch the SPL---although I'm still struggling at the moment to get 
it working fully on my ROCK64. [2]

> why does the Rockchip's binary-only loader is unable to detect the 
> serial once I change the baud rate???

I don't think that message is coming from Rockchip's loader; it's being 
output from the "trusted firmware" (BL31) code. Rockchip's code exits 
after printing "OUT".

But regardless, I think the underlying problem is that the order of 
execution is wrong. The way I believe it's supposed to work (and the way 
things have been working for me) is

- First either the Rockchip loader or U-Boot's TPL runs, to do basic 
hardware setup (mostly just configuring the UART and SDRAM controller) 
and load the U-Boot SPL.

- The U-Boot SPL then finishes initializing the hardware and determines 
how the operating system is to be launched, by loading and executing a 
kernel or an EFI bootloader, for instance.

- Then the operating system runs and does everything else required to 
get to a login prompt.

 From the output you sent it seems the U-Boot SPL is running _first_, 
ahead of everything else. After that the Rockchip loader runs, 
re-initializing the hardware (including the UART, setting it back to the 
default speed) and once it and the trusted-firmware image have 
finished... there's nothing to hand control to next, since only the SPL 
actually knows how to launch an operating system and it's already exited.

All I can suggest right now is to try building a U-Boot image as 
described in my last email (which basically duplicates the instructions 
in older versions of U-Boot [3]) and see if you can get that working. If 
you can get that far, perhaps it will become apparent what the NetBSD 
package is doing differently and whether it ought to be changed.

[1] 
https://github.com/rockchip-linux/rkbin/blob/master/bin/rk33/rk3328_ddr_333MHz_v1.16.bin
[2] https://lists.denx.de/pipermail/u-boot/2019-September/384076.html
[3] 
https://gitlab.denx.de/u-boot/u-boot/blob/8b1ceb0ac1aa1746c6751d698ce7a012a236fa65/doc/README.rockchip

-- 
Simon South
simon at simonsouth.net