Mainline U-Boot with SPI, NVMe and SATA boot support

[hunderteins]

Using HDMI output from U-Boot seems to break HDMI output from mainline Linux until a Linux app runs that changes the video mode, which resets HDMI and gets it working again.

have not tried it yet, but

https://github.com/FireflyTeam/kernel/co...2a296eb0ef

seems to fix this.

[sigmaris]

(1) reboot from linux will not longer work. The machine just stands. Kernel 4.4

I guess you're using Rockchip's BSP 4.4 kernel (or one derived from it like Ayufan's or mrfixit2001's)? I think the Rockchip BSP u-boot (and actually more importantly their binary Trusted Firmware) is probably better matched with Rockchip BSP kernel. The 4.4 kernel is probably making some call to the Rockchip binary firmware to reboot the system, which the open-source ARM Trusted Firmware doesn't interpret properly. All I can say is I have been using this u-boot with 5.x Linux kernels and reboot (with Linux calling TF-A via PSCI to reboot) works successfully.

(2) is this huge (16384 sectors) offset on mmc-u_boot.itb really necessary? mmc_idbloader.img is about 148kB. Do you wanted to go for 0x80000 (1024 sectors) and got 0x800000?

I'm following Rockchip's default partition layout for SD/MMC, if you have a look at the table on that linked page, it places u-boot at 16384 sectors - it could probably go lower as I don't think the "vendor storage" and "reserved" space is used by the fully-open-source boot loader and firmware, but I wanted to stick with what was "standard" to avoid confusion.

[hunderteins]

I guess you're using Rockchip's BSP 4.4 kernel (or one derived from it like Ayufan's or mrfixit2001's)? I think the Rockchip BSP u-boot (and actually more importantly their binary Trusted Firmware) is probably better matched with Rockchip BSP kernel. The 4.4 kernel is probably making some call to the Rockchip binary firmware to reboot the system, which the open-source ARM Trusted Firmware doesn't interpret properly. All I can say is I have been using this u-boot with 5.x Linux kernels and reboot (with Linux calling TF-A via PSCI to reboot) works successfully.

yes, the reboot problem is with the 4.4 kernel from ayufan. The psci is just fine like in linux-mainline-kernel.
But I found the cause in the reboot_notifier of driver/cpufreq/rockchip-cpufreq.c
This driver is missing from linux-mainline-kernel.
When disabling CONFIG_ARM_ROCKCHIP_CPUFREQ the 4.4 kernel reboots just fine with your u-boot.

I guess this is also the reason, why the mainline-kernel runs painfully slow when booting with the old u-boot from ayufan.

[sigmaris]

I guess this is also the reason, why the mainline-kernel runs painfully slow when booting with the old u-boot from ayufan.

The old u-boot from Ayufan set up the "little" Cortex-A53 CPU cores to run at a normal speed but left the "big" Cortex-A72 cores running at only 12MHz (!). During boot, the mainline kernel cpufreq driver does set the big cores to a sensible speed, but this happens quite late in the boot process, after a lot of the previous boot process has run on the very slow "big" CPU cores (because in theory they are meant to be more powerful). That's what makes it slow. The mainline U-Boot initialises all cores to 600MHz (as far as I remember) which makes boot reasonably fast.

[amiraeva]

I have updated the OP with info about a new release, based on mainline U-Boot v2020.01, and now with PCIe SATA drive boot support as well as NVMe.

There are also patches on the U-Boot mailing list which get HDMI output working from U-Boot. I've tested this and it works as expected, but I've not included it in the current build because

• Using HDMI output from U-Boot seems to break HDMI output from mainline Linux until a Linux app runs that changes the video mode, which resets HDMI and gets it working again.
  
• to be properly useful to interact with U-Boot, it'd require a USB keyboard, but starting U-Boot's USB support (required before any keyboard is recognised) takes several seconds, and it doesn't seem worthwhile to slow down every boot with the "usb start" command when normally it's not required.
  

In any case, if anyone is interested, you can see the changes required for HDMI and USB keyboard support in this branch.

