James Kingdon

I remember reading somewhere (probably in this thread) tkaiser saying that charging the battery generates a lot of heat that transfers to the cpu through the shared heat-sink. I normally put the pinebook on charge when I'm not using it, so it's not something I'd run into before, until the battery got low today and I plugged it in. My word! It's really warm and it's the first time I've seen thermal throttling in normal use. I was coming around to the idea of liking not having a fan, but if you want to use while charging, I think adding a fan would be a good idea, although it's likely to be an ugly hack. Perhaps I'll stick to charging overnight

Hi Zador, thanks for replying. Yes, kernel and u-boot sources. They are indeed in the cache which is why I can get away with not downloading them on each build. For reasons I haven't been able to fathom, in this particular location the environment inside docker can't resolve github.com, so every attempt to contact it results in a long timeout which was slowing the builds down a lot. No worries on IGNORE_UPDATES. I made some quick changes to the scripts to skip the downloads and only compile u-boot while I was working on that part and it did what I needed it to do. I understand that I'm not using the tools the way they were intended, so it's not surprising that things aren't quite straight forward

Hi, I'm trying to iterate quickly to test out some ideas on the mmc driver, so I was wondering if it is possible to prevent re-downloading the sources every time. It looked like IGNORE_UPDATES=yes might be what I want, but when I tried that I got a failure during compile_atf: [ o.k. ] Installing [ rkbin-tools ] [ o.k. ] Cleaning output/debs for [ pinebook-a64 default ] [ o.k. ] Cleaning [ o.k. ] Compiling ATF [ o.k. ] Compiler version [ aarch64-linux-gnu-gcc 6.4.1 ] [ o.k. ] Started patching process for [ atf pine64-pinebook-a64-default ] [ o.k. ] Looking for user patches in [ userpatches/atf/atf-pine64 ] make: *** No rule to make target 'bl31'. Stop. [ error ] ERROR in function compile_atf [ compilation.sh:65 ] [ error ] ATF compilation failed [ o.k. ] Process terminated I'm using docker so my command line was $ ./compile.sh docker IGNORE_UPDATES=yes

Now that's something I don't hear very often Sorry I missed the fun - work gets in the way. But wow, you guys get productive when you get together - great job at getting Ayufan interested. I didn't realize he had a dynamic tuning thing going on, sounds like he's going to be the key person for seeing if we can get the full performance out of the modules. I did try building the mainline kernel in armbian but I couldn't get the resulting image to boot (even from SD). It's the first time I've tried to build a full image so I may have messed something up. I've got the mmc-utils installed, results at http://sprunge.us/DhAK

I haven't figured out the 'proper' way of adding patches to Armbian yet, but assuming it's documented I should be able to submit a PR. I'll get the mmc info, hopefully later today.

