User avatar
liz
Raspberry Pi Foundation Employee & Forum Moderator
Raspberry Pi Foundation Employee & Forum Moderator
Posts: 5202
Joined: Thu Jul 28, 2011 7:22 pm
Contact: Website

Re: Hexxeh's automatic firmware updater

Thu May 10, 2012 6:01 pm

rpi-updater has already had a mention on these forums, but if you've not come across it yet, I've put a short post about it on the front page now it's reached maturity.
Director of Communications, Raspberry Pi

User avatar
nick.mccloud
Posts: 804
Joined: Sat Feb 04, 2012 4:18 pm

Re: Hexxeh's automatic firmware updater

Thu May 10, 2012 7:23 pm

Works a treat for me - been using it on both standard and hardfloat Debian. Highly recommend it as a simple and quick way of updating.

vman81
Posts: 31
Joined: Wed Nov 02, 2011 11:13 am

Re: Hexxeh's automatic firmware updater

Thu May 10, 2012 7:35 pm

Seemed to work fine, but is there a firmware changelog somewhere? Is there anything noticeable I should see?

Hexxeh
Posts: 91
Joined: Thu Apr 05, 2012 3:07 pm
Contact: Website

Re: Hexxeh's automatic firmware updater

Thu May 10, 2012 9:48 pm

vman81 said:


Seemed to work fine, but is there a firmware changelog somewhere? Is there anything noticeable I should see?


The tool uses a Git repo as it's remote store for firmware, you can look at the commit log:

https://github.com/Hexxeh/rpi-firmware/commits/master

I try to give more user-friendly descriptions of whats changed, but here's the original official firmware repo the files come from:

https://github.com/raspberrypi/firmware/commits/master

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

Re: Hexxeh's automatic firmware updater

Fri May 11, 2012 2:50 am

Nice I don't have a RPi yet, but as a bit of a BASH-scripter I had a quick play with it on my regular Linux box (after hacking out the auto-update and must-be-root parts). Here's my feedback:

The auto-update part is quite neat The _interpreter part seems a bit pointless though, given that /bin/bash is hard-coded 3 other times in that function? I removed all the _interpreter and _payload lines, and changed the wget to just --output-document="$_tempFileName"

Very minor thing - there seems to be an over-use of ${} style variable quoting where it's not needed.

Should a backup of the /lib/modules directory be made similar to what's done for /boot ?

I created a separate function to prevent the same lines being repeated near the bottom of the script:


function do_update {
    update_firmware
    update_modules
    update_sdk
    set_split
    finalise
    echo "If no errors appeared, your firmware was successfully $1"
}


and then do_update "updated" and do_update "setup"

Just after the check-for-root I added:


if [[ $FW_RAM -ne 224 ]] && [[ $FW_RAM -ne 192 ]] && [[ $FW_RAM -ne 128 ]]; then
    echo "RAM value must be one of: 224, 192, 128"
    exit 1
fi


I clarified the memory-display line: echo "Using RAM/GPU memory split of ${FW_RAM}MB/${FW_GPU}MB"

Where you've used $GITCMD it really ought to be eval $GITCMD (or better would be to change it to git $GITARGS ... )

The bit where you check $RETVAL != 0 ought to be $RETVAL -ne 0


Given that the local git repo is "hidden", would it be better to just do a git pull rather than a fetch and then a merge ?

I made some quoting-changes so that all the commands would work with spaces in the directory names - but as you're always running from /root and /boot on the RPi these aren't relevant outside of non-Pi testing.

Feel free to use/abuse/ignore any or all of these suggestions

Other suggestions - maybe you could get the distro-name from /etc/issue and only display the relevant distro-specific package install instructions?

Would it be possible to determine if the "git update" doesn't actually involve any file-changes (i.e. same revision before and after), and if so tell the user that they're already up-to-date, rather than blindly overwriting the files every time the script is run?

Maybe it'd be worth adding a "A reboot is needed to activate the new firmware" type message at the end?

Slighty-related: Dunno if you'd be interested by http://www.raspberrypi.org/arc.....ment-20968

Hexxeh
Posts: 91
Joined: Thu Apr 05, 2012 3:07 pm
Contact: Website

Re: Hexxeh's automatic firmware updater

Fri May 11, 2012 1:44 pm

Changes you've detailed look good, if you want to put them into a commit and submit a pull request, that'd be great. My Bash is patchy at best, so I've probably not done things the right way in places, as you've pointed out.

The fetch/merge is there because using pull brought up a commit message window for the merge, which I couldn't get rid of by passing any options to pull. I just tend to use ${} everywhere so that I don't forget to use it where it is needed. Seeing a mix of the two looks messy to me, too.

It's not the most user friendly of scripts, but the changes you've detailed improve that somewhat, and are very much welcome.

User avatar
jojopi
Posts: 3141
Joined: Tue Oct 11, 2011 8:38 pm

Re: Hexxeh's automatic firmware updater

