Upgrading the Colibri vf50 u-boot/Linux kernel without using the serial port

Technical Support
, , , ,
1

hi, we upgraded our system from Linux Kernel 3.0 with U-Boot (2014) to Linux Kernel 4.4 with the new U-Boot (BSP 2.8) for the Colibri vf50 board with our custom carrier board. The new system worked great. However, we need to upgrade the new firmware for the boards in the customer’s sites as well.

We do not have serial access for the boards in the working sites. We would like to upgrade the U-Boot and Linux kernel over the Ethernet (preferred) or using the sd card on the board (less-preferred). Would someone please let me know if this is doable? and point me to some resources?

thank you

Weixiong

2

Hi @weixiong100

Thanks for writing to the Toradex Community!

Concerning your question:

We do not have serial access for the boards in the working sites.

So, this means there is no console access to the module?

We would like to upgrade the U-Boot and Linux kernel over the Ethernet (preferred) or using the sd card on the board (less-preferred).

You can flash the module over Ethernet as described here.

Best regards,
Jaski

3

Hi, Jaski,

Thank you for your answers. For the boards on the sites, we do not have serial access. However, we can access the board through ssh after it boots into Linux.

For (Flashing Embedded Linux over Ethernet), does the board needs to be in U-Boot while performing the operation? If it needs to be in U-Boot, how do I get into U-Boot without the serial port? Please advice.

thank you

Weixiong

4

There are basically two approaches each having its pros and cons.

Either you directly do the update from within Linux e.g. similar to the following:

You may need to chroot into a ramdisk and un-mount the ubifs first, though. Plus changing anything about the NAND layout is not easily possible.

Another approach is to just do it all from within U-Boot but starting the process from Linux via U-Boot’s fw-utils aka fw_setenv.

5

hi marcel.tx,

For approach one, do you have more resources regarding it? The new firmware will have different partitions than the old one, as the new one contains device-tree partition while the old one does not.

For approach two, do you mean to modify the u-boot env, such that it would automatically execute some commands at boot-up, to erase existing image, and flash the new image? Since I do not have access to the serial console, I would need the U-Boot to perform the task automatically. right?

Thank you

Weixiong

6

For approach one, do you have more resources regarding it? The new firmware will have different partitions than the old one, as the new one contains device-tree partition while the old one does not.

Like mentioned above then it gets rather tricky and involves advanced tinkering like e.g. using kexec with updated mtdparts or the like.

For approach two, do you mean to modify the u-boot env, such that it would automatically execute some commands at boot-up, to erase existing image, and flash the new image? Since I do not have access to the serial console, I would need the U-Boot to perform the task automatically. right?

Yes, e.g. as suggested here:

7

hi marcel.tx,

I am trying to make it work with option 2. So far, I figured out the commands I need to program the u-boot env variables to load flash the new U-Boot and Linux Kernel. Now, I need to figure out modifying the U-Boot env variables from my old Linux Kernel, then I would be good to go.

Our old system consist the following:

BSP 2.2 Beta, U-Boot (2014.04) Linux Kernel 3.0.15.

I am trying to use tool fw_printenv/fw_setenv in Linux. However, this tool does not come with the BSP 2.2. I tried to use the tools in the later BSP, such as 2.4, 2.5, 2.6, 2.7 and 2.8. However, I got error while reading/writing the U-Boot Env.

my partitions are the following:

device nand0 , # parts = 6    
 # name         size              offset         mask_flags    
 0: vf-bcb              0x00020000      0x00000000      1    
 1: u-boot              0x00160000      0x00020000      1    
 2: u-boot-env          0x00080000      0x00180000      1    
 3: kernel-ubi          0x00800000      0x00200000      0    
 4: rootfs-ubi          0x01000000      0x00a00000      0    
 5: userfs-ubi          0x06600000      0x01a00000      0
 Device 0: nand0, sector size 128 KiB

In Linux,

root@ECU:~# cat /sys/class/mtd/mtd2/name
# u-boot-env

So, I know mtd2 is the right partition.

I created the /etc/fw_env.config to be

#MTD device name   Device offset    Env. size    Flash sector size   Number of sectors
/dev/mtd2      0x00000000      0x00080000      0x20000                 4

When performing the operations, I got the following

root@ECU:~# /sbin/fw_printenv    
Warning: Bad CRC, using default environment    
bootcmd=run ubiboot; run sdboot; run nfsboot    
... .... ...
    
root@ECU:~# /sbin/fw_setenv bootdelay 3
Warning: Bad CRC, using default environment    
Can't open /dev/mtd2: Permission denied    
Error: can't write fw_env to flash

I did get into the U-Boot prompt, modified one variable, and performed saveenv to make sure there is a saved copy in the flash. I did reset to verify that the new variable is being saved.

I am thinking

1)the setting on the fw_env.config is not correct

OR/AND

  1. fw_setenv tools is not the same version (CRC different) with the old BSP.

Please advise.

8

also, when I saved the env in U-Boot, I got the following.

Colibri VFxx # env save
Saving Environment to NAND...
Erasing NAND...
Erasing at 0xc0000 -- 100% complete.
Writing to NAND... OK

I am confused, as I believe 0xc0000 is where the default u-boot env located inside U-boot partition. It should save to the u-boot env partition. Am I missing something here? thank you

9

I don’t think any of them BSP 2.2 beta were meant to go anywhere near any kind of real deployment and they are no longer supported since many years ago. Anyway, the main thing that changed which is probably causing you the most issues now is the NAND driver:

Honestly, I don’t think there is any easy way to overcome this.

