Da Alchemist

If I didn't miss something the Rockpro is still marked as wip in the downloadpage right?
 

 
but well, maybe we should rename it back to wip so that only expert=yes can build images for it.. to make it more obvious..
 
but also this sub-forum has a nice reminder:

 
My RockPi 4b was used in a pure CPU numbers crunshing project for 17 days between 75°C and 80°C without any crash.. Would I call the RockPi stable.. for sure not. It seems that it did well for this test but I've no idea if it runs stable under all the other use-cases people can imagine for the board in question.
 
Just another reminder: https://forum.armbian.com/guidelines
especially this points here:
 
 
what makes you sure the powering issues are gone? Did you check voltage on 5v rail after replacing the PSU under stress?

I have just received my SATA HAT, it is recognized and working on Armbian out of the Box  (4.4.176-rk3399).  

First Pine H64/H6 mainline testing images based on @Icenowy patchset https://dl.armbian.com/pineh64/ Boot log: http://ix.io/18DU

I do not know if i understand this question the right way. After you have connected the DAC there are three soundcards
aplay -l will show us this:
root@orangepipc:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC sndcodec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: snddaudio [snddaudio], device 0: SUNXI-TDM0 snddaudio-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 In this case it is possible to access the i2s card with hw:1 or better  hw:snddaudio in your audio applications. (Be aware , that you can see this three cards even when only the Modules are loaded,[pcm0]
daudio_used = 1 is changed in the fex File and there is no Card connected)
 
Regards

