-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
USB keyboard not detected (v1.22) #15
Comments
I can replicate this. It's When using the previous version of 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... |
IMHO, the CI code should not download the latest version of those files. it should always get a specific version. |
@rgl: I don't see why we shouldn't. We have no idea of bugfixes and improvements that may happen in @jp-coding: Please re-download the archive. It should be working now. |
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. |
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
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.
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.
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... |
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. |
That's a good point. I wasn't aware of that. |
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. |
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). |
I've set up a SD card with the UEFI firmware v1.22 this evening and my Raspi 3 boots just fine into Grub. I can however not make any choices as my USB keyboard is not working/ not detected. I've rebooted multiple times to check all four USB ports with no success.
The text was updated successfully, but these errors were encountered: