TonyMac32

THE MEDIA SCRIPT IS NOW DEPRECATED, IN FAVOR OF THE OFFICIAL MULTIMEDIA FRAMEWORK. PLEASE REFER TO THIS TOPIC:
 
 
And, for last,  the first version of:
The UN-official, UN-supported, UN-expected
RK3328 MEDIA TESTING SCRIPT
 
This is the first release of the RK3328 media testing script. The script provides a functionality similar to its RK3288/3399 equivalents, except for the OpenCL related stuff, which is not supported by the SoC. So it includes:
Installing all the libraries and system configurations necessary for GPU accelerated X desktop, Chromium WebGL, full VPU video play acceleration up to 4k@60 10-bit HEVC (the maximum supported by the SoC), and GLES 2.0 support. Three video players supporting full VPU acceleration (RKMPP) and KMS display (GBM or a X11 DRM "hack", as described by the authors), namely: MPV, Gstreamer and Kodi. A library that will act as an OpenGL to OpenGL-ES wrapper, allowing you to run programs that use OpenGL 1.5-2.0. Two additional features, that have no big interest from the Armbian development prospective, but I find them interesting to play with: Chromium browser with support for Flash and DRM-protected commercial web video streaming (tested with Amazon Prime, should also work with Netflix, Hulu, etc.), and a simple Pulseaudio GTK equalizer using LADSPA.  
Here is a more thorough documentation:
 
 
 
>>> DOWNLOAD LINK <<<
 
Prerequisites:
You need a fresh Armbian Bionic desktop image with default kernel installed. 
 
Instructions:
Download the file above Untar it: tar xvf media-rk3328_*.txz cd media-script ./media-rk3328.sh  
Notes:
This script is not officially supported by the Armbian project. It is just a community effort to help the development of the main build, by experimenting with a possible implementation of the media capabilities of this particular SoC. Therefore, questions about the script should not be laid out as support requests, but as commentaries or community peer-to-peer assistance. That being said, all commentaries/suggestions/corrections are very welcome. In the same way, I will do my best to help solve any difficulty that may arise regarding the script.  
Enjoy!

Yeah, VPU doesn't exist in mainline.  There are some patches for educational purposes out there, but nothing constituting a truly functional driver.  Mali needs patched in, similar to what @Myy does with RK3288.

Tinkerboard "Next" Stretch and Bionic images available for download using kernel 4.19.
 
Notable changes include the use of device tree overlays.

Tinkerboard "Next" Stretch and Bionic images available for download using kernel 4.19.
 
Notable changes include the use of device tree overlays.

I'm afraid not.   :-/  I have an 800x400 hdmi, it's behavior is a bit different from a typical HDMI display, but as to why, I'm afraid I'm in the dark.

I'm using Home Assistant for more than one year and if you follow the armbian installation : use a Virtualenv !!!!! or you'll be facing very painful upgrades.
 
I switched to docker images but that's the same spirit.

you can start with testing: https://github.com/armbian/testings
maybe not yet for the RockPi 4b but for other boards you have?
 
google is a good helper which I quite often use.
 
If you want to dive into this it might be worth to start with some basics in device tree. The kernel comes with docs, docs are great to understand what a *random devicetree node* does. Combine this stuff try to build images, get errors on building or that the DT doesn't work, use google (or ask here), build again and learn step by step.
 
You need a virtual machine with ubuntu on it and some spare-time. You may file a few times until you get something working but that's fine. Happens to all of us.

Wait, what? Not much faster? If you say at burning energy during operation, I agree; otherwise, I think every benchmark on the planet is against you. I have 2 Pi3's, I can't use them because they are slower than very nearly every other board I possess, they collect dust. My Pi2 serves to play music for me.

Sent from my Pixel using Tapatalk

With the SDIO changes for better strength done by @TonyMac32, it seems that the laggyness is gone !

And also Terms of Use / Community guidelines should be linked somewhere in plain sight. Right now it can be accessed when registering, and even there it is not clearly shown as a link. IMO it should be on the top menu row as it is more important than i.e. Privacy policy that exists mostly for legal reasons.
 
Edit: It's also on the bottom bar, but it will be hidden after you click "Accept", looks like by a specific cookie.
 
