TonyMac32

The 32 GB eMMC that can be purchased with one. Agreed, although there was a question about HDMI connected vs not. In my case it was connected. Will be good to see what is different.

Some "numbers without meaning" for people to look at since it's running. Kernel 4.4, Ayufan Edition: tinymembench, since DDR4 and multiple channels are at play. iozone -e -I -a -s 100M -r 1k -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Hmmm. 7-zip CPU Freq: 897 1283 1288 1288 1289 1288 1288 1288 1288 RAM size: 3924 MB, # CPU hardware threads: 4 RAM usage: 882 MB, # Benchmark threads: 4 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 2080 312 649 2024 | 54016 377 1222 4608 23: 2064 320 657 2104 | 48891 352 1201 4230 24: 2033 330 662 2186 | 40864 304 1178 3587 25: 1983 339 668 2264 | 38180 298 1142 3398 ---------------------------------- | ------------------------------ Avr: 325 659 2144 | 333 1186 3956 Tot: 329 922 3050 [edit] I'm only getting 1296 MHz according to armbianmonitor, haven't looked at the dts just yet

Building Renegade.... ***time goes by*** :-( [ 58.886742] EXT4-fs error (device mmcblk1p1): ext4_find_entry:1454: inode #16268: comm blueman-applet: reading directory lblock 0 [ 59.661737] EXT4-fs error (device mmcblk1p1): ext4_journal_check_start:56: [ 59.661785] EXT4-fs (mmcblk1p1): Remounting filesystem read-only I don't know what's doing that, this was one I built, let me try the official download, maybe I need to purge my build system again. ;-) Problem on my end it would seem. Works good, now to play with it. ***installed to/booted from eMMC.*** Job well done, lads.

I need to look into my board, I'm getting a read-only FS again, even with new images... Update, nothing to be concerned about, everything is good.

Says Igor clone #4, apparently. I couldn't make it into my basement and start an SSH session before he fixed it... ;-)

I think it is the patches in the wrong subfolder as mentioned earlier. I'll check it out now Sent from my Pixel using Tapatalk

Strange, since even the U-boot message said Rock64, I built the roc-whatever recipe and it was labelled correctly. That's interesting. I had a Rock64 built and yes, it was panic-on-boot, wheras the renegade wasn't finding the boot script/environment at all. Sent from my Pixel using Tapatalk

@Igor was the image uploaded actually and accidentally a renamed Rock64 image? That could explain (part of) the issue with that image. For the filesystem issue, I haven't gotten any farther debugging unfortunately. Sent from my Pixel using Tapatalk

Did you apply the patch Myy mentioned? I'll push it later if it worked.

Yeah, this appears to be the same issue facing the RK3288 kernel. I just tried to boot a fresh build, crash on boot exactly the same way. Since I'm going to be "investing" my time in the Tinker space, I'll look at this one as well. @MarkH I have thought of that, but the issue with Rockchip is they don't "squash and merge" their changes, so what you get is a randomly shuffled deck, which might actually be worse than the current situation. The last tagged release was 12/2017 by wzyy2, so maybe they have a release mark coming up? My thought would actually be to fork this, then share the code between any boards using this BSP that do so "cleanly". Or choose an existing fork like Ayufan's.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?h=v4.14.52&id=16d7ceb04b554207aa68dd27c1bc11f8933813fd

I see the patches in there, let me verify by building it myself. Building a Rock64 at the moment to see if there was a different issue entirely, but that seems not to be the case I can boot the one I build myself. [edit] ...buuuut it seems to like to lock down the filesystem midstream. let me get some monitoring hardware set up and see if I've found a bad cable or if the SD slot perhaps does not support the modes it claims to... SD cards in question: 128 GB Samaung EVO select 32 GB SanDisk Extreme U3 A1

There is something gone wrong with the U-boot setup, it's going into a loop n ethernet @JMCC, were there some U-boot patches that should have been included?

I own the board, give me some time to get it set up Sent from my Pixel using Tapatalk

I'm afraid I don't have any good details on that board, can you elaborate on your statement? Is it underpowered using the vendor supply? The rk3399 boards seem a bit more complex where it comes to power, needing 12V a lot of the time.

No, without the initial framebuffer you have to serial port or should in on first boot, and the touchscreen is non-functional for anyone who might want to use it. It locked up on my last test with it, more work tonight. Sent from my Pixel using Tapatalk

Neat. Sent from my Pixel using Tapatalk

The mainline kernel has been relatively good, the Rockchip one is slowly being recovered, trying to get the first boot video terminal back and the touchscreen

Right, or if you're reasonably careful, a heat gun

I know a lot of chips load the SPL into a small amount of on-SoC RAM, that could be it Maybe you could attempt to reflow the board and see if you cracked a joint

Keep an eye on your system voltages, I thought (will verify) that was a generally unprotected 5V input

I use nail polish for joints/etc, and if I want to keep things from electrically touching. I'm going to guess the flaking depends on the type of nail polish, you have to get the good toxic kind for it to work well

Found my XU4 sitting there at "should it be glowing" temperature (I did something wrong with Arch at the time), doesn't seem to have taken any damage. Tinkers like to go into full "Three Mile Island" mode if they crash as well, a good thing to watch out for.

@tkaiser or have standards compliant USB ports perhaps? It would be an industry first. :-P

@balbes150 I believe the maximum temperature a piece of equipment can be without warning in industrial applications is 50 C, so a warning is possibly in order if the SoC is living at 80-85 C. Add to that roughly 35 C ambient as a possible operating parameter...