Notes on restoring embedded systems
I tried to collect my experience of porting OpenWRT to embedded equipment. In this article I will talk about how to work with the u-boot bootloader and the main problems encountered when loading the operating system.
The embedded ones do not have a separate BIOS card, so the bootloader (u-boot in our case) is located directly on the flash drive. Therefore, you need to be very careful when working with flash drives, and do not forget to dump the bootloader before any dangerous actions! Also note the feature of NOR-flash drives: drive cells are presented in the form of RAM. This allows you to run programs on the fly - without copying to memory. In the case of NAND flash drives, special programs are used for recording. So we have a loader, straight arms, and an awareness of what to do. We study the output printenv in search of aliases that we can greatly facilitate life. Find something like this:
kimage = $ {download} $ {memtmp_addr} $ {kimagename}; run erase_kimage; cp.b $ {memtmp_addr} $ {kernel_addr} $ {filesize}.
')
I will analyze in more detail what is happening here. When you run run kimage, execute download (by default download = tftp, you can change to nfs or serial line), the file is loaded into the address recorded in memtmp_addr, kimagename is equal to vmlinux.gz.uImage and so on through the list, the variables are visible by printenv. After downloading the file to the RAM, the process of erasing the flash drive starts and then the file is copied from the memory to the USB flash drive. I note that the variable filesize is equal to the size of the last downloaded file and will be filled with the tftp command in this case. Also note that when you run run erase_kimage (erase $ {kernel_addr} $ {kernel_size} is hidden under it), the volume is not erased from the new kernel, but from the variable kernel_size. Accordingly, if your kernel is larger than the kernel_size equal to the default partition for the kernel, it will write to sectors that have not been reset. That in the case of NOR memory will lead to data corruption in those cells. Be alert.
And so, we check the network settings, again the IP-address of the tftp-server is specified in printenv. Put the kernel in the tftp directory and run the run kimage. In order to avoid troubles, it is not bad to check the checksum, run the crc32 $ {memtmp_addr} $ {filesize} command in the loader and check with the data received via the crc32 vmlinux.gz.uImage on the host machine, or use the iminfo utility, which will do this check itself but only if headers were inserted into the kernel via mkimage.
An example of a sequence of actions in the absence of aliases:
tftp 0x80060000 openwrt-ar71xx-generic-uImage-gzip.bin
erase 0xbf050000 + $ {filesize}
cp.b 0x80060000 0xbf050000 $ {filesize}
reset
0x80010000 - address of a place in RAM, usually tftp, knows where to write.
0xbf050000 - address (from the range of destination for flash) where the download starts. You can look at the variable bootcmd.
Attention. All the addresses in the article are fictional and their use can turn your system into a brick!
You can also pass parameters to the kernel via the bootloader:
setenv bootargs console = ttyS0,115200 rootfstype = jffs2
Some flash drive drivers support MTD markup management via the command line:
mtdparts = spi0.0: 320k (u-boot) ro, 128k (u-boot-env) ro, 1024k (kernel), 14848k (rootfs), 64k (art) ro, 15872k @ 0x70000 (firmware)
MTD is an intermediary mechanism between flash memory and the file system driver. Allows you to work with a flash drive as with a conventional block or character device. It is necessary because the blocks on flash drives (NOR, NAND ..) must be erased before recording.
With the bootloader finished, then I will list the most popular causes of boot problems.
The bootloader does not load:
1. The loader was corrupted.
The processor cannot start the bootloader. This problem can be solved by several methods. If possible, you can use JTAG for recovery. Or program the flash drive with a programmer - usually flash drives are connected via SPI.
2. Hardware problems.
If you have electronic skills and a good soldering station, then we study specifications, measure voltages, and so on, until you find the cause of the problem.
The kernel does not boot:
1. Unexpected data format.
The loader waits for lzma without the mkimage signature, and gets a gzip with the signature. Usually, the developer throws all the unnecessary things out of the bootloader, so if he himself uses gzip to compress the kernel, then lzma will most likely not understand the bootloader. Also, there are more advanced cases when the loader waits for certain headers before the kernel. It may also not like the fully striped kernel, since the loader expected to see the signature of the elf file.
2. The kernel was incorrectly written.
For example, sectors where it was recorded were not previously erased. Or a spoiled image was recorded.
Do not mount FS:
1. Unspecified root fs.
The kernel does not know which FS to use as root. You must specify root =, or in the case of openwrt, the kernel can be patched so that the rootfs partition is automatically used as root.
2. The kernel does not support this fs.
Support for this file system is not included in the kernel, or enabled by a module (initrd is not usually used). Or features of FS, for example compression, are not supported.
3 Actually there is no data in the root section.
Perhaps there was a miss with the FS entry due to an incorrectly specified offset or partition.
Work with u-boot
The embedded ones do not have a separate BIOS card, so the bootloader (u-boot in our case) is located directly on the flash drive. Therefore, you need to be very careful when working with flash drives, and do not forget to dump the bootloader before any dangerous actions! Also note the feature of NOR-flash drives: drive cells are presented in the form of RAM. This allows you to run programs on the fly - without copying to memory. In the case of NAND flash drives, special programs are used for recording. So we have a loader, straight arms, and an awareness of what to do. We study the output printenv in search of aliases that we can greatly facilitate life. Find something like this:
kimage = $ {download} $ {memtmp_addr} $ {kimagename}; run erase_kimage; cp.b $ {memtmp_addr} $ {kernel_addr} $ {filesize}.
')
I will analyze in more detail what is happening here. When you run run kimage, execute download (by default download = tftp, you can change to nfs or serial line), the file is loaded into the address recorded in memtmp_addr, kimagename is equal to vmlinux.gz.uImage and so on through the list, the variables are visible by printenv. After downloading the file to the RAM, the process of erasing the flash drive starts and then the file is copied from the memory to the USB flash drive. I note that the variable filesize is equal to the size of the last downloaded file and will be filled with the tftp command in this case. Also note that when you run run erase_kimage (erase $ {kernel_addr} $ {kernel_size} is hidden under it), the volume is not erased from the new kernel, but from the variable kernel_size. Accordingly, if your kernel is larger than the kernel_size equal to the default partition for the kernel, it will write to sectors that have not been reset. That in the case of NOR memory will lead to data corruption in those cells. Be alert.
And so, we check the network settings, again the IP-address of the tftp-server is specified in printenv. Put the kernel in the tftp directory and run the run kimage. In order to avoid troubles, it is not bad to check the checksum, run the crc32 $ {memtmp_addr} $ {filesize} command in the loader and check with the data received via the crc32 vmlinux.gz.uImage on the host machine, or use the iminfo utility, which will do this check itself but only if headers were inserted into the kernel via mkimage.
An example of a sequence of actions in the absence of aliases:
tftp 0x80060000 openwrt-ar71xx-generic-uImage-gzip.bin
erase 0xbf050000 + $ {filesize}
cp.b 0x80060000 0xbf050000 $ {filesize}
reset
0x80010000 - address of a place in RAM, usually tftp, knows where to write.
0xbf050000 - address (from the range of destination for flash) where the download starts. You can look at the variable bootcmd.
Attention. All the addresses in the article are fictional and their use can turn your system into a brick!
You can also pass parameters to the kernel via the bootloader:
setenv bootargs console = ttyS0,115200 rootfstype = jffs2
Some flash drive drivers support MTD markup management via the command line:
mtdparts = spi0.0: 320k (u-boot) ro, 128k (u-boot-env) ro, 1024k (kernel), 14848k (rootfs), 64k (art) ro, 15872k @ 0x70000 (firmware)
MTD is an intermediary mechanism between flash memory and the file system driver. Allows you to work with a flash drive as with a conventional block or character device. It is necessary because the blocks on flash drives (NOR, NAND ..) must be erased before recording.
With the bootloader finished, then I will list the most popular causes of boot problems.
Causes of failures
The bootloader does not load:
1. The loader was corrupted.
The processor cannot start the bootloader. This problem can be solved by several methods. If possible, you can use JTAG for recovery. Or program the flash drive with a programmer - usually flash drives are connected via SPI.
2. Hardware problems.
If you have electronic skills and a good soldering station, then we study specifications, measure voltages, and so on, until you find the cause of the problem.
The kernel does not boot:
1. Unexpected data format.
The loader waits for lzma without the mkimage signature, and gets a gzip with the signature. Usually, the developer throws all the unnecessary things out of the bootloader, so if he himself uses gzip to compress the kernel, then lzma will most likely not understand the bootloader. Also, there are more advanced cases when the loader waits for certain headers before the kernel. It may also not like the fully striped kernel, since the loader expected to see the signature of the elf file.
2. The kernel was incorrectly written.
For example, sectors where it was recorded were not previously erased. Or a spoiled image was recorded.
Do not mount FS:
1. Unspecified root fs.
The kernel does not know which FS to use as root. You must specify root =, or in the case of openwrt, the kernel can be patched so that the rootfs partition is automatically used as root.
2. The kernel does not support this fs.
Support for this file system is not included in the kernel, or enabled by a module (initrd is not usually used). Or features of FS, for example compression, are not supported.
3 Actually there is no data in the root section.
Perhaps there was a miss with the FS entry due to an incorrectly specified offset or partition.
Source: https://habr.com/ru/post/128045/
All Articles