Jump to content

Armbian customization

chradev

By chradev
in Allwinner sunxi

 Share

Recommended Posts

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

I try to make eMMC bootable incl. rootfs but encounter following problems.

 

In case of preparing the device with command:

dd if=Armbian_5.07_Lime2_Debian_jessie_4.4.6.raw of=/dev/mmcblk1

It boots successfully from eMMC. U-Boot and Kernel register eMMC as mmcblk0. There are following messages related to mmc:

[    3.521635] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
[    3.522515] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    3.562879] sunxi-mmc 1c0f000.mmc: base:0xf0d74000 irq:26
[    3.563345] sunxi-mmc 1c11000.mmc: No vqmmc regulator found
[    3.602667] sunxi-mmc 1c11000.mmc: base:0xf0d78000 irq:27
[    3.608676] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !!
[    3.612909] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.613804] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.614683] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.615566] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.646545] mmc1: MAN_BKOPS_EN bit is not set
[    3.653022] mmc1: new high speed MMC card at address 0001
[    3.653914] mmcblk0: mmc1:0001 P1XXXX 3.60 GiB
[    3.654397] mmcblk0boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB
[    3.654803] mmcblk0boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB
[    3.656023]  mmcblk0: p1
[    4.049583] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[   11.773025] EXT4-fs (mmcblk0p1): re-mounted. Opts: data=writeback,commit=600,errors=remount-ro

Unfortunately,  rootfs stays not resized:

root@lime2:~# df
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/root        1141308 948920    116296  90% /

and cannot be resized:

root@lime2:~# resize2fs /dev/mmcblk0p1
resize2fs 1.42.12 (29-Aug-2014)
The filesystem is already 298551 (4k) blocks long.  Nothing to do!

If eMMC is prepared in alternative way:

fdisk /dev/mmcblk1 -> n, p, 1, default, default, w
mkfs.ext4 -j /dev/mmcblk1p1
mount /dev/mmcblk1p1 /mnt
tar -zxvf armbian-from-sdcard.tar.gz -C /mnt
sync
umount /mnt
dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8

After booting the rootfs is read only and there are following messages:

[    3.507990] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found
[    3.508740] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    3.541456] sunxi-mmc 1c0f000.mmc: base:0xf0d74000 irq:26
[    3.541890] sunxi-mmc 1c11000.mmc: No vqmmc regulator found
[    3.581217] sunxi-mmc 1c11000.mmc: base:0xf0d78000 irq:27
[    3.587225] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !!
[    3.591528] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.592397] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.593263] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.594122] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[    3.625081] mmc1: MAN_BKOPS_EN bit is not set
[    3.631553] mmc1: new high speed MMC card at address 0001
[    3.632423] mmcblk0: mmc1:0001 P1XXXX 3.60 GiB
[    3.632813] mmcblk0boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB
[    3.633237] mmcblk0boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB
[    3.634477]  mmcblk0: p1
...
[    4.028069] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[    4.028143] VFS: Mounted root (ext4 filesystem) readonly on device 179:1.
...
[    6.126078] EXT4-fs (mmcblk0p1): Cannot change data mode on remount
[    6.997802] systemd-journald[149]: Received request to flush runtime journal from PID 1

Where the problems could be?

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Thanks Igor,

 

Yes, I have used the older (from a few days ago) own build and after rebuilding it the problem with resize at firstrun on eMMC is solved.

 

Unfortunately, about second one /etc/fstab files are the same:

root@lime2:~# cat /mnt/etc/fstab
# UNCONFIGURED FSTAB FOR BASE SYSTEM
tmpfs   /tmp         tmpfs   nodev,nosuid,size=256M          0  0
/dev/mmcblk0p1  /           ext4    defaults,noatime,nodiratime,data=writeback,commit=600,errors=remount-ro        0       0
/var/swap none swap sw 0 0
root@lime2:~# cat /etc/fstab
# UNCONFIGURED FSTAB FOR BASE SYSTEM
tmpfs   /tmp         tmpfs   nodev,nosuid,size=256M          0  0
/dev/mmcblk0p1  /           ext4    defaults,noatime,nodiratime,data=writeback,commit=600,errors=remount-ro        0       0
/var/swap none swap sw 0 0

but anyway it is not so important in case of having even faster way to write the image on eMMC.

 

BTW:

  • I see that Armbian is migrated to kernel 4.5.1 (the build pass fine for me).
  • But what about the problem with the latest mainline U-Boot?
  • I still use older one v.2015.10.

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,
 
