Hi.
Recently got my hands on a Colibri T30 1.1B which is going to replace the Colibri T30 1.1A for our production devices. According to the product change notifications document there are not any migration steps necessary.
Well there is one thing that we found that breaks when changing the module version but keeping the software the same.
It is the fw_printenv/setenv tools, U-boot and Linux does not seem to agree upon where the U-boot environment is. That is if I set a variable with fw_setenv it is not “seen” in U-boot, or the other way around.
The configuration file matches what you currently have in your “rocko” branch
# cat /etc/fw_env.config
/dev/mmcblk0boot0 -0x2200 0x2000
I am running a bit of a custom BSP release so would appreciate to get a hint if you have verified that fw_printenv/setenv tools works on official releases before we dig too deep, but our U-boot configuration is very similar to your official releases. Should be noted that we use the 2015.04 release though.
Anyway if our BSP works as expected on 1.1A module, I would expect it to work on 1.1B as well for this.
Best Regards
Mirza
Hi Mirza
Yes, this definitely works in e.g. our latest official BSP 2.8b2. I just verified this again.
I guess the question is whether the problem lays on the U-Boot or Linux side. An easy way to assess this would be to do raw reads in both and see who is going wrong…
Maybe first I guess you understand that the underlying issue is that the eMMC hardware boot area partition sizes are different between the two. And we do write the U-Boot environment before the last block of the primary eMMC hardware boot area partition. The last block being our Toradex Factory Configuration Block with the serial number/MAC address, production and version information. The U-Boot environment size may be found here: CONFIG_ENV_SIZE = 0x2000 = 8192
Colibri T30 V1.1A IT (resp. V1.1D but should really be similar, just don’t have the other one handy)
Colibri T30 # mmc info
Device: Tegra SD/MMC
Manufacturer ID: 90
OEM: 14a
Name: H4G1d
Tran Speed: 52000000
Rd Block Len: 512
MMC version 4.4.1
High Capacity: Yes
Capacity: 3.6 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 4 MiB
User Capacity: 3.6 GiB WRREL
Boot Capacity: 2 MiB ENH
RPMB Capacity: 2 MiB ENH
2 MiB = 2048 K = 4096 blocks
Colibri T30 # mmc dev 0 1
switch to partitions #1, OK
mmc0(part 1) is current device
Colibri T30 # mmc read $loadaddr 0xfef 1
MMC read: dev # 0, block # 4079, count 1 ... 1 blocks read: OK
Colibri T30 # md $loadaddr
80408000: cf01d99f 68637261 6d72613d 75616200 ....arch=arm.bau
...
root@colibri-t30:~# dd if=/dev/mmcblk0boot0 bs=512 skip=4079 | hexdump -C | head
17+0 records in
17+0 records out
00000000 9f d9 01 cf 61 72 63 68 3d 61 72 6d 00 62 61 75 |....arch=arm.bau|
...
Colibri T30 V1.1B
Colibri T30 # mmc info
Device: Tegra SD/MMC
Manufacturer ID: 13
OEM: 14e
Name: Q2J54
Tran Speed: 52000000
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 3.6 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 3.6 GiB WRREL
Boot Capacity: 16 MiB ENH
RPMB Capacity: 512 KiB ENH
16 MiB = 16384 K = 32768 blocks
Colibri T30 # mmc dev 0 1
switch to partitions #1, OK
mmc0(part 1) is current device
Colibri T30 # mmc read $loadaddr 0x7fef 1
MMC read: dev # 0, block # 32751, count 1 ... 1 blocks read: OK
Colibri T30 # md $loadaddr
81000000: 03a9a986 68637261 6d72613d 75616200 ....arch=arm.bau
...
root@colibri-t30:~# dd if=/dev/mmcblk0boot0 bs=512 skip=32751 | hexdump -C | head
17+0 records in
17+0 records out
00000000 86 a9 a9 03 61 72 63 68 3d 61 72 6d 00 62 61 75 |....arch=arm.bau|
...
What result do you get on your module(s)?
U-boot:
# mmc info
Device: Tegra SD/MMC
Manufacturer ID: 13
OEM: 14e
Name: Q2J54
Tran Speed: 52000000
Rd Block Len: 512
MMC version 5.0
High Capacity: Yes
Capacity: 3.6 GiB
Bus Width: 8-bit
Erase Group Size: 512 KiB
HC WP Group Size: 8 MiB
User Capacity: 3.6 GiB WRREL
Boot Capacity: 16 MiB ENH
RPMB Capacity: 512 KiB ENH
# mmc read $loadaddr 0x7fef 1 && md $loadaddr
MMC read: dev # 0, block # 32751, count 1 ... 1 blocks read: OK
80408000: a12e896d 5f34584d 54535953 545f4d45 m...MX4_SYSTEM_T
80408010: 3d455059 00303374 68637261 6d72613d YPE=t30.arch=arm
80408020: 75616200 74617264 31313d65 30303235 .baudrate=115200
< ... >
Linux:
$ dd if=/dev/mmcblk0boot0 bs=512 skip=32751 | hexdump -C | head
00000000 6d 89 2e a1 4d 58 34 5f 53 59 53 54 45 4d 5f 54 |m...MX4_SYSTEM_T|
00000010 59 50 45 3d 74 33 30 00 61 72 63 68 3d 61 72 6d |YPE=t30.arch=arm|
00000020 00 62 61 75 64 72 61 74 65 3d 31 31 35 32 30 30 |.baudrate=115200|
00000030 00 62 6c 6b 63 6e 74 3d 35 31 30 30 30 00 62 6c |.blkcnt=51000.bl|
00000040 6b 73 74 61 72 74 3d 31 31 64 30 30 30 00 62 6f |kstart=11d000.bo|
00000050 61 72 64 3d 6d 78 34 5f 74 33 30 00 62 6f 61 72 |ard=mx4_t30.boar|
00000060 64 5f 6e 61 6d 65 3d 6d 78 34 5f 74 33 30 00 62 |d_name=mx4_t30.b|
00000070 6f 6f 74 5f 61 5f 73 63 72 69 70 74 3d 6c 6f 61 |oot_a_script=loa|
00000080 64 20 24 7b 64 65 76 74 79 70 65 7d 20 24 7b 64 |d ${devtype} ${d|
00000090 65 76 6e 75 6d 7d 3a 24 7b 62 6f 6f 74 70 61 72 |evnum}:${bootpar|
Actually forgot to mention that I get the following:
$ ./fw_printenv foo
Too few good blocks within range
when
$ cat /etc/fw_env.config
/dev/mmcblk0boot0 -0x2200 0x2000
And this explains it I belive. We normally put this in our /etc/fw_env.config
# cat /etc/fw_env.config
/dev/mmcblk0boot0 0x3fde00 0x2000
Which I guess is correct on 1.1A but not on 1.1B since the size has changed of the part.
I wonder though why I get:
Too few good blocks within range
To old fw_utils? (2015.04 U-boot)
Yes to old U-boot, tools/env: allow negative offsets · u-boot/u-boot@f4742ca · GitHub
You should probably update the PCN, because it says that it works with “Embedded Linux: V2.3 beta 5 and newer”. I guess that is not true since it requires 2016.11 U-boot and that is V2.7 and newer?
I do believe with our stock BSPs it really should work even with that ancient long since no longer supported V2.3 beta 5. However, the exact way we do it changed a little bit over time (see e.g. the following commit). While we used to determine the exact offset during first boot we now rely on a newer fw-utils version which allows for negative offsets.
One really can’t just hardcode this offset but that is not something we ever did as far as I remember (resp. we did it intelligently during first boot).
Yeah makes sense. Thanks. We will probably implement the “first boot” calculation.
You are very welcome and sorry that we missed pointing that out explicitly.
