Manjaro Linux support

Yes, the armbian port uses a 2020 version of u-boot (I forget which one, but it’s in their repos)

Here’s the latest on that DRAM patch:

U-Boot TPL 2021.10-1 (Nov 26 2021 - 15:48:09)
ed!
rk3399_dmc_init DRAM init failed -22
Missing DTB

Progress, I think? I probably need to look more at the changes between the two instead of playing whack-a-mole :sweat_smile:

2 Likes

Right! Better to step back and rethink when in this mode :grinning:

I need to dive into the u-boot options and build process as well and have some nice environment to play with. I used buildrootfs, copied the code and chroot’ed in for building and testing but it is still not so nice. What are you doing in order to work on the u-boot (modification, compilation, testing)?
I am not very familiar with Manjaro and first I tried to use the buildarmimg but this is a very slow process (besides all the setups that I needed to do to get the img build with the new packages) and not very developer friendly when I want to play with u-boot code.
Any hint would be nice.

That’s essentially what I’m doing as well :grimacing: I did make a testing repo to throw new package builds in to make using buildarmimg easier, since you can pass it a custom repo URL (I just threw it in an S3 bucket, basically)

If you can get a bare-metal AArch64 cross-compiler going (clang supposedly works pretty well, but I got hung-up on dependencies for compiling trusted-firmware), compiling u-boot directly (outside of using buildarmpkg) and writing it directly to the SD is probably faster, e.g.:

make clockworkpi-a06-rk3399_defconfig
make all u-boot.itb

# Replace /dev/mmcblk0 w/ whatever device has the SD card on your machine
sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64
sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384

This is a good resource for consulting (not all applies, but useful generally for rk3399): https://stikonas.eu/wordpress/2019/09/15/blobless-boot-with-rockpro64/ (site seems to be down for me right now, but it was working earlier) – Archived version: Blobless boot with RockPro64 « Andrius Štikonas

1 Like

Nice. This looks like a good resource. I still need to figure out why the .itb is written with seek=16384. How does the idbloader know that it needs to look at this offset. It seems there some mechanism for it to know where to look.

Btw, I booted the image as well and got the same output but on my terminal I saw an additional error message that got lost in your log:

U-Boot TPL 2021.10-1 (Nov 26 2021 - 18:11:49)
sdram_init: LPDDR3 - 800MHz failed!
rk3399_dmc_init DRAM init failed -22
Missing DTB

Maybe the DRAM config that was choosen is not yet correct to initialize the RAM.

I don’t really see the use case when you can really easily remove the SD card and re image it from another computer?!

Way easier and way more simple to do…

1 Like

These offsets are actually specified by the RK3399 bootrom, I believe: Boot option - Rockchip open source Document

2 Likes

I agree regarding the UART option but I think DFU can still be handy. Nonetheless it is for tinkering and for that purpose anything can be fun.

Oh yeah, sure thing!!

I decided to do more digging into the u-boot on armbian, and here’s the output from Armbian’s u-boot (a bit messed up, but most still readable):

DDR Version 1.24 20191016
In
channel 0
CS = 0
MR0=0x98
MR472
MR14=0x72
MR18=0x0
MR19=0xchannel 0
CS = 0
MR0=0x98
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x
MR19=0x0
MR24=0x8
x725=0xFF
MR14=0x72
MR18=0x0
MR19=0 training pass!
channel 1 trainchannel 0, cs 0, advanced training done
ng done
channel 1, cs 0, advanced training done
ng done
change freq to 856MHz 1ide = 0xD
ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 416MHZ, ctl_inde_index 1
support 416 856 328 66
CPUId = 0x0
ChipType = 0x10, erCapSize=15193MB
FwPartOffset=SecureInit read PBA: 0x804
Secu

