James Kingdon

Since 100MHz worked in hs200 mode, and porting the dynamic tuning code looks like a fair bit of work, I decided to try 150MHz and see what happens. Result is it seems to be stable (I'm typing on the pinebook in that mode now), and it gave a nice boost to the iozone results: 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 6891 7237 11490 11482 6614 5651 102400 16 19316 19884 49466 48654 25507 17839 102400 512 67821 58035 126793 127178 114462 47874 102400 1024 67095 57421 127057 127459 119481 46386 102400 16384 68019 58935 125989 126261 126379 54282 I'm going to leave the pinebook with this as the default setup and see how it shakes out. In the meantime, I hope to make some progress on dynamic tuning and the long march towards hs400 Maybe I'm too easily pleased, but 120+ MB/s read blows my mind for a $30 module (and the write speed isn't exactly bad either).

ok, that worked (compiling a matching set of kernel + modules with a new LOCALVERSION so that I could tell them apart from everything else, and packaging as a deb). Looking at the vermagic strings, it looks like I threw myself off by setting a kernel config option for module versions before I took Zador's advice of using LOCALVERSION to make the uname -r strings match. I suspect if I hadn't done that, things might have worked fine, but I have a tendency to thrash around trying things out and generally getting myself into trouble.

Hmm, I just found something about vermagic strings embedded in the module .ko files. It seems my understanding of how modules work is very naive. I think I'll try using a different LOCALVERSION post fix and creating a matching set of kernel and modules and see if that works.

Hi Igor, I'm not specifying a config file, so I believe it's picking up the default .config

Hi, If I build my kernel 'properly' using the armbian compile.sh script with docker, everything works fine. If I run the docker image interactively, go into /armbian-cache/_data/sources/linux-pine64/my-hacks-1.2 and do export PATH=/root/armbian/cache/toolchains/gcc-linaro-5.4.1-2017.05-x86_64_aarch64-linux-gnu/bin/:$PATH make ARCH=arm64 CROSS_COMPILE="aarch64-linux-gnu-" -j8 $* I get a kernel that seem to work in every way, except it won't load any modules. The 'normal' build uses modules in /lib/modules/3.10.107-pine64. The non-compliant kernel reports uname -r of 3.10.107+. I tried copying the existing /lib/modules/3.10.107-pine64 to /lib/modules/3.10.107+ and running depmod, but it doesn't seem to have helped. Can anyone point me in the right direction to fix this? While running the whole compile.sh process makes sense for a final build, while I'm hacking on the device driver it's a lot quicker to just recompile inside an interactive docker process than it is to generate new patch files and create a new docker image. Thanks for any help!

Me too. I'm itching for this board to come out. I keep looking at the firefly but it's going to cost me $$$ by the time I factor in the exchange rate, shipping and the hideous border duties. My guess is $100 would be at the low end of the possible price range for Orange, but the closer they can get to that the happier I will be. The tv boxes look like great value, but I've had bad experiences with every tv box I've tried so far, so I want to see someone else get Linux up and running on one first

He's definitely making progress. I haven't checked the new release, but from what he said on irc I don't think it's working properly with the 64G sandisk on pinebook. Apparently it works great on the rock64. I've been looking at the code changes in the new release and one in particular has let me make a bit more progress - I can now successfully switch into hs200 mode, which is a necessary step to full speed. The next thing is to run auto-tuning in hs200 mode, without it the host<->mmc communications don't work reliably at 200MHz. Unfortunately the normal code path is via function pointer that hasn't been set, so I have to do some searching to try and find where the routine is. For giggles I tried running hs200 at 100MHz which seems to work fine. It's currently running in sdr mode and it has almost identical performance to 50MHz/ddr, which makes sense. Baby steps...

I put a copy of the kernel image I'm using on filebin for one of the guys on irc: https://filebin.ca/3dBZ0qmNivMa/Image-3.10.107-pine64 Of course I forgot you'd also need a copy of the modified uboot, and it's been long enough since I've looked at uboot that I'll have to dig around to find where I left a copy. I'll update when I find it. OK, here's the uboot to go with the above kernel: https://filebin.ca/3dBng1sFqg02/linux-u-boot-pinebook-a64_5.32_arm64.zip The zip file contains the uboot binary and a very simple script to install it. Check the device in the script matches the device for the emmc on your machine before running it, which will need to be done as root/sudo. I'll try and get these contributed as patches to armbian as soon as I can (sorry for the delay, work has been very busy recently)

Interesting, seems to be the same here - sleep on idle doesn't seem to kick in, although I have a place to set it in the power management preferences dialog.

mate-power-manager is running, so I guess so. systemd-inhibit seems to confirm that: What: handle-power-key:handle-suspend-key:handle-lid-switch Why: Mate power manager handles these events Mode: block

Works fine for me using an armbian build with mate installed on top. I didn't have to do anything to make it work. One thing that does catch me out is the machine powers up when you plug the dc in. I have to try and remember not just plug the connector in with the machine closed and suspended and wander off to bed.

Ah, that rings bells - I have two RK3288 boards, neither of which work. It was a reference to OpenCL on the Q8 that was one of the reasons I got one of those. Your comments about the potential pitfalls made me smile. Good points, but all part of the fun (maybe).

Ah, that's interesting. Is there a currently available SBC that has working openCL? It's something that I'd like to learn about someday, but hadn't looked into which boards could support it.

