Search the Community

[drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 8.748477] [drm] No driver support for vblank timestamp query. [ 8.751175] [drm] Cannot find any crtc or sizes [ 8.752049] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 1 [ 9.596617] Adding 502880k swap on /dev/zram1. Priority:5 extents:1 across:502880k SSFS [ 9.760746] [drm] Cannot find any crtc or sizes [ 9.763672] zram0: detected capacity change from 0 to 52428800 [ 11.920458] EXT4-fs (zram0): mounted filesystem without journal. Opts: discard [ 11.921159] ext4 filesystem being mounted at /var/log supports timestamps until 2038 (0x7fffffff) [ 14.451738] random: crng init done [ 14.452073] random: 7 urandom warning(s) missed due to ratelimiting [ 14.810329] ------------[ cut here ]------------ [ 14.810765] kernel BUG at fs/inode.c:588! [ 14.811128] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 14.811614] Modules linked in: zstd dw_hdmi_i2s_audio rockchipdrm lima snd_soc_rk3328 analogix_dp gpu_sched dw_mipi_dsi dw_hdmi zram ip_tables ipv6 crc_ccitt dwmac_rk stmmac_platform stmmac phylink phy_rockchip_inno_usb3 phy_rockchip_inno_hdmi [ 14.813531] CPU: 2 PID: 1 Comm: systemd Not tainted 5.4.14-rockchip64 #rc1 [ 14.814139] Hardware name: Pine64 Rock64 (DT) [ 14.814530] pstate: a0000005 (NzCv daif -PAN -UAO) [ 14.814967] pc : evict+0x164/0x168 [ 14.815276] lr : evict+0xe8/0x168 [ 14.815572] sp : ffff80001002b930 [ 14.815869] x29: ffff80001002b930 x28: ffff00003e1646c0 [ 14.816343] x27: ffff800011126d88 x26: ffff00003c6be500 [ 14.816815] x25: ffff00003c6be500 x24: ffff80001136b508 [ 14.817286] x23: ffff80001027e988 x22: ffff00003a210298 [ 14.817757] x21: ffff800010dca880 x20: ffff00003bcc4b10 [ 14.818231] x19: ffff00003bcc4b20 x18: 0000000000000000 [ 14.818703] x17: 0000000000000000 x16: 0000000000000000 [ 14.819176] x15: ffffffffffffffff x14: ffff80001136b508 [ 14.819649] x13: ffff80001002bb58 x12: ffff80001002bb4d [ 14.820121] x11: 00000000046b9e80 x10: ffff80001002bac0 [ 14.820594] x9 : 00000000ffffffd8 x8 : 0000000000000000 [ 14.821065] x7 : 0000000000000001 x6 : 0000000000000000 [ 14.821537] x5 : 0000000000000001 x4 : 61c8864680b583eb [ 14.822009] x3 : ffff800011366180 x2 : ffff8000113666f8 [ 14.822492] x1 : 0000000000000000 x0 : ffff00003bcc4bb0 [ 14.822972] Call trace: [ 14.823200] evict+0x164/0x168 [ 14.823474] iput+0xd8/0x190 [ 14.823732] dentry_unlink_inode+0x114/0x160 [ 14.824114] __dentry_kill+0xc0/0x1c0 [ 14.824442] shrink_dentry_list+0x7c/0xd8 [ 14.824799] shrink_dcache_parent+0xd8/0x130 [ 14.825180] d_invalidate+0x60/0xe0 [ 14.825494] proc_flush_task+0xa8/0x198 [ 14.825841] release_task.part.27+0x78/0x448 [ 14.826220] wait_consider_task+0x7a4/0x820 [ 14.826591] do_wait+0x130/0x1d8 [ 14.826880] kernel_waitid+0x110/0x1e0 [ 14.827212] __do_sys_waitid+0x3b4/0x428 [ 14.827561] __arm64_sys_waitid+0x24/0x30 [ 14.827921] el0_svc_common.constprop.1+0x88/0x178 [ 14.828346] el0_svc_handler+0x20/0x80 [ 14.828681] el0_svc+0x8/0xc [ 14.828944] Code: 17ffffd2 f90013f5 d4210000 d4210000 (d4210000) [ 14.829490] ---[ end trace b3d7224f99874ee8 ]--- [ 14.829902] note: systemd[1] exited with preempt_count 2 [ 14.830373] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 14.831048] SMP: stopping secondary CPUs [ 14.831400] Kernel Offset: disabled [ 14.831712] CPU features: 0x0002,20002000 [ 14.832067] Memory Limit: none [ 14.832342] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- verb=7 output same error not syncing on bionic and buster minimal current release img's.

