TonyMac32

That's the question we're working on. I think we can handle all from one codebase, at least as long as there aren't too many Tinker Reboot workarounds on other boards (I have that "contained" so it doesn't break anything) From kernel to kernel the MAli drivers need tweaking, and while @Myy does excellent work with this, I thought it easier to keep Next on an an LTS kernel, then if people want bleeding edge they can compile a Dev image. Also, welcome back!

I can't see the logic of that, the eMMC is twice as fast as the typical SD card, the system will run much better there, and you can then mount an SD card as storage. My opinion aside, that can't currently be done with the mainline/LTS kernel.

We could, but 4.14 is working nicely, we could wait until we get the next LTS to switch Next, since that should happen in a few months, giving us some time to prepare and consolidate if necessary.. We could try to work to get everything staged for that. We also need to decide (meaning I'm not just going to do random stuff) on moving the HDMI-hotplug scripts provided by @botfap to the generic section, as the same script is currently servicing at least 3 families (XU4, Rockchip, Meson64), and is "hiding" in the Rockchip bsp folder.

I'm hoping it is cleared up soon, but so far I haven't been able to get strange green static out of my video on the K2. Another thing to think about. @balbes150 I haven't spent a lot of time on the K2 video "static", is disabling cvbs entirely the way to stop that?

As I only really handle the RK3288 stuff, I was seeing what the agreement of others was. But, as both topics (as @tkaiser pointed out) died, I'll pose questions: kernel 4.4: @ayufan I don't see any problem with rebasing for releases. Do you see any issue with having patches for the MiQi/Tinker Board involved? In any case I could simply hold those locally to the Armbian build script. kernel 4.14+: I see no reason we couldn't have all mainlines lumped together on Rockchip, I've been careful to avoid cross-contamination on my side

Tinker S eMMC iozone: 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 kB reclen write rewrite read reread read write 102400 4 32212 37213 36771 36971 23893 36212 102400 16 60315 61679 69904 70326 64224 58809 102400 512 71918 72275 116044 116542 113055 71026 102400 1024 72041 71703 118508 118489 116860 71708 102400 16384 68241 72212 132131 132147 131849 72001

OK, I just followed my own instructions with a new in-box board (had a spare) and with one currently flashed with armbian. it works both ways: - do not put the jumper in maskrom. You need u-boot to enable UMS so etcher can flash the eMMC. iozone of eMMC: @tkaiser if interested, I can't remember if this was shared yet. 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 kB reclen write rewrite read reread read write 102400 4 32212 37213 36771 36971 23893 36212 102400 16 60315 61679 69904 70326 64224 58809 102400 512 71918 72275 116044 116542 113055 71026 102400 1024 72041 71703 118508 118489 116860 71708 102400 16384 68241 72212 132131 132147 131849 72001

That is the answer to the idea. As far as getting the image onto the device, attach the Tinker Board S to your PC with a microUSB cable (ideally to a power-ready port), and your PC will see 2 new drives. Open etcher, and it will burn the image to the eMMC for you. once etcher finishes, reboot, no jumpers.

There are a few patches that need to be implemented to get the Linux kernel on Tinker S to enable the eMMC if the jumper is in the "maskrom" position. I pull the jumper as soon as U-boot is loaded from SD and that works. I have not tried modifying them for mainline.

I would guess there are some similarities between the Allwinner method and the Amlogic one, both using a small mcu to handle the laundry and cooking. ;-) But, a look at the Amlogic kernel would be the most certain way to know

I missed this. Yes, there is a node on the Amlogic devices.

I answered on my phone earlier, thread with benchmark:

Yes, the Veyron Chromebooks can be had cheaply, actually.

I used a TRS80 model 100 portable as a Linux console simply to troll my friends. :-) I also have an old HP Jornada 720 and an NEC mobilepro 900, both have keyboards and in clamshell format. I miss the "back pocket clamshell" form factor, maybe Pine64 is listening? :-P. I was recently looking for LCD's to swap in with a connector-depopulated board, 640x240 is not something you find... :lol:

I am going to call the K2 I have a "close enough" to C2 board (both are Amlogic gxb dev boards in Pi form factor). I would say that today, right this second that the switch would not be a great one in the case of either board. That said, I only support/work with mainline kernels, and an RFC patchset has just been submitted for review to enable the video decoder hardware. With that and the Mali driver you'd have a superior solution to the RPi in either case, hands down. As to the board vs board situation: Le potato is lacking GbE, wifi. It is, however, not incredibly expensive and has quite impressive memory performance compared to the C2. (Benchmarking thread has details). That will be important for 4k video. The C2 is the only Amlogic based device on the market that does not lie about it's current clock speed. This has to do with some ugly history and past claims of "2.0 GHz" operation. There is a whole thread here somewhere talking about clockspeed cheating. As an HTPC that's not as important, and RPi is guilty of it as well, if not even worse depending on the board. With the hardware support in mainline maturing so quickly, I'd guess the Amlogic devices will be a good bet for that use case very soon. If you want wifi and GbE you'll want a C2/K2, if you want faster memory for potentially smoother playback go Le Potato.

@martinayotte I'm glad you said something, I was going to start playing with that in the next few days. Do you have a RockPro64?

I have an S905X VIM, haven't put Linux on it as yet, perhaps tonight. No heat sink, as delivered.

I need to verify this, remember I mainlined the K2 U-boot with the generic Amlogic gxb blob. I'll see what I get with the friendlyelec blob, but the repo looks like the garden variety stuff to me.

Le Potato: http://ix.io/1iSQ (1.408 GHz max speed when 1.512 commanded) Tinker: http://ix.io/1iSX (Claiming throttling, but I think it's because we add OC OPPs and limit it to 1.8 GHz by default) NanoPi K2 (S905 has different blob than S905X): http://ix.io/1iT1 (I need to build a 4.18 and see if that makes some of the differences go away. ) The Potato and the K2 had extremely different results, I need to re-run the K2 with a 4.18 kernel and see if that changes things, since Meson64 mainline is still active development, whereas RK3288 is more or less stable Memory access in Meson64, it seems the Potato wins by a good margin, Potato: standard memcpy : 1812.9 MB/s (0.2%) standard memset : 5731.6 MB/s K2: standard memcpy : 1655.6 MB/s (0.3%) standard memset : 3871.9 MB/s C2: standard memcpy : 1424.9 MB/s (0.2%) standard memset : 2600.6 MB/s ... But then miner showed something odd: K2: Total: 4.62 kH/s C2: Total: 4.63 kH/s Potato: Total: 3.93 kH/s <---- wtf?!?!

The 7z file is a compressed archive containing the image Sent from my Pixel using Tapatalk

I don't see where a *.y file is in the download. As far as the supply goes, I would want to verify the output of it before I tried another. If you have a USB power monitor https://www.amazon.com/Musou-Digital-Multimeter-Chargers-Capacity/dp/B071214RD8/ you can see what is happening on the Tinker Board by measuring one of it's USB outputs.

Sounds amazing... I have a Chicony-made "Amazon basics" for primary lab use, I would like to mention that on 4.17 in particular I had USB problems (as in no usb at all on Lepotato or NanoPi K2. I assume that means C2 would have the same issue). Appears to have been cleared up on 4.17.7 or so, I haven't seen what was the issue

This is more about the developer and less about the kernel. I haven't taken the time to learn enough about the overlays to get it done in a supportable way. Sent from my Pixel using Tapatalk

Well that's entertaining

Requires device tree overlays, something not yet implemented in these kernels.