Fri May 11, 2012 2:39 pm

Why does it get the firmware from the Hexxeh repository instead of raspberrypi?

Should it not update arm{128,192,224}_start.elf?

Hexxeh
Posts: 91
Joined: Thu Apr 05, 2012 3:07 pm
Contact: Website

Re: Hexxeh's automatic firmware updater

Fri May 11, 2012 2:40 pm

It gets the firmware from my repo because if you downloaded the official repo, you'd be downloading a bunch of files you don't need. I just copy the official repo, remove things you don't need and rearrange it into a format it's easy for the tool to work with.

It does update arm*.elf already, too.

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

Re: Hexxeh's automatic firmware updater

Fri May 11, 2012 2:48 pm

My git skills aren't up to the level of "pull requests" and as I don't have a RPi for testing, I was only offering suggestions rather than a completely new version of the script

Re: the git pull asking for a merge commit message - wouldn't that only happen if the files in /root/.rpi-firmware have been edited? Which the average user isn't likely to be doing? (I could be wrong, never used git much)

This comment provides an interesting use-case for allowing the rpi-update script to run in an "offline" mode, i.e. updating files in /mnt/sd_card/boot/ etc. using a regular Linux PC. But I dunno how you'd add any extra command-line options given the way the script auto-updates itself by setting command parameters in updateScript.sh - in fact it might be better to have a separate rpi-offline-update script as I guess you wouldn't want to be running depmod or ldconfig !

User avatar
jojopi
Posts: 3141
Joined: Tue Oct 11, 2011 8:38 pm

Re: Hexxeh's automatic firmware updater

Fri May 11, 2012 2:55 pm

Hexxeh said:

It does update arm*.elf already, too.
It only updates *.bin *.img start.elf.

Hexxeh
Posts: 91
Joined: Thu Apr 05, 2012 3:07 pm
Contact: Website

Re: Hexxeh's automatic firmware updater

Fri May 11, 2012 2:58 pm

jojopi said:


Hexxeh said:


It does update arm*.elf already, too.


It only updates *.bin *.img start.elf.


Ah, yeah, it doesn't update the arm*.elf files in boot, but it copies an updated start.elf from it's own store. I'll add a call to have it copy the other versions too.

AndrewS said:


My git skills aren't up to the level of "pull requests" and as I don't have a RPi for testing, I was only offering suggestions rather than a completely new version of the script 

Re: the git pull asking for a merge commit message - wouldn't that only happen if the files in /root/.rpi-firmware have been edited? Which the average user isn't likely to be doing? (I could be wrong, never used git much)

This comment provides an interesting use-case for allowing the rpi-update script to run in an "offline" mode, i.e. updating files in/mnt/sd_card/boot/ etc. using a regular Linux PC. But I dunno how you'd add any extra command-line options given the way the script auto-updates itself by setting command parameters in updateScript.sh - in fact it might be better to have a separate rpi-offline-update script as I guess you wouldn't want to be running depmod or ldconfig !


If you have a version with your changes somewhere, upload it and I'll merge the changes in.

Even without changes, I kept getting asked for a message. In the event a user accidentally adds files, the current setup will prevent a commit message window appearing.

The best way to do an offline update without hacking the script to death might be just to chroot into the SD card they have, make sure /boot is mounted and then run the script as normal. You'd need qemu-arm-static in there to let you chroot, but it should work.

Tavalin
Posts: 59
Joined: Mon Apr 16, 2012 9:53 pm

Re: Hexxeh's automatic firmware updater

Fri May 11, 2012 4:54 pm

Hi Hexxeh,

Firstly good work with this.  I tried it last night and it worked without any problems.

I do have a question though, when I ran it it said it was updating with softfp libs.  Now I saw someone else's output from the update and it was updating with hardfp libs.  What's the difference?  How can you get it to get the hardfp libs?

Thanks

Hexxeh
Posts: 91
Joined: Thu Apr 05, 2012 3:07 pm
Contact: Website

Re: Hexxeh's automatic firmware updater

Fri May 11, 2012 5:06 pm

Tavalin said:


Hi Hexxeh,

Firstly good work with this.  I tried it last night and it worked without any problems.

I do have a question though, when I ran it it said it was updating with softfp libs.  Now I saw someone else's output from the update and it was updating with hardfp libs.  What's the difference?  How can you get it to get the hardfp libs?

Thanks


The libs used must match the system you're running on. At the moment, unless you're running Raspbian, this will always be SoftFP.

User avatar
AndrewS
Posts: 3625
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
Contact: Website

Re: Hexxeh's automatic firmware updater

Tue May 15, 2012 11:40 am

Hi Hexxeh, did you get the email I sent you a couple of days ago?

Hexxeh
Posts: 91
Joined: Thu Apr 05, 2012 3:07 pm
Contact: Website

Re: Hexxeh's automatic firmware updater

Tue May 15, 2012 12:22 pm

Replied now, apologies for taking so long to get back to you.

Return to “General discussion”