USB keyboard not detected (v1.22) about rpi3 HOT 9 CLOSED

I can replicate this.

It's start.elf + fixup.dat issue (which are files we don't create but obtain from the Raspberry Pi Foundation).

When using the previous version of start.elf and fixup.dat with the new firmware, everything is fine, but with the current ones, not only does USB keyboard/mouse not work but we get garbled output on the console, which most likely comes from start.elf.

I guess a quick workaround is be to update the current archive to use the previous version while we try to figure out how the Pi Foundation boot code is interfering with the UEFI firmware...

from rpi3.

IMHO, the CI code should not download the latest version of those files. it should always get a specific version.

from rpi3.

@rgl: I don't see why we shouldn't. We have no idea of bugfixes and improvements that may happen in start.elf and that may be relevant to us. It'd be like us telling users of the UEFI firmware that they should stick with a specific version. I'd much rather try to figure out what's wrong than deprive users of potentially important improvements because we are holding start.elf back...

@jp-coding: Please re-download the archive. It should be working now.

from rpi3.

Using the latest version of anything is a thin ice walking, sometimes it brakes and you go under. Using a specific version means you know what is inside your release. And you know how to reproduce the build. And it's the same reason you are not using the latest version of edk2 I guess. You only want to depend on a known/stable/tested version, which rpi firmware has. So, maybe this should at least only depend on the latest stable version (known at the time of this repo version build) of the rpi firmware.

from rpi3.

sometimes it brakes and you go under

No, sometimes it breaks and we address it. If anything it helps us identifying issues long before someone comes to us and says "I updated my start.elf and fixup.dat because it's supposed to include fixes or improvements for something I need, and now it doesn't work".

And you know how to reproduce the build.

That's a non issue. For one thing, there are timestamps in the firmware, so reproducing builds exactly is not going to happen unless we address that. But outside of the timestamps, you just have to know the time the build was issued to know which of the firmware files were used, so if someone is interested to reproduce our builds, including picking up the same blobs we use, they very much can. The Pi Foundation does not hide the old blobs once they release new ones, they are very much still available from their firmware repo.

And it's the same reason you are not using the latest version of edk2 I guess.

Oh but we very much do. All of the repos we depend on for the build, including edk2, are updated to latest before we issue it. And that's for the same reason as above: in order to pre-empt any recent changes introducing breakage rather than waiting for sporadic reports from users that may never come, if it's just a handful of users trying a blob update and silently reverting when they find it doesn't work... The idea here is that we can offset some of the testing to our users, rather than have to run a comprehensive battery of tests every time we push a release, which would otherwise require time that we genuinely don't have. So that's what we are doing because, as you have seen, we can usually quickly and easily sort something up so that our users aren't left stranded, if they do report issues.

depend on the latest stable version (known at the time of this repo version build) of the rpi firmware.

Every rpi firmware is supposed to be stable. The firmwares blobs published by the Pi Foundation are not supposed to be experimental, so breakage is supposed to be the exception rather than the rule, which is why we really want to investigate and help fix issues, hopefully with the help of the Foundation, when that happens. It's much better than have to maintain a spreadheet of "blobs from YYYYMMDD: good, blobs from YYYYMMDD + N: bad" and potentially end up, in 5 or 10 years time, using outdated blobs because we chose to stick to the last known version that seemed to work and never investigated anything...

from rpi3.

Sorry, I didn't understand that the point of this repo is for testing the latest releases of everything. Looking at it that way, I'm perfectly fine with it.

About the rpi firmware versions, they do have a stable and experimental versions. At least they have a master and stable branches.

from rpi3.

they do have a stable and experimental versions.

That's a good point. I wasn't aware of that.
Do you know if these can be identified from the commit log or do we have to look elsewhere to find out which are stable and which are experimental?

from rpi3.

Ah, I see they are using branches: https://github.com/raspberrypi/firmware/commits/stable

That's very good to know. If we're running into too many issues with master we may switch to using that.

from rpi3.

I do not known much more details; I think it would be good if they tagged theirs releases, but I didn't look into it further than noticing they have several "release channels". I've start noticing it at https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware (as different files/directories where they use some kind of versioning in the filenames) and at the https://github.com/raspberrypi/firmware (as different branches).

from rpi3.