Following the need to install and customize too many times RPI Monitor (for Lime2) I find useful to gzip in a single file all the staff have to be added or modified (in case of mainline kernel usage) afterwards. Reading all discussions, advises and own experience I succeed to reduce the procedure to a file and 5 easy steps:

root@lime2:~# armbianmonitor -r
// Check if RPI Monitor is working on: http://lime2-ip-address:8888/
root@lime2:~# tar -zxvf /path-to-archive/armbianmonitor.tar.gz -C /
root@lime2:~# service rpimonitor restart
// Check if RPI Monitor is customized on: http://lime2-ip-address:8888/

Find attached armbianmonitor.tar.gz file including a couple of goodies as well.
 
On the other hand it is a time to offer RPI Monitor itself to be added to the main Armbian distribution because of:

  • it is quite useful for almost all users
  • its adding to the customization script is quite tricky to be leaved to the users
  • its customization is board dependent and could be leaved to the users because the support is not finished yet

Best regards
Chris

armbianmonitor.tar.gzFetching info...

1
chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

I need the messages to be printed on a serial console while booting vanilla kernel (4.5.1) in Armbian (5.07) so I change in boot.cmd:

setenv bootargs "console=tty1 ...

to

setenv bootargs "console=/dev/ttyS0,115200 ...

Unfortunately, no boot messages on serial console afterwards.

I have read in the forums a few posts with the same problem but without solution.

 

Can somebody help me to solve the problem?

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi tkaiser,

 

  On 4/17/2016 at 9:04 PM, tkaiser said:

Hmm... what about following the documentation: https://github.com/igorpecovnik/lib/blob/master/documentation/user-faq.md#how-to-troubleshoot

 

Or in other words: Why do you feel the need to add '/dev/' here to kernel's cmdline?

 

I have tested both with and without '/dev'. With '/dev' is simple last one I tested and put in the post.

I have also look on kernel configuration but did not see something wrong.

I have also search on the forum and see other guy having the same problem (without '/dev').

Even make last minute test as per pointed documentation:

setenv bootargs "init=/bin/bash root=/dev/mmcblk0p1 rootwait console=ttyS0,115200 ...

but get an error in the very beginning:

Uncompressing Linux... done, booting the kernel.
/bin/bash: sunxi_no_mali_mem_reserve: No such file or directory
[    4.311114] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

and the board reboots after printing the stack.

 

And finally successed after removing 'init=/bin/bash' but leaving the order:

setenv bootargs "root=/dev/mmcblk0p1 rootwait console=ttyS0,115200 ...

Next change again the order as tested before:

setenv bootargs "console=ttyS0,115200 root=/dev/mmcblk0p1 rootwait ...

and for my surprise it works again! Probably there was something wrong when tested it before.

 

Thanks traiser for the help and sorry for the "noise".

 

Best regards

Chris

tkaiser

tkaiser

Posted
Posted
  On 4/17/2016 at 9:45 PM, chradev said:

Thanks traiser for the help and sorry for the "noise".

 

You're welcome. BTW: I also find it sometimes a bit anoying to edit boot.cmd and call mkimage just to switch between display and serial console for verbose output. I think we should try to address that in a future version of Armbian in a more user friendly way (maybe further misusing the armbianmonitor script).

 

And I would also believe we should overthink our u-boot handling. There was an interesting discussion about board vs. distro specific stuff and how to handle that from within u-boot last week in linux-sunxi chat: http://irclog.whitequark.org/linux-sunxi/2016-04-13#16132252;

chradev

chradev

Posted
  • Author
Posted

Hi tkaise,

 

I will read pointed chat in a while.

  On 4/18/2016 at 7:38 AM, tkaiser said:

You're welcome. BTW: I also find it sometimes a bit anoying to edit boot.cmd and call mkimage just to switch between display and serial console for verbose output. I think we should try to address that in a future version of Armbian in a more user friendly way (maybe further misusing the armbianmonitor script).

 

And I would also believe we should overthink our u-boot handling. There was an interesting discussion about board vs. distro specific stuff and how to handle that from within u-boot last week in linux-sunxi chat: http://irclog.whitequark.org/linux-sunxi/2016-04-13#16132252;

 

Definitely, especially after my "dark" night tonight.

After happiness of last problem solution and almost reached my dreamed staff I "succeeded" to "brick" my board.

The "two SD/MMC cards problem" has suddenly overtaken me. May be it is phenomenon like "console messages" just "solved".

 

After a day with no problem booting from eMMC (without SD card inserted) and from SD/MMC if present in some reason the kernel decided to change its behavior.

