1120950 - [dolphin] dolphin 512MB device freeze on boot up

Status: RESOLVED DUPLICATE of bug 1129797

(Firefox OS Graveyard :: GonkIntegration, defect)

Comment 1

[Kai-Zhen Li [:seinlin][:kli]]

Attachment: Support extfs_sparse_flag on system and cache partition

Michael, Now we got new dolphin device with 512MB Ram and it use different flash and filesystem. We need to support extfs_sparse_flag on system and cache partition in order to boot up it properly. Could you review this patch? Thanks!

Comment 2

[Michael Wu [:mwu]]

Can't you support this using a different product.mk? This doesn't seem necessary.

Comment 3

[Kai-Zhen Li [:seinlin][:kli]]

(In reply to Michael Wu [:mwu] from comment #2)
> Can't you support this using a different product.mk? This doesn't seem
> necessary.

Sorry for wrong description in comment 1. What we need is to support disable sparse on system/cache/userdata image independently.

In dolphin-512's  BoardConfig.mk, Only system image's extfs_sparse_flags is disabled.
TARGET_SYSTEMIMAGES_SPARSE_EXT_DISABLED := true
TARGET_USERIMAGES_SPARSE_EXT_DISABLED := false
TARGET_CACHEIMAGES_SPARSE_EXT_DISABLED := false

Now, we use 'extfs_sparse_flag' to build all image. Currently, I don't have a good idea to achieve this goal without this patch.

If we disable on all images, the image size will be increased a lot:
cache.img 5.3MB --> 144MB
userdata.img 51MB --> 3GB

BTW, I also discuss with partner why sparse of system image need to be disabled.

Comment 4

[Kai-Zhen Li [:seinlin][:kli]]

Michael, I've discussed with partner and know that they need to disable sparse on system image for performance. I updated PR not to break the current logic and also can support device to disable sparse of system/userdata image only. Could you have a look?

Comment 5

[Michael Wu [:mwu]]

Hmm, do you have more details about why they need to disable sparse? Sparse actually makes flashing easier since the entire image doesn't need to be stored in ram. The main difference is if they care about writing all the empty blocks in between with zeros, which can be emulated anyway if it's necessary.

BTW we don't need build side logic to get non-sparse images. You can run simg2img from out/host/linux-x86/bin to convert a sparse image to a regular image, which might be a good alternative until fastboot is fixed.

Comment 6

[Kai-Zhen Li [:seinlin][:kli]]

(In reply to Michael Wu [:mwu] from comment #5)
> Hmm, do you have more details about why they need to disable sparse? Sparse

I'll keep discussion with partner if it is possible not disable sparse.

> actually makes flashing easier since the entire image doesn't need to be
> stored in ram. The main difference is if they care about writing all the
> empty blocks in between with zeros, which can be emulated anyway if it's
> necessary.
> 
> BTW we don't need build side logic to get non-sparse images. You can run
> simg2img from out/host/linux-x86/bin to convert a sparse image to a regular
> image, which might be a good alternative until fastboot is fixed.

If we don't build a non-sparse image and using simg2img. I think we have some options:

1. Use simg2img manually. Developer need to convert image before flash; otherwise device will be bricked.

2. Add a condition check in flash.sh, convert image to raw format if it is needed.

3. Convert image after system.img is built in build time.
   (But I think this is a little bit redundant, as we can built a raw image by just remove '-s' option)