I got a mainline kernel up and running. It detects the mmc ok, but clearly fails to get it into hs200 or hs400, so I'm not going to get any clues from the new driver. kB reclen write rewrite read reread read write 102400 4 10712 11284 11803 11642 5615 8249 102400 16 15740 16719 18346 18308 12720 15285 102400 512 21920 22029 22545 22659 21987 21794 102400 1024 22085 22075 22784 22810 22470 21942 102400 16384 21628 22318 23012 23019 23007 21744 the /sys info suggests it's in 50MHz sdr mode: root@pinebook:/sys/kernel/debug/mmc2# cat ios clock: 52000000 Hz actual clock: 50000000 Hz vdd: 21 (3.3 ~ 3.4 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 3 (8 bits) timing spec: 1 (mmc high-speed) signal voltage: 0 (3.30 V) driver type: 0 (driver type B) I contacted SanDisk to see if they would provide a datasheet or app note for the chip, but they politely declined. Such is life.

Call me boring, but I wish that had been openCL support.

While I had the pinebook open just now I grabbed the chip markings from the emmc module. SanDisk SDINADF4-64G 7265DRKGP02Z I haven't had any luck finding a real datasheet or application note for the SanDisk modules, so if anyone finds one please throw me a link

I did a quick test with 2A charge rate in shutdown. I had the back of the case and the heatsink off so I could attach the probe, so it won't entirely reflect normal usage, but the pmic stabilised at just under 40C, with the battery at about 25. This was with the battery at 20% capacity, so the PMIC should be delivering most of the target current. I'm fairly happy with that rate/temperature compromise, so I don't think I'll try and push it any harder.

Well, it seemed like a nice theory, but it didn't work. I've tried a few other things as well, such as switching the order of steps before attempting the speed switch, but nothing has helped so far. I took a look at the mmc driver in mainline, and it has changed a lot. A very quick attempt at dropping the new driver into the legacy build failed about as quickly as you'd probably expect. I think I'll try and boot a 4.x kernel and see if it can get the card into hs200/hs400. If it does then I can compare the speed change sequence in the new and old drivers, and hopefully either fix the old to match or put the effort into back porting the new. If the new driver can't get the card into hs200 either, then I'll clean up the existing HS/ddr50 hack and stick with that.

OK, I have a theory for being unable to switch to hs200 based on the following output from the mmc-utils: Power class for 52MHz, DDR at 1.95V [PWR_CL_DDR_52_195: 0xdd] Power class for 200MHz at 3.6V [PWR_CL_200_360: 0xdd] It looks to me like operation above 52MHz requires the module to be supplied with 3.6V and switched into the appropriate power class (in this case power class 13). This will mean an increase in power consumption from around 400mA to 700mA, so it will be interesting to see if it solves the problem and is worth the power in terms of actual performance gains. I wrote the code to switch the supply to 3.6V last night, but didn't realise at the time that I also need to configure the power class, so still failed the switch to HS200. Can't wait to get back and try the next step!

I dropped runtime_chgcur down to 1/2 amp and that seems much more manageable to me. I might go a little lower to try and bring the idle temp down further. I currently have suspend at 1.5A and shutdown at 1.8A. When I get some time I'll experiment with raising the shutdown charge rate. The typically recommended 1/2C charge rate would be 5A which we won't get anywhere near with this psu and charger. I'm hoping that something between 2 and 2.5A during shutdown will be usable which will give me a 'normal' overnight charge in suspend and a 'turbo' charge if I shut the machine down before charging. I'd drop the suspend rate lower but then I might not always get back to 100% overnight. I need to open the machine up and attach k-type probes before testing as I don't want to cook the pmic.

Perfect! Many thanks Edit - ah, I see, it's exactly backwards from what I want Age old story - everyone has different requirements. At least we have the freedom to change things around.

Legacy. I haven't had a chance to try mainline on the pinebook yet (which would be an interesting thing to do), but my understanding is that it isn't ready for desktop/gui use yet. As far as aufs vs Overlay2 goes, I read enough to realise there's a lot of political stuff around the adoption into the kernel and newer distributions, but I haven't seen any technical comparisons of the two. Apart from the bug above, aufs seems to have been working extremely well, but I guess if the momentum now is behind overlay2 then that's the direction we will all be going in.

Hi, I hit a problem on pinebook where docker would hang with defunct processes consuming high cpu. A bit of googling turned up a known problem with aufs as the cause, so I grabbed the patches, combined them and created a pull request https://github.com/armbian/build/pull/772 I gave the resulting kernel a fairly good work-out this evening and it seems to be working fine now.

Is the charging current adjustable? I'd quite like to be able to set the charge current to a relatively low value if I'm using the pinebook, and then boost it to a higher value as part of the suspend/shutdown sequence.

I had a bit more time to experiment today. I still can't get the card into hs200 mode, but I did manage to get it into HS with 50MHz clock. That bumps the iozone results quite nicely: random random kB reclen write rewrite read reread read write 102400 4 6504 6963 8756 8655 6348 5735 102400 16 17309 18487 49367 49211 24288 17154 102400 512 52978 55655 82921 82812 77202 48372 102400 1024 55163 54478 83549 83580 80463 48929 102400 16384 54695 56817 83931 83774 83917 51651 This was just with a prototype hack. I might try and clean it up a bit and use it while I keep prodding away at the switch to hs200.