Hello,
i am trying to update kernel and eventuelle u-boot outside u-boot after system is started. U-boot is stored in /dev/mtd1, kernel seems to be stored in ubi partition. The problem is i can not get access to relevant flash parts because they are write-protected. What is the best way to perform a firmware update outside u-boot ?
David
I am trying to update kernel and eventually U-Boot outside U-Boot after system is started. U-Boot is stored in /dev/mtd1,
Yes, and redundantly in mtd2 as well:
root@colibri-imx7:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00020000 "mx7-bcb"
mtd1: 00180000 00020000 "u-boot1"
mtd2: 00180000 00020000 "u-boot2"
mtd3: 00080000 00020000 "u-boot-env"
mtd4: 1fc00000 00020000 "ubi"
kernel seems to be stored in ubi partition. The problem is I can not get access to relevant flash parts because they are write-protected.
No, not at all. One just needs the proper tools to do so.
What is the best way to perform a firmware update outside U-Boot?
How about something along those lines?
U-Boot:
root@colibri-imx7:~# flash_erase /dev/mtd1 0 0
Erasing 128 Kibyte @ 160000 -- 100 % complete
root@colibri-imx7:~# nandwrite /dev/mtd1 u-boot-colibri-imx7-2016.11-2.7.3-gitrf0e4149.imx
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
root@colibri-imx7:~# flash_erase /dev/mtd2 0 0
Erasing 128 Kibyte @ 160000 -- 100 % complete
root@colibri-imx7:~# nandwrite /dev/mtd2 u-boot-colibri-imx7-2016.11-2.7.3-gitrf0e4149.imx
Writing data to block 0 at offset 0x0
Writing data to block 1 at offset 0x20000
Writing data to block 2 at offset 0x40000
Writing data to block 3 at offset 0x60000
Writing data to block 4 at offset 0x80000
Kernel:
root@colibri-imx7:~# cat /sys/class/ubi/ubi0_0/name
kernel
root@colibri-imx7:~# ubiupdatevol /dev/ubi0_0 zImage--4.1-2.0.x-2.7.3-colibri-imx7-20170623142722.bin
Device Tree:
root@colibri-imx7:~# cat /sys/class/ubi/ubi0_1/name
dtb
root@colibri-imx7:~# ubiupdatevol /dev/ubi0_1 zImage--4.1-2.0.x-2.7.3-imx7d-colibri-eval-v3-20170623142722.dtb
And in case you would be interested in the M4 Firmware as well. That one could be put here:
root@colibri-imx7:~# cat /sys/class/ubi/ubi0_2/name
m4firmware
Some more information may also be found from the following thread.
Thank you for the answer, it worked to update the kernel. Updating bootloader does not work yet, i get following message:
root@colibri-imx7:~# flash_erase /dev/mtd1 0 0
flash_erase: error!: /dev/mtd1
error 13 (Permission denied)
So it may be necessary to change kernel command line to make u-boot partition writeable.
What exact BSP version are you using? As you may see from my answer above at least in our latest BSP 2.7b2 it works just fine.
I have the same problem as david444
In my case I “only” use the toradex kernel and the rootfs is from buildroot.
Is it possible, that toradex made a patch for the flash_erase, that it funtions with the mounted flash?
When yes is it possible to have this patch?
I really don’t think so. What exact software version of things are you talking about?
Could it be that you are using the eMMC SKU rather than the raw NAND based one? What exact module model, version and serial number are you trying this with?
I’m talking about the toradex Kernel 4.9. (toradex_4.9-1.0.x-imx-next)
I’m using the mtd-utils-2.0.0
I’m using the i.MX7d 512MB version c, s/n: 02927842
That should still work just fine:
Colibri-iMX7_LXDE-Image 2.8b1.64 20171229
colibri-imx7 login: root
root@colibri-imx7:~# uname -a
Linux colibri-imx7 4.9.67-+g1db9f06 #1 SMP Fri Dec 29 01:48:55 UTC 2017 armv7l GNU/Linux
root@colibri-imx7:~# opkg list-installed | grep mtd-utils
mtd-utils - 2.0.0-r0
mtd-utils-ubifs - 2.0.0-r0
root@colibri-imx7:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00020000 "mx7-bcb"
mtd1: 00180000 00020000 "u-boot1"
mtd2: 00180000 00020000 "u-boot2"
mtd3: 00080000 00020000 "u-boot-env"
mtd4: 1fc00000 00020000 "ubi"
root@colibri-imx7:~# flash_erase /dev/mtd1 0 0
Erasing 128 Kibyte @ 6400160000 -- 0 % complete
Thanks a lot for your help.
I tested it with the Toradex LXDE Demo Image and at first it did not work.
I found out, that the problem is not in the kernel or in the rootfs it is in the environment settings / boot settings of my U-Boot. When I use the default environment from the Toradex U-Boot everything works fine.
It works also with my setup as long as I use the bootcommand ubiboot or when I change the mtdpart configuration (no longer set the uboot1, uboot2 to “ro”).
I still have no idea which command of the ubiboot makes it possible to run the flash_erase command successfully on the U-Boot partition,
But for now I just use the complete ubiboot command to start my system.
You are very welcome.
The described behaviour indeed sounds strange but I guess one would have to compare the two configurations in more detail to figure out what exactly may be happening.
Should UBI not yet be attached (e.g. when booting from something other than the regular NAND UBIFS root file system) one may attach it prior to any of them above commands as follows:
root@colibri-imx6ull:~# ubiattach -p /dev/mtd4
[ 270.037201] ubi0: default fastmap pool size: 45
[ 270.042462] ubi0: default fastmap WL pool size: 22
[ 270.047669] ubi0: attaching mtd4
[ 270.266009] ubi0: attached by fastmap
[ 270.270230] ubi0: fastmap pool size: 45
[ 270.274409] ubi0: fastmap WL pool size: 22
[ 270.328455] ubi0: attached mtd4 (name "ubi", size 124 MiB)
[ 270.334338] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 270.341528] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 270.348520] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 270.355735] ubi0: good PEBs: 988, bad PEBs: 4, corrupted PEBs: 0
[ 270.361976] ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
[ 270.393488] ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 686984167
[ 270.428966] ubi0: available PEBs: 0, total reserved PEBs: 988, PEBs reserved for bad PEB handling: 16
[ 270.470288] ubi0: background thread "ubi_bgt0d" started, PID 273
UBI device number 0, total 988 LEBs (125452288 bytes, 119.6 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)