tkaiser has built a new Kernel with i2s Modules. With this Kernel and some cheap DAC  e.g. (http://www.ebay.de/itm/Audiophonics-I2S-DAC-ES9023-Sabre-to-Analog-24bit-192KHZ-fur-Raspberry-PI-/291573327639?hash=item43e31fe717:g:TTwAAOSw~OdVZXtm)  it is possible to get good quality sound  out of the Orange Pis. After installing the Kernel
Two Things have to be changed in the fex File:
 
Change Directory to boot:
cd /boot Turn the script.bin to a fex-File and open it in an Editor
sudo bin2fex script.bin script.fex sudo nano script.fex Now change the following Entries:
[twi1] twi_used = 1 to
[twi1] twi_used = 0 and
[pcm0] daudio_used = 0 to
[pcm0] daudio_used = 1 Save your changes and do :
sudo fex2bin script.fex script.bin After a reboot your done.
 
 
I do not know for what the Section [twi1] is good for, i hope nothing serious..
This connections have to be made:
 
5V > Pin 2
Gnd > Pin6
BCK > Pin 27
LRCK > Pin 28
Data > Pin37
 
(according to the Picture "giachi" has posted on the diyaudio Forum http://www.diyaudio.com/forums/pc-based/285427-i2s-connection-orange-dac.html#post4587580
see below)
 
The second Picture is only for orientation on an Orangepi PC, the red Wire is 5V ! Be aware that the Header is rotated by 180°on the One!
 
That´s all .
 
Regards

I do not know if i understand this question the right way. After you have connected the DAC there are three soundcards
aplay -l will show us this:
root@orangepipc:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: audiocodec [audiocodec], device 0: SUNXI-CODEC sndcodec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: snddaudio [snddaudio], device 0: SUNXI-TDM0 snddaudio-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: sndhdmi [sndhdmi], device 0: SUNXI-HDMIAUDIO sndhdmi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 In this case it is possible to access the i2s card with hw:1 or better  hw:snddaudio in your audio applications. (Be aware , that you can see this three cards even when only the Modules are loaded,[pcm0]
daudio_used = 1 is changed in the fex File and there is no Card connected)
 
Regards

tkaiser has built a new Kernel with i2s Modules. With this Kernel and some cheap DAC  e.g. (http://www.ebay.de/itm/Audiophonics-I2S-DAC-ES9023-Sabre-to-Analog-24bit-192KHZ-fur-Raspberry-PI-/291573327639?hash=item43e31fe717:g:TTwAAOSw~OdVZXtm)  it is possible to get good quality sound  out of the Orange Pis. After installing the Kernel
Two Things have to be changed in the fex File:
 
Change Directory to boot:
cd /boot Turn the script.bin to a fex-File and open it in an Editor
sudo bin2fex script.bin script.fex sudo nano script.fex Now change the following Entries:
[twi1] twi_used = 1 to
[twi1] twi_used = 0 and
[pcm0] daudio_used = 0 to
[pcm0] daudio_used = 1 Save your changes and do :
sudo fex2bin script.fex script.bin After a reboot your done.
 
 
I do not know for what the Section [twi1] is good for, i hope nothing serious..
This connections have to be made:
 
5V > Pin 2
Gnd > Pin6
BCK > Pin 27
LRCK > Pin 28
Data > Pin37
 
(according to the Picture "giachi" has posted on the diyaudio Forum http://www.diyaudio.com/forums/pc-based/285427-i2s-connection-orange-dac.html#post4587580
see below)
 
The second Picture is only for orientation on an Orangepi PC, the red Wire is 5V ! Be aware that the Header is rotated by 180°on the One!
 
That´s all .
 
Regards

Fixed with the release of v60, at least for me.

It depends on your specific needs. Usually, it's never just about pure calculating power.
 
A theoretical comparison is usually bad way since you (can) have bad kernel/support on those big numbers and the board can still not be used for nothing but (Android) media player ... where top stability is not needed. There is usually no schematics for media players and therefore it's much harder to fix anything. And ... there will not be many people having this player since it's costly.
 
But. It can be better than this and you might get lucky. Sometimes some player works well I put my luck on Alfawise Z28 Pro since it matches chip on Rock64 where we are putting our efforts to. Not that powerful but with more chances of success.

Some Time ago I bought a cheap Z28 TV Box fromGearbest for 27€. I was curious about this chip after I saw a Picture of the Rock64 here on Armbian.  When I first connected the Box it only comes up with 720p Resolution, far away from 4K at all.
 
Some other things happened, Rock64 was send to Devs and Developement seems to become more and more Stable, so it tried to check Ayufans Android Image on this Box. I got me the Android Tools and flashed the Image to the box on a Windows Machine . Adroid came up without Network, (as expected) but seeing this Image Booting made me thnking of trying the a Desktop Image on this Box.
The Android Image can be flashed via Android Tools, but not the Linux Image. To make the Box boot from SDCard it has to be Set to Maskrom Mode. This could be easily done with the Android Tool.
1. Start the Android Tool on Windows
2. Go to Upgrade Firmware
3. Load some Firmware for this Box (the one from Ayufan or some of the originals..)
4. Plug a Male to Male USB Cable to the OTG Port of this Box, while Pressing the Reset Button for ca. 5s
5. Now go to "Erase Flash" , Done the Box is now in MaskRom Mode..
 
Just like always prepare a SD Card with an Image and watch Ubuntu comig up on this Cheapo.
 
I am writing now from this Box and even this is an early Stage of Developement, it looks very promising. (Just found that "Take Screenshots" is not working...)
 

I found the test point for enter MASKROM mode without erasing internal memory :-)

It really works :-)
How about internal flash driver? There is no suitable device in /dev :-(
 

The RK3328 seems like a very nice SoC, but the support in mainline linux is currently very limited and there are still a few issues with Rockchip's LSK 4.4 kernel.
We are currently tracking a few RK3328 issues at https://github.com/Kwiboo/linux-rockchip/issues for our LibreELEC endeavor.
 
@Xalius @Da Alchemist Android is most likely limited to 720p due to the weak GPU, we are planing on doing the same for LibreELEC/Kodi/PMP, limit gles to 720p/1080p but allow video frames to be shown in 2160p.
On the Z28 box we are only able to have a smooth gui at 720p, at 1080p there are noticeable frame rate drops at times.
 
@jernej there was a ffmpeg mpp decoder submitted earlier today, see https://patchwork.ffmpeg.org/patch/3904/
Multi-channel PCM via HDMI should work very similar as other SoCs with 8ch I2S and a DesignWare HDMI TX IP, works great on Rockchip's LSK 4.4 kernel at least.
The Rockchip RK3399TRM V1.3 Part2.pdf from Firefly-RK3399 docs is very interesting if you want more details about the HDMI TX IP and its registers.

That may be hard, but I just checked mpp source (Rockchip HW video acceleration library) and it mentions that RK3328 is fully supported. Rockchip kernel 4.4 also has initial support for video decoding. I would say that future is bright.

[Disclaimer on]
This is the try to play through some sort of an approval process contuining discussion from here and there -- maybe move @hmartin's last post to the latter thread? IMO we need a transparent process to decide whether to support new devices or not weighing pros/cons for both developers and users and estimate efforts especially if it's a new platform. Even if hardware vendors send out free dev samples we should not automatically start with new boards but discuss and evaluate first since we already deal with way too much boards with a crew just too small. I would believe @Igorhas now every new Olimex device and TL Lim said he sent out 3 ROCK64 boards to various Armbian devs me being amongst... I think that's an opportunity to start to establish such a process now?
 
Since I've thought about this issue for a few days and came to no conclusion (Github issue or not or discussion in forum and so on) I'm now just naively start with a new thread regarding this RK3328 device and maybe we find out collectively how to define a process based on this?
[Disclaimer off]
 
Let me introduce ROCK64:
 
RK3328 SoC: feature list ROCK64 schematic (preliminary since vendor promised to accept last minute changes/suggestions within the 2 next weeks) Board layout picture (same form factor as Raspberries, pre-production samples do not fit exactly in RPi enclosures, final design should fit) 1GB, 2GB or 4GB PC-18666 LPDDR3 eMMC has higher boot priority than SD card (but eMMC can be disabled via jumper) socketed eMMC modules are the same as on Pinebook and SoPine (and compatible to older ODROIDs and their SD card adapter) 128Mb SPI NOR flash (16MB) on future board revisions (to directly boot from USB[3] storage, network or whatever) RK3328 should be interesting for media center purposes (4K support, video codedcs, somewhat decent GPU, high memory bandwidth) Due to USB3, GbE and additional Fast Ethernet also interesting for NAS/server use cases (TBC, both USB3 and GbE performance needs to be checked) I2S exposed and compatible to some early RPi DACs, a lot more GPIOs exposed as usual (see picture above and this) Pricing will be competitive (can't share details yet but it's based on amount of DRAM and tries to match Pine64 costs but since DRAM prices increased a lot the last months it might be slightly more. Prices will be announced publicly within the next 2 weeks)  
Pros:
board vendor actively participates (listens to community, provides information including schematic and cares about correctness, tries to bridge developer community and chip vendor) board vendor provides dev samples and documents problems devs might run into (see below) chip vendor actively supports mainline Linux and u-boot chip vendor is said to focus on ROCK64 as currently best supported RK3328 device to spread market adoption (TBC) SDK/BSP not horribly outdated (RK relies currently on 4.4) almost all Armbian target audiences might benefit from RK3328 support (desktop replacement, NAS/server, audiophiles + IoT use cases due to exposed GPIOs/interfaces) No unreliable shitty Micro USB for DC-IN but sane 3.5/1.35mm barrel plug to be combined with 5V/3A PSU Pine Inc already sells together with Pinebook Icenowy already received a dev sample  
Cons:
 
new platform (Rockchip 64-bit) needing more initial work  
Did anyone of you received shipping confirmation with tracking number already? @jernej? Unfortunately I get a dev sample with unusable USB3 (some components need to be desoldered which is a pity since I'm not good in soldering at all)
 
My next steps planned:
 
Boot the board with what's provided within one week (TL Lim mentioned a 'Debian based 4.4 BSP, later Yocto' and said RK would be ready with a mainline variant within the next weeks) Test GbE speeds, memory throughput and the usual Armbian tunables (IRQ distribution) ask @Xaliusfor USB3 numbers (his dev sample was shipped out later and doesn't need soldering) Present results to continue discussion

BTW: I don't want to discourage anyone working on this board and further improving support. It's just me giving up on this hardware since ASUS performs so lousy (wrt deal with 3rd parties wanting to do exactly that: improving software support for their hardware). So as a last hint: since I believe the only really interesting use cases for this board are 'Desktop replacements' you should focus on this when experimenting with different cpufreq governors. Most desktop tasks benefit a lot from cpufreq being ramped up as quick as possible. Also have a look at: https://forum.armbian.com/index.php?/topic/4246-can-improve-the-desktop-performance/ (though I believe it's also important to improve IO behaviour of browsers)
 
 
 
This is Rock64 with an I2S companion board sitting on it: https://drive.google.com/file/d/0B0KJDZUkcqOqUnBYNU9JN0EwV2c/view (details will be available soon so I won't share more information now since there isn't much more I know anyway  )

4.4 kernel should support it since last month or something like that (I was analyzing exactly that piece of the code), but I didn't test it.

Tested it and it is working! Great!

@Da Alchemist Should be o.k. now: https://github.com/igorpecovnik/lib/commit/71d89e856da2d56fa56822885a30149f7d2ee420

The answer to this question is quite simple. Without soldering you will not get any I2S output, because Dout, PA20 is used for a led. So in my opinion  there is no need to activate this feature.
 
The PC2 is a fantastic Board, if you use the Multichannel HDMI output with the legacy Kernel from Xulong. My PC2 is running as active Crossover and mpd as Streamer. None of the other Oranges support this feature.

Once SoC is supported, adding new boards should be easy. But first, please wait until RK3288 is supported in Armbian.

I have installed  JackD and  Guitarix  on my OpiPC+ and it looks promissing. As Soundcard i have plugged in a cheap Behringer UCA202 

I will update audio drivers from tinaos, which improves I2S (reported in another thread). Based on the fact that HDMI also uses I2S internally, I hope this will improve situation. From what I know, tinaos and H5 BSP codebases are not very far apart.

Tested the Hummingboard and found only 16bit supported. The Things from Solidrun are far too expensive IMO.
 
Regards

There is no Multichannel Output on H3 Boards via HDMI, i have checked this months ago. All Channels are downmixed to 2 Channels playback. 
I am using a Raspberry Pi 1 (singlecore) for the Thing you want to do. But even with a "tweaked Kernel" the Raspberry can only do 16 bit Output. I am using Brutefir for Crossover and Roomcorrection and build the Filters with rePhase. The Raspberry Pi (1) can do 2 Channels digital Input ( via Wolfson Audio Card) and 4 Channesl Output via HDMI...USB is not recommended cause USB and Network are using the same Chip.
 
Regards