Applying kernel provided DT fixup script (rockchip-fixup.scr): Finally got a serial board so theres the output. Hope this helps to fix my V2 rock64 on new images. This is for latest standard buster server RC image. Not syncing is usually it cant find the right partition to complete the boot.

So good news.... I got a 1G Rock64 V2. build RC1 image totally works

I'm new to armbian so hi to all. I recently bought a sealed Rock64 v2 off ebay with psu and sdcard for low cost. It works ok but has lots of same issues like others have. I'm just adding my 2 cents in here so another user is heard in the thread. Armbian Bionic w/4.4 minimal works well. Anything else newer does not boot. I dont have serial cable so that's all I can report for now. Compiles well too. Arch and Manjaro stock images work well (5.5.1) but they segfault when compiling anything. Still looking for an image for v2 that compiles and is 5.2 or newer.

I am building from source using the vagrant process, as outlined here: https://docs.armbian.com/Developer-Guide_Using-Vagrant/ When running ./compile.sh, I get the option to customize the kernel via dialog and I did select some customizations. When saving the config, I choose the default `.config` as output. However, when running `./compile.sh` a second time, all the settings are back at default and I can not find any `.config` file anywhere in the tree. No files in `userpatches` are changed since before running the compile. Reading https://docs.armbian.com/Developer-Guide_Build-Preparation/#providing-build-configuration suggests new config files should be generated but I can't locate any. The files in userpatches are untocuhed. I do see `./output/config/linux-rockchip64-current.config` - this seems to contain kernel config (I did a build for rockchip64 here). Is this what I'm looking for? If so, how do I reuse this in a sustainable way? Lastly, do I get it right if by default I should put generic customizations in `./userpatches/config-default.conf` and board-specific ones in e.g. `./userpatches/rock64.conf`? (Asking since docs seem to be very out of date wrt directory structure)

@Mathias - I have run some tests now. With a Samsung Portabel T5 500GB connected to USB-C, 1x 4TB WD Red NAS HDD and 1x 8TB WD Red NAS HDD. I got 2 or 3 random reboots. I did wirte 10TB down, and did backup 2TB or so. Not sure why the reboots. CPU & HDD temp was acceptable. I have found a chaep 4 port sata pcie, i can't find info on the board itself. Will teste the 4port card now. @deathisunknown - I have looked around, there is someone that has wrote a python simple fan control. I have not tried it out. You can check it here FAN control not 100% sure if it is only to ROCK64. Here is some patch made to work in Libre.. Maybe it could be to some use, to point out. This on is to LibreELEC FAN script ROCKPRO64 and HERE . Will you please report back if it helped you? Thanks.

@chwe Good points in general. Sorry being unclear, I was referring to Rock64. They were announcing for a long time that PoE would be coming in the Rev3 of that board but it was eventually dropped. I ended up buying one anyway due to availability in my country, so now I'm here with a Rock64, a couple of Pis and thinking what the next board would be when I inevitably grow out of that. In general I'm wary of getting power supplies from untrusted vendors on places like Ali but it seems like it's either than or DIY for most boards, sadly. Thanks for the link either way; I'm thinking that should actually work fine with most SBCs rated at 5V/3-4A including Rock64 and Pi3B/4 but yeah, I'm wary of power especially if connecting external disks. And good that you pointed out UART, I wouldn't have considered that otherwise.

With the correct DTB, the sound works in the official images for rk3328 (I tried the official images for Renegade and Rock64). All it took was adding the correct DTB (with audio support). If use a DTB from roc-cc, there is no sound. You can see how the sound was added to DTS here. https://github.com/150balbes/Amlogic_s905-kernel/blob/5.4/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts https://github.com/150balbes/Amlogic_s905-kernel/blob/5.5/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts

I had the same problem on my Rock64 board running Armbian, it fixes after reboot.

