From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis Date: Fri, 20 Sep 2019 12:03:28 +0200 (CEST) Subject: [U-Boot] ROCK64 fails to boot using U-Boot TPL In-Reply-To: <528ca18f-f707-b63e-0934-7c830f4d7484@simonsouth.net> (message from Simon South on Thu, 19 Sep 2019 04:56:57 -0400) References: <528ca18f-f707-b63e-0934-7c830f4d7484@simonsouth.net> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > From: Simon South > Date: Thu, 19 Sep 2019 04:56:57 -0400 > > I've been unable so far to boot NetBSD on my PINE64 ROCK64 (v2.0, > Rockchip RK3328) using U-Boot built with its own TPL, the default since > commit ff3dd0a474. > > The same NetBSD image boots fine using the binary TPL supplied by Rockchip. > > The exact failure varies but it always seems memory-related. Typically > the NetBSD kernel fails right after starting with a panic in its > virtual-memory system, uvm. > > Also significant may be these messages sometimes output by U-Boot at > startup, which I haven't seen when the Rockchip TPL is used: > > libfdt fdt_check_header(): FDT_ERR_BADMAGIC > > I've pasted the output from a typical failed boot below and have > submitted a problem report (with a bit more detail) to the NetBSD project: > > https://gnats.netbsd.org/54557 > > Does anyone know why this might be happening? Is there perhaps some > additional setup the U-Boot TPL expects from the OS to finish > configuring the RK3328's memory controller that's currently missing from > NetBSD? Hi Simon, One thing to look at is whether (voltage) regulators and/or clocks are set up right. I've seen the OpenBSD kernel crash because one of the voltages supplied to the SoC was too low. I beieve that was on the rockpro64. The regulator in question was a "boot-on" regulator so the OpenBSD kernel assumed the regulator was already properly configured. But I believe the Linux kernel doesn't trust the bootloader and will configure such a regulator anyway. In my rockpro64 case the regulator was skipped because of some DM-conversion fall-out. Using the U=boot "dm" commands you can check whether drivers for various regulators are enabled. If a "boot-on" regulator doesn't have a "*" next to it, that is a clear indication of a problem. Worth looking at "always-on" regulators as well. Cheers, Mark