While U-Boot swaps SD/MMC enumeration depending of SD card presence and sending always 'root=/dev/mmcblk0p1' in command line to the kernel it begin enumerating eMMC as mmcblk0 only.

It makes impossible to boot from SD card and my "fast" try was to "clean" eMMC from u-boot but the kernel continue to try to boot from eMMC and get "panic-ed".

Unfortunately, the chosen by me way was also "dirty" and my board become "bricked".

 

Probably for "un-bricking" I have to build image with 'root=/dev/mmcblk1p1' in command line to the kernel but answering the question "why" has to be answered first.

 

Any ideas?

 

About "overthink our u-boot handling" my opinion is that boot behavior has to be deterministic instead of "smart".

One of the goals in my customization is to have "read only" and "never changing" staff on eMMC and SD, USB or SSD R/W one that can be updated.

At user action (button pressed while resetting or powering on the board) the boot from eMMC will give an option to restore functionality to "factory defaults".

 

That is why I cannot understand the reasons of swapping SD/MMC devises in U-Boot instead of deterministic way to boot using priorities.

 

In my opinion it is better to boot from eMMC in lack of other boot-able device and from SD card, USB or SATA if present.

U-Boot will be loaded by BROM using his priority which will try boot in fixed order described in its boot script.

Booting from eMMC if user button is pressed will be used if other "none-eject-able" device (like SATA) fails or user decides to restore to "factory defaults".

My inspections is to have deterministic boot and firmware update behavior suitable for none maintainable "black box" device (like SOHO routers).

 

Best regards

Chris

tkaiser

tkaiser

Posted
Posted
  On 4/18/2016 at 12:41 PM, chradev said:

Probably for "un-bricking" I have to build image with 'root=/dev/mmcblk1p1' in command line to the kernel but answering the question "why" has to be answered first.

 

Any ideas?

 

Maybe just the simple reason that your SD card got corrupted? One of the nice features of Allwinner based boards is that they never can be bricked since they always listen for FEL boot attempts (when no SD card is present and on boards that feature NAND/eMMC when FEL/u-boot button is pressed) and in case a SD card is present always prefer this over onboard eMMC or NAND.

 

So I would simply suspect that not the kernel changed his mind (close to impossible) but that for whatever reasons the board wasn't able to boot from SD card and then used eMMC as the normal fallback. After you wiped out also eMMC it's obviously not possible to boot any more since both boot sources are already corrupted.

 

Your ideas to get consistent enumeration obviously can't work too since the device you boot from is mmcblk0 by design and the next ones mmcblk1, mmcblk2 and so on.

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 4/18/2016 at 12:41 PM, chradev said:

After a day with no problem booting from eMMC (without SD card inserted) and from SD/MMC if present in some reason the kernel decided to change its behavior.

While U-Boot swaps SD/MMC enumeration depending of SD card presence and sending always 'root=/dev/mmcblk0p1' in command line to the kernel it begin enumerating eMMC as mmcblk0 only.

It makes impossible to boot from SD card and my "fast" try was to "clean" eMMC from u-boot but the kernel continue to try to boot from eMMC and get "panic-ed".

Kernel changing SD/MMC cards enumeration on boards with 2 SD slots or with SD+eMMC combination is a known problem. You can read through this issue for example.

 

Unfortunately there is no "perfect" solution AFAIK.

 

Root by partition UUID will need workarounds due to FS resize procedure at first boot.

Root by filesystem UUID requires initrd, "bare" kernel has no means of getting FS UUID.

Kernel hacks (like in sunxi legacy kernel)? Hard to test and maintain, so not a good idea.

 

It may be possible to affect SD/MMC devices enumerations with DT aliases, I'll try to find more info and perform some tests.

zador.blood.stained

zador.blood.stained

Posted
Posted

Aliases for SD/MMC were not implemented unfortunately

 

https://groups.google.com/forum/#!topic/fa.linux.kernel/sSi9mllOrAc

 

Edit:

@chradev

 

You can try appying this 

or better this based on comments in groups.google.com thread:

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 0aecd5c..837089a 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -322,8 +322,12 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 	/* scanning will be enabled when we're ready */
 	host->rescan_disable = 1;
 	idr_preload(GFP_KERNEL);
+	err = of_alias_get_id(dev->of_node, "mmc");
 	spin_lock(&mmc_host_lock);
-	err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
+	if (err >= 0)
+		err = idr_alloc(&mmc_host_idr, host, err, err+1, GFP_NOWAIT);
+	if (err < 0)
+		err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
 	if (err >= 0)
 		host->index = err;
 	spin_unlock(&mmc_host_lock);

