Xalius

Just in time for FOSDEM some more infos on the new Pine64 H6 and RK3399 boards are available now...
 
https://forum.pine64.org/showthread.php?tid=5614

I am investigating a weird issue I have with SOPine modules at the moment, GbE works fine on the Baseboard A with 4.15-rc6, but not on clusterboard, I also have an issue with MAC address assignment where the interface drops into monitor mode after a while...

What Igor said :-), you can also use an overlay to enable it at run-time. Ayufan just added a script to toggle existing nodes without creating an overlay for each.
 
https://github.com/ayufan-rock64/linux-build/blob/master/package/root/usr/local/sbin/enable_dtoverlay
 
The eth1 interface was disabled by default since it creates issues when there is no magjack mounted on the Rock64 for it, e.g. when you don't have the top-board with the audio DAC, this is also the usual Linux convention for boards with headers.

Those are not really video drivers, it's more or less just the glue layer between Cedarx (AW's proprietary video libraries) and the kernel drivers for Android BSP (Linux 3.10.x).... so it's more or less just a reference to look up some things that are not in the documentation (which might be released soon...)

Leapo has started porting RPi.GPIO to Rock64 as R64.GPIO, you can find her work in progress at
 
https://github.com/Leapo/Rock64-R64.GPIO
 
Original thread with instructions/updates is here:
 
https://forum.pine64.org/showthread.php?tid=5902
 
She also made a more simple tool to work with GPIO:
 
https://github.com/Leapo/Rock64-BashGPIO

I have three of the V3s based LicheePi Zero's and they work ok, V3s mainline u-boot and 4.16.x Linux work out of the box... you can still buy those at the taobao shop page Zepan set up...

I assembled a mainline (thanks @Icenowy and @jernej!) image with some Arch rootfs for my PineH64 and now after the libdram workarounds and other spl fixes seem to work, I got a least USB2, USB3 and GbE working...  waiting for some more linux-sunxi upstream patches now to fix an issue with DRAM clocks...

I assembled a mainline (thanks @Icenowy and @jernej!) image with some Arch rootfs for my PineH64 and now after the libdram workarounds and other spl fixes seem to work, I got a least USB2, USB3 and GbE working...  waiting for some more linux-sunxi upstream patches now to fix an issue with DRAM clocks...

Free Electrons (now Bootlin ;/) have launched a Kickstarter to get the work on the Allwinner VPU (Video Processing Unit) off the ground again...
 
 
https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel

Free Electrons (now Bootlin ;/) have launched a Kickstarter to get the work on the Allwinner VPU (Video Processing Unit) off the ground again...
 
 
https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel

Free Electrons (now Bootlin ;/) have launched a Kickstarter to get the work on the Allwinner VPU (Video Processing Unit) off the ground again...
 
 
https://www.kickstarter.com/projects/bootlin/allwinner-vpu-support-in-the-official-linux-kernel

Has the rx/tx delay been tuned on the Tinkerboard? Since we did that for Pine64/Rock64 most of the GbE issues have gone away. Ayufan made an automated script that uses configfs/dt-overlays to iterate through all the values without rebooting each time, based on tkaiser's scripts... 
 
https://github.com/ayufan-rock64/linux-build/tree/master/recipes/gmac-delays-test
 
This resulted in a small patch that did wonders for GbE performance:
 
https://patchwork.kernel.org/patch/10178969/
 
Worked both for BSP and mainline...
 
 

Just in time for FOSDEM some more infos on the new Pine64 H6 and RK3399 boards are available now...
 
https://forum.pine64.org/showthread.php?tid=5614

Just in time for FOSDEM some more infos on the new Pine64 H6 and RK3399 boards are available now...
 
https://forum.pine64.org/showthread.php?tid=5614

RPi is not 'The grandfather of SoCs', if you think that, you are about 10 years late, and it is a good example of how you can still make a good project of obsolete hardware by having enough people buy into the hype...

