I am trying to update the Linux kernel for our product. Instead of doing it from U-boot, I need to do it within Linux because we do not have serial connection for the devices in the field.
I have done the following:
in Linux:
$cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00020000 "vf-bcb"
mtd1: 00160000 00020000 "u-boot"
mtd2: 00080000 00020000 "u-boot-env"
mtd3: 00800000 00020000 "kernel-ubi" **** this is the image I want to replace ****
mtd4: 01000000 00020000 "rootfs-ubi"
mtd5: 06600000 00020000 "userfs-ubi"
$mtd_debug info /dev/mtd3
mtd.type = MTD_NANDFLASH
mtd.flags = MTD_WRITEABLE
mtd.size = 8388608 (8M)
mtd.erasesize = 131072 (128K)
mtd.writesize = 2048 (2K)
mtd.oobsize = 64
regions = 0
$./flash_erase /dev/mtd3 0 0
Erasing 128 Kibyte @ 64007e0000 -- 0 % complete
$nandwrite /dev/mtd3 /mnt/sd/v3_kernel.img -p
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
Writing data to block 5 at offset 0xa0000
Writing data to block 6 at offset 0xc0000
Writing data to block 7 at offset 0xe0000
Writing data to block 8 at offset 0x100000
Writing data to block 9 at offset 0x120000
Writing data to block 10 at offset 0x140000
Writing data to block 11 at offset 0x160000
Writing data to block 12 at offset 0x180000
Writing data to block 13 at offset 0x1a0000
Writing data to block 14 at offset 0x1c0000
Writing data to block 15 at offset 0x1e0000
Writing data to block 16 at offset 0x200000
Writing data to block 17 at offset 0x220000
Writing data to block 18 at offset 0x240000
Writing data to block 19 at offset 0x260000
After rebooting, I received the following error in u-boot:
UBI error: ubi_read_volume_table: the layout volume was not found
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -22
UBI init error 22
Please help… Did I miss something? I was actually re-programming the same kernel image in the process. I want to make sure it can bootup properly after re-programming before using the new Linux kernel.
I have upgraded the BSP and Linux kernel to the latest in our products recently. I am working on the upgrade to the products in the customers’ site now. For those units, the kernel is very old.
yes, I know it is very old. We actually have upgraded the whole system for our new products already (U-Boot, dtd, and Kernel). However, for the products in the customers’ site, we do not have access to the serical/uboot. My plan is to overwrite the u-boot configuration to make the units to boot into u-boot and flash the whole system from MMC. However, the u-boot configuration portion was configured as read-only, and I have no ways to modify that since I cannot go into u-boot for existing products in the customer’s site. I am planning to recompile the same old kernel 3.0 after modifying the source code to ignore the read-only flag. With the modified kernel 3.0, hopefully I can overwrite the u-boot config sector, plus, I can upgrade the whole system.
This is a new very special case for us. We need to internally investigate on this.
Could you tell us about how many products without serial console you need to update?
Is there no UART or USB connection on the custom carrier board?
What about ethernet connection?
We have over thousands of units without UART on the custom carrier board. We actually have USB ports on them, but I never tried anything with the USB port. Are there any chance that allows me to get into U-boot with the USB?
We do not have Ethernet connection in U-Boot. The Ethernet only works after Linux booted up. It is because the U-Boot Ethernet setting does not match our carrier board, and we modified the Linux Ethernet driver to make it work.
The only solution meeting your advanced update requirements will involve a multi step approach like you already figured out. Depending on whether or not and how much existing data may need to be preserved resp. how big the new software is external communication or storage may be required at least during some of those steps. Please first make sure that the “new” software adheres to the latest raw NAND best practices (e.g. limiting separate MTD partitions to a minimum and using one big single UBI for most everything). One big issue you may face is that the underlying raw NAND data representation changed too significantly preventing the old BSP from easily writing in a way the new BSP may be able to read it or vice versa. One way to assess this may be to NFS boot the old BSP on a module running the new BSP trying to read/write from/to NAND. Good luck!