and experimenting with aliases in DT.

chradev

chradev

Posted
  • Author
Posted

The SD card is definitely not corrupted. U-Boot on eMMC is cleaned. I have re-write SD card before try to boot and u-boot at least if loaded as expected from it.

When u-boot try to load the kernel it tries to do from mmc0 (from u-boot point of view):

 

  Reveal hidden contents

 

chradev

chradev

Posted
  • Author
Posted

Hi Zador,

  On 4/18/2016 at 1:27 PM, zador.blood.stained said:

Aliases for SD/MMC were not implemented unfortunately

 

https://groups.google.com/forum/#!topic/fa.linux.kernel/sSi9mllOrAc

 

Edit:

@chradev

 

You can try appying this

or better this based on comments in groups.google.com thread:

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 0aecd5c..837089a 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -322,8 +322,12 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 	/* scanning will be enabled when we're ready */
 	host->rescan_disable = 1;
 	idr_preload(GFP_KERNEL);
+	err = of_alias_get_id(dev->of_node, "mmc");
 	spin_lock(&mmc_host_lock);
-	err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
+	if (err >= 0)
+		err = idr_alloc(&mmc_host_idr, host, err, err+1, GFP_NOWAIT);
+	if (err < 0)
+		err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
 	if (err >= 0)
 		host->index = err;
 	spin_unlock(&mmc_host_lock);

and experimenting with aliases in DT.

No, I did not make any changes to u-boot and kernel (except once to support eMMC) because everything has worked perfectly until tonight by unknown reason.

Last change I make was to test prepared by Igor patches for vanilla kernel and mainline u-boot to support eMMC (the same as offered and used by me).

Reverting back to my patches did not make sense.

 

I have u-boot and rootfs on both eMMC and SD card. It boots from eMMC if SD card is not inserted and from SD card if present.

And that was for a day or so with many image builds/boots.

 

EDIT: BTW I try to boot from second lime2-eMMC board but with virgin eMMC - result is the same.

chradev

chradev

Posted
  • Author
Posted

Hi Zador,

 

  On 4/18/2016 at 1:27 PM, zador.blood.stained said:

Aliases for SD/MMC were not implemented unfortunately

 

https://groups.google.com/forum/#!topic/fa.linux.kernel/sSi9mllOrAc

 

Edit:

@chradev

 

You can try appying this

or better this based on comments in groups.google.com thread:

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 0aecd5c..837089a 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -322,8 +322,12 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 	/* scanning will be enabled when we're ready */
 	host->rescan_disable = 1;
 	idr_preload(GFP_KERNEL);
+	err = of_alias_get_id(dev->of_node, "mmc");
 	spin_lock(&mmc_host_lock);
-	err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
+	if (err >= 0)
+		err = idr_alloc(&mmc_host_idr, host, err, err+1, GFP_NOWAIT);
+	if (err < 0)
+		err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
 	if (err >= 0)
 		host->index = err;
 	spin_unlock(&mmc_host_lock);

and experimenting with aliases in DT.

 

Following your advise I patch the kernel as follow:

diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 0aecd5c..837089a 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -322,8 +322,12 @@ struct mmc_host *mmc_alloc_host(int extra, struct device *dev)
 	/* scanning will be enabled when we're ready */
 	host->rescan_disable = 1;
 	idr_preload(GFP_KERNEL);
+	err = of_alias_get_id(dev->of_node, "mmc");
 	spin_lock(&mmc_host_lock);
