TonyMac32

The tinker has 3.3/1.8, and so does Le Potato. That said, it is the source of the reboot bugs on the Tinker, and requires messy workarounds. (I had to add the device tree checks because of the MiQi crashing and burning with those hacks in place). Now, for all of that, the Rock64 has SPI flash, so U-boot can live there and boot your system from USB3 if you wish, which could be faster than any option discussed here. Oh, in case anyone thinks of running some 1.8v lines for a custom board or anything else: https://www.sdcard.org/developers/overview/low_voltage_signaling/index.html Any card predating these "LV" cards requires 3.3 volts to start, then a voltage switch is negotiated with the SD card.

I think that would be helpful, it could be put under tutorials and make sure the title is just rk3288, since it will also work with MiQi. Sent from my Pixel using Tapatalk

Excellent, I must have been holding the clock line too long on boot.

I do not have this behavior either, I forgot to mention.

For some various thoughts from several people. it's got a good power option (meaning not micro-USB), lots of RAM, GbE/USB3, an additional fast ethernet if you can wire it up (is there a "hat" for that now?) Cons: not any real Armbian support yet. ;-) There were some GbE and USB3 issues, but I believe those have all been resolved.

@Kwiboo Sorry to bug you, but have you seen the Rockchip linux oops when switching video modes? It's a null pointer dereference: [65622.009223] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 3 840*2160, close all win [65622.061744] [drm:hdmi_config_hdr_infoframe] *ERROR* Not support DRM Infoframe [65669.817468] Unable to handle kernel NULL pointer dereference at virtual addre ss 00000000 [65669.826474] pgd = ecb30000 [65669.829499] [00000000] *pgd=00000000 [65669.833472] Internal error: Oops: 5 [#1] SMP ARM [65669.838570] Modules linked in: 8723bs ip_tables uas [65669.843965] CPU: 0 PID: 947 Comm: Xorg Not tainted 4.4.115-rockchip #40 [65669.851271] Hardware name: Rockchip (Device Tree) [65669.856465] task: eca3e200 task.stack: ecb26000 [65669.861474] PC is at vop_crtc_bandwidth+0x268/0x34c [65669.866861] LR is at vop_crtc_bandwidth+0x1ac/0x34c I can't find any reference to it in the Rockchip repo, botfap claimed to have seen it but hasn't been in touch in a while.

The miniarm.dtb in mainline is a simple name change to keep things simple script wise, if you would like to remove that patch and make changes for the scripts I don't have any objections. Anything for/from the Asus images (like overlays) will expect miniarm.dtb on the 4.4, and the educated user will expect tinker.dtb for mainline.

Yes, Ayufan. ;-). I am working with that script now , some limited success so far (about 20 minutes invested) Sent from my Pixel using Tapatalk

I will need to experiment with something that ayufan rolled out for the Rock64 to tune the timings on GbE, that could cause the network to fail (Rock64 has/had some GbE instability as well) In the meantime, updated the available packages with current state of my fork, Rockchip repo updated to 4.4.112, I've patched to 4.4.115, however a couple chunks did not patch in properly and a couple claimed to already be in place, so not 100%

The rk3399 looks like the hot item this year, prices look like they're starting around $60 (it's an expensive SoC). Assuming everything works reasonably well (PCIe / etc), I think it would be hard to beat. For something with more "miles" I'd opt for an Odroid XU4 or one of its cloud variants.

I would assume, if indeed all packages are rebuilt nightly, that this would pop up in beta tomorrow, it was too late last night to hit today I think. To be honest I haven't spent time understanding the build frequencies/etc, something I should probably figure out.

Ah ok, it seemed somewhat tangential to the topic at hand. You switched fairly recently then, I hadn't been keeping up. By the way, I tested it on Le Potato, quite simple, nice to use. Given the lack of time and the... non-descriptive commit history, where are you grabbing the GPIO names? The device tree for the mainline amlogic devices has every exposed gpio named in the tree, but that doesn't come through using gpioinfo.

Stretch has demonstrated it's own set of issues, but it is available if you wish to build it yourself. My last test was certainly more promising than in the past, a few months ago it would lock up for approximately 20 seconds while loading apps like web browsers or LibreOffice. Now it is still glitchy but does not hang. Strange that is was unselected, I'll update that, or you can put in a pull request. updated in build system

Thanks @Tido, this was a simple device tree tweak, so lack of errors = AOK for now. I noticed the gpio names changed with the pin assignment fix, it doesn't call them gpio0 and gpio10 anymore, just gpio 0 and 1. Only the activity LED seems to come on (amber) for me, but given my board being a historical artifact that could be the cause. ;-) Did some housekeeping on the patches, the BayLibre work is filtering back to 4.14 so the patches for bugs are dropping, at this point the patches are primarily for WIP items.

@Tido, I found the ethernet LED's and a couple of other adjustments that weren't part of the 4.14 patchset. Quick test then I'll push it.

accidental mis-post? Probably intended for the GPIO/IOT discussion? If so, and a mod moves it, delete my post about it as well.

Sorry I missed this, that shouldn't be the issue, I've started it on both HD and 4K without issue. The display issue I've had involves changing from 4k to another resolution and the DRM system crashing. Did you install all of the debs, and remove the old kernel packages? It was rolled out at the same time as the others, and shows up in your "lsmod" output as a loaded module. That's about all I know. who's display is that? I only have the RPi one at 800x480. Stefan, I just wanted to make sure you had cloned my fork of the Armbian build system, and then check to make sure I answered your question well enough.

Actually "default" is the correct option. Thanks for testing!

Gaze longingly at it's many ports and connectors.

That would be ideal. Yes, working features is primary, I've had mine running for 5 days on my desk with the wifi/touchscreen, just looking through files/using IRC/etc. Thanks!

According to http://opensource.rock-chips.com/wiki_Boot_option: eliminated the 4-byte skip and u-boot is alive and well, however it now can't do some various things and freezes: As opposed to the older image:

Current issues with Armbian board support: -U-Boot problems (various) Solutions so far: - fix the method of generating idbloader.bin. <--- update: the "release" and "mainline-master" behave significantly differently. Mainline-master behaves as it should as far as writing the bootloader. Release does not.

Going to start a thread on this under Rockchip

Well, that's exactly the reason. ;-). The video codec/etc are not yet implemented in mainline.

I think I found it, although I'm not sure why this would happen: ccache: error: Could not find compiler "aarch64-linux-gnu-gcc" in PATH ccache: error: Could not find compiler "aarch64-linux-gnu-gcc" in PATH when compiling u-boot, so that build fails but doesn't crash the script, allowing you to build the image. well then, that didn't repeat on a second try, stay posted.