I compiled Manjaro's (mainline-ish) u-boot for the PBP and added the additional config lines from your rk3399-hdmi branch, naively hoping I could get the USB keyboard and eDP display to work on boot. It compiled but unfortunately neither the keyboard/LCD display work in uboot or grub; GRUB still says "error: no suitable video mode found" when trying to display on tty1.

Do you have any suggestions on how I can go about getting this to work? Thanks!

[hunderteins]

I compiled Manjaro's (mainline-ish) u-boot for the PBP and added the additional config lines from your rk3399-hdmi branch, naively hoping I could get the USB keyboard and eDP display to work on boot. It compiled but unfortunately neither the keyboard/LCD display work in uboot or grub; GRUB still says "error: no suitable video mode found" when trying to display on tty1.

Do you have any suggestions on how I can go about getting this to work? Thanks!

It's more than just change the config. hdmi-support for rk3399 is a patch from Jagan Teki.

I compiled the hdmi-branch from sigmaris, wrote it to mmc and got a wonderful u-boot-console on hdmi. usb-keyboard was not working, serial did.
So I hit a key to intercept the autoboot. After
=> usb start
the usb-keyboard was working, too.

As sigmaris wrote, usb-init takes time and slows down the boot. So it is not part of autoboot, yet.

After booting the kernel 4.4 I have the same syncing problem with hdmi that I already have with the linux-mainline-kernel. It seems this new hdmi-init in the u-boot-patches and the modern kernels set some frequency or register my monitor doesn't like.

[amiraeva]

I compiled Manjaro's (mainline-ish) u-boot for the PBP and added the additional config lines from your rk3399-hdmi branch, naively hoping I could get the USB keyboard and eDP display to work on boot. It compiled but unfortunately neither the keyboard/LCD display work in uboot or grub; GRUB still says "error: no suitable video mode found" when trying to display on tty1.

Do you have any suggestions on how I can go about getting this to work? Thanks!

It's more than just change the config. hdmi-support for rk3399 is a patch from Jagan Teki.

I compiled the hdmi-branch from sigmaris, wrote it to mmc and got a wonderful u-boot-console on hdmi. usb-keyboard was not working, serial did.
So I hit a key to intercept the autoboot. After
=> usb start
the usb-keyboard was working, too.

As sigmaris wrote, usb-init takes time and slows down the boot. So it is not part of autoboot, yet.

After booting the kernel 4.4 I have the same syncing problem with hdmi that I already have with the linux-mainline-kernel. It seems this new hdmi-init in the u-boot-patches and the modern kernels set some frequency or register my monitor doesn't like.

Thanks - I definitely wouldn't have figured that out! I managed to get the PBP keyboard working after playing around with the configs.

After applying the changes from the hdmi-support branch, and playing around with the config I still wasn't able to get the eDP LCD display for the PBP to work. I might just have to wait until someone smarter than me comes along and writes a patch to have it work out of the box.

[sigmaris]

Thanks - I definitely wouldn't have figured that out! I managed to get the PBP keyboard working after playing around with the configs.

After applying the changes from the hdmi-support branch, and playing around with the config I still wasn't able to get the eDP LCD display for the PBP to work. I might just have to wait until someone smarter than me comes along and writes a patch to have it work out of the box.

Yeah, unfortunately support for the eDP display on RK3399 does not seem to be in U-boot mainline, at least from my understanding. There is a driver for "Rockchip eDP" display support but it seems to be aimed at RK3288 only.

[hunderteins]

When disabling CONFIG_ARM_ROCKCHIP_CPUFREQ the 4.4 kernel reboots just fine with your u-boot.

4.4 kernel without CPUFREQ is no fun. But with the upstream patches for system monitor from Finley Xiao the reboot hang is resolved, too.
Booting from SATA, with HDMI/USB-keyboard to choose the boot-kernel - thank you very much!

[pgwipeout]

Hey @sigmaris have you succeeded at getting the grub-efi to give a menu on a serial console?

All I ever get is this:

Code:

139264 bytes read in 12 ms (11.1 MiB/s)
error: no suitable video mode found.
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: ERROR: Could not determine UEFI Secure Boot status.
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

Edit:
Figured it out, if anyone ever feels like they are nuking something, remember to change this:

Code:

GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0

to

Code:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=2