Edit 2: Now that I'm looking at those (Registration Terms specifically) - they should be a numbered list instead of a bullet list, and we should probably add a new rule "Try to stay on topic defined by the starting post or developer posts in the thread. Off-topic posts that derail the discussion may be hidden, moved or deleted."

I renamed the link and rebooted, works fine for my odroidc2; no more spam in the journal.
 
# cd /etc/systemd/system/getty.target.wants && mv serial-getty@ttyS0.service serial-getty@ttyAML0.service # ls -l [...] lrwxrwxrwx 1 root root 34 Sep 18 11:24 getty@tty1.service -> /lib/systemd/system/getty@.service lrwxrwxrwx 1 root root 41 Sep 18 16:38 serial-getty@ttyAML0.service -> /lib/systemd/system/serial-getty@.service  

Hola tauroblau,
 
    If possible please use English on the forums, it is quite helpful to everyone, since all told there are probably over 10 (low estimate) languages spoken by the various members.
 
For the Pi there is no plan on supporting that family of boards.  They embody many of the things we point to as fundamental problems with basic board design (micro USB power, horrible I/O bandwidth, propagandist marketing, just plain wrong benchmarking, I could go on.  The 300 Mbps on the RPi will be significantly affected (negatively) by any other USB peripheral, like a storage drive.  I would recommend researching other boards and finding one with GbE for your needs, the RK3328 boards, RK3288 boards, etc.  They are pricier, but if you need the performance, you will have it.

Aha!  I only turned up the V1.1 datasheet that does not specify the "G" variant.

I'm afraid not.  A few have some sort of "marker" to show what they are (a resistor somewhere tied to an ADC, and efuse value, etc), but they are as non-standard as the SoC's themselves.
 
 
A lot of people feel this way, but it would require an agreement on a standard.  SPI flash or an eeprom drive cost some vendors will never sign up for, and create some problems when needing to upgrade the information stored on them (device tree bugs, bootloader fixes, etc)
 
And projects like this one wouldn't have much to do either, the "big guys" would take over and you'd have the same basic options as PC, with others like us and Arch being "alternatives".  That said, there is a versatility of application to SBC's that does not exist with PC.  Few strap a PC to a bench with bare I/O monitoring things, that died with the parallel port.  So I think there will always be room.
 
An FPGA that runs a RISC-V  powerful enough for linux isn't in my budget just yet, but it does look interesting.

That would be ideal, but some of these boards have... peculiarities that cause source code issues (Tinker has some gymnastics around reboot that require some ugly hacking of the sd/emmc driver that can break other RK3288 devices) or userspace issues (manually toggling IO's to reset BT adapters).  In general, though, you'll find that most of our images are the same for the same SoC, just with DTB/boot script differences for each particular layout, it's why on any board bringup you see us just manually swapping DTB's to see if it will work out of the box.

If the devices aren't plugged in on boot with 4.17+ the hub will go into a suspend state that can't be woken.  I've patched this in the 4.19 dev images by copying the solution for Rockchip (same IP block).  One of the upstream contributors submitted a nearly identical patch within a day of mine, so it will be fixed in the future.

On bionic 4.19.12-meson64 #5.67.181226:
$ xrandr -d :0 -q
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 16384 x 8192
Composite-1 connected (normal left inverted right x axis y axis)
  720x576i      50.00  
  720x480i      59.94  
HDMI-1 connected 1920x1200+0+0 (normal left inverted right x axis y axis) 546mm x 352mm
  1920x1200     59.95*+   (yes)
  1920x1080     60.00  (yes)
  1600x1200     60.00  
  1680x1050     59.88   (yes)
  1280x1024     75.02    60.02  (HDMI only)
  1440x900      59.90  (yes)
  1280x960      60.00  
  1152x864      75.00  
  1024x768      75.03    70.07    60.00  
  832x624       74.55  
  800x600       72.19    75.00    60.32    56.25  
  640x480       75.00    72.81    66.67
 
Legenda of test result:
(yes) means that HDMI to HDMI and HDMI to DVI both work
(HDMI only) means HDMI to HDMI works
no () means that HDMI to HDMI and HDMI to DVI both don't work.
 
PS
To change resolution from UART console I used for example:
$ xrandr -d :0 --output HDMI-1 --mode 1920x1080
 

Other test performed. I am starting to understand better the "HDMI to DVI" working/not working laziness problem:
 
HDMI to DVI works BUT, just after the boot, I have to move the mouse to wake up the monitor and get the desktop (I usually interact with the SBC via the uart console).
 
That's with the last:
ARMBIAN 5.67.181221 nightly Ubuntu 18.04.1 LTS 4.19.11-meson64
 
 
 
 

Thanks, worked great.  I now see bus /dev/i2c-0 and /dev/i2c-1 and my device id shows up on /dev/i2c-0
 
i2cdetect -l
i2c-1    i2c           DesignWare HDMI                     I2C adapter
i2c-0    i2c           Meson I2C adapter                   I2C adapter
 
Looking forward to the future update with the overlays and eMMC, I have what I need to try and port the Pi-Top device support over now.

Hi all!
 
I've tried Xulong Extension board for Orange Pi Zero and found it useless waste of my money. Almost two months ago I've decided to make my own hacking shield which allows me much more in terms of control and peripherals. 
 

 
 I've tested functionality most important to me and I'm pretty happy with result. I2C works, USB power switch works, power measurement works. Project page on GitHub
 
Now I'm in progress making peripherals accessible to the system and user.  Userspace tools for python/node/C works and later I will publish tutorial (or more than one) how to make it (because it is not clear to me and take huge amount of time).

We plan to use https://github.com/superna9999/pyamlboot for LaFrite, but it works on LePotato aswell, and it will be supported by the next U-boot version (in master right now https://github.com/u-boot/u-boot/commit/d96a782d09dbdc4a28ece3d18dc17a572e39d4f2)
We still need to generate a generic initramfs+kernel image to flash anything.

I've broken these things down (perhaps too far, but I will give a case for it, and we can all discuss), here are the overlays:
 
- ds1307
- i2c1
- i2c4
- spi0
- spi2
- spidev0
- spidev2
- uart1
- uart2
- w1-gpio
 
The DS1307 was simply pulled from ASUS as a simple test overlay while I was working through implementing the scripts.  it can be jettisoned for all I care.
 
These are all written with only the Tinker Board in mind, of course they are all SoC-centric other than the 1wire and ds1307
 
"Pi" ports:
 
- i2c1 is the "Pi" I2C channel.  Make it configurable in case you just want the GPIO
- i2c4 is the "Pi" ID I2C channel.  Make it configurable in case you just want the GPIO
- spi2 is the "Pi" SPI channel. Makes it configurable in case you want just the GPIO
- spidev2 enables the user space spidev driver with 2 chip selects for spi2
- uart1 is the "Pi" UART position. 
 
Tinker ports:
 
- spi0 is the "extra" spi channel on Tinker, on pins 11/13/15/29/31.  Disabled by default, it occupies the same pins as UART4  *Not Pi Compliant in location*
- spidev0 enables the user space spidev driver with 2 chip selects for spi0
- uart2 is the debug port for Tinker.
 
There are some interesting extra features exposed on some of the pins (PWM/etc) that I would like to experiment with, we'll see. 
 
I have pulled the spi out as an overlay separate from the peripheral attached to it, my thought is, there may be 2 unrelated devices tied into the board on each chipselect that the user has their own overlay for.  (So up to 4 devices on hardware SPI)

When I copy/pase links from AliExpress or eBay, I always shortening them manually to before the first "?" and check if link still relevant ...

Jamess (Asus) located the sample rate issue, seemingly due to an RK commit for a "fix" in the rockchip clock driver. They will now check with RK why that was done.
Good thing: it did not make it into upstream, so with 4.19.y we should be fine for the (time being).
 
 

I forgot this came up in this topic, I have modified the rk3328.dtsi to use 8mA drive strength on all rk3328 boards, that will fix the issues for most users as far as the electrical interface is concerned (it is default 4 mA). 12 mA is available, if someone spends enough time rigorously testing to determine it's needed (probably edge cases with crappier than normal cards or poorly routed designs with too much capacitance) Rock64 was having the same complaints.
 
https://github.com/ayufan-rock64/linux-kernel/commit/501b604fcb0b317e82be21183f764bc3e4e1f519
 
For S905X, I'm afraid I haven't found a way to change the output drive level.