TonyMac32

The newest revision does not boot from current SD images. I'm working to debug why. If anyone else has a board and can test it out, let me know. The eMMC will boot, no problem, so it's just the SD itself. Model: Pine64 Rock64 DRAM: 1022 MiB MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1 SF: Detected w25q128bv with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Pine64 Rock64 misc_init_r cpuid=55524b50303930343200000000051f1a serial=f55c6806c317581 Net: eth0: ethernet@ff540000 Hit any key to stop autoboot: 0 Card did not respond to voltage select! mmc_init: -95, time 9 switch to partitions #0, OK mmc1 is current device ** No partition table - mmc 1 ** starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: Core Release: 3.10a USB3: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.10 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... 2 USB Device(s) found scanning bus 2 for devices... 2 USB Device(s) found scanning bus 3 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Device 0: unknown device ethernet@ff540000 Waiting for PHY auto negotiation to complete......... TIMEOUT Ideally getting old an new to boot would be ideal, @Igor this might mean a fragmentation for this board though, like having a V2 and older and a V3 and newer build if we can't make them all play nice with one bootloader.

Thanks for the update @jpegxguy, As you're aware I've been haunting the lkml, I've been laying low on 64-bit Rockchip in general since it's been a complete and utter mess. As it stands here I think 5.1 is going to be a good place to start trying to get mainline back into Armbian. There was absolutely no sense running after a thousand patches to get basic hardware like HDMI and USB3 working up front, I went down that road before. You can build an image with kernel 4.20 right now (last I checked it still built, building it now actually to test), we just don't support it as the kernel itself is WIP and changes can be somewhat severe from revision to revision, especially where Ayufan/Armbian/whoever else has patched it to meet their needs.

I almost think you should maintain some hard angularity to it, as the 2D. Very nice though!

If you're using ayufan's mainline: https://github.com/ayufan-rock64/linux-mainline-kernel/blob/master/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts can check to see how correct that is.

The SixFab hat itself is just a fancy connector, what does lsusb say on 4.19? Also, as a general recommendation, "next" images will remain 4.19 until the next LTS release is finalized and we have a good feeling about it here, so I would stick with it for daily use outside of development.

As I put in another topic, I can use a $20 4G modem all day with Armbian and any board with a recent kernel. Integrated is nice, but...

I split this into it's own topic, carry on.

This was where you boot without the monitor attached and plug it in later. But that was only a few reports, best to just use an up to date image Sent from my Pixel using Tapatalk

If the 4.14 image is from the right period of time, the u-boot can lock up while trying to init the HDMI monitor. That's what I mentioned to dragonlost earlier. Sent from my Pixel using Tapatalk

Please try a 4.19 image, we've moved on from 4.14. Sent from my Pixel using Tapatalk

It's impossible to debug without information beyond "it doesn't work". As far as the no SSH issue, that is very irregular. What kernel/image/etc? I'm guessing you don't have the ability to watch the debug UART? Sent from my Pixel using Tapatalk

Here is by far the simplest solution I think: on your 4.19 kernel type lsusb and figure out what your usb 4G modem looks like. that device is obviously supported in the mainline kernel config, it might be available in 4.4 but simply not enabled.

The last time we enabled the HDMI in u-boot it crashed the kernel somehow. Never tried to debug it. Sent from my Pixel using Tapatalk

I pushed a template for the NanoPi NEO (2/Air/Core/Plus2) onto my github: https://github.com/Tonymac32/kicad-templates If you want to make add-ons, that's fully labelled and the header positions are as correct as I could get them without official reference. I have made a few boards with it, so can vouch that it will assemble. I'll add more as I have time and money to do so, since I don't want to push any that aren't verified in some manner.

The board itself is barely bootable on Armbian, so we haven't gotten to luxuries like the fancy wifi.

Haha. I still need to do that thermal comparison between factory, my Frankenstein above, and the nice case they sent me. It is far superior to the factory cooler, although it would still throttle in your situation. Sent from my Pixel using Tapatalk

That's the only reasonable way to do something stressful with an RK3288. I'd add GPIO powering on top of that to be sure, since it not thermal throttling presents challenges for everything else in the system that might not have anticipated pulling 15 Watts for over an hour.

If you look around in the Armbian build script you'll see I've had all Meson64 boards using mainline u-boot for some time now. Sent from my Pixel using Tapatalk

Firstly, thanks for the link/well-formatted write-up. I mainlined the NanoPi K2 based (heavily) on the C2. Only one point after a quick look: For S905, you should point people to "README.nanopi-k2" The C2 has special blobs due to some... issues with advertising with Odroid. The C2 blobs are only for use with the C2, the K2 uses the standard public blobs.

Ram configuration, something else. They aren't the same board, and the Rockchip designs, using such complex PMIC's, don't usually just come on with each others' images. (MiQi and Tinker won't boot each other's images, I don't believe Renegade and Rock64 will either). I need to sit down and make a wip/csc for this board. Confirmed, renegade elite has LPDDR4, Firefly has DDR3.

I agree. The Tritium boards are "least common denominator" type boards, if I need a Pi-shaped board for running a tester or monitoring station, that's it.

The Tritium boards have fixed regulators, capping their maximum frequency right around 1 GHz, whereas the Potato has proper frequency scaling (within the limits of Amlogic) so achieves 1.4-1.5 GHz peak (impossible to know which at any given time thanks to blobs)

@Jack953 I merged your three posts into one. @sfx2000 plainly stated to not knowing, no one else was engaging with you, please refrain from "frustration-bumping" threads. I am glad you were able to find the info. Unfortunately, unless someone out there picks up these boards and works to add them to Armbian, I don't expect you'll see it appear in our image listings.

Haha, haven't used the Potato in a while?

Well, I didn't say unreliable, I just said thirsty.