Re: [rockchip] broken SPI on RockPro64 and other RK3399 targets
Alper Nebi Yasak writes:
> Something else you can test:
> - Remove the aliases block from rk3399-rockpro64-u-boot.dtsi
> - Add "spi[0-5] = [0-5];" aliases to rk3399-u-boot.dtsi
> - Add CONFIG_SF_DEFAULT_BUS=1 to configs/rockpro64-rk3399_defconfig
This fixed for me the same issue on my Pinebook Pro, turning
Loading Environment from SPIFlash... Invalid bus 0 (err=-19)
*** Warning - spi_flash_probe_bus_cs() failed, using default environment
into
Loading Environment from SPIFlash... SF: Detected gd25q128 with page size 256
Bytes, erase size 4 KiB, total 16 MiB
Patch attached, for clarity.
>From bda546ffdc5b0a25ee554d75f963d1c0570f3f7e Mon Sep 17 00:00:00 2001
From: Simon South
Date: Tue, 10 Nov 2020 12:49:27 -0500
Subject: [PATCH] rockchip: Pinebook Pro: Fix SPI flash
As per a suggestion by Alper Nebi Yasak.
---
arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 4
arch/arm/dts/rk3399-u-boot.dtsi | 5 +
configs/pinebook-pro-rk3399_defconfig| 1 +
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
index 76fc8c3825..1318e03b9a 100644
--- a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
@@ -7,10 +7,6 @@
#include "rk3399-sdram-lpddr4-100.dtsi"
/ {
- aliases {
- spi0 =
- };
-
chosen {
u-boot,spl-boot-order = "same-as-spl", , ,
};
diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
index ecd230c720..09916d633b 100644
--- a/arch/arm/dts/rk3399-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-u-boot.dtsi
@@ -11,7 +11,12 @@
mmc0 =
mmc1 =
pci0 =
+ spi0 =
spi1 =
+ spi2 =
+ spi3 =
+ spi4 =
+ spi5 =
};
cic: syscon@ff62 {
diff --git a/configs/pinebook-pro-rk3399_defconfig b/configs/pinebook-pro-rk3399_defconfig
index 95a04bc0fb..865bfc72b1 100644
--- a/configs/pinebook-pro-rk3399_defconfig
+++ b/configs/pinebook-pro-rk3399_defconfig
@@ -45,6 +45,7 @@ CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_SDMA=y
CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_SF_DEFAULT_BUS=1
CONFIG_SF_DEFAULT_SPEED=2000
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_SPI_FLASH_WINBOND=y
--
2.29.2
--
Simon South
si...@simonsouth.net
Re: Pinebook Pro keyboard (RK3399 OHCI)?
Simon South writes: > Has anyone managed to get the built-in keyboard of the Pinebook Pro > working with U-Boot? > > Even using the latest code, having USB started makes the U-boot > console feel sluggish while pressing keys on the keyboard produces no > result. To follow up on this, for anyone looking into it in the future: The issue is that the Pinebook Pro's keyboard firmware does not actually implement the keyboard boot protocol (described in the USB HID specification[1]). It also doesn't support retrieving input reports via its control interface, meaning neither of the two mechanisms U-Boot normally uses for polling keyboard data are functional. The firmware does recognize the Set_Protocol request, and will even store the supplied value in the controller's memory and return it in response to Get_Protocol. But it doesn't actually change how the keyboard operates. As such, the keyboard continues to NAK every interrupt-transfer request it sees (whenever the user isn't pressing a key), despite U-Boot expecting it to return a report at least once each 40-millisecond period. Consequently the submit_common_msg() routine in drivers/usb/host/ohci-hcd.c is continually timing out waiting for a response, and this slows down the U-Boot console considerably. Arnaud Patard has pointed out setting the CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE configuration option seems to improve the keyboard's responsiveness somewhat, and while this is true, I suspect all this does is increase the likelihood U-Boot will happen to be polling the keyboard at the same moment the user is pressing a key. It doesn't address the underlying problem. In fact, nothing seems likely to address this unless and until new keyboard firmware is created for the Pinebook Pro. There has actually been some progress in this area[2], but the complexity involved in using an external programmer with the controller[3] (and the possibility of bricking it without one) makes it risky for an end-user to experiment with anything beyond very minor changes to the existing code. [1] https://www.usb.org/document-library/device-class-definition-hid-111 [2] https://github.com/jackhumbert/pinebook-pro-keyboard-updater/tree/master/firmware [3] https://electronics.stackexchange.com/a/277395 -- Simon South si...@simonsouth.net
Re: Pinebook Pro keyboard (RK3399 OHCI)?
Arnaud Patard (Rtp) writes: > Did you check the stdin variable content if it contains only "usbkbd" ? > If you have more than one value in it (like "serial,usbkbd"), do you have > CONSOLE_MUX configuration setting enabled ? Yes, "stdin" is set to "serial,usbkbd" and CONSOLE_MUX is set. The console works fine via the serial connection, apart from being sluggish while USB is enabled. > Same here. I just now tried removing another variable by building U-Boot from a fresh checkout on the PBP itself, rather than cross-compiling from my x86_64 machine as I normally do. Same result. So I'm completely at a loss. If you have them handy, would you be willing to email me (off-list) your idbloader.img and u-boot.itb files please so I can try booting them on my hardware? I'm starting to think at this point I somehow got a lemon, but if your build works that would at least point to something I've missed in my setup. -- Simon South si...@simonsouth.net
Re: Pinebook Pro keyboard (RK3399 OHCI)?
Arnaud Patard (Rtp) writes: > Did you check if everything needed is enabled in your configuration and > if the keyboard is detected after a usb start / usb tree ? It is detected, yes. I believe the configuration is fine; I see this issue using the standard "pinebook-pro-rk3399_defconfig" and building either from the latest commit in git or from the tree at commit 3a5771249 (Peter's, which he mentioned earlier). Changing the configuration to remove the XHCI and EHCI drivers, or to add the Inno USB phy driver, doesn't help. Beyond that, for BL31 I'm using a release build of v2.3 of the ARM Trusted Firmware. I've tested using debug and release builds of v2.3 and v2.2 without seeing a difference. > Your keyboard is working with linux, right ? Yes it is. It's only U-Boot that's affected. The only things I've thought of so far that might be unique about my setup are - My PBP is from the latest manufacturing run of a few months ago, not last year's; and - I currently have the eMMC module disabled via the internal switch and am booting off a microSD card. Otherwise I'm at a total loss. The driver sets everything up correctly and then the controller just does nothing. In GNU/Linux, everything works fine. Very strange. -- Simon South si...@simonsouth.net
Re: Pinebook Pro keyboard (RK3399 OHCI)?
Peter Robinson writes: > It should be fixed in the main devel repo, commit 3a5771249 That commit enables the OHCI driver but doesn't lead to a working keyboard, at least for me. Have you actually tested this successfully on a PBP? (Has anyone else?) I wonder if there's something different about my unit. -- Simon South si...@simonsouth.net
Pinebook Pro keyboard (RK3399 OHCI)?
Has anyone managed to get the built-in keyboard of the Pinebook Pro working with U-Boot? Kever, Jagan: Are you aware of any special setup required to have the RK3399's OHCI controller begin processing its periodic list? Even using the latest code, having USB started makes the U-boot console feel sluggish while pressing keys on the keyboard produces no result. The issue seems to be the OHCI (USB 1.1) driver continually times out waiting for the controller to start an interrupt transfer (to poll the keyboard for a keypress). Dumping the OHCI controller's registers as well as the endpoint and transfer descriptors shows everything set up correctly, however, as best I can tell from the OHCI spec: The descriptors have the right values, the ED is added to the first interrupt list, and the controller even "sees" the ED (the HcPeriodCurrentED register holds its address once per frame). Yet when the timeout expires the TD remains unprocessed, with its condition code still set to "not accessed" and the controller's error counters still at zero. Oddly, control messages are passed to the keyboard just fine. It's as though the controller is simply ignoring the periodic list, even though the bit to enable its processing is set in the HcControl register. Plugging in an external keyboard (after updating the build configuration to include the right phy driver) produces the same result, so it's not just the built-in one. And obviously the OHCI driver works on other platforms, so it seems to me this could be something specific to Rockchip's implementation not yet reflected in the code. Has anyone found a solution to this? -- Simon South si...@simonsouth.net
[U-Boot] [PATCH 1/1] clk: rockchip: rk3328: Configure CPU clock
Add a call to rk3328_configure_cpu() during initialization to set the
CPU-clock frequency.
Signed-off-by: Simon South
---
arch/arm/include/asm/arch-rockchip/cru_rk3328.h | 3 +++
drivers/clk/rockchip/clk_rk3328.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/include/asm/arch-rockchip/cru_rk3328.h
b/arch/arm/include/asm/arch-rockchip/cru_rk3328.h
index 15b9788d9c..4bf69dbe08 100644
--- a/arch/arm/include/asm/arch-rockchip/cru_rk3328.h
+++ b/arch/arm/include/asm/arch-rockchip/cru_rk3328.h
@@ -66,4 +66,7 @@ enum apll_frequencies {
APLL_600_MHZ,
};
+void rk3328_configure_cpu(struct rk3328_cru *cru,
+ enum apll_frequencies apll_freq);
+
#endif /* __ASM_ARCH_CRU_RK3328_H_ */
diff --git a/drivers/clk/rockchip/clk_rk3328.c
b/drivers/clk/rockchip/clk_rk3328.c
index a89e2ecc4a..4331048a87 100644
--- a/drivers/clk/rockchip/clk_rk3328.c
+++ b/drivers/clk/rockchip/clk_rk3328.c
@@ -282,6 +282,8 @@ static void rkclk_init(struct rk3328_cru *cru)
u32 hclk_div;
u32 pclk_div;
+ rk3328_configure_cpu(cru, APLL_600_MHZ);
+
/* configure gpll cpll */
rkclk_set_pll(cru, CLK_GENERAL, _init_cfg);
rkclk_set_pll(cru, CLK_CODEC, _init_cfg);
--
2.23.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/1] rk3328: clk: Configure CPU clock during initialization
This patch changes the RK3328 CRU driver so it explicitly configures the CPU clock during initialization, through a call to rk3328_configure_cpu(). Previously rk3328_configure_cpu() was implemented but not called from anywhere, which I'm assuming was unintentional. This change matches the RK3399's CRU driver (drivers/clk/rockchip/clk_rk3399.c) by - Invoking the function at the start of rkclk_init() and - Setting the CPU clock to the lowest defined frequency, 600 MHz. It yields no real functional change (the CPU clock is already set to 600 MHz at power-on) but it does make it straightforward to set a higher clock rate at compile time for systems like the ROCK64 that run reliably at higher frequencies. Tested on my ROCK64. Simon South (1): clk: rockchip: rk3328: Configure CPU clock arch/arm/include/asm/arch-rockchip/cru_rk3328.h | 3 +++ drivers/clk/rockchip/clk_rk3328.c | 2 ++ 2 files changed, 5 insertions(+) -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ram: rk3328: Fix loading of skew values
Fix a typo that caused incorrect values to be loaded into the DRAM controller's deskew registers. Signed-off-by: Simon South --- drivers/ram/rockchip/sdram_rk3328.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ram/rockchip/sdram_rk3328.c b/drivers/ram/rockchip/sdram_rk3328.c index 0541bbadf0..e84c9be6a2 100644 --- a/drivers/ram/rockchip/sdram_rk3328.c +++ b/drivers/ram/rockchip/sdram_rk3328.c @@ -394,7 +394,7 @@ static void phy_cfg(struct dram_info *dram, copy_to_reg(PHY_REG(phy_base, 0x70), _params->skew.cs0_dm0_skew[0], 44 * 4); copy_to_reg(PHY_REG(phy_base, 0xc0), - _params->skew.cs0_dm1_skew[0], 44 * 4); + _params->skew.cs1_dm0_skew[0], 44 * 4); } static int update_refresh_reg(struct dram_info *dram) -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] ram: rk3328: Use correct frequency units in function
Fix a pair of tests in phy_dll_bypass_set() that used incorrect units for the DDR frequency, causing the DRAM controller to be misconfigured in most cases. Signed-off-by: Simon South --- drivers/ram/rockchip/sdram_rk3328.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/ram/rockchip/sdram_rk3328.c b/drivers/ram/rockchip/sdram_rk3328.c index 656696ac3c..0541bbadf0 100644 --- a/drivers/ram/rockchip/sdram_rk3328.c +++ b/drivers/ram/rockchip/sdram_rk3328.c @@ -311,12 +311,12 @@ static void phy_dll_bypass_set(struct dram_info *dram, u32 freq) setbits_le32(PHY_REG(phy_base, 0x56), 1 << 4); clrbits_le32(PHY_REG(phy_base, 0x57), 1 << 3); - if (freq <= (400 * MHz)) + if (freq <= 400) /* DLL bypass */ setbits_le32(PHY_REG(phy_base, 0xa4), 0x1f); else clrbits_le32(PHY_REG(phy_base, 0xa4), 0x1f); - if (freq <= (680 * MHz)) + if (freq <= 680) tmp = 2; else tmp = 1; -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] Fix memory instability on ROCK64
These two patches fix small issues with the Rockchip RK3328 SDRAM driver that prevented my PINE64 ROCK64 from booting and running normally using U-Boot's TPL [1]. The first patch updates the phy_dll_bypass_set() function to use the correct units for its DDR-frequency parameter, which is already specified in MHz and does not need converting. This issue caused the DRAM controller to be misconfigured for all but the lowest memory speeds. The second patch fixes an apparent typo in phy_cfg() that caused the DRAM controller's deskew registers to be loaded with incorrect values: Instead of copying from the second 44-element portion of the skew-value array the driver instead re-used a portion of the first. This also produced instability. With both these patches applied my ROCK64 boots and runs normally using the U-Boot TPL and a memory frequency of either 800 or 933 MHz: In both cases the "mtest" memory-test command runs indefinitely without error, and I can boot into NetBSD successfully without the kernel hanging or panicking. [1] https://lists.denx.de/pipermail/u-boot/2019-September/384076.html Simon South (2): ram: rk3328: Use correct frequency units in function ram: rk3328: Fix loading of skew values drivers/ram/rockchip/sdram_rk3328.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] tiny-printf: Support vsnprintf()
Add a simple implementation of this function, to allow logging to be
enabled in the SPL or TPL for systems that rely on the tiny printf()
implementation.
To keep the code size small,
- The function is built only when logging is enabled, as it
(currently) is not needed otherwise; and
- Like the existing implementation of snprintf(), its buffer-size
parameter is ignored.
Signed-off-by: Simon South
---
lib/tiny-printf.c | 16
1 file changed, 16 insertions(+)
diff --git a/lib/tiny-printf.c b/lib/tiny-printf.c
index ebef92fc9f..62e6381961 100644
--- a/lib/tiny-printf.c
+++ b/lib/tiny-printf.c
@@ -366,6 +366,22 @@ int sprintf(char *buf, const char *fmt, ...)
return ret;
}
+#if CONFIG_IS_ENABLED(LOG)
+/* Note that size is ignored */
+int vsnprintf(char *buf, size_t size, const char *fmt, va_list va)
+{
+ struct printf_info info;
+ int ret;
+
+ info.outstr = buf;
+ info.putc = putc_outstr;
+ ret = _vprintf(, fmt, va);
+ *info.outstr = '\0';
+
+ return ret;
+}
+#endif
+
/* Note that size is ignored */
int snprintf(char *buf, size_t size, const char *fmt, ...)
{
--
2.23.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] common: Kconfig: Fix typo in TPL_LOG_CONSOLE description
Signed-off-by: Simon South --- common/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/Kconfig b/common/Kconfig index 28d5e9a0cc..d9ecf79e0a 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -764,7 +764,7 @@ config SPL_LOG_CONSOLE line number are omitted. config TPL_LOG_CONSOLE - bool "Allow log output to the console in SPL" + bool "Allow log output to the console in TPL" depends on TPL_LOG default y help -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] Small fixes to SPL/TPL logging
These two patches fix small issues I encountered when enabling debugging output for U-Boot's TPL. The first fixes a typo in the description of the TPL_LOG_CONSOLE configuration option. The second adds a simple implementation of vsnprintf() to the tiny-printf library. Without this, enabling either SPL or TPL logging for systems (such as the PINE64 ROCK64) that also use the tiny printf() implementation causes the build to fail with error messages like aarch64-linux-gnu-ld.bfd: common/built-in.o: in function `_log': (...)/u-boot/common/log.c:212: undefined reference to `vsnprintf' make[1]: *** [scripts/Makefile.spl:404: spl/u-boot-spl] Error 1 make: *** [Makefile:1762: spl/u-boot-spl] Error 2 To minimize the impact on code size, the function is built only when logging is enabled, as it appears to be unneeded otherwise. Note we could probably shave off a few bytes by having the existing sprintf() and snprintf() functions call vsnprintf() when it's available. I haven't made this change only because it isn't how the existing code is written (printf() could call vprintf(), and snprintf() could call sprintf(), yet neither do) and I assume this is for a reason. Simon South (2): common: Kconfig: Fix typo in TPL_LOG_CONSOLE description tiny-printf: Support vsnprintf() common/Kconfig| 2 +- lib/tiny-printf.c | 16 2 files changed, 17 insertions(+), 1 deletion(-) -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] help with serial on the rockchip64
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 si...@simonsouth.net ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] help with serial on the rockchip64
On 2019-09-24 5:41 p.m., Sérgio de Almeida Lenzi wrote: D:0x805 Y In LPDDR3 333MHz > ... This is output from Rockchip's binary-only loader, which always resets the UART speed to 1.5Mbps. But it should be running before the U-Boot SPL, not after it. How are you building the microSD-card image? Here are the commands I've been using to build working images for the ROCK64: Building U-Boot (note this will overwrite your configuration with the contents of the defconfig file): make distclean; rm -f idbloader.img make rock64-rk2238_defconfig all u-boot.itb Assembling an image with the Rockchip loader: tools/mkimage -n rk3328 -T rksd -d ~/src/rockchip-linux/rkbin/bin/rk33/rk3328_ddr_333MHz_v1.16.bin idbloader.img cat spl/u-boot-spl.bin >> idbloader.img Writing it to the microSD card: sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384 -- Simon South si...@simonsouth.net ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-24 2:35 p.m., Matwey V. Kornilov wrote> How do you take NetBSD image? I've been building my own images from NetBSD-CURRENT, following the guides [1][2]. There was until recently a buffer-alignment issue in NetBSD's EFI bootloader that prevented it from working with the current version of U-Boot, but a fix has been committed so something like the following should now work, without patching: cd /usr/src # or $HOME/netbsd/usr/src, etc. cvs update -A -dP -C -D '20190922 1140Z' ./build.sh -U -u -m evbarm64 release Then write the resulting image to a microSD card with zcat obj/releasedir/evbarm/binary/gzimg/arm64.img.gz | sudo dd bs=32768 of=/dev/mmcblk0 skip=512 seek=512 and build and install U-Boot as in my previous email. [1] https://netbsd.org/docs/current/index.html [2] https://netbsd.org/docs/guide/en/chap-build.html -- Simon South si...@simonsouth.net ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-24 12:54 p.m., Matwey V. Kornilov wrote: Simon, maybe you'll describe a way to obtain SD card image which you use? For the case if anybody wants to reproduce the issue in situ? Sure---I'd love for other people to test this, and it's pretty easy since it doesn't require anything other than U-Boot itself. Assuming the CROSS_COMPILE and BL31 environment variables are set up appropriately (I'm using ATF 2.1 from the mainline repository): 1. Switch to U-Boot's master branch and/or configure the source tree identically to my own with git checkout a9fa70b7b7167487affc5d919e541872c99e814b 2. Apply the attached patch, which enables the "mtest" command, with patch -p1 < rock64-enable-mtest.patch 3. Build U-Boot as usual: make distclean; rm -f ./idbloader.img make rock64-rk3328_defconfig all u-boot.itb 4. Write U-Boot to a microSD card as usual: sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384 5. Place the microSD card in the ROCK64 and start it. Once the SPL loads, hit the spacebar to enter the shell and start the memory test with mtest On my ROCK64, this immediately begins throwing off errors like FAILURE (read/write) @ 0x020014c0: expected 0x0299, actual 0x0219) and if I continue the boot process with "boot", the NetBSD kernel will load but panic almost immediately. Note mine is a ROCK64 v2.0 with a 32Gb SpecTek LPDDR3 memory module---there is also a ROCK64 v3.0 and some variance in the memory chips used, so it could be this is limited to a specific model or production run. Now here's what I've discovered lately: Everything works normally if I have U-Boot TPL's set a slightly lower clock rate for the memory, by editing arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi and changing the "800" on line 27 to "766". That suggests a hardware issue with my ROCK64, and in fact others have reported similar problems with the 2.0 version [1]. I'd be willing to leave it at that, except that if I also patch the (333MHz) Rockchip TPL to set a _higher_ clock rate for the memory, it continues to work just fine---all the way up to 933MHz! So this is not just a hardware problem; there is some incompatibility between the RK3328 SDRAM driver as it exists in U-Boot and at least one group of ROCK64s in the world. At the moment I'm still trying to identify what's different in the closed-source loader that causes it not to have this issue. Anyone have any thoughts? [1] https://forum.pine64.org/showthread.php?tid=7387 -- Simon South si...@simonsouth.net diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index 3ab0af1158..90061498c9 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -28,6 +28,8 @@ CONFIG_SPL_ATF=y CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y +CONFIG_CMD_MEMTEST=y +CONFIG_SYS_ALT_MEMTEST=y CONFIG_CMD_MMC=y CONFIG_CMD_SF=y CONFIG_CMD_USB=y diff --git a/include/configs/rk3328_common.h b/include/configs/rk3328_common.h index 3ff3331c80..3c09fd94b9 100644 --- a/include/configs/rk3328_common.h +++ b/include/configs/rk3328_common.h @@ -29,6 +29,9 @@ #define CONFIG_SYS_SDRAM_BASE 0 #define SDRAM_MAX_SIZE 0xff00 +#define CONFIG_SYS_MEMTEST_START 0x0200 +#define CONFIG_SYS_MEMTEST_END 0x03ff + #ifndef CONFIG_SPL_BUILD #define ENV_MEM_LAYOUT_SETTINGS \ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-19 4:56 a.m., Simon South wrote: 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... This definitely seems memory-related: After enabling the "mtest" command (patch attached) and running the memory test at the U-Boot shell I see all kinds of errors: Testing 0200 ... 03ff: Iteration: 1 FAILURE (read/write) @ 0x020014c0: expected 0x0299, actual 0x0219) FAILURE (read/write) @ 0x02001580: expected 0x02b1, actual 0x0231) FAILURE (read/write) @ 0x02001680: expected 0x02d1, actual 0x0251) FAILURE (read/write) @ 0x02001e40: expected 0x03c9, actual 0x0349) ... Using the Rockchip TPL instead the memory test runs fine. Is anyone else able to reproduce this? My guess is the supplied configuration parameters (in arch/arm/dts/rk3328-sdram-lpddr3-1600.dtsi) for the RK3328's SDRAM controller aren't a match for the SpecTek LPDDR3 module on the 4GB ROCK64. (The Rockchip TPL seems to apply a different configuration, but also claims to drive the memory at only 333MHz.) Assuming I'm on the right track here, what's the likelihood I'd be able to determine from the SpecTek datasheet how the SDRAM controller's configuration should be tweaked to get this working? -- Simon South si...@simonsouth.net diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index 3ab0af1158..90061498c9 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -28,6 +28,8 @@ CONFIG_SPL_ATF=y CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y +CONFIG_CMD_MEMTEST=y +CONFIG_SYS_ALT_MEMTEST=y CONFIG_CMD_MMC=y CONFIG_CMD_SF=y CONFIG_CMD_USB=y diff --git a/include/configs/rk3328_common.h b/include/configs/rk3328_common.h index 3ff3331c80..3c09fd94b9 100644 --- a/include/configs/rk3328_common.h +++ b/include/configs/rk3328_common.h @@ -29,6 +29,9 @@ #define CONFIG_SYS_SDRAM_BASE 0 #define SDRAM_MAX_SIZE 0xff00 +#define CONFIG_SYS_MEMTEST_START 0x0200 +#define CONFIG_SYS_MEMTEST_END 0x03ff + #ifndef CONFIG_SPL_BUILD #define ENV_MEM_LAYOUT_SETTINGS \ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-21 8:29 a.m., Matwey V. Kornilov wrote:
Could you try to load dtb (and check that dtb is valid) into the other
memory location?
Same result: With the U-Boot TPL this fails (the FDT header is corrupt);
with the Rockchip TPL this works fine. See below.
I notice though it always seems to be only that one single bit (bit 7 of
the first 32-bit word loaded) that differs between the two runs.
Everything else in memory looks fine. And with the U-Boot TPL in use I
can manually set a new value for that word, and it seems to stick:
=> md ${kernel_addr_r} 2
0208: edfe0d50 09d1 P...
=> fdt addr ${kernel_addr_r}
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
=> nm ${kernel_addr_r}
0208: edfe0d50 ? edfe0dd0
0208: edfe0dd0 ? q
=> md ${kernel_addr_r} 2
0208: edfe0dd0 09d1
=> fdt addr ${kernel_addr_r}
=>
I wonder if this is a clue as to what's going on.
--
U-Boot TPL:
Hit any key to stop autoboot: 0
=> print kernel_addr_r
kernel_addr_r=0x0208
=> md ${kernel_addr_r} 20
0208: ad8a ea22286a baa0aeae aa7aa1aaj("...z.
02080010: a8b200ab abaa000a a8a2aa08 aa88aaea
02080020: e92a00a3 2aacf8aa e8fa ab88..**
02080030: aaa8a0aa 2aaa 22a5e2ba 8aea4a3c...*..." load mmc 1 ${kernel_addr_r} /dtb/rockchip/rk3328-rock64.dtb
53513 bytes read in 10 ms (5.1 MiB/s)
=> md ${kernel_addr_r} 20
0208: edfe0d50 09d1 3800 70baP..8...p
02080010: 2800 1100 1000 ...(
02080020: 9912 38ba ...8
02080030: 0100
02080040: 0300 1e00 656e6970pine
02080050: 722c3436 366b636f 6f720034 68636b6364,rock64.rockch
02080060: 722c7069 326b 0038 0300ip,rk3328...
02080070: 0400 0b00 0100 0300
=> fdt addr ${kernel_addr_r}
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
=>
Rockchip TPL:
Hit any key to stop autoboot: 0
=> print kernel_addr_r
kernel_addr_r=0x0208
=> md ${kernel_addr_r} 20
0208: ad9a ea23286a baa8aeae aa7aa3aaj(#...z.
02080010: aaf200ab abaa080a a8b2aa88 aa88aafa
02080020: e92a4ca3 aafcf8aa e8fa ab88.L*.
02080030: aaa8a0aa 2aea888b e2a5ebfa abea6abe...*.j..
02080040: abb188aa a29aac4a 8aaa 8eee8caeJ...
02080050: d2ce aaa4feea ea8a6ebe eaa38b8a.n..
02080060: aee4b2a9 aaacaaba aaea8ab8 3aeeb8aa...:
02080070: aaa1aaae aaeeab9e aeae8ce8 ae2e8aaa
=> load mmc 1 ${kernel_addr_r} /dtb/rockchip/rk3328-rock64.dtb
53513 bytes read in 10 ms (5.1 MiB/s)
=> md ${kernel_addr_r} 20
0208: edfe0dd0 09d1 3800 70ba...8...p
02080010: 2800 1100 1000 ...(
02080020: 9912 38ba ...8
02080030: 0100
02080040: 0300 1e00 656e6970pine
02080050: 722c3436 366b636f 6f720034 68636b6364,rock64.rockch
02080060: 722c7069 326b 0038 0300ip,rk3328...
02080070: 0400 0b00 0100 0300....
=> fdt addr ${kernel_addr_r}
=>
--
Simon South
si...@simonsouth.net
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-21 3:47 a.m., Matwey V. Kornilov wrote: Could you please try to revert this commit and see what's happening then? Unfortunately undoing that change makes things worse: Either the NetBSD EFI bootloader hangs immediately on start (without any output) or it crashes with output like "Synchronous Abort" handler, esr 0x9644 elr: fd1ad760 lr : fd1ac030 (reloc) elr: fbeeb760 lr : fbeea030 x0 : fcf679a0 x1 : fef3e628 x2 : x3 : fbf17408 (...) In either case I still see the "FDT_ERR_BADMAGIC" messages from U-Boot. Applying Elaine's patches for RK805 support makes no difference. Complete log attached. -- Simon South si...@simonsouth.net U-Boot TPL 2019.10-rc3-00361-ga9fa70b7b7-dirty (Sep 21 2019 - 07:45:04) LPDDR3 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc3-00361-ga9fa70b7b7-dirty (Sep 21 2019 - 07:45:04 -0400) Trying to boot from MMC2 Card did not respond to voltage select! spl: mmc init failed with error: -95 Trying to boot from MMC1 NOTICE: BL31: v2.1(release):v2.1-678-g2fc6ffc4-dirty NOTICE: BL31: Built : 12:10:07, Sep 12 2019 ERROR: over or zero region, nr=4187432, max=10 NOTICE: BL31:Rockchip release version: v1.2 U-Boot 2019.10-rc3-00361-ga9fa70b7b7-dirty (Sep 21 2019 - 07:46:10 -0400) Model: Pine64 Rock64 DRAM: 4 GiB MMC: rksdmmc@ff50: 1, rksdmmc@ff52: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In:serial@ff13 Out: serial@ff13 Err: serial@ff13 Model: Pine64 Rock64 Net: Warning: ethernet@ff54 (eth0) using random MAC address - 92:21:88:52:60:47 eth0: ethernet@ff54 Hit any key to stop autoboot: 2 1 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... 53513 bytes read in 16 ms (3.2 MiB/s) Found EFI removable media binary efi/boot/bootaa64.efi libfdt fdt_check_header(): FDT_ERR_BADMAGIC Scanning disk rksd...@ff50.blk... Card did not respond to voltage select! Scanning disk rksd...@ff52.blk... Disk rksd...@ff52.blk not ready Found 3 disks BootOrder not defined EFI boot manager: Cannot load any image 205136 bytes read in 35 ms (5.6 MiB/s) libfdt fdt_check_header(): FDT_ERR_BADMAGIC U-Boot TPL 2019.10-rc3-00361-ga9fa70b7b7-dirty (Sep 21 2019 - 07:45:04) LPDDR3 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc3-00361-ga9fa70b7b7-dirty (Sep 21 2019 - 07:45:04 -0400) Trying to boot from MMC2 Card did not respond to voltage select! spl: mmc init failed with error: -95 Trying to boot from MMC1 NOTICE: BL31: v2.1(release):v2.1-678-g2fc6ffc4-dirty NOTICE: BL31: Built : 12:10:07, Sep 12 2019 ERROR: over or zero region, nr=4187432, max=10 NOTICE: BL31:Rockchip release version: v1.2 U-Boot 2019.10-rc3-00361-ga9fa70b7b7-dirty (Sep 21 2019 - 07:46:10 -0400) Model: Pine64 Rock64 DRAM: 4 GiB MMC: rksdmmc@ff50: 1, rksdmmc@ff52: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In:serial@ff13 Out: serial@ff13 Err: serial@ff13 Model: Pine64 Rock64 Net: Warning: ethernet@ff54 (eth0) using random MAC address - fe:f0:6b:1f:55:ce eth0: ethernet@ff54 Hit any key to stop autoboot: 2 1 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... 53513 bytes read in 16 ms (3.2 MiB/s) Found EFI removable media binary efi/boot/bootaa64.efi Scanning disk rksd...@ff50.blk... Card did not respond to voltage select! Scanning disk rksd...@ff52.blk... Disk rksd...@ff52.blk not ready Found 3 disks BootOrder not defined EFI boot manager: Cannot load any image 205136 bytes read in 35 ms (5.6 MiB/s) "Synchronous Abort" handler, esr 0x9644 elr: fd1ad760 lr : fd1ac030 (reloc) elr: fbeeb760 lr : fbeea030 x0 : fcf679a0 x1 : fef3e628 x2 : x3 : fbf17408 x4 : x5 : 0018 x6 : fcf679a0 x7 : fefa8a00 x8 : fbee x9 : 0008 x10: 0001 x11: fcf29acc x12: 00c0 x13: fcf29a8c x14: 080ef000 x15: 0002 x16: fef41c54 x17: x18: x19: fef3e628 x20: fcf29e30 x21: x22: fefa8a00 x23: fef3e628 x24: fefec000 x25: fefec000 x26: x27: x28: fcf5d250 x29: fcf29d80 UEFI image [0xfbee9000:0xfbf17fff] pc=0x2760 '/efi\boot\bootaa64.efi' Resetting CPU ... resetting ... U-Boot TPL 2019.10-rc3-00361-ga9fa70b7b7-dirty (Sep 21 2019 - 07:45:04) LPDDR3 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc3-00361-ga9fa70b7b7-dirty (Sep 21 2019 - 07:45:04 -0400) Try
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-20 1:27 p.m., Simon South wrote: I'm going to apply Elaine's patches and see if that changes things. Unfortunately no; other than this line now appearing in the output: PMIC: RK8050 (on=0x10, off=0x04) nothing seems to have changed. Either the machine hangs or NetBSD's kernel panics. -- Simon South si...@simonsouth.net ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-20 1:37 p.m., Matwey V. Kornilov wrote: What is the difference? In filesize? The EFI bootloader: 205136 bootaa64.efi The DTB file: 53513 rk3328-rock64.dtb It's about one quarter the size. It is strange the EFI bootloader and the kernel both seem always to load reliably when the DTB file doesn't. -- => ls mmc 1 /EFI/BOOT/ ./ ../ 205136 bootaa64.efi 1 file(s), 2 dir(s) => ls mmc 1 /dtb/rockchip/ ./ ../ 77017 rk3399-sapphire.dtb 81304 rk3399-sapphire-excavator.dtb 78646 rk3399-rockpro64.dtb 77846 rk3399-rock960.dtb 76155 rk3399-rock-pi-4.dtb 77701 rk3399-roc-pc.dtb 78035 rk3399-puma-haikou.dtb 78483 rk3399-nanopi-m4.dtb 78791 rk3399-nanopc-t4.dtb 86532 rk3399-gru-scarlet-kd.dtb 86507 rk3399-gru-scarlet-inx.dtb 89522 rk3399-gru-kevin.dtb 85495 rk3399-gru-bob.dtb 80312 rk3399-firefly.dtb 78519 rk3399-ficus.dtb 68842 rk3399-evb.dtb 53513 rk3328-rock64.dtb 52150 rk3328-roc-cc.dtb 51134 rk3328-evb.dtb 19 file(s), 2 dir(s) => -- Simon South si...@simonsouth.net ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-20 12:43 p.m., Matwey V. Kornilov wrote:
Could you please use u-boot console and try to locate and load dtb
file manually using `ls` and `load` commands in both scenarios?
Results attached.
I'm using a regular microSD card, not eMMC, but you're right: Using the
U-Boot TPL the DTB file isn't loaded correctly; it's placed in memory
but the data is corrupt:
=> md ${fdt_addr_r}
01f0: ad8a ea22282a baa0aeae aa7aa3aa*("...z.
01f00010: a8a200ab abaa000a a8a2aa08 aa88aafa
01f00020: e92a00a3 aabcf8a8 e8fa ab88..*.
01f00030: aaa8a0aa 2aa8088a 22a5e3ba 8bea4abe...*...".J..
01f00040: 23b188aa a20aa84a 82aa 8eee8cae...#J...
01f00050: 924a aaa4feaa aa8a2eae eaa38b8aJ...
01f00060: aae4b2a8 aaacaaba aaea8ab8 2aeeb82a*..*
(...)
=> load mmc 1 ${fdt_addr_r} /dtb/rockchip/rk3328-rock64.dtb
53513 bytes read in 10 ms (5.1 MiB/s)
=> md ${fdt_addr_r}
01f0: edfe0d50 09d1 3800 70baP..8...p
01f00010: 2800 1100 1000 ...(
01f00020: 9912 38ba ...8
01f00030: 0100
01f00040: 0300 1e00 656e6970pine
01f00050: 722c3436 366b636f 6f720034 68636b6364,rock64.rockch
01f00060: 722c7069 326b 0038 0300ip,rk3328...
(...)
=> fdt addr ${fdt_addr_r}
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
=>
Note the magic number at the start, which should be "edfe0dd0".
When the Rockchip TPL is used the same DTB file loads without issue, and
the magic number is correct.
My current theory (following Mark Kettenis' email) is that all this is
due to U-Boot's not configuring the RK805 PMIC on the ROCK64. The device
tree suggests it's used to regulate power to the DRAM and is expected to
be set up at pre-boot:
vcc_ddr: DCDC_REG3 {
regulator-name = "vcc_ddr";
regulator-always-on;
regulator-boot-on;
regulator-state-mem {
regulator-on-in-suspend;
};
};
However I see only yesterday Elaine Zhang posted patches that enable
support in U-Boot for the RK805, which makes me think this isn't taking
place currently. And while NetBSD includes its own RK805 driver it is
likely assuming this setup has already happened ("regulator-boot-on") by
the time the kernel starts and does not need to be done again.
Does this sound reasonable?
I'm going to apply Elaine's patches and see if that changes things.
--
Simon South
si...@simonsouth.net
U-Boot TPL 2019.10-rc3-00361-ga9fa70b7b7 (Sep 20 2019 - 04:55:01)
LPDDR3
Trying to boot from BOOTROM
Returning to boot ROM...
U-Boot SPL 2019.10-rc3-00361-ga9fa70b7b7 (Sep 20 2019 - 04:55:01 -0400)
Trying to boot from MMC2
Card did not respond to voltage select!
spl: mmc init failed with error: -95
Trying to boot from MMC1
NOTICE: BL31: v2.1(release):v2.1-678-g2fc6ffc4-dirty
NOTICE: BL31: Built : 12:10:07, Sep 12 2019
ERROR: over or zero region, nr=4187432, max=10
NOTICE: BL31:Rockchip release version: v1.2
U-Boot 2019.10-rc3-00361-ga9fa70b7b7 (Sep 20 2019 - 04:56:02 -0400)
Model: Pine64 Rock64
DRAM: 4 GiB
MMC: rksdmmc@ff50: 1, rksdmmc@ff52: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In:serial@ff13
Out: serial@ff13
Err: serial@ff13
Model: Pine64 Rock64
Net:
Warning: ethernet@ff54 (eth0) using random MAC address - 9a:fd:d8:85:88:9f
eth0: ethernet@ff54
Hit any key to stop autoboot: 2 0
=> md ${fdt_addr_r}
01f0: ad8a ea22282a baa0aeae aa7aa3aa*("...z.
01f00010: a8a200ab abaa000a a8a2aa08 aa88aafa
01f00020: e92a00a3 aabcf8a8 e8fa ab88..*.
01f00030: aaa8a0aa 2aa8088a 22a5e3ba 8bea4abe...*...".J..
01f00040: 23b188aa a20aa84a 82aa 8eee8cae...#J...
01f00050: 924a aaa4feaa aa8a2eae eaa38b8aJ...
01f00060: aae4b2a8 aaacaaba aaea8ab8 2aeeb82a*..*
01f00070: aaa0aaac aaeeab9a aeae84c8 ac2e8aaa
01f00080: 88a2 8a8a98a8 aee8aacc 686aa880..jh
01f00090: acaa8a8a ac8eaec4 eaaaec80 ca8c
01f000a0: 28acaacd aae88a8a aba88e89 aaa8aaa8...(
01f000b0: 122caca4 a24eacc8 abea8cca 8aa0aa6e..,...N.n...
01f000c0: ea08988a aaacc8ca ee8eac8c 2488e89a...$
01f000d0: c22ca84e 82a98a8c 88e888ae 8ac0aa92N.,.
01f000e0: a8a8a289 aeaaa8c8 8ccceacb aaeaee84
01f000f0: 2feaa947 aae2a628 a3c688a8 ceaee8a9G../(...
=> ls mmc 1 /dtb/rockchip
./
../
77017 rk3399-sapphire.dtb
81304 rk3399-sapphire-excavator.dtb
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-20 6:03 a.m., Mark Kettenis wrote: One thing to look at is whether (voltage) regulators and/or clocks are set up right... Thanks, Mark. This is helpful. But I believe the Linux kernel doesn't trust the bootloader and will configure such a regulator anyway. This is my assumption right now as well, that Linux is itself configuring the RK3328 "correctly" and either the U-Boot TPL or the NetBSD kernel needs to be updated to do the same thing. I'm going to grab the Linux source and see if I can spot anything it does at startup that's missing from the TPL. Using the U=boot "dm" commands you can check whether drivers for various regulators are enabled. I tried capturing the output of these commands when each TPL is used and comparing them. Unfortunately nothing jumps out: After booting with U-Boot's TPL "dm tree" shows additional entries for the S/PDIF and MMC controllers, and when booting with Rockchip's TPL a (possibly spurious) "Initializing UCLASS_EFI" message is output, but otherwise they're the same. I've attached the two capture logs in case anyone is curious. -- Simon South si...@simonsouth.net dm tree Class Index Probed DriverName --- root 0 [ + ] root_driver root_driver firmware 0 [ ] psci |-- psci clk 0 [ + ] fixed_rate_clock |-- xin24m syscon 0 [ + ] rk3328_syscon |-- syscon@ff10 serial 0 [ + ] ns16550_serial|-- serial@ff13 syscon 1 [ ] syscon|-- power-management@ff14 i2c 0 [ ] i2c_rockchip |-- i2c@ff16 simple_bus 0 [ ] generic_simple_bus|-- amba clk 1 [ + ] rockchip_rk3328_cru |-- clock-controller@ff44 sysreset 0 [ ] rockchip_sysreset | `-- sysreset mmc 0 [ + ] rockchip_rk3288_dw_m |-- rksdmmc@ff50 blk 0 [ + ] mmc_blk | `-- rksd...@ff50.blk mmc 1 [ + ] rockchip_rk3288_dw_m |-- rksdmmc@ff52 blk 1 [ ] mmc_blk | `-- rksd...@ff52.blk eth 0 [ + ] gmac_rockchip |-- ethernet@ff54 usb 0 [ ] ehci_generic |-- usb@ff5c usb 1 [ ] ohci_generic |-- usb@ff5d usb 2 [ ] dwc2_usb |-- usb@ff58 pinctrl 0 [ + ] rockchip_rk3328_pinc |-- pinctrl gpio 0 [ + ] gpio_rockchip | |-- gpio0@ff21 gpio 1 [ + ] gpio_rockchip | |-- gpio1@ff22 gpio 2 [ ] gpio_rockchip | |-- gpio2@ff23 gpio 3 [ ] gpio_rockchip | |-- gpio3@ff24 pinconfig0 [ ] pinconfig | |-- pcfg-pull-up pinconfig1 [ ] pinconfig | |-- pcfg-pull-down pinconfig2 [ ] pinconfig | |-- pcfg-pull-none pinconfig3 [ ] pinconfig | |-- pcfg-pull-none-2ma pinconfig4 [ ] pinconfig | |-- pcfg-pull-up-2ma pinconfig5 [ ] pinconfig | |-- pcfg-pull-up-4ma pinconfig6 [ ] pinconfig | |-- pcfg-pull-none-4ma pinconfig7 [ ] pinconfig | |-- pcfg-pull-down-4ma pinconfig8 [ ] pinconfig | |-- pcfg-pull-none-8ma pinconfig9 [ ] pinconfig | |-- pcfg-pull-up-8ma pinconfig 10 [ ] pinconfig | |-- pcfg-pull-none-12ma pinconfig 11 [ ] pinconfig | |-- pcfg-pull-up-12ma pinconfig 12 [ ] pinconfig | |-- pcfg-output-high pinconfig 13 [ ] pinconfig | |-- pcfg-output-low pinconfig 14 [ ] pinconfig | |-- pcfg-input-high pinconfig 15 [ ] pinconfig | |-- pcfg-input pinconfig 16 [ ] pinconfig | |-- i2c0 pinconfig 17 [ ] pinconfig | | `-- i2c0-xfer pinconfig 18 [ ] pinconfig | |-- i2c1 pinconfig 19 [ ] pinconfig | | `-- i2c1-xfer pinconfig 20 [ ] pinconfig | |-- i2c2 pinconfig 21 [ ] pinconfig | | `-- i2c2-xfer pinconfig 22 [ ] pinconfig | |-- i2c3 pinconfig 23 [ ] pinconfig | | |-- i2c3-xfer pinconfig 24 [ ] pinconfig | | `-- i2c3-gpio pinconfig 25 [ ] pinconfig | |-- hdmi_i2c pinconfig 26 [ ] pinconfig | | `-- hdmii2c-xfer pinconfig 27 [ ] pinconfig | |-- uart0 pinconfig 28 [ ] pinconfig | | |-- uart0-xfer pinconfig 29 [ ] pinconfig | | |-- uart0-cts pinconfig 30 [ ] pinconfig | | |-- uart
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-20 3:39 a.m., Matwey V. Kornilov wrote: Could you please provide us console logs for both successful and unsuccessful cases? Attached. The only differences I see are - The random Ethernet address assigned in each case, and - The "FDT_ERR_BADMAGIC" error messages that are output only when the U-Boot TPL is used. -- Simon South si...@simonsouth.net DDR version 1.16 20190528 ID:0x805 Y In LPDDR3 333MHz Bus Width=32 Col=11 Bank=8 Row=15/15 CS=2 Die Bus-Width=32 Size=4096MB ddrconfig:7 OUT U-Boot SPL 2019.10-rc3-00361-ga9fa70b7b7 (Sep 20 2019 - 04:55:01 -0400) Trying to boot from MMC2 Card did not respond to voltage select! spl: mmc init failed with error: -95 Trying to boot from MMC1 NOTICE: BL31: v2.1(release):v2.1-678-g2fc6ffc4-dirty NOTICE: BL31: Built : 12:10:07, Sep 12 2019 ERROR: over or zero region, nr=4187432, max=10 NOTICE: BL31:Rockchip release version: v1.2 U-Boot 2019.10-rc3-00361-ga9fa70b7b7 (Sep 20 2019 - 04:56:02 -0400) Model: Pine64 Rock64 DRAM: 4 GiB MMC: rksdmmc@ff50: 1, rksdmmc@ff52: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In:serial@ff13 Out: serial@ff13 Err: serial@ff13 Model: Pine64 Rock64 Net: Warning: ethernet@ff54 (eth0) using random MAC address - 36:69:6f:cb:26:ed eth0: ethernet@ff54 Hit any key to stop autoboot: 2 1 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1 is current device Scanning mmc 1:1... 53513 bytes read in 10 ms (5.1 MiB/s) Found EFI removable media binary efi/boot/bootaa64.efi Scanning disk rksd...@ff50.blk... Card did not respond to voltage select! Scanning disk rksd...@ff52.blk... Disk rksd...@ff52.blk not ready Found 3 disks BootOrder not defined EFI boot manager: Cannot load any image 205136 bytes read in 17 ms (11.5 MiB/s) |/-\|/- >> NetBSD/evbarm EFI Boot (aarch64), Revision 1.11 (Wed Sep 18 15:50:45 UTC >> 2019) (from NetBSD 9.99.12) Press return to boot now, any other key for boot prompt booting netbsd - starting in 5 seconds. 4 seconds. 3 seconds. 2 seconds. 1 seconds. 0 seconds. \|/-\|/-\|/-\6100056|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\+2730512|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/+1985652-\|/-\|/-\|/-\|/-\|/-\|/-\|/-\|/+1823764-\ [701640|/-\|/-\|/-+490622\|/-\|/]=0xec5b00 [ 1.000] NetBSD/evbarm (fdt) booting ... [ 1.000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, [ 1.000] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, [ 1.000] 2018, 2019 The NetBSD Foundation, Inc. All rights reserved. [ 1.000] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.000] The Regents of the University of California. All rights reserved. [ 1.000] NetBSD 9.99.12 (GENERIC64) #16: Wed Sep 18 12:30:03 EDT 2019 [ 1.000] ssouth@laptop:/usr/src/sys/arch/evbarm/compile/obj/GENERIC64 [ 1.000] total memory = 4064 MB [ 1.000] avail memory = 3918 MB [ 1.000] armfdt0 (root) [ 1.000] simplebus0 at armfdt0: Pine64 Rock64 [ 1.000] cpus0 at simplebus0 [ 1.000] simplebus1 at simplebus0 [ 1.000] simplebus2 at simplebus0 [ 1.000] cpu0 at cpus0: Cortex-A53 r0p4 (Cortex V8-A core) [ 1.000] cpu0: package 0, core 0, smt 0 [ 1.000] cpu0: IC enabled, DC enabled, EL0/EL1 stack Alignment check enabled [ 1.000] cpu0: Cache Writeback Granule 16B, Exclusives Reservation Granule 16B [ 1.000] cpu0: Dcache line 64, Icache line 64 ... U-Boot TPL 2019.10-rc3-00361-ga9fa70b7b7 (Sep 20 2019 - 04:55:01) LPDDR3 Trying to boot from BOOTROM Returning to boot ROM... U-Boot SPL 2019.10-rc3-00361-ga9fa70b7b7 (Sep 20 2019 - 04:55:01 -0400) Trying to boot from MMC2 Card did not respond to voltage select! spl: mmc init failed with error: -95 Trying to boot from MMC1 NOTICE: BL31: v2.1(release):v2.1-678-g2fc6ffc4-dirty NOTICE: BL31: Built : 12:10:07, Sep 12 2019 ERROR: over or zero region, nr=4187432, max=10 NOTICE: BL31:Rockchip release version: v1.2 U-Boot 2019.10-rc3-00361-ga9fa70b7b7 (Sep 20 2019 - 04:56:02 -0400) Model: Pine64 Rock64 DRAM: 4 GiB MMC: rksdmmc@ff50: 1, rksdmmc@ff52: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In:serial@ff13 Out: serial@ff13 Err: serial@ff13 Model: Pine64 Rock64 Net: Warning: ethernet@ff54 (eth0) using random MAC address - 02:f5:da:18:50:8d eth0: ethernet@ff54 Hit any key to stop autoboot: 2 1 0 Card did not respond to voltage select! switch to partitions #0, OK mmc1 is current device Sca
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-19 12:29 p.m., Jagan Teki wrote: It seems to be a memory overlap or similar. replace TPL with rkbin would be worth checking since the DRAM is managed by rkbin instead of TPL here. rkbin => SPL => U-Boot proper That configuration works and allows NetBSD to boot just fine. It's only when using U-Boot's own TPL that the kernel panics shortly after starting. Can you think of what the difference might be between the two TPLs? -- Simon South si...@simonsouth.net ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] ROCK64 fails to boot using U-Boot TPL
On 2019-09-19 11:48 a.m., Matwey V. Kornilov wrote: I have no idea what is going on. But are you sure that you tested the same u-boot binaries with or without binary TPL? I believe so. Here's how I build U-Boot with its own TPL: make -j2 distclean; rm idbloader.img make -j2 rock64-rk3328_defconfig all u-boot.itb With the Rockchip TPL instead, it's: make -j2 distclean; rm idbloader.img make -j2 rock64-rk3328_defconfig all u-boot.itb tools/mkimage -n rk3328 -T rksd -d ~/src/rockchip-linux/rkbin/bin/rk33/rk3328_ddr_333MHz_v1.16.bin idbloader.img cat spl/u-boot-spl.bin >> idbloader.img In either case I install on the microSD card with sudo dd if=idbloader.img of=/dev/sdb seek=64 sudo dd if=u-boot.itb of=/dev/sdb seek=16384 Does this look right? -- Simon South si...@simonsouth.net ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] ROCK64 fails to boot using U-Boot TPL
c000becd30 kmem_zalloc() at ffc000485dc4
netbsd:kmem_zalloc+0x84
[ 1.000] fp ffc000becd50 module_builtin_add() at
ffc0004432a0 netbsd:module_builtin_add+0x98
[ 1.000] fp ffc000becdf0 module_init() at ffc0004437f8
netbsd:module_init+0xf0
[ 1.000] fp ffc000bece50 main() at ffc0005d0b08
netbsd:main+0x108
[ 1.000] fp aarch64_start() at ffc0183c
netbsd:aarch64_start+0x103c
[ 1.000] cpu0: End traceback...
Stopped in pid 0.1 (system) at netbsd:cpu_Debugger+0x4: ret
db{0}>
--
Simon South
si...@simonsouth.net
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
