James Kingdon

  • Content count

  • Joined

  • Last visited

1 Follower

About James Kingdon

  • Rank
    Advanced Member
  1. Pinebook install to eMMC?

    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.
  2. Quick Pinebook Preview / Review

    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
  3. How to build without downloading from git everytime?

    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
  4. 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
  5. Pinebook install to eMMC?

    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
  6. Pinebook install to eMMC?

    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.
  7. Pinebook install to eMMC?

    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).
  8. Quick Pinebook Preview / Review

    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).
  9. Pinebook install to eMMC?

    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; }
  10. Pinebook install to eMMC?

    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.
  11. Pinebook install to eMMC?

    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
  12. Pinebook install to eMMC?

    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.
  13. Pinebook install to eMMC?

    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
  14. Pinebook install to eMMC?

    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...
  15. Pinebook install to eMMC?

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