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_333M... [2] https://lists.denx.de/pipermail/u-boot/2019-September/384076.html [3] https://gitlab.denx.de/u-boot/u-boot/blob/8b1ceb0ac1aa1746c6751d698ce7a012a2...