dragonboard emmc support

Bug #1812243 reported by Ondrej Kubik
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu Image
New
Undecided
Unassigned

Bug Description

ubuntu-image currently does not support build of Dragonboard 410c images suitable for emmc

There is way to configure also gadget as separate drives where each partition is represented by single file but that still produces incompatible images.

Dragonboard supports boot from emmc and sdcard
File system layout is identical for both situations ( in case of secure boot there is one more partition on emmc).

However for sdcard we need single disk image file. While for emmc we need gpt partition file accompanied by image for each partition. gpt partition file is already presented in gadget snap.

artefacts for emmc has to compatible with fasttboot tool. In this form they are already seeded in gadget snap, and should not be further altered by ubuntu-image.
When gadget.yaml is configured to produce separate images, those are padded and cause problem.

Additionally writable.img has to be created as sparse image, otherwise fastboot will refuse it.
I did some testing with fs tools in xenial, none of them worked reliably and eventually had to use fs tools from bionic which work fine.

As temp solution I created standalone tool creating correct images. Similar functionality should be enabled also in ubuntu-image
For reference temp tool is here:
https://git.launchpad.net/~ondrak/ondras-snaps/+git/db-builder?h=master

tags: added: id-5cdea807c8bfda26a2c96208
Revision history for this message
Kyle Nitzsche (knitzsche) wrote :

It would be preferable to use standard ubuntu-image tool for our snapdragon project. Is this bug on the radar?

Revision history for this message
Woodrow Shen (woodrow-shen) wrote :

Hi, I understand what Ondrej did and db-builder which was good enough for project, so here we just want to see if ubuntu-image has a chance to fix this case based on my hook. The post-populate-rootfs hook I proposed is also based on part of db-builder to create system-boot and writable image (for Android sparse image). Of course it's rough prototype now and meanwhile it has to refine how we put content from source to target specifed by gadget.yaml, for system-boot partition. We're craving to discuss with foundation team to have the same identical code available by default in the ubuntu-image.

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

This is indeed something that we'd like to have in ubuntu-image for sure, sooner or later. But I would prefer this to be an official part of the gadget.yaml spec, allowing for more fine-grained control of how the final partitions and volumes would look (support for sparse images as well).

I will look into both the post-populate-rootfs hook and the db-builder tool to see what we need exactly. Thanks!

Revision history for this message
Ondrej Kubik (ondrak) wrote : Re: [Bug 1812243] Re: dragonboard emmc support

@Lukasz Zemczak <email address hidden> feel free to pull me for
brainstorming about this as by now I have accounted for multiple scenarios
where ubuntu-image was not suitable.
I totally agree right way would be to extend language in gadget to the
point we have flexible yet robust way to describe what ubuntu image should
do, rather than feeding it with endless amount of parameters. Image
building experience should not change, one should just get expected output.
Given changes planned for UC20 which will need to be accommodated anyway,
we better be more forward thinking here rather than short term fix....

On Tue, Jul 23, 2019 at 5:41 PM Łukasz Zemczak <email address hidden>
wrote:

> This is indeed something that we'd like to have in ubuntu-image for
> sure, sooner or later. But I would prefer this to be an official part of
> the gadget.yaml spec, allowing for more fine-grained control of how the
> final partitions and volumes would look (support for sparse images as
> well).
>
> I will look into both the post-populate-rootfs hook and the db-builder
> tool to see what we need exactly. Thanks!
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1812243
>
> Title:
> dragonboard emmc support
>
> Status in Ubuntu Image:
> New
>
> Bug description:
> ubuntu-image currently does not support build of Dragonboard 410c
> images suitable for emmc
>
> There is way to configure also gadget as separate drives where each
> partition is represented by single file but that still produces
> incompatible images.
>
> Dragonboard supports boot from emmc and sdcard
> File system layout is identical for both situations ( in case of secure
> boot there is one more partition on emmc).
>
> However for sdcard we need single disk image file. While for emmc we
> need gpt partition file accompanied by image for each partition. gpt
> partition file is already presented in gadget snap.
>
> artefacts for emmc has to compatible with fasttboot tool. In this form
> they are already seeded in gadget snap, and should not be further altered
> by ubuntu-image.
> When gadget.yaml is configured to produce separate images, those are
> padded and cause problem.
>
> Additionally writable.img has to be created as sparse image, otherwise
> fastboot will refuse it.
> I did some testing with fs tools in xenial, none of them worked reliably
> and eventually had to use fs tools from bionic which work fine.
>
> As temp solution I created standalone tool creating correct images.
> Similar functionality should be enabled also in ubuntu-image
> For reference temp tool is here:
> https://git.launchpad.net/~ondrak/ondras-snaps/+git/db-builder?h=master
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu-image/+bug/1812243/+subscriptions
>

Revision history for this message
Steve Langasek (vorlon) wrote :

The implementation here needs to take on board Gustavo's feedback at the UC20 sprint last month regarding overall design, since this requires changes to gadget yaml which needs to be agreed between ubuntu-image and snapd.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.