U-Boot 2020.10-armbian (Aug el: Clockworkpi A06
DRAM:  3.9 GiB
PMIC:  RK808 
mmc@fe320000: 1, sdhci@fe330000:... select!
*** Warning - No block 
FATAL: read zero bytes from port
term_exitfunc: reset failed for dev UNKNOWN: Input/output error

the DDR Version 1.24 20191016 piece there indicates to me that it’s actually using the Rockchip miniloader instead of the u-boot TPL to load into full u-boot, so it’s possible the memory configuration is not supported in u-boot TPL and we may need to be using the miniloader approach instead, with the correct blob for the DDR configuration. That looks similar to the approach taken for manjaro-arm / packages / core / uboot-pinebookpro-bsp · GitLab, so I’m going to play around with doing something similar (different blobs, device configuration, and probably mainline u-boot still, but similar process for building)

1 Like

Updated to use miniloader (and switched to a shorter USB cable, thanks for the tip!), and the result is better DRAM info, but it doesn’t seem to be passing off to u-boot, so I’ll need to make sure I built and flashed that correctly (u-boot repo has been updated though)

DDR Version 1.25 20210517
In
channel 0
CS = 0
MR0=0x98
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
CS = 1
MR0=0x18
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 1
CS = 0
MR0=0x98
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
CS = 1
MR0=0x18
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB
256B stride
channel 0
CS = 0
MR0=0x98
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
CS = 1
MR0=0x18
MR4=0x81
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 1
CS = 0
MR0=0x98
MR4=0x1
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
CS = 1
MR0=0x18
MR4=0x3
MR5=0xFF
MR8=0x8
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0xFF
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 0, cs 1, advanced training done
channel 1, cs 0, advanced training done
channel 1, cs 1, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x2020
ch 1 ddrconfig = 0x101, ddrsize = 0x2020
pmugrf_os_reg[2] = 0x3AA1FAA1, stride = 0xD
ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 416MHZ, ctl_index 0
ddr_set_rate to 856MHZ, ctl_index 1
support 416 856 328 666 MHz, current 856MHz
OUT

Notably, looks like it actually has LPDDR4 and not LPDDR3 as indicated on the website (!!!), which might be part of the reason the LPDDR3 setup was failing before

2 Likes

ooo nice! very exciting.

discovered that there’s a bit of difference between mkimage in the rkbin tools and the upstream u-boot tools that was blocking the miniloader from really running post-DDR config. Used the upstream mkimage instead, and now it seems miniloader loads, and BL31 seems to get loaded as well

Boot1 Release Time: May 29 2020 17:36:36, version: 1.26
CPUId = 0x0
ChipType = 0x10, 347
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
emmc reinit
mmc: ERROR: SDHCI ERR:cmd:0x102,stat:0x18000
mmc: ERROR: Card did not respond to voltage select!
SdmmcInit=2 1
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=15193MB
FwPartOffset=2000 , 0
StorageInit ok = 56470
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT part:  0, name:          primary, start:0xf424, size:0x6acfd
GPT part:  1, name:          primary, start:0x7a121, size:0x3f1ebe
no find partition:uboot.
Trust Addr:0x4000, 0x58334c42
No find bl30.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0xa8770
RunBL31 0x40000 @ 197727 us
NOTICE:  BL31: v1.3(release):845ee93
NOTICE:  BL31: Built : 15:51:11, Jul 22 2020
NOTICE:  BL31: Rockchip release version: v1.1
INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 0
INFO:    plat_rockchip_pmu_init(1196): pd status 3e
INFO:    BL31: Initializing runtime services
INFO:    BL31: Initializing BL32
INF [0x0] TEE-CORE:init_primary_helper:337: Initializing (1.1.0-266-gee81607c #1 Mon Aug 17 09:23:30 UTC 2020 aarch64)

INF [0x0] TEE-CORE:init_primary_helper:338: Release version: 1.2

INF [0x0] TEE-CORE:init_teecore:83: teecore inits done
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9

I made things a little bit difficult for myself too by switching the UART over to 115200 from the default 1.5Mbps, so to get the next set of output, I needed to reconnect at 115200, but it shows u-boot loading the kernel:

U-Boot 2021.10-1 (Nov 27 2021 - 17:03:43 -0600) Manjaro ARM

Model: Clockworkpi A06
DRAM:  3.9 GiB
PMIC:  RK808 
MMC:   mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from MMC... Card did not respond to voltage select! : -110
*** Warning - No block device, using default environment

In:    serial
Out:   serial
Err:   serial
Model: Clockworkpi A06
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
307 bytes read in 5 ms (59.6 KiB/s)
1:	Manjaro ARM
Retrieving file: /initramfs-linux.img
8381351 bytes read in 530 ms (15.1 MiB/s)
Retrieving file: /Image
30761472 bytes read in 1937 ms (15.1 MiB/s)
append: initrd=/initramfs-linux.img earlycon=uart8250,mmio32,0xff1a0000 console=tty1 console=ttyS2,1500000 root=PARTUUID=fb1982bb-3ad6-4426-9865-1f44a8ea0e72 rw rootwait quiet splash plymouth.ignore-serial-consoles fbcon=rotate:1
Retrieving file: /dtbs/rockchip/rk3399-clockworkpi-a06.dtb
78446 bytes read in 12 ms (6.2 MiB/s)
Moving Image from 0x2080000 to 0x2200000, end=4030000
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f5732000, end f5f303a7 ... OK
   Loading Device Tree to 00000000f571b000, end 00000000f573126d ... OK

Starting kernel ...

[    2.323843] rockchip-usb2phy ff770000.syscon:usb2phy@e450: failed to create phy
[    2.334551] rockchip-usb2phy ff770000.syscon:usb2phy@e460: failed to create phy
[    2.759623] rockchip-usb2phy ff770000.syscon:usb2phy@e450: failed to create phy
[    2.771585] rockchip-usb2phy ff770000.syscon:usb2phy@e460: failed to create phy

This means that u-boot is working now. The screen backlight also comes on now, which is the devicetree getting loaded, but kernel stalls out a bit. will need to do another kernel build to correct the UART baud rate to keep it 1.5Mbps everywhere and get some more output. but calling it a success for tonight :sweat_smile:

5 Likes

And we have a splash screen :smiley: (Still hangs, but we’re very close now to a booting system)

2 Likes

Excited to see this. For what it’s worth, the pinebook pro has the same rockchip soc as the a06 and they’ve done a ton of work on uboot/manjaro to make it more useable. I was able to lift a couple userland scripts and they work as expected. I assume a decent amount of it has been upstreamed, but not all.

Not sure if you’ll be able to lift any tricks from them, but I’m interested to see how the new kernel affects power usage. From my (unscientific powertop) measurements, the pinebook uses a couple less watts at both idle and load despite having a much larger screen.

2 Likes

Congratulations! Many thanks for your efforts.
When do you think a lay person like me will have an Manjaro image for A06?

1 Like

Wow that is quite some progress. On my site, thanks to all your input @m4xm4n, I was able to process with the TPL approach and create a minimal Manjaro ARM image that seems to boot fully through some install dialog.

Here is the bootlog till the linux boot. I have the baudrate still at 115200 so there is nothing to be seen here. Part of the linux messages appeared on the screen but I was not fast enough to create a picture:

U-Boot TPL 2021.10-1 (Nov 29 2021 - 08:52:12)
con reg ffa80000 ffa80800 ffa82000 ffa84000 ffa88000 ffa88800 ffa8a000 ffa8c000
cru ff760000, cic ff620000, grf ff320000, sgrf ff330000, pmucru ff750000, pmu ff310000
Starting SDRAM initialization...
sdram_init: data trained for rank 2, ch 0
sdram_init: data trained for rank 2, ch 1
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
lpddr4_set_ctl: channel 0 training pass
lpddr4_set_ctl: channel 1 training pass
lpddr4_set_rate: change freq to 400000000 mhz 0, 1
lpddr4_set_ctl: channel 0 training pass
lpddr4_set_ctl: channel 1 training pass
lpddr4_set_rate: change freq to 800000000 mhz 1, 0
Finish SDRAM initialization...
Trying to boot from BOOTROM
Returning to boot ROM...
rk3399_dmc_probe: pmugrf = ff320000

U-Boot SPL 2021.10-1 (Nov 29 2021 - 08:52:12 +0000)
Trying to boot from MMC1
NOTICE:  BL31: v2.5(release):bf56e28-dirty
NOTICE:  BL31: Built : 08:52:12, Nov 29 2021


U-Boot 2021.10-1 (Nov 29 2021 - 08:52:12 +0000) Manjaro ARM

Model: Clockworkpi A06
DRAM:  rk3399_dmc_probe: pmugrf = 00000000ff320000
3.9 GiB
PMIC:  RK808 
MMC:   mmc@fe320000: 1, mmc@fe330000: 0
Loading Environment from MMC... Card did not respond to voltage select! : -110
*** Warning - No block device, using default environment

In:    serial
Out:   serial
Err:   serial
Model: Clockworkpi A06
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  0 
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
257 bytes read in 5 ms (49.8 KiB/s)
1:      Manjaro ARM
Retrieving file: /initramfs-linux.img
8385715 bytes read in 358 ms (22.3 MiB/s)
Retrieving file: /Image
30827008 bytes read in 1307 ms (22.5 MiB/s)
append: initrd=/initramfs-linux.img console=ttyS2,115200 root=PARTUUID=fa4ec9f0-07bd-4d1a-bdb1-3c8bb21
Retrieving file: /dtbs/rockchip/rk3399-clockworkpi-a06.dtb
78446 bytes read in 11 ms (6.8 MiB/s)
Moving Image from 0x2080000 to 0x2200000, end=4040000
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f5734000, end f5f334b3 ... OK
   Loading Device Tree to 00000000f571d000, end 00000000f573326d ... OK

Starting kernel ...

Actually I am not sure if the DRAM initialization is correct but it seems it can proceed.

My changes are here. The rest is as it comes from @m4xm4n in his repos.

If anyone wants I can also share the minimal image file but that’s not tested and might fry your hardware… :smiley:
For the brave, here is the link to the file:
https://transfer.sh/Vq8azn/Manjaro-ARM-minimal-devterm-testbuild.img.xz
Note! This is untested software. It might harm your pretty little new device.

2 Likes

Tried with an XFCE build. Seems ok but the display rotation seems to be setup incorrect. Will look at this later.

Here is the link to the testbuild image for the brave. Same warning, it is untested software and might does some harm to your device!

https://transfer.sh/6K5Npp/Manjaro-ARM-xfce-devterm-testbuild.img.xz

1 Like

Try one of these, I don’t remember which one was the one that set it straight.

xrandr --output DSI-1 --rotate normal
xrandr --output DSI-1 --rotate inverted

You also have:
xrandr --output DSI-1 --rotate left
xrandr --output DSI-1 --rotate right

1 Like

Nice!! Was doing some reading and it sounded like mixing upstream u-boot with mini loader might have been the cause for the kernel panic I was seeing, so u-boot TPL & SPL sounds like the better approach! I believe the DDR timing info in upstream u-boot is actually extracted from the Rockchip blobs, so I suspect that if the LPDDR4 one from upstream works fine, it’s the same as as the blob and we’re good to go.

3 Likes

Ok this sounds reasonable. With the LPDDR4 I have mixed feelings. These things can look nice but turn out to be tricky in later cases where the RAM starts failing occasionally. But I agree, for now it looks fine and the values are potentially grabbed from the rockchip binary blobs.
The trusted firmware I updated to 2.6 so I could remove the 2 patches for it as they are already included in that version.

3 Likes