chradev

Hi Zador, 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

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.

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

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.

Hi Zador, 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

Hi Zador, 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.

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

Hi tkaise, I will read pointed chat in a while. 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

Hi tkaiser, 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

Hi Igor, See https://github.com/igorpecovnik/lib/issues/258

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

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

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

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

I will test them a.s.a.p.

Hi to All, Find short summary from latest thermal and power tests made on Lime2-eMMC board. Best rehards Chris Armbian-5.07_Kernel-4.4.6_A20-Lime2-eMMC_Power-Thermal-Tests-Summary.pdf

Tanks tkaizer, I finally succeed to install and customize RPI Monitor 2.10 in Armbian 5.07 with Kernel 4.4.6 and run it on A20-Olinuxino-Lime2-eMMC. I put all pointed by you staff in /etc/armbianmonitor and /etc/armbianmonitor/templates folders. I modify /etc/armbianmonitor/armbian.conf as: web.page.icon='img/armbian.png' web.page.menutitle='Monitor ('+data.hostname+')' web.page.pagetitle='Monitor ('+data.hostname+')' web.status.1.name=Lime 2 web.statistics.1.name=Lime 2 web.addons.1.name=Addons web.addons.1.addons=about include=/etc/rpimonitor/template/version.conf include=/etc/armbianmonitor/templates/uptime.conf include=/etc/armbianmonitor/templates/axp209_template_battery.conf include=/etc/rpimonitor/template/memory.conf include=/etc/rpimonitor/template/swap.conf include=/etc/rpimonitor/template/sdcard.conf include=/etc/rpimonitor/template/network.conf and link it to: /etc/rpimonitor/data.conf -> /etc/armbianmonitor/armbian.conf Some changes are also made to the following files: /etc/armbianmonitor/templates/uptime.conf /etc/armbianmonitor/templates/axp209_template_battery.conf The results are published in my post. Best regards Chris

Hi to All, Thanks to tkaize's post I succeeded to install and customize RPI Monitor 2.10 in Armbian 5.07 with Kernel 4.4.6 and run it on A20-Olinuxino-Lime2-eMMC. You can find the report of the series of thermal and power tests done with and without CPU and Network load in the attached file. The good news is that there are no hangs while testing even the temperatures of both CPU and PMU chips go up to 58°C. EDIT: Forget to mention that the tested board is out of a box (horizontal placed) and CPU has ALUMINIUM-HEATSINK-20x20x6MM. Attachment slightly modified with event and Network bandwidth marks around the graphics. Best regards Chris Armbian-5.07_Kernel-4.4.6_A20-Lime2-eMMC_Power-Thermal-Tests.pdf

Hi tkaiser, I am trying to add armbian monitoring staff in Armbian (kernel 4.4.6) but starting armbianmonitor-daemon reports that a lot of files from /etc/armbianmonitor and /etc/armbianmonitor/templates do not exists. I try to add them as a copy from rpimonitor or simply creating the empty once. Finally armbianmonitor-daemon starts but exits from some time. As I see the files in /etc/armbianmonitor/datasources exist and have right values but reading discussions I cannot create the needed infrastructure and link it with rpimonitor. Any help for that? Best regards Chris

Hi to All, I try to run RPI Monitor and A20 & AXP209 support in Armbian next (kernel 4.4.6) on A20-Olinuxino-Lime2-eMMC but without success. /usr/share/rpimonitor/scripts/sunxi-temp-daemon.sh prints error from line 107 because PMUTemp is empty (even if lm-sensors is installed). Unfortunately, I could not understand what should be done to succeed at: # check whether PMU value could be read before if [ "X${PMUTemp}" = "X" ]; then # Maybe the patches from http://sunxi.montjoie.ovh are applied and lm-sensors installed PMUTemp=$(sensors | awk -F" " '/CHIP: / {printf ("%0.0f",$2*10); }') fi BTW is there something newer to install instead of thread the work is in progress so I can try to test in cease of some guidance. Best regards Chris

The patches for default case (legacy kernel 3.4) userpatches/kernel/sun7i-default/a20-lime-emmc-kernel-default.patch Copy lib/config/lime2.fex as lib/config/lime2-emmc.fex and use following patch: I personally prefer to keep lime2-emmc.fex outside Armbian source tree and to overwrite /boot/bin/lime2.bin file in customization phase.

I have succeed to patch U_Boot (v2015.10) for being able to recognize eMMC on Lime2-eMMC board by following patch: At boot u-boot reports: From u-boot: Final patch for the mainline kernel (4.4) to recognize eMMC on Lime2-eMMC board is: it makes eMMC usable as /dev/mmcblk1 and works fine. It is time to prepare u-boot script to boot from eMMC

The fault is to try to patch kernel instead of u-boot. The Olimex patch: is for the U-Boot and verified to have effect with v2015.10. Alternative patch is proposed by Michael Haas here. The result is higher then 100 Mbps performance while Lime2 Ethernet port is connected to GBit switch.

I test creating of patch with 'git diff phy_device.c > a20_gigabit_slow.patch' command (after modifying drivers/net/phy/phy_device. file): and put it in userpatches/kernel/sunxi-next folder. Unfortunately, file is patched but kernel compile process crashes at the same place. Where is my fault? EDIT: The patch is not for this file even it is not for kernel but for u-boot

Meanwhile I try to apply similar path to file drivers/net/phy/phy_device.c: In some reason kernel compile process crashes. May be the patch is wrong. EDIT: patch is for u-boot How can I create patch after modifying some file in source tree (kernel for example)? Have I to double the tree or the file inside original tree? What command should I use: 'diff -c ...' or 'diff --git ...'? EDIT: Make first build without modification of the file(s) edit the file(s) you want to modify re-build with 'FORCE_CHECKOUT = "no"' option in compile.sh and test modification(s) inside the source tree issue command 'git diff modified_file.x > /path-to-patches/modified_file.patch' if more than a file is modified concatenate all files patches in a single file (respect the order if important) re-build with 'FORCE_CHECKOUT = "yes"' option in compile.sh Sorry for the "noise"