Closed Bug 1141635 Opened 5 years ago Closed 5 years ago

[spark] Add recovery support to allow FOTA updates

Categories

(Firefox OS Graveyard :: GonkIntegration, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED FIXED
2.2 S8 (20mar)

People

(Reporter: dhylands, Assigned: dhylands)

References

Details

(Whiteboard: [spark])

Attachments

(4 files, 1 obsolete file)

The lightsaber phone doesn't currently include a recovery partition. So this bug is to add the equivalent functionality.

Cyanogen Mod has a way to get into a recovery mode, so this bug will be to implement a similar mechanism.
Assignee: nobody → dhylands
Whiteboard: [lightsaber]
Target Milestone: --- → 2.2 S8 (20mar)
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Priority: -- → P1
Inspired from Cyanogen Mod's init.sh script for support recovery on the Z3 and Z3C.

This requires that we flash the FOTAKernel partition with the recovery.img file which is built as part of the aries build.

Alternatively, we could store the recovery ramdisk on the initial ramdisk used during normal boot.

I took the flash recovery.img route initially because it meant I didn't have to make any modifications to the build/core/Makefile
Attachment #8580421 - Flags: review?(lissyx+mozillians)
Point RECOVERY_EXTERNAL_STORAGE to internal sdcard so that you don't have to have a physical sdcard in order to perform recovery.

This means certain types of recovery won't be possible (i.e. anything related with moving partitions containing /data), but seems to me to tbe the way we'd want to do things for normal FOTA.
Attachment #8580424 - Flags: review?(lissyx+mozillians)
Attached file Add recovery.fstab for aries device (obsolete) —
This adds recovery.fstab which is needed so that /cache can be mounted by the recovery ROM.
Attachment #8580425 - Flags: review?(lissyx+mozillians)
Woo nice. I may also request feedback from people who are very knowledgeable regarding FOTAKernel partitions :)
Comment on attachment 8580421 [details]
New repository to go into external/init_sh

Adding Adam who knows a lot about hacking this kind of stuff.
Attachment #8580421 - Flags: feedback?(adam)
Comment on attachment 8580424 [details] [review]
Point RECOVERY_EXTERNAL_STORAGE to internal sdcard

Adding Adam who knows a lot about hacking this kind of stuff.
Attachment #8580424 - Flags: feedback?(adam)
Comment on attachment 8580425 [details] [review]
Add recovery.fstab for aries device

