Take the 2-minute tour ×
Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. It's 100% free, no registration required.

I am working on a project where upgrades to the Raspberry PI will over HTTP, and the Raspberry PI will not be directly accessible (cannot just swap cards).

I would like to have a partition setup like so:

  • Partition 1- /boot (contains kernels for both partitions)
  • Partition 2- / (recovery partition)
  • Partition 3- / (primary partition)

When an upgrade goes bad and the Raspberry PI gets into a reboot loop, or hangs on boot, I'd like the user to be able to press a button, which triggers a GPIO line, which would cause the boot loader to boot into the recovery partition instead of the primary partition.

The recovery partition would never be upgraded, so this would be safe.

I see a couple of options:

  1. Always boot into the recovery partition, check GPIO, then boot into primary partition of no button pressed
  2. GPIO is checked by the boot loader directly

I'm basically trying to do something similar to what routers do, where if you hold in reset while it boots you can TFTP over a new image or something.

Is this possible with the Raspberry PI? If so, is there any documentation for doing this sort of thing?

Edit:

I found this answer to this related question: Is it possible to dual boot from the SD card?

A comment on the above question led me here: http://www.berryterminal.com/doku.php/berryboot. This looks promising, but I'll have to research it more to see if I can get a GPIO read from it. If anyone has any experience with it, I'd be very interested.

share|improve this question
    
Let us know how you get on with that, looks interesting :) –  Jivings Dec 4 '12 at 8:12
    
I think I found a way to accomplish this by writing a simple 2nd stage bootloader, so I'll make sure to document it here if I get around to it. Still hoping for a simple solution though... –  tjameson Dec 4 '12 at 18:29
    
Any success with 2nd stage bootloader? –  avra Nov 27 '13 at 12:39
    
Unfortunately no, but I significantly reduced the chance of corruption using a RO filesystem: /boot (RO), / (RO), /var (RW), /home (RW). The initial problem was filesystem corruption when power is cut during boot. I'd still like like to write/find a 2nd stage bootloader though. –  tjameson Nov 30 '13 at 20:45
    
You could look at what the NOOBS (raspberrypi.org/archives/4100) bootloader for the Pi does. It might actually suit your purposes just to use it, as it provides for recovery partitions and installation. –  Fred Mar 7 at 8:11
show 4 more comments

3 Answers 3

If the error can happen any time after the system started, you can use a watchdog timer and some boot script.

The principle of this method is that whenever the system reboots without properly shut down, it goes to the recovery partition.

You need to write a script that runs every time the system starts and properly shuts down. Change /boot/cmdline.txt to recovery partition when the system starts, and changes back before properly shut down.

Then set up the watchdog timer. You can use the built-in one in the BCM2835 chip, or (if using a revision 2 board) construct your own using two GPIO pins, the reset header P6 and a 555 chip. When the critical program is started start the watchdog timer, and kick the dog periodically if the system is working properly. When the system fails the watchdog timer will be tripped and resets the processor, sends it to the recovery partition. This requires no user interaction as well and if using the built-in timer, no GPIO.

Using this method, you can also implement a reset button that will guarantee to send the system to recovery manually on a Rev. 2 board by installing a button to P6 header.

share|improve this answer
    
Your first answer is a bit closer to what I'd probably do, but I like the idea of using GPIOs in userspace and a watchdog. While I probably won't use any of the ideas wholesale, you've given me some good ideas. Thanks! –  tjameson Mar 24 at 5:54
add comment

I have a way of doing this without hacking the kernel, that involves protecting the system from an untimely reboot:

  1. Download the upgrade image, checksum it and expand it into scratch space.
  2. Change /boot/cmdline.txt so that the next time the system boots it uses recovery partition as the root block device.
  3. Install the upgrade from the scratch space and verify that it is working.
  4. If the upgrade is working, change /boot/cmdline.txt back.
  5. If required, reboot.

A failed upgrade will cause the system to be booted into the recovery automatically. No GPIO needed.

share|improve this answer
    
The only issue here is (depending on the system) a fault may be detected hours after the update completes, at which point the user has no option to revert to the recovery partition. –  Dan Nixon Mar 18 at 9:12
1  
@DanNixon I am posting another answer to resolve this new issue. –  Maxthon Chan Mar 18 at 9:28
add comment

Also, there is a third possible solution, but it will require you to dissect initrd of some PC version of Linux distribution to figure out how the syscall pivot_init() works. I am not sure if the kernel of Pi have this syscall. If it does, this method is possible, no kernel hack is required as well, and it uses one GPIO.

To do that, you will need to write a custom init program in the production system. check if the GPIO is on. If so, pivot_root() to recovery. Then exec() the original init so that the system continues to boot. You can, in the production system, figure out a way to keep this GPIO-watching constructed init running side-by-side (PID=2) with the original init (PID=1) and keep an eye on the GPIO and reboot to recovery if the button is pressed.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.