Just realised the above is only part of the changes I'm currently running with. You also need to prevent the driver giving up when it sees revision 8. Here's a more complete diff *** mmc.c-orig 2017-09-04 10:51:31.720262885 -0400 --- mmc.c 2017-09-11 09:43:45.262343562 -0400 *************** int mmc_decode_ext_csd(struct mmc *mmc, *** 567,577 **** --- 567,581 ---- dec_ext_csd->rev = ext_csd[EXT_CSD_REV]; + // Hack to minimize behaviour changes + if (dec_ext_csd->rev > 7) dec_ext_csd->rev = 7; + /* if (dec_ext_csd->rev > 7) { MMCINFO("unrecognised EXT_CSD revision %d\n", dec_ext_csd->rev); err = -1; goto out; } + */ dec_ext_csd->raw_sectors[0] = ext_csd[EXT_CSD_SEC_CNT + 0]; dec_ext_csd->raw_sectors[1] = ext_csd[EXT_CSD_SEC_CNT + 1]; *************** int mmc_decode_ext_csd(struct mmc *mmc, *** 635,641 **** dec_ext_csd->data_sector_size = 512; } ! out: return err; } --- 639,645 ---- dec_ext_csd->data_sector_size = 512; } ! //out: return err; } *************** static int mmc_startup(struct mmc *mmc) *** 2000,2007 **** break; case MMC_VERSION_5_1: MMCINFO("MMC v5.1\n"); default: ! MMCINFO("Unknow MMC ver\n"); break; } } --- 2004,2012 ---- break; case MMC_VERSION_5_1: MMCINFO("MMC v5.1\n"); + break; default: ! MMCINFO("Unknown MMC ver\n"); break; } } *************** static int mmc_complete_init(struct mmc *** 2269,2280 **** } mmc->init_in_progress = 0; err = sunxi_switch_to_best_bus(mmc); if (err) { MMCINFO("switch to best speed mode fail\n"); ! return err; } init_part(&mmc->block_dev); /* it will send cmd17 */ return err; } --- 2274,2290 ---- } mmc->init_in_progress = 0; err = sunxi_switch_to_best_bus(mmc); if (err) { MMCINFO("switch to best speed mode fail\n"); ! MMCINFO("JBK - skipping error return and resetting to 0\n"); ! //return err; ! err=0; } init_part(&mmc->block_dev); /* it will send cmd17 */ return err; } In this version I also overwrite csd->rev with 7 if the value was greater than this. I haven't checked if that is necessary or not, but by inspection I could see that rev 8 would take some code paths that could never have been run before (because the code would fail early if it saw rev>7).

Quick update for anyone following this thread but not having seen With lots of help from Tkaiser and more we now have the pinebook booting from the new Sandisk 64G modules (older modules used Foresee chips and may still be available for a while). It needs a relatively small patch to the mmc driver in both the kernel and u-boot, and we're trying to home in on the safest minimal patch to add to the armbian builds. The speed delta noted above is related - one of the reasons that u-boot was failing is that for some reason the driver fails to switch this module into high speed mode. We haven't solved that yet, but even so the system is very usable running from the new cards. I'm optimistic that we'll get the card running faster with time (we may need some help from the original authors of the driver, or at least find the programming guide for the chip though).

Ok, I gave this a quick try. Commenting out the return err; statement isn't sufficient as the value in err is returned a couple of lines later and causes the init to fail. However, if you overwrite the err value with 0 inside that comment block it then continues and boots up normally. iozone results are unchanged, so the speed change really did fail (as opposed to just returning a non-zero value by accident). err = sunxi_switch_to_best_bus(mmc); if (err) { MMCINFO("switch to best speed mode fail\n"); ! MMCINFO("JBK - skipping error return and resetting to 0\n"); ! //return err; ! err=0; }

That's right, the latest 64G modules are using sandisk chips. I'm afraid I don't have the tools with me to open up the case and get the id.

Hi, I'll give that change a try and see what happens. I guess it depends on whether the mmc is in a working state or not after the failed speed change attempt. Not sure if I'll get a chance to do it today or not - depends what time I finish flying. I ran iozone again with the performance governor, the results are pretty similar to the first set. The kernel mmc driver also fails the change to high speed, so I'm guessing there will be more throughput available if I can get hs400 working. 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 5344 5538 9782 9802 5373 5066 102400 16 11138 11377 18972 19196 13528 10996 102400 512 21522 21606 22809 22841 22370 21385 102400 1024 21623 21375 22752 22875 22642 21546 102400 16384 21623 21692 22887 22902 22877 21620 iozone test complete. I wonder if the mainline kernel is bootable yet? It would be interesting to see if the latest and greatest mmc driver can get this chip into hs400. If it can I could try back-porting the changes. Although, after last night I'm a bit more intimidated by the code than I was before - it's not entirely obvious what the code is doing, and there aren't a lot of comments. armbianmonitor -u output: http://sprunge.us/KDdK

Success! I made a rather hacky change by disabling the following call in mmc_complete_init: /** err = sunxi_switch_to_best_bus(mmc); if (err) { MMCINFO("switch to best speed mode fail\n"); return err; } */ That was sufficient to allow the system to boot from the emmc. Once the kernel starts up it looks like the emmc is initialised again by the kernel's version of the mmc driver, so that's where it makes more sense to spend time trying to get full hs400 support working.

OK, I finally got the serial port working after trying what felt like every permutation of slider switch, software mux and wiring reversal. It's now obvious that the emmc driver in uboot fails to switch to HS400 mode, but instead of falling back to a lower speed it fails the entire startup attempt. The version of the driver in the kernel also fails to change to HS400, but falls back to a lower speed. Hopefully it won't be too hard to compare the two implementations and make the uboot version behave the same way. The quickest change may just be to disable the attempt to switch to HS400 in the first place, and the ideal long term case would be to get HS400 working properly [mmc]: ************Try MMC card 2************ sunxi_pwm_config: reg_shift = 0, reg_width = 4, prescale temp = 7f, pres=15 PWM _TEST: duty_ns=16601, period_ns=83333, freq=12000, per_scal=0, period_reg=0x7cf018e sunxi_pwm_config: reg_shift = 0, reg_width = 4, prescale temp = 7f, pres=15 PWM _TEST: duty_ns=16601, period_ns=83333, freq=12000, per_scal=0, period_reg=0x7cf018e [mmc]: Invalid ext_csd revision 8 [mmc]: host caps: 0x1ef [mmc]: MID 000045 PSN bba0ed22 [mmc]: PNM DF4064 -- 0x44-46-34-30-36 [mmc]: PRV 0.1 [mmc]: MDT m-7 y-2017 [mmc]: MMC v5.1 [mmc]: Unknow MMC ver [mmc]: speed mode : HSSDR52/SDR25 [mmc]: clock : 50000000 Hz [mmc]: bus_width : 8 bit [mmc]: user capacity : 59640 MB [mmc]: boot capacity : 4096 KB [mmc]: rpmb capacity : 4096 KB [mmc]: ************SD/MMC 2 init OK!!!************ [mmc]: ========best spd md: 4-HS400, freq: 5-200000000 [mmc]: already at HSSDR52_SDR25 mode [mmc]: Fail to switch to expected mode by SWITCH cmd [mmc]: mmc swtich status error [mmc]: mmc change to hs400 failed [mmc]: switch speed mode fail [mmc]: switch to HS400 fail [mmc]: switch to best speed mode fail [mmc]: erase_grp_size : 0x400WrBlk*0x200=0x80000 Byte [mmc]: secure_feature : 0x55 [mmc]: secure_removal_type : 0x8 [mmc]: EOL Info(Rev blks): Normal [mmc]: Wear out(type A): 0%-10% life time used [mmc]: Wear out(type B): 0%-10% life time used [mmc]: mmc_init: mmc init fail, err -21 MMC init failed initcall sequence bffa4aa0 failed at call 4a00bf64

I gave the new script a try last night (my, that's changed a lot from the version I used before!), but unfortunately still no boot. I wired up a serial port connector this morning, but unfortunately I'd missed the info that there's a switch on the mainboard that needs setting so I didn't get any output before having to leave for work. Hopefully more progress tonight...

Ah great, I'll take a look when I get home tonight. Thank you (all) for your patience with me on this.

Ok, that's good to know. The most likely explanations are that my fix to uboot was incorrect or that I didn't manage to get the modified uboot installed. One thing I noticed is that the log file produced by the installer seems to be incomplete, at least judging by the output lines I can see in the script. Both install attempts, the log has ended at "stopping cron.service": Mon Sep 4 14:03:10 EDT 2017: Start nand-sata-install. Files open for write: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME <list of open files...> SD uuid: UUID=b9f5e64a-6539-4756-9221-840a81f46398 UUID=5653fb2e-330a-43cf-865d-f903448ae450 Satauid: UUID=b9f5e64a-6539-4756-9221-840a81f46398 Emmcuuid: UUID=b9f5e64a-6539-4756-9221-840a81f46398 ext4 Boot: $1 /dev/mmcblk0p1 ext4 Root: $2 /dev/mmcblk0p1 Usage: 4910 Dest: 54967 Stopping cron.service

No, I haven't got the serial port setup yet. I don't think I have one of the 4 pole AV plugs, but hopefully an ordinary stereo connector will do the job.

Interesting, your eMMC is running much faster than the 64G module I have: 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 5212 5531 9691 9710 5301 4522 102400 16 10971 11371 18865 19056 13534 10918 102400 512 21356 21507 22808 22763 22360 21477 102400 1024 21410 21495 22718 22795 22618 21570 102400 16384 21547 21517 22846 22849 22848 21577

Hi, just a quick sanity check - is install to eMMC on pinebook known to be working (with recent Armbian images from the wip section), and is nand-sata-install the right way to do it? It just occurred to me that I might be spinning my wheels trying to figure out something that just isn't ready yet Thanks, James

Ah, still doesn't boot from eMMC. I guess I'm going to have to figure out that serial port connection. Wonder what I'm missing.

Small steps - with Zador's help I got the armbian build system working with Docker and managed to force in my changes. The new kernel now runs better than my previous attempt which couldn't load any modules for some reason, which prevented wifi from working amongst other things. I also found that the uboot version of mmc.c has the same test for csd.rev which seems like a reasonable explanation for the boot failure from eMMC, so I've removed the test and rebuilt uboot. I installed the resulting .deb onto the armbian running from sd card, rebooted and have now started a fresh run of nand-sata-install. The only problem is that I have no idea where nand-sata-install gets the copy of uboot to write to the eMMC, so I hope it picks up my modified version and not a copy of the original from somwhere! Ah, looks like the installer gets uboot from /usr/lib/linux-u-boot-pinebook-a64_5.32_arm64/ and that's been updated today, so presumably contains my new build: /usr/lib/linux-u-boot-pinebook-a64_5.32_arm64$ ls -l total 960 -rw-rw-r-- 1 root root 983040 Sep 4 11:46 u-boot-with-dtb.bin Fingers crossed!

Thanks again Zador, that was enough to get me going. I did some fairly hacky things to the build scripts to force my changes (I must learn how to use the user patch system to do this properly) and have a new kernel and uboot compiled.

It looks like the cgroup-rule lines are only needed for building images, so I've commented them out and passed KERNEL_ONLY=yes on the command line for now. I'm still not quite understanding how to work with this environment though. How do I ensure that the state of the container is persisted after the build so that I can make a small change to the kernel source and rebuild the kernel? How do I interact with the container to edit a file? Sorry for the beginner questions!

I'm a bit confused over the version numbering in Docker - have they changed formats or are there two different projects with the same name? ./compile.sh docker fails and suggests using version 17.06. My docker install returns a version number of 1.12.6 with a build date of Jan 2017 [ .... ] Running the container unknown flag: --device-cgroup-rule See 'docker run --help'. [ warn ] Docker error [ 125 ] [ warn ] please make sure you are using the latest version (17.06 CE or newer) [ warn ] please check the Armbian documentation for the Docker setup procedure Client: Version: 1.12.6 API version: 1.24 Go version: go1.6.2 Git commit: 78d1802 Built: Tue Jan 31 23:35:14 2017 OS/Arch: linux/amd64 Server: Version: 1.12.6 API version: 1.24 Go version: go1.6.2 Git commit: 78d1802 Built: Tue Jan 31 23:35:14 2017 OS/Arch: linux/amd64

Hmm, the install to eMMC seemed to work ok in that if I boot from SD I can mount the eMMC and see the files, but it won't boot from the eMMC. Unfortunately I don't have a serial line hooked up to the pinebook so I can't see what's going on. Visually, the backlight of the screen turns on, but nothing appears on the display. The LED for caps lock is not responsive. When I mount the filesystem on the eMMC it is reported as 62G, so I assume that resizefs must have been run. /boot/Image on the eMMC is sym-linked to my kernel with the modified mmc driver, so that seems good. I compiled the kernel by cloning longsleep's linux-pine64 kernel directly (I've been having problems building armbian), so maybe I'm missing some patches? It feels like it must be close to working, I'll see if I can dig into it some more.

Ah, I ran "docker build ./" in the armbian build directory and "docker run <imageid>" to invoke. I'm hosting on Linux mint 18.2 sonya on 64bit x86. Thanks for the info, I'll try again.