@chwe--I just found this in @ayufan's repository: https://github.com/ayufan-rock64/linux-kernel/commit/afadea9477b7df1daae04389f8f1fa0f9b041c5c" " stdout-path = "serial2:1500000n8"; // disable stdout-path as it causes instability due // to sound card power leak //stdout-path = "serial2:1500000n8"; " The Manjaro boot args don't include stdout-path, or earlycon=uart8250 but do include console=ttys2. Maybe if I get brave, after dinner I will try removing that from the boot arguments.... The current Manjaro boot.txt doesn't show any video argument BTW. Maybe something in the config or dts? I will try to look after I check the sound stuff.

---CONFUSED--- started at last night i just broke my x88 pro tvb, by flashing false uboot on the emmc, then every boot its crash caused by wrong DRAM frequency,, i guess my only way to fix it by entering maskroom mode, i open the boxes and pull out the heatsink, seeking some clue on there,,, just a bit surprissed, its was "Rockchip rk3318" (not 3328) cleary writen there... that was my confusion... Whats is rk3318? is it has the same family whit rk3328? searching on the web just found some few documentation about it,,, searching some configuration on some u-boot or kernel repository almost cant find anything usefull... hmmm... luckily this i found the EMMC CLK pin, searching it manually by using an earphone and listen to it.. (bcz i didnt see my board on the web) i reflash it then, its comeback to alive... i put it back on Armbian 19.11.9 using legacy kernel 4.4.210 which i compiled last night and using the Rock64 debian buster rootfs, since it was fine,,, (eth,IR OK, no wifi BT) may be will just stop trial on the 5.x kernel for now, until have enough clue on the 3318 things... here i attach some picture and logs... just a story...

at least for x86-64 mesa 19.3 works like a charm on bionic... OpenGL ES profile version string: OpenGL ES 3.2 Mesa 19.3.2 - kisak-mesa PPA but I don't think he provides armhf/arm64 packages for it.. and yes, it doesn't work with friendly arms kernel fork, and I honestly don't understand why it works with ayufans kernel.. e.g. the supposed bits needed to get it working are missing in panel-simple (e.g. no timings nor clockspeed for the display we use) https://github.com/ayufan-rock64/linux-kernel/blob/d3f1be0ed310d118ccf04cf9b691c92a914a97a9/drivers/gpu/drm/panel/panel-simple.c#L1295-L1321 vs. mrfixit (that's a different panel) https://github.com/mrfixit2001/rockchip-kernel/blob/1440cd8cfcd029eb4f97c97c11f607e49d1986a3/drivers/gpu/drm/panel/panel-simple.c#L1330-L1353 I guess I need to understand how ayufan got the display working.. or why it works on his kernel even when he didn't touch panel-simple..

Support for Rock64 is still not matured while maker is already on their future products ... there are three (3) HW board revisions which only raises support expenses. No problem about that. You found a bug which was fixed while typing this. I tested the exact same image on my Rock64 Revision 3. No problems. First login: "Desktop environment will not be enabled if you abort the new user creation" We want to keep system clean, so there are no users on the system beside system ones and running desktop under root is not a good idea. Some applications will also not work. If you skipped our scripts and created new user manually ... there will be no desktop and you are on your own to get it up. My mouse and keyboard works straight up. Even over KVM ... but USB troubles are known. Try other port.

That's great so what can I do to help with the latest rock64 kernel 5.4? Should I get a setup with rock64 plugged into a monitor and then compare the boot info from Armbian_19.11.3_Rock64_buster_current_5.3.11 (working) vs Armbian_19.11.6_Rock64_buster_current_5.4.y (broken) If this is a good starting point then happy to assist...

Hello, bumping this thread, as this is also about the rock64 and usb3 with a more recent image. It seems to me that now for the "legacy" kernel (tested here with Armbian_19.11.6_Rock64_buster_legacy_4.4.207 image) there is support for the usb3 bus, but for the mainline Armbian_19.11.5_Rock64_buster_current_5.4.6 there is not (the 19.11.6 current kernel image gives me an oops on boot and no network). Is there something I can do to add it to the mainline/current image? Tia, Huey output on mainline: root@rock64:~# uname -a Linux rock64 5.4.6-rockchip64 #19.11.5 SMP PREEMPT Fri Dec 27 21:46:18 CET 2019 aarch64 GNU/Linux root@rock64:~# lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M output on legacy: root@rock64:~# uname -a Linux rock64 4.4.207-rockchip64 #1 SMP Sun Jan 5 00:23:38 CET 2020 aarch64 GNU/Linux root@rock64:~# lsusb -t /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M

