I’m trying to update a TK1 module with our latest Linux deployment.
I can push the deployment image to a microSD card as follows:
./update.sh -m 2 -o /media/dev/<name-of-sdcard>
This seems to complete OK. However, when I attempt to update the TK1 from within u-boot as follows:
run setupdate
run update
The updating goes beyond the number of blocks available on the microSD card (141 blocks on our deployment) and continues indefinitely until I abort the task. The error reported is:
reading apalis-tk1/root.ext3-190
** Unable to read file apalis-tk1/root.ext3-190 **
I’ve checked the microSD and there are definitely 141 blocks (140 are of identical size with the last being smaller) so there is no issue with corruption.
Any clues would be most helpful.
Have you modified any of the update scripts? Please note that only 100 (numbered 100 - 199) chunks are supported by our scripts. If you need to flash bigger images, Toradex Easy Installer 1.3 release includes support for Apalis TK1 modules.
More information:
@dominik.tx Nothing has been modified. As per my original question, the blocks go up to 141 which is within the range of your update.sh script
Can you share listing of the sd root and apalis-tk1 directories as well as content of apalis-tk1/apalis-tk1.img.
@dominik.tx, I can indeed:
SD card root:
drwxr-xr-x 3 root root 32768 Jan 1 1970 ./
drwxr-xr-x 3 root root 4096 Dec 11 13:03 ../
drwxr-xr-x 2 root root 32768 Dec 11 09:02 apalis-tk1/
-rwxr-xr-x 1 root root 710 Dec 11 10:44 flash_blk.img*
-rwxr-xr-x 1 root root 444 Dec 11 10:44 flash_eth.img*
-rwxr-xr-x 1 root root 307 Dec 11 10:44 flash_mmc.img*
And inside the apalis-tk1 directory:
drwxr-xr-x 2 root root 32768 Dec 11 09:02 ./
drwxr-xr-x 3 root root 32768 Jan 1 1970 ../
-rwxr-xr-x 1 root root 594432 Dec 11 10:44 apalis-tk1.img*
-rwxr-xr-x 1 root root 16777216 Dec 11 10:44 boot.vfat*
-rwxr-xr-x 1 root root 2723 Dec 11 10:44 flash_blk.img*
-rwxr-xr-x 1 root root 2479 Dec 11 10:44 flash_eth.img*
-rwxr-xr-x 1 root root 512 Dec 11 10:44 mbr.bin*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:44 root.ext3-100*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:44 root.ext3-101*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:44 root.ext3-102*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:44 root.ext3-103*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:44 root.ext3-104*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:44 root.ext3-105*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:45 root.ext3-106*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:45 root.ext3-107*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:45 root.ext3-108*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:45 root.ext3-109*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:45 root.ext3-110*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:45 root.ext3-111*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:45 root.ext3-112*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:45 root.ext3-113*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:45 root.ext3-114*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:46 root.ext3-115*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:46 root.ext3-116*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:46 root.ext3-117*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:46 root.ext3-118*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:46 root.ext3-119*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:46 root.ext3-120*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:46 root.ext3-121*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:46 root.ext3-122*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:47 root.ext3-123*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:47 root.ext3-124*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:47 root.ext3-125*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:47 root.ext3-126*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:47 root.ext3-127*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:47 root.ext3-128*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:47 root.ext3-129*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:47 root.ext3-130*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:47 root.ext3-131*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:48 root.ext3-132*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:48 root.ext3-133*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:48 root.ext3-134*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:48 root.ext3-135*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:48 root.ext3-136*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:48 root.ext3-137*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:48 root.ext3-138*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:48 root.ext3-139*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:48 root.ext3-140*
-rwxr-xr-x 1 root root 67108864 Dec 11 10:49 root.ext3-141*
-rwxr-xr-x 1 root root 49709 Dec 11 10:43 tegra124-apalis-eval.dtb*
-rwxr-xr-x 1 root root 5470600 Dec 11 10:44 uImage*
-rwxr-xr-x 1 root root 197 Dec 11 10:44 versions.txt*
Hang on a second, the last block is showing as the same size as all the others whereas it wasn’t - it used to show 6mb! A clue…
I kind of remember that this case was broken at one point. What exact version of our BSP did you base you stuff upon?
@marcel.tx, I’m almost certain that it was the 2.7b2 (this is what I have in my downloads folder) with instructions followed from this article:
However, the version of the BSP used in this guide has now changed.
Then you are most likely affected by that issue and need to update your update scripts.
Please note that 2.7b2 is officially no longer supported as we only support stable as well as the latest beta (2.7b5 at the time of this writing) BSPs.
Ok, so I can’t add any more replies to the comments.
For the time being, am I able to copy the “*.scr” files from the “apalis-tk1_bin” directory from the 2.7b5 BSP?
You should be able to do it.
Nope, hasn’t worked - all blocks are still of the same size and now the system is reporting the same “unable to read xxx” error
No, the .img files is what you need. They can e.g. be generated using the mk-u-boot-scripts.sh script.
Thanks @marcel.tx, do I need to update the .scr files to the latest ones first?
Yes, especially if you plan to regenerate the .img files out of them .scr ones e.g. using above mentioned script.
@marcel.tx thank you, .scr files updated, .img files regenerated and the deployment image is being written to microSD as I type. Fingers crossed it works this time…
Thanks again.
Ok, so this has made things worse.
I’ve just checked the target microSD card and there are still 141 identically sized blocks. When I perform the run setupdate and run update, an error is generated on the first block:
** Unable to read file apalis-tk1/root.ext4-100 **
And from here, the system reboots.
This is because all of the files on the microSD card are ext3 and not ext4. I’m guessing that this means I’ve not updated update.sh correctly.
Yes, you should really update everything including update.sh. As mentioned before we don’t really support anything other than stable and the latest beta versions.
@marcel.tx, updated but won’t boot. I will update to 2.7b5 and try again…
What exact error message do you get upon booting? You might need to re-set your U-Boot environments to defaults resp. configure for ext3 vs. ext4 properly. I also added a note to our JetPack article about Canonical’s resp. NVIDIA’s stuff requiring some special care concerning mounting the root file system ro vs. rw needing manual tweaking if using one of our latest BSPs.
