Dear community,
We are trying to load generated config block in mmcblk0boot0 and want to know if we are on the good way.
By editing create_configblock.sh from Here cause awk is not available on our platform, we are able to have a file conform with the original script (sha1 are equals).
Now, we are expecting that if we load the generated file there :
<------------------------ /dev/mmcblk0boot0 ------------------------------>
0-------2------------138---------------4079 -----------------4095------------4096
| |SPL |u-boot.img |u-boot Environment |Toradex config |
------------------------------------------------------------------------------
By doing :
dd if=configblock.bin of=/dev/mmcblk0boot1 seek=4095 bs=1
the configblock will be restored, is that correct ?
Hello @Vincentt,
may I ask what is the reason for manually creating and overwriting the config block? This is an operation that shouldn’t be necessary in most cases.
The procedure you described to write the config block is mostly correct, but the way that you are doing can break if the eMMC on the modules is changed to a different model (because of supply chain issues we had to do this on several of our modules already). The reason for that is that the boot partition size can change between models so using a fixed offset from the beginning of the chip will certainly not give consistent results.
Best regards,
Rafael Beims
Hi @rafael.tx ,
We have some devices that have to be updated, with some heavy features such as re-partitionning emmc to have a symetric system, for update purpose.
The best way to do it, for our point of view, is to boot the system with TEZI and simply proceed to emmc flash with our custom image to have the benefits of TEZI features (that let’s say, work like a charm).
Unfortunately, we have discovered that some of our devices have not been correctly flash during assembly process, i.e the image flash process of TEZI has been aborted during SD cart formating because of a misconnection of it (sd card not present). However, the rest of emmc has been correctly written so our image boots like a charm. The “dark” side of it is that it seems that, cause the TEZI process has been aborted, the config block has not been correctly written/updated.
So now, by booting on TEZI to update those devices, we have the famous error “Unable to read config block” from TEZI UI.
That is the story ^^
By now, could you explain please why the raw config block read by TEZI is different than the one generated with create_configblock script ? The fields seem to be at difference places :
The script generates configblock.bin with header / mac addr serial / product desc/ dummy bytes (ff)
The raw file read looks like : header / product desc. / mac addr serial / dummy bytes (00)
For the address offset, maybe we can write from the end of the emmc, as described in fw_envconfig file to avoid emmc corruption ?
Thank you,
Vincent
Hi @Vincentt !
Thanks for the answer.
I have a question for you that might be a stretch: have you considered using TorizonCore?
TorizonCore is developed by Toradex for our modules and has already the over-the-air software stack in place for you to use.
Also, you will be able to use online or offline updates.
Best regards,
The concerned devices are already certified with our own image, it will be too heavy for us to switch on TorizonCore. But maybe on new generation ^^.
Have you some answers about my last message ? I think we are close to have something that works ^^
Are there a lot of modules in this failed state? I ask because if there are not many I think the best approach would be to restore the config block of these modules using Tezi itself. After you receive the message that the config block is invalid it should open a form so that you can manually type in the information.
If the config block is lost you would need to type in some information manually anyway (for instance the serial number of the module).
These scripts for creating the config block are old and unmaintained at this point, all this functionality is handled at tezi at this point.
Hi @rafael.tx,
We do not know how many are in this state before launching the upgarde process. Fortunately, we have for each of them the datas of module installed (we have recorded the data contents in datamatrix of each module). So, we should anticipate and generate the config block easily. Now the point is how to restore it.
The people in charge of upgrading the system are not familiar with IT world and do not have any material to proceed with TEZI UI. More, they have to go at different places to have access to the devices.
Is there a possibility to bring us some technical support on this topic ? I understand that you do not want to open TEZI code source (and we do not request it), but the support could be done with some confidentially aspect if you wonder.
BR,
Vincent
I quickly looked through the code and it seems to me that the order of the tags should not matter. If the file generated by the script includes valid tags with valid data (i.e. the correct PID of the module, the mac address) it should be fine.
You could test this in one of your development modules. Just write the config block you generated with the script to the last sector of the boot partition and run tezi to check if it detects an error on the config block or not. If everything is OK tezi should just run as normal.
Hi @rafael.tx
Ok, let’s give it a try so, thank you.
Hi all,
Question : To avoid this situation in the future, is this eventually correct to swith from :
"name": "mmcblk0boot0",
"erase": \**true\**,
"content": {
"filesystem_type": "raw",
"rawfiles": [
{
"filename": "SPL",
"dd_options": "seek=2"
},
{
"filename": "u-boot.img",
"dd_options": "seek=138"
}
]
}
To :
"name": "mmcblk0boot0",
"erase": \**false\**,
"content": {
"filesystem_type": "raw",
"rawfiles": [
{
"filename": "SPL",
"dd_options": "seek=2"
},
{
"filename": "u-boot.img",
"dd_options": "seek=138"
}
]
}
Hi,
Tested on apalis-imx6 1.1 A/B/C/D/Y/Z version, by writing correctly in the last sector, TEZI is happy to find well formatted data.
Thaks for you support.
1 Like
Hi @Vincentt ,
Sorry for the delay.
Glad that it worked.
If you have more questions feel free to reach out.
Best Regards
Kevin