a little update regarding my rk3318 box - at my last try it was hanging at u-boot -> see: i finally got it booting by dd'ing the u-boot from this image: xenial-minimal-rock64-0.5.15-136-arm64.img.xz from https://github.com/ayufan-rock64/linux-build/releases/tag/0.5.15 to my sd-card and afterwards dd'ing the trust.img from: on top of it ... not really straight forward, but works at least best wishes - hexdump

Hi guys, I recently bought a Rock PI 4 and installed Armbian Buster with kernel 5.4.6. The os is booting fine but I am facing major performance issues when trying to download from the internet. I have also a Raspberry Pi 4 connected to the same switch (via LAN) and when I execute the following command curl -L http://speedtest.belwue.net/1G > /dev/null I am getting download speed of approx 8MB/s on my Raspberry but only 2MB/s on my Rock PI 4. From connection side and rooting there is no difference. While using the same Armbian version on my Rock64 I am getting the same speed as my Raspberry Pi. Is this a known problem with the Rock PI 4 or am I missing something important? I also tried other kernel versions but the problem persists. One thing to mention: I tried the same command with a local webserver (same network, same switch) and there I was able to get download speeds of about 60MB/s, so it seems to not being an issue with the LAN port itself. Any ideas? Thanks! Bye

I believe the problem with the dts definition which I found a year ago was fixed by Ayufan for his mainline builds, but still exists in the official repo. My rock64 is not available for me to test right now. Perhaps someone else could take a look? https://forum.armbian.com/topic/9413-make-419-kernel-available-again-for-rock64/?do=findComment&comment=70578

Can also confirm issues on my new Rock64. USB3 works on fresh install of Buster server 4.4 Linux rock64 4.4.198-rockchip64 #27 SMP Fri Dec 27 21:32:05 CET 2019 aarch64 GNU/Linux No USB3 device recognized on Buster server 5.4 Linux RockHole 5.4.6-rockchip64 #19.11.5 SMP PREEMPT Fri Dec 27 21:46:18 CET 2019 aarch64 GNU/Linux USB2 works OK on both. EDIT: Also no USB3 on Linux RockHole 5.3.11-rockchip64 #19.11.3 SMP PREEMPT Mon Nov 18 21:03:09 CET 2019 aarch64 GNU/Linux

Same problem here with a clean installation of the current image for rock64 (19.11.5 - 5.4.6). With the legazy image (4.4) there is no such problem with usb3.

there's a tool to test this: https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test @tkaiser wrote one too back then.. but I can't remember where I have it anymore.. Nevermind https://github.com/ayufan-rock64/linux-build/blob/02fae982767ca242009baaf995f7ce64b5d82469/recipes/gmac-delays-test/range-test#L3 https://github.com/armbian/build/issues/546

Hi guys, I have recently bought a Rock64 to improve the performance of my VPN gateway. First tests look very promising as you can see here: root@rock64:~# openssl speed -evp aes-128-cbc -elapsed You have chosen to measure elapsed time instead of user CPU time. Doing aes-128-cbc for 3s on 16 size blocks: 15394610 aes-128-cbc's in 2.99s Doing aes-128-cbc for 3s on 64 size blocks: 12591175 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 6719021 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 2448108 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 352617 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 16384 size blocks: 177668 aes-128-cbc's in 3.00s OpenSSL 1.1.1d 10 Sep 2019 built on: Sat Oct 12 19:56:43 2019 UTC options:bn(64,64) rc4(char) des(int) aes(partial) blowfish(ptr) compiler: gcc -fPIC -pthread -Wa,--noexecstack -Wall -Wa,--noexecstack -g -O2 -fdebug-prefix-map=/build/openssl-H2OJIf/openssl-1.1.1d=. -fstack-protector-strong -Wformat -Werror=format-security -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DVPAES_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG -Wdate-time -D_FORTIFY_SOURCE=2 The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes aes-128-cbc 82379.18k 268611.73k 573356.46k 835620.86k 962879.49k 970304.17k root@rock64:~# openvpn --genkey --secret /tmp/secret root@rock64:~# time openvpn --test-crypto --secret /tmp/secret --verb 0 --tun-mtu 20000 --cipher aes-256-cbc Sat Dec 14 10:26:40 2019 disabling NCP mode (--ncp-disable) because not in P2MP client or server mode real 0m4.978s user 0m4.945s sys 0m0.032s Unfortunately when executing a simple curl, the throughput is very low: root@rock64:~# curl -L https://speed.hetzner.de/1GB.bin > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 2 1000M 2 29.9M 0 0 2090k 0 0:08:09 0:00:14 0:07:55 3106k When using Ubuntu 18.04 Bionic I am reaching speeds of 8,4MByte/s. I have checked the openvpn process and it seems that it is only using 25% of CPU, whereas when using in Ubuntu it is using 50-60%. What are the differences here and why is Armbian limiting the process to 25%? Thanks! Bye