10

hi, marcel.tx

sorry that I stated wrong, as my old BSP is 2.3 instead of 2.2. Hopefully 2.3 is much more advanced for what I am doing.

I am trying to overcome this issue

root@ECU:~# /sbin/fw_setenv bootdelay 3
Warning: Bad CRC, using default environment    
Can't open /dev/mtd2: Permission denied    
Error: can't write fw_env to flash

I believe it is because the u-boot-env partition is configured to be read-only, as shown in

device nand0 , # parts = 6    
# name         size              offset         mask_flags    
0: vf-bcb              0x00020000      0x00000000      1    
1: u-boot              0x00160000      0x00020000      1    
2: u-boot-env          0x00080000      0x00180000      1    
3: kernel-ubi          0x00800000      0x00200000      0    
4: rootfs-ubi          0x01000000      0x00a00000      0    
5: userfs-ubi          0x06600000      0x01a00000      0
Device 0: nand0, sector size 128 KiB

Do you know anyway I can ignore the read-only flag and still write to this partition from Linux? I cannot go into u-boot and make the modification as I do not have serial access for the units in the working sites.

thank you for your help
Weixiong

11

I don’t believe there exists any easy solution around any of this.

12

Can I do this?

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.

I tried to do this, but the unit does not boot anymore. It would be great if you can give me some help on this.

I did this in Linux:

$./flash_erase /dev/mtd3 0 0
$./nandwrite /dev/mtd3 /mnt/sd/v3_old_kernel.img -p

However, I got he following error after rebooting

U-Boot 2014.04 (May 24 2014 - 01:16:51)
CPU:   Freescale Vybrid VF610 at 396 MHz
Reset cause: unknown reset
Board: Colibri VF50
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  128 MiB
MMC:   FSL_SDHC: 0
In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
Booting from NAND...
UBI: attaching mtd1 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:    126976 bytes
UBI: smallest flash I/O unit:    2048
UBI: VID header offset:          2048 (aligned 2048)
UBI: data offset:                4096
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

did I miss something?

13

Yeah, that ancient BSP still expected the Linux kernel binary to live in it’s own UBI partition. So instead of nandwrite you would need to use resp. UBI tooling.

14

If I check my current UBI partions, I get the following:

 $ ls /sys/class/ubi
 ubi1_0   ubi1     ubi0_0   ubi0     version
 
 $ cat /sys/class/ubi/ubi0_0/name
 rootfs
 
 $ cat /sys/class/ubi/ubi1_0/name
 userfs

I do not see the kernel in the UBI list. If I need to use the ubi tools, do you know which one I should use, and what s the command line?
thank you very much

15

Most likely you still keep the device tree binary and/or the Linux kernel binary outside of UBI plus you are using two separate UBIs for rootfs and userfs which is bad practice. One should only maintain one single UBI (per physical raw NAND chip that is) which should cover as much of the raw NAND flash as possible. Within that single UBI one may of course keep several volumes be it static ones (e.g. for said device tree binary and/or Linux kernel binary) or dynamic ones (e.g. for rootfs and/or userfs).

16

hi Marcel,

Yes, you are right. We placed the kernel in one ubi.

I did some googling, and I found that I need to use tool ubiupdatevol . How do I apply the tool? Do I need to attach the ubi first?

I did the following:

$./ubiattach -p /dev/mtd3
[926832.322576] UBI: attaching mtd3 to ubi2
[926832.327117] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[926832.334168] UBI: logical eraseblock size:    126976 bytes
[926832.340453] UBI: smallest flash I/O unit:    2048
[926832.345748] UBI: VID header offset:          2048 (aligned 2048)
[926832.352350] UBI: data offset:                4096
[926832.417105] UBI: empty MTD device detected
[926832.421418] UBI: max. sequence number:       0
[926832.427472] UBI: create volume table (copy #1)
[926832.452566] UBI: create volume table (copy #2)
[926832.484169] UBI: attached mtd3 to ubi2
[926832.488066] UBI: MTD device name:            "kernel-ubi"
[926832.503499] UBI: MTD device size:            8 MiB
[926832.509785] UBI: number of good PEBs:        64
[926832.514895] UBI: number of bad PEBs:         0
[926832.519888] UBI: number of corrupted PEBs:   0
[926832.524963] UBI: max. allowed volumes:       128
[926832.530175] UBI: wear-leveling threshold:    4096
[926832.535462] UBI: number of internal volumes: 1
[926832.540847] UBI: number of user volumes:     0
[926832.545933] UBI: available PEBs:             58
[926832.551032] UBI: total number of reserved PEBs: 6
[926832.556382] UBI: number of PEBs reserved for bad PEB handling: 2
[926832.562968] UBI: max/mean erase counter: 0/0
[926832.567863] UBI: image sequence number:  -1461965809
[926832.573503] UBI: background thread "ubi_bgt2d" started, PID 16700
UBI device number 2, total 64 LEBs (8126464 bytes, 7.8 MiB), available 58 LEBs (7364608 bytes, 7.0 MiB), LEB size 126976 bytes (124.0 KiB)

$ls /sys/class/ubi
ubi2     ubi1_0   ubi1     ubi0_0   ubi0     version

$./ubiupdatevol /dev/ubi2 /mnt/sd/v3_old_kernel.img
ubiupdatevol: error!: "/dev/ubi2" is an UBI device node, not an UBI volume node

Do you know what did I do wrong? Sorry for the simple questions, as I do not have much experience with the tools

17

Yeah, something like the following plus if not yet attached ubiattach may help (;-p).