Jump to content

Pinebook install to eMMC?


James Kingdon

Recommended Posts

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

Link to comment
Share on other sites

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 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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' )?

Link to comment
Share on other sites

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 */

 

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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). 

Link to comment
Share on other sites

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;
  	}

 

Link to comment
Share on other sites

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 by James Kingdon
spelling
Link to comment
Share on other sites

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]$'
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines