TonyMac32

I was unaware of it, I'll take a quick look.

Seems ok. I would like to switch to Ayufan as soon as it is even with current Rockchip.

To echo Igor it should be possible. If the rk3288 is too much trouble (for example kernel configs) I'd recommend we move over to something more "conventional" with "RK32" and "RK33". Once @ayufan rebases on today's Rockchip kernel we can use his source on Tinker, I just think we'll have to have separate configs.

Agreed. I'll do some cleaning and we can flag it for release Sent from my Pixel using Tapatalk

Ah, I had forgotten the "Chosen" in the patchset. I can revert that. Thank you for the test! Sent from my Pixel using Tapatalk

I am working on restoring the vendor kernel for rk3288, if you could, a pull request would be greatly appreciated

While that's true, noisy little fan is not either in most consumer products, I'd rather not hear my media player humming in the corner while watching movies. Large dissipative plate works, load managing works, etc. The point is, for a Linux desktop (dynamic unmanaged load) heat sink of some variety is mandatory, in the box, from factory. Quite honestly I was surprised that some sort of dissipative cooling strategy was not implemented on all VIM's as sold, not only as an additional purchase later in the small space. Otherwise I am quite pleased with the hardware, it is very nice. Excellent.

It's applied per pin associated with the peripheral, so unless there's some drive strength multiplexing you should only define it for the desired SD pins. I haven't had an issue with mine, but I also haven't stressed it so I'll give it a look some time. (Next couple days I am a slave to my company, it will be 14 hours/day). Sent from my Pixel using Tapatalk

My VIM has no heat sink and no space for one. Seems they do enjoy roasting marshmallows on the processors.

OK, bluetooth and touchscreen return to rockchip-default tinkerboard. Anyone who can build it themselves please test. @JMCC I am off for some sleep, but if you get a chance,m build and test Mali/vcodec?

Small physical size + huge memory are not compatible. 512 will probably be tops for a tiny device. For size I would look at the nanopi duo. It has audio out as well as 2 USB's on pin headers. And it's an Allwinner H2+ (quad core a7), should be able to handle some processing. Pair it with https://www.adafruit.com/product/2377 by wiring it directly to a UART on the Duo to minimize size, and keeping it to something you'd be comfortable with. Unless: https://make.kosakalab.com/arduino/obaka/project-2/index_en.html If you are adventurous you can also run a http://www.cypress.com/documentation/development-kitsboards/cy8ckit-043-psoc-4-m-series-prototyping-kit I use the older one of these and the PSoC 5lp for work all the time, the software works quite well and the configurations are straight forward. I'd have made a hat with one by now if cypress had a linux development suite. ADC's make the Arduino look like trash. @Larry Bank Any thoughts?

armbianmonitor -u please. AP6356S on NanoPC-T4 is working without issue or complaint with that firmware. (currently attached at 585 Mb/s) I would review the kernel config you're using, especially after:

The build I am running on my NanoPC-T4 is showing all 6 cores.

Yes, otherwise any activity at all will cause it to throttle performance to avoid damage.

Missed that detail. the reference to the heavy pads though is that I'm guessing they are a power in point rather than a power out point, probably to feed that mythical connector spot further discussed below: Right, the big Molex and the mini-Spox are relatively easy, but it appears they designed that board to take a stand-alone 15-pin SATA power plug that doesn't exist. Not having 5V though, as you said, makes that irrelevant anyway, it won't be an overly clean solution no matter how you run it, a jumper to the big pads from the board (micro-usb powere, so :-/), or to an external supply. I guess at least it's the right size to fit the board.

I'm sure @tkaiser has something like this already, but for the rest of us ;-) https://www.amazon.com/gp/product/B07C34MT32/ This should work, of course you need to power the drive, I've ordered one so I can get a look at those partially hidden headers spots, looks to be a sata power pattern (15 places) May need some solder time to get both headers and (I would guess) the heavy pads are for the various power rails if you want to "spin rust" as I've seen it written. Finding the SATA power socket could prove challenging for the hobbyist, I'll pull up the Molex number for it I stand corrected, my search through the usual channels show no options for just a power connector to go through a PCB. I will dig some more, but...

I know this is irrelevant, but it's too cool for me not share: (Rockchip kernel 4.4 via HJC's work, Samsung 256 GB Disk /dev/nvme0n1: 238.5 GiB, 256060514304 bytes, 500118192 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Command line used: iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 4 63148 98717 117726 103704 32253 74841 102400 16 200588 282047 286796 312951 89631 242632 102400 512 472102 577041 458541 430672 540748 557106 102400 1024 506514 560837 485540 455210 498891 576875 102400 16384 951626 994023 920260 996905 973086 994344 Command line used: iozone -e -I -a -s 1000M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 1024000 4 72776 85094 109072 121242 34017 98562 1024000 16 221422 302439 331772 333805 88144 290576 1024000 512 565209 639164 465860 473754 602073 599450 1024000 1024 759673 793099 669950 684237 721181 748267 1024000 16384 1045977 1095899 1070003 1079163 1075869 1066718

We'll, there's very little difference in them fundamentally, it should take very little work to say Ayufan instead of Rockchip. I can try it and we can just swap. Same for RK3288

Default kernel is again bootable, still has some issues, anyone able to build/debug please do so and either put in fixes or give me recommendations.

I concur, and I have a feeling the editable nature of the wiki may be... impermanent, let's say.

@hjc Thanks for the hard work!

Not bad at all. If it isn't shorting anything out and you can tolerate the geometry, it is fine. Stick with copper or aluminum for heat sinks, more mass results in higher temperature stabilty, more surface area means more dissipative value.

On the RK3288 boards, if I am remembering correctly, the drive level is modified in the dts to avoid this issue. Is that possible with the RK3328 at least? I think the mmc IP is the same, but don't quote me on that. [edit] https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L1432 This part of the dtsi shows the default 4 mA drive levels for the pins. Tinker Board sets the equivalent RK3288 pins to 8 mA: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288-tinker.dts#L429 It would stand to reason you could do the same with RK3328: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L979

You have a fairly easy starting point as well: https://github.com/armbian/build/blob/master/config/boards/z28pro.csc Sent from my Pixel using Tapatalk

My attempt to build dev image resulted in an image missing the kernel version. [edit] found it, the packaging script is for "next", not "dev" - Fixed. Slow boot confirmed. :-)