I just booted a mainline kernel on my Rock64 (4.12-rc7 with defconfig, rest was from ayufan's minimal xenial image) and that seems to work ok.  Currently investigating a problem with the GMAC0 not finding the PHY, so no network at the moment, but USB2 seems to work, USB3, video and audio drivers are not there yet...
 
Boot log: http://pastebin.ubuntu.com/25206030/
 
I guess I will try 4.12.4, 4.13-rc2 and rockchip-next as well...

I just booted a mainline kernel on my Rock64 (4.12-rc7 with defconfig, rest was from ayufan's minimal xenial image) and that seems to work ok.  Currently investigating a problem with the GMAC0 not finding the PHY, so no network at the moment, but USB2 seems to work, USB3, video and audio drivers are not there yet...
 
Boot log: http://pastebin.ubuntu.com/25206030/
 
I guess I will try 4.12.4, 4.13-rc2 and rockchip-next as well...

I just booted a mainline kernel on my Rock64 (4.12-rc7 with defconfig, rest was from ayufan's minimal xenial image) and that seems to work ok.  Currently investigating a problem with the GMAC0 not finding the PHY, so no network at the moment, but USB2 seems to work, USB3, video and audio drivers are not there yet...
 
Boot log: http://pastebin.ubuntu.com/25206030/
 
I guess I will try 4.12.4, 4.13-rc2 and rockchip-next as well...

I either use the eMMC adapter that came with one of my ODROIDs or write to the eMMC from a sdcard image. There is also a flash tool from RK that uses USB-OTG via USB A-to-A cable... As for heatsinks, I mounted a small 14x14x14mm sink since I build a lot on my Rock64 and that keeps it from throttling with all four cores running at 1.3Ghz. The RK3328 is implemented with 28nm node, not sure what S905 uses?
 
http://www.fischerelektronik.de/web_fischer/en_GB/heatsinks/B01/Heatsinks for PGA/PR/ICKPGA14x14x14_/index.xhtml

I added some experimental tweaks to my development image to enable HS-200 mode for the eMMC ( was SDR50 before just like the SD card). I will submit a proper patch for ayufan's BSP linux branch during this week. To get HS-200 mode working, there were some clock definitions (looking at you, ciu-sample and drive clocks...) missing and some properties (maximum bus frequency) I had to add to the rk3328.dtsi... but it seems to run stable now...
 
Some iozone results before and after switching SDR50 to HS-200:
 
---------------- SDR50 --------------------------------------------- random random kB reclen write rewrite read reread read write 512000 4 3430 3554 10964 10472 8152 1614 512000 16 7064 7647 25009 25242 2069 6249 512000 512 10800 11494 41555 43169 42551 10620 512000 1024 11228 11736 42159 43690 43338 10890 512000 16384 11258 11733 44909 44825 44875 11165 ----------------- HS-200 ------------------------------------------- 512000 4 3414 3399 17914 8218 11523 1752 512000 16 9078 9804 56272 56583 39466 7190 512000 512 13173 14054 119128 118530 116335 13008 512000 1024 13816 14607 117665 121782 120387 13429 512000 16384 13814 14662 122756 124242 123471 14007 It seems we are getting close to the 140MB/s read performance the datasheet promises, but 15MB/s is still short of the 35MB/s write performance according to the datasheet, so any hints are welcome here...
 
I would also like some advice on the phase correction loop sublayer in the generic mmc driver, how does one pre calculate the default phase shift? 

http://linux-sunxi.org/USB/UAS

@r1kaomsk, the 4.4.x BSP kernel tried to store MACs in the GPT vendor partition on the eMMC. ayufan changed that for Rock64 images to the SPI flash since eMMC are removable here...

I use either flashcp or nandwrite from the mtd-tools, those can work directly on /dev/mtd0 or partitions..

Yeah the connectors for USB3-A are tricky. On my old Thinkpad the lower USB3 port which I used a lot more than the upper port enumerates half the time only as high speed instead of super speed because it seems to be worn out, I also noticed some USB3 connectors fit a lot tighter than others... I wonder if there is some low level stats we can pull out of Linux to see USB transmissions errors as an indicator for bad cable connections?
 
Edit: apparently there is this https://wiki.wireshark.org/CaptureSetup/USB

Yeah the connectors for USB3-A are tricky. On my old Thinkpad the lower USB3 port which I used a lot more than the upper port enumerates half the time only as high speed instead of super speed because it seems to be worn out, I also noticed some USB3 connectors fit a lot tighter than others... I wonder if there is some low level stats we can pull out of Linux to see USB transmissions errors as an indicator for bad cable connections?
 
Edit: apparently there is this https://wiki.wireshark.org/CaptureSetup/USB