TonyMac32

let me build it and we'll see. ;-)

https://patchwork.kernel.org/patch/10374639/ This explains my confusion a little, but how I missed adding them myself when I noticed they weren't there, well...

The device tree is a beautiful thing.

Well, I must be blind. I'll add that one in and that should fix it. Thank you.

That would be surprising if true (I honestly don't know). However, if you look at the FriendlyElec NanoPi Neo or NanoPi Core, you'll get the same size and I2S (even a DAC if you aren't horribly picky: http://www.friendlyarm.com/index.php?route=product/product&product_id=151 http://www.friendlyarm.com/index.php?route=product/product&product_id=169 I did a write-up on using these with MPD, so I know for a fact they and the DAC work, but I don't think you'll need it. (actually linked on the FriendlyARM device page somehow...) I don't think anything else is that small, so you already know.

From where I'm sitting I can't see paying that much for it when I can get a 4G USB dongle for a well-supported chip

The sad part is, given the capabilities of the Rock64, this should be a good device, it is possible it would be interesting enough to support if we had reason.

From tinker dts: sound { compatible = "simple-audio-card"; simple-audio-card,format = "i2s"; simple-audio-card,name = "rockchip,tinker-codec"; simple-audio-card,mclk-fs = <512>; simple-audio-card,codec { sound-dai = <&hdmi>; }; simple-audio-card,cpu { sound-dai = <&i2s>; }; }; Still getting a "could not get #sound-dai-cells" error, dtsi for the HDMI says nothing about it.

Well, I was pointing out that another page is talking about this project without (seemingly) anyone knowing about our supposed support for their thingy.

@Igor: This is at the bottom of their product page: http://www.kovu.io/

@Jyu Ho not yet. my offline responsibilities took away time from this project over the last few weeks, progress has been slow

The eMMC would be the typical boot device, however if you have a "blank" machine with no software, one of the USB ports is an OTG and will be able to respond to commands as a USB device (Rockchip has a loader for PC for this). You have to flash stuff over that link in worst case. Rockchip devices can boot from eMMC, SD, and SPI flash, typically. The bootloader can then load a kernel/rootfs from whatever it happens to support (USB, network, etc)

Well, this was more like expecting a Prius and getting a Golf GTI

1 Mh/s ?!?!

ahhh ok. I wonder if there is a bug somewhere with freeing the resource...

I hadn't heard anything about this board since the last post on this thread, I would guess no one has one among the developers... :-/

I got a series of errors with the miner program using the readme.txt command: WARNING: GPU_MAX_ALLOC_PERCENT is not specified! WARNING: GPU_USE_SYNC_OBJECTS is not specified! Error -6: Creating kernel from program failed to init GPU thread 0

Beautiful. Script ran flawlessly, rebooted and watched a Netflix movie. :-)

@Myy looky here.

I experimentally booted an orange pi PC 2 image on mine. Starting from there and correcting the device tree to match the actual hardware should be sufficient

My 1992 Conner hard drive is weeping. Nice write-up.

There is a memory and firmware allocation issue, unfortunately as a WIP board I haven't spent a ton of time on it, however I should be able to sort it out as I work to end the "blobtastrophy" that was our U-boot situation before. I only have to ask @Neil Armstrong if BayLibre has NanoPi K2 in the list of GXBB devices to get mainlined. Most of the work is done thanks to the Odroid C2, so worst case eventually I'll look at it.

Mine arrived, no time to play with it yet, been putting in 10-12 hours a day at my regular job... :-(

Agreed. Do we have enough information to move forward with a build?

Ok, the 4.4 uses a newer driver than mainline, that may explain it. It also used a newer version than Asus for some time, that is not the case now however.