Adding Adam who knows a lot about hacking this kind of stuff.
Attachment #8580425 - Flags: feedback?(adam)
(In reply to Dave Hylands [:dhylands] from comment #1)

[...]

> 
> This requires that we flash the FOTAKernel partition with the recovery.img
> file which is built as part of the aries build.

I know this is specific to Sony's devices, but maybe we will have to hack flash.sh for supporting this, right?
I currently use this repo on AOSP 5.0 for Sony recoveries: https://github.com/fxpdev/device-sony-recovery and this solution has been used successfully on CM for years.

It simply bundles a prebuilt CM-recovery ramdisk into the boot.img, with a script to select the correct ramdisk at boot (it's just a simplified version of what we do on CM).

the important part is extract_elf_ramdisk which is open source, but you'll probably want to build busybox rather than use the prebuilt like I have.

The readme mentions the two commits you'll need to override img generation with "custombootimg.mk". 

We use "BOARD_CUSTOM_MKBOOTIMG := mkqcdtbootimg" to deal with dtb files on AOSP, but you won't need that if you are using qcom's solutions, and I don't think this works on AOSP 4.4 anyway.
Comment on attachment 8580425 [details] [review]
Add recovery.fstab for aries device

Why only for aries? Shouldn't we also be able to get this on shinano ?
Building and flashing recovery to FOTAKernel partition works.
Rebooting into recovery mode works, even though it seems to be taking some time.
Building FOTA update package works.
Sideloading FOTA update package works.

For now, I only found mounting the sdcard that was failing.
> $ grep sdcard recovery.fstab 
> /dev/block/mmcblk1p1                              /sdcard           ext4    nosuid,nodev,barrier=1,data=ordered,nodelalloc                  wait

So as far as I remember, mmcblk1p1 will be the first partition of the physical sdcard, not the internal one. Hence why mounting /sdcard will fail. Since we are building librecovery with the /data/media/0 value it should not be a problem for applying from Gecko, but it may be one if people put their update on the sdcard itself.
> E:failed to mount /sdcard (Invalid argument)
Moving recovery.fstab to shinano-common, adding "TARGET_RECOVERY_FSTAB := device/sony/shinano-common/recovery.fstab" to shinano-common/BoardConfig.mk, changing ext4 to vfat in recovery.fstab and I get sdcard to be mounted properly in recovery mode.
Flags: needinfo?(dhylands)
Comment on attachment 8580425 [details] [review]
Add recovery.fstab for aries device

I'm fine with this, but I would prefer that we have the external sdcard being in vfat rather than ext4, and that we move this to shinano-common, as documented just above.
Attachment #8580425 - Flags: review?(lissyx+mozillians)
Attachment #8580425 - Flags: feedback?(adam)
Comment on attachment 8580421 [details]
New repository to go into external/init_sh

That works, but we will need a patch for the shinano.xml manifest of course.
Attachment #8580421 - Flags: review?(lissyx+mozillians)
Attachment #8580421 - Flags: review+
Attachment #8580421 - Flags: feedback?(adam)
Comment on attachment 8580424 [details] [review]
Point RECOVERY_EXTERNAL_STORAGE to internal sdcard

> 03-20 14:26:04.890  1612  1612 I Gecko   : *** AUS:SVC UpdateService:applyOsUpdate - Rebooting into recovery to apply FOTA update: /storage/emulated/legacy/updates/fota/update.zip
> 03-20 14:26:04.890  1612  1612 I GeckoConsole: AUS:SVC UpdateService:applyOsUpdate - Rebooting into recovery to apply FOTA update: /storage/emulated/legacy/updates/fota/update.zip
> 03-20 14:26:04.900  1612  1612 D librecovery: Rebooting into recovery: --update_package=/data/media/0/updates/fota/update.zip
Attachment #8580424 - Flags: review?(lissyx+mozillians)
Attachment #8580424 - Flags: review+
Attachment #8580424 - Flags: feedback?(adam)
Comment on attachment 8580421 [details]
New repository to go into external/init_sh

Adding mwu for feedback.

I'm going to file followup bugs to build busybox and extract_ramdisk_elf from source, and I'll also update flash.sh to flash the recovery when doing a full flash.
Flags: needinfo?(dhylands)
Attachment #8580421 - Flags: feedback?(mwu)
This updates flash.sh to flash the recovery partition on an aries or shinano device when doing a full flash.
Attachment #8580928 - Flags: review?(lissyx+mozillians)
Comment on attachment 8580425 [details] [review]
Add recovery.fstab for aries device

I'm obsoleting this PR and updated the shinano-common pull request to include the recovery.fstab instead.
Attachment #8580425 - Attachment is obsolete: true
Blocks: 1145849
Comment on attachment 8580928 [details] [review]
Update flash.sh to flash recovery partition when doing a full flash

./flash.sh properly flashes the FOTAKernel partition. Could we also take the time to support:
 (1) flashing recovery by doing ./flash.sh recovery ?
 (2) supporting flashing multiple partitions at once ? Like |./flash.sh boot system recovery| if I want to keep my userdata partition.
Attachment #8580928 - Flags: review?(lissyx+mozillians) → review+
Comment on attachment 8580421 [details]
New repository to go into external/init_sh

Looks alright. The ramdisk switching idea also sounds pretty good, but up to you guys to figure out what solution we use.
Attachment #8580421 - Flags: feedback?(mwu)
(In reply to Michael Wu [:mwu] from comment #22)
> Comment on attachment 8580421 [details]
> New repository to go into external/init_sh
> 
> Looks alright. The ramdisk switching idea also sounds pretty good, but up to
> you guys to figure out what solution we use.

Partly, this boils down to the way that the ramdisk images are built.

The way that the current build (build/core/Makefile) creates things is that it does the following:

1 - Creates the ramdisk used for normal booting
2 - Creates the recovery ramdisk by unpacking the ramdisk from 1 and makes some modifications

There are basically 2 schemes I can see:

1 - Have the initial ramdisk be neither the normal one, nor the recovery one. It would have just enough to figure out which one to use and then load the real ramdisk.

2 - What I did was to have the initial ramdisk be the normal one, and for doing recovery, it removes most of the contents of the initial one and overlays the contents of the recovery one.

And then for each scheme you have some choices about where the contents of the ramdisk come from.

What CM does works well for "modify an existing image", but doesn't work so well as "build it from scratch". I'm sure that part of this is I'm still learning various bits and pieces of the android build system. It may very well be not too difficult to implement scheme 1, and it would probably be preferred, but I'll defer it until I get a bit more familiar with some of the build stuff.
(In reply to Alexandre LISSY :gerard-majax from comment #21)
> Comment on attachment 8580928 [details] [review]
> Update flash.sh to flash recovery partition when doing a full flash
> 
> ./flash.sh properly flashes the FOTAKernel partition. Could we also take the
> time to support:
>  (1) flashing recovery by doing ./flash.sh recovery ?
>  (2) supporting flashing multiple partitions at once ? Like |./flash.sh boot
> system recovery| if I want to keep my userdata partition.

I like this, and will file a followup bug.

I'll also need to modify the manifests in order to land this properly, but I think that the first step will be getting the init_sh repository created and populated, and then update the manifest, and finally, land the other 2 patches.
Blocks: 1146465
Now that I've created the init_sh repository, we can add it to the manifest.

Then the other 2 parts of this bug can land.
Attachment #8582050 - Flags: review?(fabrice)
Comment on attachment 8582050 [details] [review]
Add init_sh repository to the shinano/aries builds

lgtm, but this should be reviewed by mwu.
Attachment #8582050 - Flags: review?(fabrice) → review?(mwu)
Component: General → GonkIntegration
Attachment #8582050 - Flags: review?(mwu) → review?(lissyx+mozillians)
Comment on attachment 8582050 [details] [review]
Add init_sh repository to the shinano/aries builds

I think we will have to mirror this on git.mozilla.org too
Attachment #8582050 - Flags: review?(lissyx+mozillians) → review+
Blocks: 1147190
Whiteboard: [lightsaber] → [ignite]
Whiteboard: [ignite] → [spark]
Blocks: spark-ota
No longer blocks: spark
Summary: [lightsaber] Add recovery support to allow FOTA updates → [spark] Add recovery support to allow FOTA updates
You need to log in before you can comment on or make changes to this bug.