-	err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
+	if (err >= 0)
+		err = idr_alloc(&mmc_host_idr, host, err, err+1, GFP_NOWAIT);
+	if (err < 0)
+		err = idr_alloc(&mmc_host_idr, host, 0, 0, GFP_NOWAIT);
 	if (err >= 0)
 		host->index = err;
 	spin_unlock(&mmc_host_lock);
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c..4bc6ce7 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -54,6 +54,8 @@
 
 	aliases {
 		serial0 = &uart0;
+	        mmc1 = "mmc@01c11000";
+	        mmc0 = "mmc@01c0f000";
 	};
 
 	chosen {

The good news is that it works

[    4.795430] mmc1: new high speed MMC card at address 0001
[    4.796351] mmcblk0: mmc1:0001 P1XXXX 3.60 GiB
[    4.796763] mmcblk0boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB
[    4.797145] mmcblk0boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB
[    4.805206]  mmcblk0: p1
...
[    5.090549] mmc0: new high speed SDHC card at address 0002
[    5.096878] mmcblk1: mmc0:0002 00000 3.70 GiB
[    5.102951]  mmcblk1: p1
...
[    5.204156] EXT4-fs (mmcblk1p1): mounted filesystem with writeback data mode. Opts: (null)
[    5.212566] VFS: Mounted root (ext4 filesystem) readonly on device 179:25.
[    5.224087] devtmpfs: mounted

but it is not a solution (not complete at least) of the problem. It only make MMC devices with fixed names.

 

Linux command line 'root=/mmcblk0p1' has to be changed to 'root=/mmcblk1p1' by U-Boot after recognizing actual boot device

Resize script has to be changed as well. Other staff may also be affected afterwards.

 

Unfortunately, the situation is even more complicated adding that:

  • U-Boot can be on SD card, eMMC or both and device names can also be swapped
  • The rootfs can be on eMMC, SDC, USB HDD/Flash, SATA HDD/SSD or other recognized by U-Boot device
  • The rootfs can be on any partition of the device

 

Any way this path is probably the only possible leaving to Armbian user to change only boot priority in boot script (changed seriously).

On the other hand boot environment could be alternative (better ?) place for searching and setting rootfs device

 

Any thoughts?

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted
  On 4/19/2016 at 1:10 PM, chradev said:

The good news is that it works

[    4.795430] mmc1: new high speed MMC card at address 0001
[    4.796351] mmcblk0: mmc1:0001 P1XXXX 3.60 GiB
[    4.796763] mmcblk0boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB
[    4.797145] mmcblk0boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB
[    4.805206]  mmcblk0: p1
...
[    5.090549] mmc0: new high speed SDHC card at address 0002
[    5.096878] mmcblk1: mmc0:0002 00000 3.70 GiB
[    5.102951]  mmcblk1: p1
...
[    5.204156] EXT4-fs (mmcblk1p1): mounted filesystem with writeback data mode. Opts: (null)
[    5.212566] VFS: Mounted root (ext4 filesystem) readonly on device 179:25.
[    5.224087] devtmpfs: mounted

Not really sure it is because of aliasing or swapping. I have never made SD card as mmcblk0 with changing of aliases.

 

I cannot understand how it worked a few days and why it is stopped at given moment.

As 'working' I mean that the kernel automatically register under mmcblk0 eMMC (swap is needed) or SD card depending its presence (no swap).

 

The only big difference meanwhile is migration from kernel 4.4.6 to 4.5.1 but it had definitely worked in the beginning after migration.

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 4/19/2016 at 1:10 PM, chradev said:

Linux command line 'root=/mmcblk0p1' has to be changed to 'root=/mmcblk1p1' by U-Boot after recognizing actual boot device

 

If you cloned SD contents to eMMC with "dd", it will be hard to implement. Otherwise if u-boot correctly identifies "mmc 0" as boot device, it should be possible to implement with "root by partition UUID"

/*
 *	Convert a name into device number.  We accept the following variants:
...
 *	6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
 *	   unique id of a partition if the partition table provides it.
 *	   The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
 *	   partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-
 *	   filled hex representation of the 32-bit "NT disk signature", and PP
 *	   is a zero-filled hex representation of the 1-based partition number.
 *	7) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
 *	   a partition with a known unique id.
...
 */

So boot script for a single partition image would look like this:

# get partition UUID of partition 1 of mmc 0 device
# and store it in "partuuid" variable
part uuid mmc 0:1 partuuid
# pass it to the kernel
setenv bootargs "console=ttyS0,115200 root=PARTUUID=${partuuid} rootfstype=ext4 rootwait ..."

# all other things go as usual
ext4load mmc 0 0x49000000 /dtb/${fdtfile}
ext4load mmc 0 0x46000000 zImage
env set fdt_high ffffffff
bootz 0x46000000 - 0x49000000
chradev

chradev

Posted
  • Author
Posted

Thanks Zador,

 

Looking on the boot script code it should work even at partition UUID change, shouldn't it?

After reading the posts about this method I was left with the impression that it be a problem.

 

Best regards

Chris

zador.blood.stained

zador.blood.stained

Posted
Posted

If you cloned SD to eMMC with "dd", then partition UUIDs will be cloned too (AFAIK) - that is my main concern.

If you partition your eMMC manually and use rsync to clone rootfs (or once nand-sata-install script is extended to handle eMMC installation), this should work fine.

Previous posts probably were mentioning hardcoding partition UUID in boot script, which won't work well with FS resizing procedure - but getting UUIDs dynamically in u-boot should work even with FS resizing (once it is fixed).

chradev

chradev

Posted
  • Author
Posted

I test situation with kernel 4.4.6 and find as described before.

If SD card is mounted kernel assign it mmcblk0 and the system boots and resizes partition as expected.

Later on I write the image to eMMC with 'dd' and it boots and resizes as well.

 

There is some difference between kernel 4.4.6 and 4.5.1.

 

Any way is proposed solution to use partition UUID works it will be more reliable regarding later kernel changes.

 

Really U-Boot 2016.10 correctly identifies "mmc 0" as boot device for now.

I will try with 2016.01 and 2016.05-rc1 as reported to boot Armbian on Lime2 boards.

And is everything is ok probably this will be the right solution.

chradev

chradev

Posted
  • Author
Posted

Hi Zador,

 

  On 4/19/2016 at 2:50 PM, zador.blood.stained said:

If you cloned SD to eMMC with "dd", then partition UUIDs will be cloned too (AFAIK) - that is my main concern.

If you partition your eMMC manually and use rsync to clone rootfs (or once nand-sata-install script is extended to handle eMMC installation), this should work fine.

Previous posts probably were mentioning hardcoding partition UUID in boot script, which won't work well with FS resizing procedure - but getting UUIDs dynamically in u-boot should work even with FS resizing (once it is fixed).

 

I test your proposal to retrieve and use 'root=PARTUUID=${partuuid}' in u-boot.

 

Unfortunately, if both SD card and eMMC is cloned by 'dd' from the same image they are completely identical and kernel mount fist device it parses.

 

I try to find tool for changing it after cloning but without success. Partition UUID can be changed easily by:

tune2fs /dev/sde5 -U 'uuidgen'

I am not sure that the only way to get different PARTUUID is to format disk and then clone partition only.

In such a case lower sectors (incl. u-boot) should be updated separately (like nand-sata-install script style).

Unfortunately, this will take much more time as well.

 

Is there a way to change only PARTUUID?

 

Best regards

Chris

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 4/19/2016 at 7:23 PM, chradev said: 
tune2fs /dev/sde5 -U 'uuidgen'

This changes filesystem UUID, not partition UUID.

       -U UUID
              Set the universally unique identifier (UUID) of  the  filesystem
              to UUID.  The format of the UUID is a series of hex digits sepaâ€
              rated          by          hyphens,          like          this:
              "c1b9d5a2-f162-11cf-9ece-0020afc76f16".   The UUID parameter may
              also be one of the following:

According to quick Google search, PARTUUID can be changed with gdisk:

https://unix.stackexchange.com/questions/154171/changing-hfsplus-uuid-from-partedmagic

 

Edit: The only difference is Armbian uses MBR instead of GPT, but I believe it still should work.

For working with MBR partition tables fdisk should be used instead of gdisk.

Don't see an option to change PARTUUID in fdisk unfortunately, will search for a solution that doesn't require recreating partition table later.

chradev

chradev

Posted
  • Author
Posted

While experimenting with 'gdisk' I succeed to change PARTUUID (probably 'gdisk -f /dev/mmcblk1' regardless of printed error).

root@egpr:~# blkid
/dev/mmcblk0p1: UUID="c7800036-5848-49e7-a462-ef56868c77bd" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="eef59632-57ca-495e-b78d-110be70feba3"
/dev/mmcblk1p1: UUID="c7800036-5848-49e7-a462-ef56868c77bd" TYPE="ext4" PARTUUID="00093953-01"
/dev/sda1: UUID="87baa5f6-3ce0-42c3-849b-0ec7a77755ef" TYPE="ext4" PARTUUID="01c14ee2-01"
/dev/sda2: UUID="acf3dece-0426-44b1-bba7-cbcb3bdfcb42" TYPE="ext4" PARTUUID="01c14ee2-02"
/dev/mmcblk0: PTUUID="d7f3e31b-62c0-4ec5-b54c-62a5911bb702" PTTYPE="gpt"
/dev/mmcblk1: PTUUID="00093953" PTTYPE="dos"

Changed is /dev/mmcblk0p1 (SD card). After rebooting u-boot prints:

U-Boot 2015.10-armbian (Apr 19 2016 - 15:04:27 +0300) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 1 (SD), SUNXI SD/MMC: 0 (eMMC)

instead of (when PARTUUID are identical):

U-Boot 2015.10-armbian (Apr 19 2016 - 15:04:27 +0300) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0 (SD), SUNXI SD/MMC: 1

and load kernel and assign root to eMMC (which it take as 0).

root@egpr:~# blkid
/dev/mmcblk0p1: UUID="c7800036-5848-49e7-a462-ef56868c77bd" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="eef59632-57ca-495e-b78d-110be70feba3"
/dev/mmcblk1p1: UUID="c7800036-5848-49e7-a462-ef56868c77bd" TYPE="ext4" PARTUUID="00093953-01"
/dev/sda1: UUID="87baa5f6-3ce0-42c3-849b-0ec7a77755ef" TYPE="ext4" PARTUUID="01c14ee2-01"
/dev/sda2: UUID="acf3dece-0426-44b1-bba7-cbcb3bdfcb42" TYPE="ext4" PARTUUID="01c14ee2-02"
/dev/mmcblk0: PTUUID="d7f3e31b-62c0-4ec5-b54c-62a5911bb702" PTTYPE="gpt"
/dev/mmcblk1: PTUUID="00093953" PTTYPE="dos"
root@egpr:~# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda            8:0    0 55.9G  0 disk
├─sda1         8:1    0   50G  0 part /media/sda1
└─sda2         8:2    0  5.9G  0 part /media/sda2
mmcblk1boot0 179:16   0   16M  1 disk
mmcblk1boot1 179:24   0   16M  1 disk
mmcblk0      179:0    0  3.7G  0 disk
└─mmcblk0p1  179:1    0  1.2G  0 part
mmcblk1      179:8    0  3.6G  0 disk
└─mmcblk1p1  179:9    0  3.4G  0 part /

Interesting is that u-boot swap SD card / eMMC order only if PARTUUID are identical (which is most probably bug or side effect).

Unfortunately, kernel does not swap SD card / eMMC order in case of duplicated PARTUUID and the result is inability to boot from SD card again.

 

BTW: at change from tests with kernel 4.4.6 to 4.5.1 I get again dreamed behavior (to boot from SD when inserted instead of eMMC).

Unfortunately, this behavior is probably not reliable as observed before.

chradev

chradev

Posted
  • Author
Posted
  On 4/19/2016 at 8:10 PM, zador.blood.stained said:

OK, "change disk identifier" in fdisk expert menu is the right option.

Probably will give the same result as I have just described.

zador.blood.stained

zador.blood.stained

Posted
Posted

Since you used gdisk instead of fdisk, your partition table got changed from MBR to GPT. And looking at GPT documentation, it probably erased SPL and u-boot on your SD card, which caused boot from eMMC and change in SD/eMMC numbers.

 

SPL starts at 8KB, and GPT can be up to 16KB in size (with 512 bytes logical block size)

chradev

chradev

Posted
  • Author
Posted

Thanks Zador, you are right!

 

Meanwile I change eMMC disk identifier (has to be 4 bytes hex value prefixed with 0x) and re-write SD card so both PTTYPE are "dos" but PTUUID are different:

root@egpr:/media/sda1# blkid
/dev/mmcblk0p1: UUID="c7800036-5848-49e7-a462-ef56868c77bd" TYPE="ext4" PARTUUID="00093953-01"
/dev/mmcblk1p1: UUID="c7800036-5848-49e7-a462-ef56868c77bd" TYPE="ext4" PARTUUID="f9f9e8e8-01"
/dev/sda1: UUID="87baa5f6-3ce0-42c3-849b-0ec7a77755ef" TYPE="ext4" PARTUUID="01c14ee2-01"
/dev/sda2: UUID="acf3dece-0426-44b1-bba7-cbcb3bdfcb42" TYPE="ext4" PARTUUID="01c14ee2-02"
/dev/mmcblk0: PTUUID="00093953" PTTYPE="dos"
/dev/mmcblk1: PTUUID="f9f9e8e8" PTTYPE="dos"

and finally a step to the success. U-Boot identifies SD card as a first:

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 0 (SD), SUNXI SD/MMC: 1

and kernel boots successfully from SD card, starts resize script and reboots.

Unfortunately, eMMC is registered as mmvblk0 so resize script try to work on eMMC instead of SD card.

After reboot SD card was not resized but the system boots from it reliably:

/dev/mmcblk0p1: UUID="c7800036-5848-49e7-a462-ef56868c77bd" TYPE="ext4" PARTUUID="00093953-01"
/dev/mmcblk1p1: UUID="c7800036-5848-49e7-a462-ef56868c77bd" TYPE="ext4" PARTUUID="f9f9e8e8-01"
/dev/sda1: UUID="87baa5f6-3ce0-42c3-849b-0ec7a77755ef" TYPE="ext4" PARTUUID="01c14ee2-01"
/dev/sda2: UUID="acf3dece-0426-44b1-bba7-cbcb3bdfcb42" TYPE="ext4" PARTUUID="01c14ee2-02"
/dev/mmcblk0: PTUUID="00093953" PTTYPE="dos"
/dev/mmcblk1: PTUUID="f9f9e8e8" PTTYPE="dos"
root@egpr:~# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda            8:0    0 55.9G  0 disk
├─sda1         8:1    0   50G  0 part /media/sda1
└─sda2         8:2    0  5.9G  0 part /media/sda2
mmcblk1boot0 179:16   0   16M  1 disk
mmcblk1boot1 179:24   0   16M  1 disk
mmcblk0      179:0    0  3.7G  0 disk
└─mmcblk0p1  179:1    0  1.2G  0 part /
mmcblk1      179:8    0  3.6G  0 disk
└─mmcblk1p1  179:9    0  3.4G  0 part

Note that at second boot SD card is registered as mmcblk0 in opposite to the first boot.

Booting witout SD card is also fine:

U-Boot 2015.10-armbian (Apr 19 2016 - 15:04:27 +0300) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
I2C:   ready
DRAM:  1 GiB
MMC:   SUNXI SD/MMC: 1, SUNXI SD/MMC: 0 (eMMC)

...

root@egpr:~# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda            8:0    0 55.9G  0 disk
├─sda1         8:1    0   50G  0 part /media/sda1
└─sda2         8:2    0  5.9G  0 part /media/sda2
mmcblk0boot0 179:8    0   16M  1 disk
mmcblk0boot1 179:16   0   16M  1 disk
mmcblk0      179:0    0  3.6G  0 disk
└─mmcblk0p1  179:1    0  3.4G  0 part /
root@egpr:~# blkid
/dev/mmcblk0p1: UUID="c7800036-5848-49e7-a462-ef56868c77bd" TYPE="ext4" PARTUUID="f9f9e8e8-01"
/dev/sda1: UUID="87baa5f6-3ce0-42c3-849b-0ec7a77755ef" TYPE="ext4" PARTUUID="01c14ee2-01"
/dev/sda2: UUID="acf3dece-0426-44b1-bba7-cbcb3bdfcb42" TYPE="ext4" PARTUUID="01c14ee2-02"
/dev/mmcblk0: PTUUID="f9f9e8e8" PTTYPE="dos"

Now resize script has to be changed to resize partition mounted on the root.

chradev

chradev

Posted
  • Author
Posted

I try to make following change in do_expand_rootfs() function of firstrun script:

from: DEVICE="/dev/"$(lsblk -idn -o NAME | grep -w mmcblk0)
to:   DEVICE=$(mount|grep ' / '|cut -d' ' -f 1 | cut -dp -f1)

expecting the script to resize the first partition of SD card where the system is booted from.

At first boot SD card is registered as mmcblk1 and 'mount|grep ' / '|cut -d' ' -f 1 | cut -dp -f1' command prints /dev/mmcblk1 as expected.

Unfortunately, by some reason partition did not get resized.

 

Any ideas where is the problem?

 

EDIT: It was typo!

Resize is working fine even firstrun script does not require reboot.

It works meaningless how devices are registered in the kernel.

Boot and resize is working fine on eMMC as well.

 

Fortunately or not, at the last boot the order of registered devices in kernel was changed again.

Any way now sending PARTUUID from u-boot to kernel works reliably.

 

The only important thing is u-boot to recognize right boot device so following must be met:

  • disk partition table for both SD card and eMMC must have PTTYPE="dos"
  • PTUUID="XXXXXXXX" must be unique for both SD card and eMMC
  • both SD card and eMMC must have SPL with U-Boot installed

To avoid duplication of SD card and eMMC PARTUUID if 'dd' is used to write SD card eMMC can be prepared by:

  • fdisk -> new partition; mkfs.extX; rsync
  • 'dd'; fdisk -> x -> i   (change the disk identifier) -> 0x1234cdef -> r -> w
  • extended nand-sata-install script to support eMMC

In case of cloning eMMC and SD card from the same image maybe partition UUID has to be changed as well:

 tune2fs /dev/mmcblkXp1 -U 'uuidgen'

where uuidgen command is a part of uuid-runtime package in Debian and Ubuntu distributions.

 

Next steps:

  • extending of nand-sata-install script to support eMMC (I do not plan to work on it personally)
  • extend boot.scr to boot from other USB HDD/Flash and SATA HDD/SSD devices
  • extend boot.scr to boot from eMMC as fail over option on user button press
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept