latest u-boot broken on PG2 board

[fmoessbauer]

Since commit 5ac8edaca2fd29c87c2bd4922b464b31a6dbd674 at least the following board is no longer able to boot. When flashing this revision, no data is sent via UART.

• 6ES7 647-0BA00-0YA2
• FS: 01 06.2021

To rule out any flashing issues, I also erased the flash once before flashing the new firmware using the dpcmd -u sequence. But this did not make a difference. This has been confirmed on two IoT2050 boxes with the mentioned model number.

While testing I also found out that the latest dpcmd version (c7ae31) is broken on the Dediprog SF100 programmer:https://github.com/DediProgSW/SF100Linux/issues/54. The last know-to-be working version of dpcmd is c76e10f.

Please note that this issue is especially critical, as this firmware can also be flashed from userspace and once done, the box is bricked and can only be recovered with a programmer. In combination with the Dediprog bug this makes it very hard for average users to unbrick it again.

[jan-kiszka]

"FS: 01" should be PG1. Why do you think it's PG2? And it's a Basic variant, right?

Regarding the SF100Linux issue: Will you follow up on it upstream? I'm on 4aa428 here (local mtda recipe), so I didn't notice this yet.

[jan-kiszka]

FWIW:

root@mtda:~# dpcmd --vcc 2 -v -u iot2050-pg1-image-boot.bin 

DpCmd Linux 1.12.11.07 Engine Version:
Last Built on January 7 2023

Loading file, please wait ...(iot2050-pg1-image-boot.bin)

Auto Sequences, please wait ...
Device 1 (SF602412):
34.1s elapsed

Device 1 (SF602412):
Automatic program OK

Checksum(whole file): 4AF0C5CE
Checksum(Written part of file): 4AF0C5CE

Verifying, please wait ...
Device 1 (SF602412):
8.9s elapsed

Device 1 (SF602412):
Verify OK

And, obviously, if your device turns out to be PG1, flashing PG2 firmware will not work.

[fmoessbauer]

Thanks for the quick reply, @jan-kiszka .

Just tested it with the PG1 version. This only worked after manually erasing. Before that I still did not get any output. Very strange. But now I can see the bootloader and boot again. However, when I call fw_printenv I get configuration file wrong or corrupted. Might be a different issue, but in the past that worked.

While this turned out not to be a technical issue but a user mistake, can we please try to improve the documentation. I cannot find any map between the FS<x> and the PG<x> versions (plus the additional complexity with Basic and Advanced). In addition, with older versions of the firmware it was possible to at least boot an FS1 box (model from above) with a PG2 firmware. By that it could well be that people believe they have a PG2 while they actually have a PG1. All that is really frustrating and takes a lot of time.

Another problem is that the u-boot build contains a timestamp which breaks the reproducibility. By that, just comparing the checksum of the bin files is not helpful. We should really make the build bit-by-bit reproducible and use the SOURCE_DATE_EPOCH variable which is automatically set to the latest debian changelog entry.

[jan-kiszka]

Have a look at https://support.industry.siemens.com/forum/de/en/posts/overview-about-fs-states-of-iot2050/273280/?page=0&pageSize=10 for the FS mappings.

Regarding reproducibility: That's is not yet in scope, but you can send patches if you see mistakes.

[fmoessbauer]

Have a look at https://support.industry.siemens.com/forum/de/en/posts/overview-about-fs-states-of-iot2050/273280/?page=0&pageSize=10 for the FS mappings.

Thanks for the pointer, but this is rather bad source: A forum where you have to login to even be able to read things. Search engines will never pick that up. And things like the mapping need to be stated in either the official Siemens docs, or (better) in the u-boot readme in this repo. I won't open an MR for this topic, as I can only copy the information from the forum. But I would really appreciate if a maintainer could add it. @BaochengSu , @AsuraZeng .

Regarding reproducibility: That's is not yet in scope, but you can send patches if you see mistakes.

I briefly had a look into the issue. It's actually an ISAR bug as the add_deb_changelog makes the build non-reproducible both across builds, as well as on partial rebuilds. Surprisingly, the tries to make the changelog reproducible are exactly what breaks reproducability. Will report that to ISAR and likely send a patch as well.

[jan-kiszka]

@bergmanu

[BaochengSu]

@bergmanu Could we add the FS type information in the wiki of this repo?

Or to prevent double maintenance, one root source of the information then share the link of it.

[fmoessbauer]

Regarding reproducibility: That's is not yet in scope, but you can send patches if you see mistakes.

I briefly had a look into the issue. It's actually an ISAR bug as the add_deb_changelog makes the build non-reproducible > both across builds, as well as on partial rebuilds. Surprisingly, the tries to make the changelog reproducible are exactly what breaks reproducability. Will report that to ISAR and likely send a patch as well.

Fix sent to ISAR ML: https://groups.google.com/g/isar-users/c/zaWU_4eNilk

[BaochengSu]

@fmoessbauer I have put the forum link into the wiki, check https://github.com/siemens/meta-iot2050/wiki#device-variants-pgx-and-functional-states-fs

@bergmanu I've extracted the FS&PG info from the card list to a separate section in the wiki.

[fmoessbauer]

@BaochengSu Thanks! Then I'm fine with closing this.