Closed
Bug 1141635
Opened 10 years ago
Closed 10 years ago
[spark] Add recovery support to allow FOTA updates
Categories
(Firefox OS Graveyard :: GonkIntegration, defect, P1)
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 | ||
Updated•10 years ago
|
Assignee: nobody → dhylands
Whiteboard: [lightsaber]
Target Milestone: --- → 2.2 S8 (20mar)
Assignee | ||
Updated•10 years ago
|
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → ARM
Updated•10 years ago
|
Priority: -- → P1
Assignee | ||
Comment 1•10 years ago
|
||
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)
Assignee | ||
Comment 2•10 years ago
|
||
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)
Assignee | ||
Comment 3•10 years ago
|
||
This adds recovery.fstab which is needed so that /cache can be mounted by the recovery ROM.
Attachment #8580425 -
Flags: review?(lissyx+mozillians)
Comment 4•10 years ago
|
||
Woo nice. I may also request feedback from people who are very knowledgeable regarding FOTAKernel partitions :)
Comment 5•10 years ago
|
||
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 6•10 years ago
|
||
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 7•10 years ago
|
||
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)
Comment 8•10 years ago
|
||
(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?
Comment 9•10 years ago
|
||
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 10•10 years ago
|
||
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 ?
Comment 11•10 years ago
|
||
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.
Comment 12•10 years ago
|
||
> $ 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.
Comment 13•10 years ago
|
||
> E:failed to mount /sdcard (Invalid argument)
Comment 14•10 years ago
|
||
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 15•10 years ago
|
||
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 16•10 years ago
|
||
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 17•10 years ago
|
||
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)
Assignee | ||
Comment 18•10 years ago
|
||
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)
Assignee | ||
Comment 19•10 years ago
|
||
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)
Assignee | ||
Comment 20•10 years ago
|
||
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
Comment 21•10 years ago
|
||
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 22•10 years ago
|
||
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)
Assignee | ||
Comment 23•10 years ago
|
||
(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.
Assignee | ||
Comment 24•10 years ago
|
||
(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.
Assignee | ||
Comment 25•10 years ago
|
||
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 26•10 years ago
|
||
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)
Updated•10 years ago
|
Component: General → GonkIntegration
Updated•10 years ago
|
Attachment #8582050 -
Flags: review?(mwu) → review?(lissyx+mozillians)
Comment 27•10 years ago
|
||
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+
Assignee | ||
Comment 28•10 years ago
|
||
https://github.com/mozilla-b2g/init_sh/commit/3bdd26e092db9c47c5beb04b4809a35f8f767b8a
https://github.com/mozilla-b2g/b2g-manifest/commit/b5c2ba0387db79686c33b579e8584775cb1b514f
https://github.com/mozilla-b2g/device-shinano-common/commit/43be4615072aa43649d459bab91278e0ec7caa62
https://github.com/mozilla-b2g/B2G/commit/9260e00c890c1cd385fd281296d5037fa7e4dece
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
Whiteboard: [lightsaber] → [ignite]
Updated•10 years ago
|
Whiteboard: [ignite] → [spark]
Updated•10 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•