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