[U-Boot] help with serial on the rockchip64
simon at simonsouth.net
Wed Sep 25 13:54:19 UTC 2019
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 
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. 
> 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 ) 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.
simon at simonsouth.net
More information about the U-Boot