James Kingdon
-
Posts
142 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by James Kingdon
-
-
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 51651This 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.
-
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
-
4 hours ago, tkaiser said:
@James Kingdon can you please check IRC backlog from today (http://irc.pine64.uk) and join the party there? We NEED you
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).
-
On 10/09/2017 at 5:13 AM, tkaiser said:
I threw the following patch in and rebuilt u-boot: http://kaiser-edv.de/tmp/NumpU5/linux-u-boot-pinebook-a64_5.32_arm64.deb -- at least on my Pinebook with 16 GB eMMC everything ok after 'dpkg -i linux-u-boot-pinebook-a64_5.32_arm64.deb && reboot'. @James Kingdon are you able to test this too?
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index d160bd5..c9f0b9e 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -2272,7 +2272,7 @@ static int mmc_complete_init(struct mmc *mmc) err = sunxi_switch_to_best_bus(mmc); if (err) { MMCINFO("switch to best speed mode fail\n"); - return err; + /* return err; */ } init_part(&mmc->block_dev); /* it will send cmd17 */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.
-
On 5/9/2017 at 4:35 AM, tkaiser said:
Short update on the 16 GB eMMC in my 14" variant: http://sprunge.us/bHZW (search for 'mmc2:0001', it's oemid: 0x0103, manfid: 0x000088)
Google search for '0x0103 0x000088' found just a few hits (one in Armbian forum, this thing has also been used in Beelink X2). Iozone numbers:
random random kB reclen write rewrite read reread read write 102400 4 3893 4021 20855 20681 13244 3223 102400 16 18059 18444 51219 50298 39452 13805 102400 512 54907 55186 85896 84475 82634 50187 102400 1024 56220 56011 85560 85681 85800 52369 102400 16384 55816 55464 86533 86408 86711 55289Interesting, 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!
Patch for busy hang in aufs (docker)
in Advanced users - Development
Posted
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.