radxa-RockPi4: Fix identifier for RockPi 4 model A/B

[CRTified]

This closes #122

I'm really confused about this. Will test the release files for the 4C, too (EDIT: 4C works fine).

[samueldr]

Hmmm, the main discrepancy can be observed in the directory name, and that identifier. I probably copied from the directory name.

I also think that this check needs a bit of rework. Not sure what should be done. That check comes from an early brick of mine, where I wrote the Platform Firmware of a compatible-enough, but not actually working board on the wrong board.

Writing things in Hush is a real pain, so asking an additional question (do you want to continue anyway?) will be painful. Though we do have Nix at our disposal to somehow smooth over this.

Anyway, I'm thinking that a Linux-based installer is going to be the more robust solution, as anyway it would be helpful to provide a sort of "doctor" utility, that can look at the current state of things for troubleshooting purposes. E.g. the currently installed Platform Firmware.

[CRTified]

Hmmm, the main discrepancy can be observed in the directory name, and that identifier. I probably copied from the directory name.

Support for the RockPi4 was added by me in #85 - if you look at the git blame and history, both the path and the identifier were set by me. So you did nothing wrong as you didn't change anything. And that's what causes my confusion, because I was able to flash the version from the PR (ad7aabc) without problems.

That check comes from an early brick of mine

I think that this type of validation is important to prevent users that can't help themself from bricking their hardware.

Asking an additional question

That might be a first good solution (similar to some partitioning tools where you have to type uppercase YES).
I also mentioned in #122 that using some normalization might be helpful. Just comparing case-insensitive remains hopefully precise enough to prevent wrong flashes.

Linux-based installer

Would be great, but especially for the RockPi4 it's a bad situation: The spi-nor is not supported (yet) in the kernel, so there is no way of communication with it from kernel/userspace.
I know that it is possible (I successfully flashed Tow-Boot via mtdutils), but it has a strict dependency on kernel support for the flash.

[samueldr]

Just comparing case-insensitive remains hopefully precise enough to prevent wrong flashes.

In hush :)

[samueldr]

I think this is blocked on figuring out a solution for mismatched identifiers. Or am I missing something?

[CRTified]

Yes and no, I think. On one hand, this PR did fix the mismatching identifier and I don't know whether it might just be caused by some u-boot internal things(?), on the other hand, it would be great to have some way of having the identification process in a more reliable shape to be strict enough to prevent problematic flashing, while allowing for some tolerances (like capitalization).