Add support for multiple simultaneous OS installs (i.e. OS multibooting) about noobs HOT 8 CLOSED

PM_RSTS contains some bits that don't get reset across a soft reset. So we can test them when we start bootcode.bin and choose where to load the boot files (config.txt, start.elf, cmdline.txt and kernel.img).

bootcode.bin just knows to boot from the second partition, if that's an extended partition it will choose the first logical partition inside it.

To change this we'll have to use more of those bits to communicate the partition number.

Gordon

from noobs.

The bootcode.bin change that enables booting from /dev/mmcblk0p5 was here: raspberrypi/firmware@1c339b1 (firmware: add support for booting from alterative partition)

I'm guessing raspberrypi/firmware@4f2a7b9 (bootcode.bin: Support loading recovery.elf) means that it'll load recovery.elf in addition to (or in preference to?) start.elf (recovery.elf is just a renamed start.elf https://github.com/raspberrypi/noobs/blob/master/BUILDME.sh#L36 )

The "soft reboot" code in NOOBS is here: https://github.com/raspberrypi/noobs/blob/master/recovery/main.cpp#L34
And there's documentation about RB_AUTOBOOT here: http://linux.about.com/library/cmd/blcmdl2_reboot.htm

Up until now I'd assumed that it was the RB_AUTOBOOT flag that was causing bootcode.bin to load start.elf from the alternative partition, but now that I look it seems it's just the "standard" reboot flag. So I'm gonna guess that it must be during the boot of recovery.elf that 'something' gets set so that start.elf gets loaded from /dev/mmcblk0p5 instead of /dev/mmc0blkp1 after the next reboot.

In early versions of NOOBS from before raspberrypi/firmware@06f6c90 (firmware: disable splash screen when booting from second partition) the rainbow-square actually got displayed between rebooting NOOBS and loading e.g. Raspbian.

...
Ah! Just done a bit more searching and the recovery.cmdline https://github.com/raspberrypi/noobs_binaries/blob/master/recovery.cmdline includes reboot=q and it's this that triggers the alternative boot in the next call to reboot() https://github.com/raspberrypi/linux/blob/rpi-3.6.y/arch/arm/mach-bcm2708/bcm2708.c#L665 (which ties in with the PM_RSTS comments from Gordon).

It's great when (nearly) everything is open-source, allowing you to do this kind of in-depth "detective work" :-)

I'm currently away from my RPi so can't test, but I think that this all means that if you added reboot=q to the cmdline.txt on /dev/mmcblk0p5 then you'd be unable to warm-reboot into NOOBS, you'd only be able to access NOOBS from a cold-boot. (assuming that this isn't in fact the behaviour already)

from noobs.

Why do we need multiboot? BerryBoot has been around a while and does this already. NOOBS is designed for noobs, not power users.

from noobs.

I'm back home again with access to my RaspberryPi, so I've just done some more testing / investigation...
When reboot=q is present on the kernel command line (either recovery.cmdline for NOOBS or cmdline.txt for regular distros), then the next call to reboot (which in turn always calls the platform restart handler https://github.com/raspberrypi/linux/blob/rpi-3.6.y/arch/arm/mach-bcm2708/bcm2708.c#L665 ) will cause the PM_RSTS_HADWRQ_SET bit to get set in the PM_RSTS register before restarting (these addresses are all defined in https://github.com/raspberrypi/linux/blob/rpi-3.6.y/arch/arm/mach-bcm2708/include/mach/platform.h but AFAIK they're not documented anywhere - so I'd guess that PM_RSTS stands for Power Management ReSeT Status). As @ghollingworth explained, if bootcode.bin detects this bit then it loads start.elf from the second partition rather than the first. However the next reboot causes bootcode.bin to load start.elf from the first partition again, and as there's no kernel-side code that clears PM_RSTS_HADWRQ_SET, bootcode.bin (or possibly start.elf) must be clearing this bit itself.

This means that in normal use, booting after a power-on causes NOOBS to load start.elf from the first partition, and then every soft-reboot after that will alternately load start.elf from the second partition and the first partition, since recovery.cmdline on /dev/mmcblk0p1 contains reboot=q but cmdline.txt on /dev/mmcblk0p5 doesn't contain reboot=q.
And this means that if you add reboot=q to the cmdline.txt on /dev/mmcblk0p5 then (as I correctly guessed above) every soft-reboot will then always load start.elf from the second partition, and the only way to access NOOBS again will be to remove and then reconnect power (PM_RSTS is only accessible from kernel-code, so (without the help of a custom kernel module) there's no way for a user-space process to clear (or set) the PM_RSTS_HADWRQ_SET bit).
And if you remove reboot=q from the recovery.cmdline on /dev/mmcblk0p1 then NOOBS will always reboot to itself, and never be able to load the 'regular Linux distro' on the extended partitions (as seen in #70).

@inversesandwich As mentioned in the original forum thread, BerryBoot is fine as long as you're happy for all your OSes to use the same Linux kernel, which power users may not want - I think BerryBoot is effectively a root-fs switcher rather than an OS multi-loader. You're right that this feature isn't directly relevant to NOOBS, but it's being discussed on the NOOBS issue tracker though at @Rob-Bishop 's request.

from noobs.

Small addition to my "reverse engineering" notes above: I couldn't find anywhere that the Linux kernel (in NOOBS this is named recovery.img) gets told to boot with recovery.rfs as its initramfs, but doing strings recovery.elf | grep recovery (recovery.elf is just a renamed start.elf from the firmware repo) displays:

recovery.img
recovery.rfs
recovery_mode
recovery.cmdline
/mfs/sd/recovery.elf
recovery_mode

So it looks like if recovery.elf detects that it's running in 'recovery_mode' then it automatically loads recovery.img instead of kernel.img, uses recovery.cmdline instead of cmdline.txt and then "tells" Linux to use recovery.rfs as its initramfs.
At least, that's my best guess... ;-)

from noobs.

@lurch
Yep.

from noobs.

Added in acc5ec4

from noobs.

Rob - this looks Brill - you have exceeded my expectations and the comments on this feature look good too. I can't wait to try it out myself!

from noobs.