What is the supported way, if any, to redirect /var/log.hdd to a directory located on a real HDD drive? One of my systems has an eMMC to boot and operate from, and a HDD hooked up on the USB3 port. "Ideally" I'd like to use only the HDD, but the poor/incomplete USB3 boot support on the Rock64 V2 (with Bionic at least) had me to buy an eMMC and live quietly with it. As it is, I'd like to move out of the eMMC all the data that is either written often, or that it could get bigger with time passing. For the logs, however, I don't think to have found a clean way to support the relocation of /var/log.hdd on a different drive/partition, unless I hack the armbian-ramlog script (something I *don't* want to do). Or I could disable completely the log2ram feature. Thanks!

Add me to the list of users who have lost the USB3 port once I've switched to kernel 5.3.11. On one of my boards I have had to hook a monitor to understand why the Rock64 did not boot anymore from the eMMC. The problem is it is failing to mount the USB3 connected HDD and then it goes in recovery mode. The Ethernet port is also not configured. Booting from a SD card with Armbian Bionic 5.90 in it I first upgraded to the latest 5.98, which brought in kernel 4.4.198 (I was on 4.4.192), then using armbian-config I switched to the new kernel 5.3.11. On powering on the board (the switch poweroff the board instead of power cycling it), not depending on a fstab pointing to a missing drive the system booted normally, with the Ethernet port properly configured. The USB3 port is still missing from lsusb -t output

Ok...so the verdict is I have a bad TTL adapter. I have a Rock64 and some jumper wires, and the Rock64 has a UART on it capable of running a 1500000 baud...so I wired up the debug pins on the OPi to the UART on the Rock64 -- and bam, I get stuff that I can at least read. (The only bad thing is that the Rock64 leaks voltage out of the UART pins...so the board tries to power on as soon as you hook it up.) Without the SD card? I think you're right -- it tries to boot into Android. I see a bunch of messages from the kernel, and then it drops into a shell. (Interestingly, it also spits out a bunch of errors b/c the filesystem is read-only...but whatever.) With the SD card? Here's what I get: �DDR Version 1.14 20180803 In Channel 0: LPDDR4,50MHz CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size= LPDDR4,50MHz CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 CSMR4=0x1 MR5=0x1 MR8=0x8 MR12=0x4D MR14=0x4D MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 Bus Width=32 Col=10 Bank=8 Row=15/1S=2 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x7MR19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x7R19=0x0 MR24=0x8 MR25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR 0 training pass! channel 1 training pass! change freq to 400MHz 0,1 channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 25=0x0 CS = 1 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x8 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel change freq to 800MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x2020 ch 1 ddrconfig = 0x101, ddrsize = 0x2020 pmugrf_os_reg[2] = Boot1: 2018-08-06, version: 1.15 CPUId = 0x0 ChipType = 0x10, SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOfmmc0:cmd5,20 SdmmcInit=0 0 BootCapSize=0 UserCapSize=15193MB FwPartOffset=2000 , 0 StorageInit ok = 182421 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 GPT 0x3190d20 signature is wrong LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xa69c4 RunBL31 0x10000 NOTICE: BL31: v1.3(debug):f947c7e NOTICE: BL31: Built : 20:19 BTW -- I didn't have to connect TP50625 to anything to get it to boot off the SD card. So...next step -- maybe try to build a new U-Boot?