For Raspbian and derivatives
The firmware is installed by the raspberrypi-bootloader package. It has the revision in the changelog:
zcat /usr/share/doc/raspberrypi-bootloader/changelog.Debian.gz | head
raspberrypi-firmware (1.20150214-1) unstable; urgency=low
-- Sun, 15 Feb 2015 11:19:20 +0000
For rpi-update
If you used rpi-update to get firmware, it creates a /boot/.firmware_revision
containing the commit hash.
cat /boot/.firmware_revision
5b0cbedacf45e111f02d925fa5b1cec9041fb279
For everything else
If you have a mystery firmware not managed by any particular tool, the date given by vcgencmd version
is a good indicator of the firmware version. The first commit with a date more recent than that of the running firmware is most likely the same one. You can then use strings
to verify the build version of the firmware from that commit without installing it:
strings start.elf | grep VC_BUILD_ID_VERSION
VC_BUILD_ID_VERSION: 2d5ad04b63af4233440c3f7c8587108223201102 (clean)
strace vcgencmd version
implies it is getting this value from/dev/vhciq
, i.e., kernelspace. Since much of that stuff, including I think thevcgencmd
itself, is not open source, there may be no way to know where that version string comes from or to correspond it to the public repos, which contain only the compiled binaries.vcgencmd
is the "firmware version", as opposed to the version of the command application itself. These are two distinct things that may be developed in relation to each other, but are still independent entities.start.elf
, and a revision/commit of the repo may not always include a new version ofstart.elf
. So if you want some kind of table that maps the versions of all the pre-compiled, closed source artifacts (that presumably have separate private repos) to "revisions" of the public repo, methinks you are going to have to email someone about it.