What a mess: `rpiboot`

[Eagle3386]

Describe the bug

1. rpiboot --help's output lies:

• There's no recovery next to it to flash!
• Besides RPi docs, even rpiboot itself still claims flashing that while next to it, within README.md, you're told that you're supposed to execute rpiboot -d mass-storage-gadget64 & -d recovery is declared deprecated.

And even fixing aforementioned, 2nd flaw manually on his local machine (which another user did as you guys failed to provide fixes in due time), doesn't solve the issue:

I've installed rpiboot using the Windows Installer. But that does not give me all the files in the Raspberry Pi directory on my (Windows 11) computer. I've downloaded all files in /recovery manualy, just to find out it uses symlinks to all other folders. Leaving me a kind of clueless. Running rpiboot.exe -d recovery just sits still at "sending bootcode4.bin". I guess because of the file missing after following the symlink.

Great stuff, that Windows Installer. Great job, RPi. NOT!

2. The whole process of updating the bootloader firmware is outrageously unacceptable. What's (almost) a 1-stop shop/click experience with every other manufacturer, RPi manages to make even the most simple stuff like a firmware update overcomplicated - we're talking about rocket science here & I didn't even start to overexaggerate on this mess of a piece of software!

3. Given @Vishwasrao1's comment in another issue: yes, RPi's software is open-source. But that never grants any hardware manufacturer the right to release crappy software & then even dare to ask the community to fix it for them - we're talking about basic stuff that's FUBAR (missing recovery folder, outdated --help instructions, etc.) while it should've never required a fix & instead be correct from its very first release after the changes were made.

4. Given @pelwell's comment in another issue: my attitude is perfectly fine - it's yours & especially RPi's that's not only wrong, but unbelievably rude: you guys not only dare to release such crap software, but even leave it unfixed & try to reject those reminding you.

Here's another, very friendly reminder: RPi charges money for that combination of hard- & the not-so-free software parts, so - by EU law - I'm granted quite a bunch of customer rights. One of them is: faulty crap has to be fixed. By RPi's people, not by your customers - we're only entitled to help, if you kindly ask for our help & especially you didn't do to begin with.

To be clear: I'll give a damn about what you guys think about me or my "attitude". You released crap, you created rocket science where a simple CLI command should do. That alone is a shame almost unbearable. Now go, think about that.
Afterwards, think about it again. Then deliver release(s) that fix this mess to something actually usable - in conjunction with an apology for stealing us customers our free time, stressing our nerves & causing all that mess in the first place.

Lastly, after being back to a way more humbled level, you're then allowed to join the talk about attitude.

Steps to reproduce the behaviour

See above.

Device(s)

Raspberry Pi CM4

Compute Module IO board.

Home Assistant Yellow PoE, revision 1.3

RPIBOOT logs

Don't know how to get them, please explain.

Kernel logs

Don't know how to get them as I'm on Windows & rpiboot doesn't offer to execute said command, please explain.

Device UART logs

Don't know how to get them, please explain.

[P33M]

Please open a command prompt (WinKey+R -> cmd) and post the first line that appears in the terminal.

[pelwell]

A good template for an issue/bug report is:

1. what you did,
2. what you expected to happen, and
3. what actually happened.

Once we've established these facts we can try to reproduce your findings. Bear in mind that we're not especially interested in how it makes you feel, and the more you write, the more likely we are to miss something important, so keep it focused.

[Eagle3386]

Please open a command prompt (WinKey+R -> cmd) and post the first line that appears in the terminal.

There you go: Microsoft Windows [Version 10.0.26200.8655]

A good template for an issue/bug report is:
1. what you did,

As already told in the repro-steps of the other issue:

• Downloaded & installed latest Windows Installer of rpiboot.
• Opened Windows Terminal running latest PowerShell, switched to rpiboot's directory, tried to execute rpiboot -d recovery which failed, followed by running rpiboot --help which did succeed but its information lies.

2. what you expected to happen, and

Flash the darn recovery as multiple sources (Home Assistant, several blogs, etc.) claim this process in turn updates the bootloader firmware to the latest version.

3. what actually happened.

• Flashing failed.
• Researching brings up nothing but lies regarding rpiboot's usage, its Windows Installer release's contents are missing files (no-one actually knows why it's dropped from that release while others even claim those are only missing from the Windows one, not the others).
• Downloading the repo's full code & copying the recovery folder manually into rpiboot's folder & then running rpiboot -d recovery does start, but runs forever, leaving Sending bootcode.bin as the last reported progress:

NOTE: It's a absolute no-go to not include any form of progress bar (dots, percentage value, etc.) here.
This must be added - together with a working rpiboot executable which also has its --help output corrected - for the next release. No question about it.

Once we've established these facts we can try to reproduce your findings. Bear in mind that we're not especially interested in how it makes you feel, and the more you write, the more likely we are to miss something important, so keep it focused.

Bear in mind, it's especially interesting to you ("you" as in "all RPi people", but this time even twice, i.e. "you, Phil") as it's of utmost importance for you to really understand the frustration, time loss & even damage your code caused thus far.
That's because without that understanding, you probably only consider this a "usual" bug that gets a (maybe trivial) fix.

This. Is. Not. The. Case. Not. The. Slightest!

After fixing this mess in rpiboot, all your non-Linux users probably have to set up their whole Home Assistant setup anew - in my case you've got to thank "Jorg" of the HA community to remind me of an extra full backup prior to running rpiboot. But that only saves me about half the work.

The other half is this: work towards fixing this bug (including probably multiple attempts, giving feedback, etc.), then - finally - update my CM4's bootloader firmware (includes making sure you guys develop a working 1-stop shop update experience for the next firmware update which does NOT mess with user data on the eMMC at all, leaving everything intact even for regular users), then flashing my Home Assistant Yellow with the latest HAOS again, then waiting until its first boot gets to the point where I can restore my backup, then wait, then reboot, then wait again, then check everything is still working as it should.

Put simply: even ignoring all this prior GitHub issue time, I've got at least 3-4 days of work ahead until HAOS will run again as it should - as a papa, husband, regular employee & human being this is a nightmare compared to what a brutally simple CLI command was (and is!) supposed to do: update a darn bootloader firmware.

For the sake of world's evolution in IT, please keep this in mind for every future release of any RPi software.

Thanks a zillion times. From millions of users. Especially those far less advanced than me & that's with me considering myself only "semi-advanced" in terms of Windows, let alone Linux stuff!

[pelwell]

Is "the windows installer doesn't include all the loader variants that the docs refer to" a fair summary of the issue?

[Eagle3386]

No, but

Windows installer lacks what rpiboot --help claims usable (recovery image)

&

rpiboot lacks proper progress reporting upon any longer action

would.