James Kingdon Posted September 5, 2017 Posted September 5, 2017 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
martinayotte Posted September 6, 2017 Posted September 6, 2017 I must admit that I didn't tried it on Pinebook, since I'm still running ayufan image ont it. But nand-sata-install should work the same way as for other boards ... Do you have an USB-TTL to Audio Jack to figure out where it is choking ?
James Kingdon Posted September 6, 2017 Author Posted September 6, 2017 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.
Igor Posted September 6, 2017 Posted September 6, 2017 It should work unless broken. I am running my Pinebook from eMMC and install went smoothly.
James Kingdon Posted September 6, 2017 Author Posted September 6, 2017 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
Igor Posted September 7, 2017 Posted September 7, 2017 22 hours ago, James Kingdon said: 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": This log was done more or less for debugging. Lately, there were some changes to this install utility and I'll need to look closely if there are problems. In any case, we will test all those functions right before upcoming release.
tkaiser Posted September 7, 2017 Posted September 7, 2017 23 hours ago, James Kingdon said: SD uuid: UUID=b9f5e64a-6539-4756-9221-840a81f46398 UUID=5653fb2e-330a-43cf-865d-f903448ae450 Satauid: UUID=b9f5e64a-6539-4756-9221-840a81f46398 The nand-sata-install script on all installations out there got broken in the meantime after switching to UUIDs to identify filesystems. 'SD uuid' should be a single line but is two lines (check your log above) and therefore /etc/fstab has been created wrongly. A line with the correct UUID and no more entries followed by a line with the wrong UUID followed by the / parameters. Can't work. Please try replacing /usr/sbin/nand-sata-install with latest version on Github: https://raw.githubusercontent.com/armbian/build/master/packages/bsp/common/usr/sbin/nand-sata-install and report back.
James Kingdon Posted September 7, 2017 Author Posted September 7, 2017 Ah great, I'll take a look when I get home tonight. Thank you (all) for your patience with me on this.
James Kingdon Posted September 8, 2017 Author Posted September 8, 2017 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...
tkaiser Posted September 8, 2017 Posted September 8, 2017 4 minutes ago, James Kingdon said: unfortunately still no boot But now you have /var/log/nand-sata-install.log on your SD card so it would be great if you can provide 'armbianmonitor -u' output.
James Kingdon Posted September 9, 2017 Author Posted September 9, 2017 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
James Kingdon Posted September 10, 2017 Author Posted September 10, 2017 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. 1
tkaiser Posted September 10, 2017 Posted September 10, 2017 6 hours ago, James Kingdon said: That was sufficient to allow the system to boot from the emmc. Let me test this later with the 16GB eMMC on my Pinebook -- if it's sufficient we might provide a small u-boot package to fix this. Related: the 'performance' numbers you provided for your 64 GB eMMC are better at small block sizes than the 16 GB eMMC I tested but seem to be limited to the 'usual' 23 MB/s sequential barrier we see with SD cards on Pinebook and other Allwinner devices (due to using the slowest SDIO mode there). Can you please provide output from 'armbianmonitor -u' now and also re-test the 64 GB module after switching to performance cpufreq governor ('cpufreq-set -g performance' )?
tkaiser Posted September 10, 2017 Posted September 10, 2017 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 */
tkaiser Posted September 10, 2017 Posted September 10, 2017 To ease testing there's now http://kaiser-edv.de/tmp/NumpU5/Armbian_5.32_Pinebook-a64_Ubuntu_xenial_default_3.10.107_desktop.img.xz with patch applied. Works on a 16GB eMMC: http://sprunge.us/bSOE (seems we could try to stop pulseaudio in nand-sata-install but at least my short tries were all unsuccessful and I've to admit that I don't understand how this pulseaudio stuff works at all)
James Kingdon Posted September 10, 2017 Author Posted September 10, 2017 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
tkaiser Posted September 10, 2017 Posted September 10, 2017 1 hour ago, James Kingdon said: http://sprunge.us/KDdK This does not look like FORESEE eMMC (different oemid/manfid). Do you know what's written on the module?
James Kingdon Posted September 10, 2017 Author Posted September 10, 2017 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.
tkaiser Posted September 10, 2017 Posted September 10, 2017 1 hour ago, James Kingdon said: latest 64G modules are using sandisk chips Well, then manfid 0x45 would fit (SANDISK_SEM) though 'date: 07/2001' just looks wrong. Would be interesting to query this module about 'Device Health' (search for mmc-utils here for example).
James Kingdon Posted September 11, 2017 Author Posted September 11, 2017 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; }
James Kingdon Posted September 11, 2017 Author Posted September 11, 2017 (edited) 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). Edited September 15, 2017 by James Kingdon spelling
tkaiser Posted September 11, 2017 Posted September 11, 2017 Ok, I removed the insufficient u-boot patch (we tested yesterday also with the wrong module -- FORESEE and not SanDisk). Are you able to generate a PR against https://github.com/armbian/build with the necessary changes to both u-boot and kernel? BTW: Would be interesting to get output from the following (sample output for 16GB FORESEE eMMC in my Pinebook here: http://sprunge.us/JcZG) git clone https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git cd mmc-utils make ./mmc extcsd read /dev/mmcblk0 | egrep -v '0x00$|0x0000$|0x000000$|0x00]$'
James Kingdon Posted September 12, 2017 Author Posted September 12, 2017 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.
tkaiser Posted September 12, 2017 Posted September 12, 2017 @James Kingdon can you please check IRC backlog from today (http://irc.pine64.uk) and join the party there? We NEED you
James Kingdon Posted September 13, 2017 Author Posted September 13, 2017 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
James Kingdon Posted September 18, 2017 Author Posted September 18, 2017 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.
James Kingdon Posted September 22, 2017 Author Posted September 22, 2017 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! 1
tkaiser Posted September 22, 2017 Posted September 22, 2017 22 minutes ago, James Kingdon said: I have a theory for being unable to switch to hs200 based on the following output from the mmc-utils @Igor and @zador.blood.stained: I thought about bundling mmc utility from mmc-utils package already but did not found a debian package. Building from source results in these times (Clearfog Pro): time (git clone https://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git ; cd mmc-utils ; make -j$(grep -c processor /proc/cpuinfo) ) ... real 0m4.989s user 0m7.035s sys 0m0.413s Size of the binary is below 300K. Any chance to bundle this somehow with an Armbian package so I could include output from it in a future armbianmonitor -U (capital U) version?
zador.blood.stained Posted September 22, 2017 Posted September 22, 2017 mmc-utils is already present in Stretch, and we could probably build it for older releases too, but can't give any ETA due to some HW related issues. 1
James Kingdon Posted September 23, 2017 Author Posted September 23, 2017 On 22/09/2017 at 9:11 AM, James Kingdon said: It looks to me like operation above 52MHz requires the module to be supplied with 3.6V and switched into the appropriate power class 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. 1
Recommended Posts