Partition layout for snappy?

[ogra]

through fastboot i flashed all meta-binaries found in stage/blobs

aha … by default ubuntu-image indeed creates the bootloader partition images for SD, since we only support the bootloader install to MMC via the u-boot flash script … so if you tinker with fastboot, do it with a grain of salt and try to avoid touching anything but writable and system-boot (part 7 and 8 images)

[laxman456]

ya i got it now.Thanks.

[ondra]

jumping in late as I was travelling.
Anyway for fastboot flashing when writable becomes too large, try to define size of chunks:
$ fastboot -S 100M flash writable…….
About booting.
Difference between boot from sd card and emmc is in:
aboot and boot image (u-boot binary has hardcoded env path).
As ogra said, we ship in gadget snap binary blobs for both options, and uboot flash will pick correct ones.
Vanilla system boot partition is identical, however at first boot this gets “provisioned” and from then onwards u-boot environments have different values between sd card and emmc
So if you want to strip down gadget snap and generate image with ubuntu-image which can be directly flashed with fastboot to emmc, you need to change both, snapcraft.yaml and gadget.yaml to point to correct blobs for each partition.
ogra is right, from your log, you have likely messed up aboot. It does not seem to pick up emmc boot image, and since it would usually default to fastboot, you are probably running there aboot for sd card boot……

[ogra]

Anyway for fastboot flashing when writable becomes too large, try to define size of chunks:

I dont think chunks would have helped, the target partition was to small because it had not been first-boot-resized yet (most likely because the SD was not removed on first boot so that the SD “writable” was resized instead of the MMC one)…

[laxman456]

Hi both,
sorry for delay.
actually i tried these few days back by changing snapcraft.yaml and gadget,yaml involving only emmc stuff as ondra said since i dont want sdcard to come in to picture.everything went fine except the size of writable only 236M. Then i followed your instructions and it booted fine.

Hi ondra,
As ogra said i think partition was to small because it had not been first-boot-resized yet.

Thanks

[ondra]

it shouldn’t actually matter, as from part table size of writable should be whatever is left on the device. You can actually check this with $ fastboot format writable
then boot from sdcard and check to what size did fastboot formatted it.
When I was testing fastboot flash for writable, it looked like sparse format ubuntu-image spits out is not always compatible with one expected by fastboot. Something we should look into.
Fastboot assumes ext4 image was created with android tool

[ogra]

The filesystem will only be at a minimal size until first boot resized it… (no matter what the partition size is)

[ondra]

this is not about ubuntu core at all. Fastboot does not care what system is running on the device….
for emmc, part table is defined in emmc-partitions.txt
where writable partition is marked to occupy rest to the emmc. So if you format this partition using fastboot, it will give you full size available.
Now of course if you flash it using uboot, then this will will simply dd over writable from scard before resize, so in this particular case you will have indeed minimal size till initrd resizes it.
But equally you can created sparse ext4 image of writable partition with size ~7GB and flash this with fastboot and there won’t be anymore resizing at first boot….

[Shubham_Pushpkar]

Hi @ogra and @ondra,

I have created an image for olimex lime2 for SD-Card which is working good, same I build for emmc,
Now I have one problem how can I copy my image to emmc as per BBB I need to run a script during booting with sd-card which will copy the content of sd-card to emmc.
At the same time, I came to know that olime lime2 support FEL booting so I have created image with -w option which will segregate the image by its partition,
I had copied the part0.img(which is uboot) to the uboot of SOC, it will take me in FASTBOOT.
Now I tried to copy the system-boot and writeable part to emmc of SOC via FASTBOOT,but it will expect writeable and system-boot in sparse format.
My Query is -
1- How I convert part1.img(system-boot) and part2.img(writeable) in sparse format, do i use simg2img tool to covert the raw image in sparse(FASTBOOT) format ?
2- As @ondra suggested that I need to divide the large writeable image into chunks, pls suggest how can I achieve this.

Thanks!!

Appreciate your support

[ogra]

see if that helps:

Installing Ubuntu Core on devices with internal drives

The question came up recently about a good way to install a Ubuntu Core system on devices that have internal drives (like e.g. the Intel NUC) instead of the sdcards that are common on the pi2/pi3. With the pi2/pi3 the usual way is to simply dd the ubuntu-core image to the sdcard and put it in. An easy way to install Ubuntu Core on such devices is to boot a 18.04 live usb stick and then use the go-dd snap to write the image directly from the network: # needs devmode because it may need to write…

(you can indeed also install from a local image instead of a http downloaded one … )

[Shubham_Pushpkar]

@ogra thanks for your quick reply.
I will try this method and let you know my findings.

[ondra]

Hio @Shubham_Pushpkar
sorry to join the party too late, and probably late to save you some time working around the problems.
Generally running system from emmc on arm devices requires different approach to the way images are built.
ubuntu-image does not support this, not in straight forward way anyway. Hopefully with latest little kernel boot loader support added to snapd (bootloader: little kernel support) thing might move faster.
In general for devices supporting fastboot flashing, you want to build image way it has “image file per partition”
To breach the gab till ubuntu-image learns this magic, I have created temp tool called dragonboard-builder
( snap install dragonboard-builder). Ignore name as it was initially intended to build emmc images for dragon board. It has same syntax as ubuntu-image only it gives you image in form you want. Plus few more tweaks to the image
once more sorry for late comment

[Shubham_Pushpkar]

First of all thank you @ondra for your valuable information & no need to say sorry
Actually I managed to build the “image file per partition” using ubuntu-image tool by providing “-w” options while preparing the image, it will segregate the Raw IMG into image file per partition.

In my case part0.img is a uboot.img which is first stage bootloader, part1.img is a boot.img which is second stage bootloader and part2.img which is writeble.img.

After that I created MBR file for partitioning the emmc, in which I made the second partition as an active partition where my second stage bootloader is present.

I put the MBR(512k) file at the very first part of emmc as it contains the partition table.

I don’t know how much my approach are correct but it’s working fine at the very first boot.

But I am getting some error when I tried to flash the image second time.

I am out of my office, sorry I am unable to share you my exact error which I am getting, will keep you posted once I am in my office.

Please correct my approach/understanding if I am doing any mistakes.

I’ll try to implement your above suggestions as well once I am in my ofc.

Thanks you once again!!

[Shubham_Pushpkar]

Hello @ondra,

When i tried to create an image using dragonboard-builder.build-uc-image tool i am running below error -

error: Get https://api.snapcraft.io/api/v1/snaps/assertions/snap-revision/szhtO6R5pE_BlUGevZpMEoi6fMgdqTMXaratmlZxpOGr7WixBR27ylO1DoFXeli0?max-format=0: dial tcp: lookup api.snapcraft.io on [::1]:53: dial udp [::1]:53: socket: permission denied

It’s seems that I don’t have permission to use local modal_assertion .

Command used to build an image -
sudo dragonboard-builder.build-uc-image -c stable -O imagefile --extra-snaps kernel/olimex-kernel_0.1_armhf.snap --extra-snaps gadget/olimex-gadget_0.1_armhf.snap
model/olimex-lime2.model

In previous case segregated image are converted in sparse format using img2simg tool.
“https://github.com/anestisb/android-simg2img”

[ondra]

@Shubham_Pushpkar have you connected all the interfaces once you installed dragonboard-builder it does not auto connect.
Also do not run it as sudo. builder is strictly confined, so it will only have access to your home directory (use of sudo messes this up). Also make sure that builder can access all the local files you are passing to it, same for passed output dir.

I’m a bit confused by your partition table and boot sequence.
you are mentioning first stage and second stage bootloaders there.
First stage bootloader is burned in SoC, so we do not modify this and it will not be on emmc/sd card either as it’s burned in SoC. You should not need to worry about 1st stage bootloader.
Second stage bootloader is then something like u-boot, aboot, little kernel…
So what is your second stage bootloader?
Next confusing things, you are mentioning boot image. This is usually used by little kernel based boot loaders, not by u-boot. If you are using u-boot, you should instead modify it, so it meets snapd expectations ( env location, size, redundancy). Then you just need system-boot partition and rest will be taken care of.
Where is u-boot environment stored at the moment? Make sure it is stored in system-boot (this is defined in u-boot config)
As for mbr partition table, build this as part of the gadget snap.
something like this https://github.com/kubiko/if6640-gadget/blob/18/snap/snapcraft.yaml#L74
Like this, when you build image you will have correct file ready to be flashed

[ogra]

First stage bootloader is burned in SoC

very rarely

the allwinner boards all build an SPL binary during the u-boot creation, this is the first stage bootloader, the ROM only knows where to look for it … typically you have the choice between “just u-boot”, “u-boot with prefixed SPL in one img” or “two separate img’s” when building the u-boot binary. i assume here the combined img is used.

[Shubham_Pushpkar]

Thanks @ondra and @ogra for your prompt reply,

have you connected all the interfaces once you installed dragonboard-builder it does not auto connect

Sorry that was my mistake, now i am successfully created the image using dragonboard-builder.

Created image are writable image in sparse formate and system-boot image which consist of env file.

First stage bootloader is burned in SoC, so we do not modify this and it will not be on emmc/sd card either as it’s burned in SoC. You should not need to worry about 1st stage bootloader.

As ogra said in Allwinner board SOC, first & second-stage bootloader are build during u-boot creation.
In my case “u-boot-sunxi-with-spl.bin” is the first-stage bootloader.

So what is your second stage bootloader?

u-boot is my second-stage bootloader.

This is usually used by little kernel based boot loaders, not by u-boot.

Yes it was my mistake i mentioned it wrong.

you should instead modify it, so it meets snapd expectations ( env location, size, redundancy)

Yes i had done all these modifications in u-boot source code before building u-boot

you just need system-boot partition and rest will be taken care of

I think we need first-stage bootloader as well for my case as my SOC is Allwinner.

Where is u-boot environment stored at the moment?

It is in second-stage bootloader, i.e in u-boot

After successfully build the image using dragonboard-builder i have now system-boot and writable image in fastboot formate.

Shall i need to modified my gadget snap to get u-boot-sunxi-with-spl.bin(first-stage bootloader), or dragonboard-builder will take care of it (i don’t know how this tools are working internally)

where as i am using the same source while creating the image using ubuntu-image tool it provided all the three images first, second and writable image.
i.e part0, part1 & part2 respectively.

Actually I am new in this, Please don’t mind if I asking stupid questions.

Thank you & i appreciate your support !!

[Shubham_Pushpkar]

“two separate img’s”

Yes we need two separate images, first image(u-boot-sunxi-with-spl.bin) which is used to make the device in fastboot boot mode.
Once we are in fastboot mode we flash rest of the image into the emmc i.e u-boot binary and writable image.

[ondra]

dragonboard builder will give you file per partition, as long as gadget has those files
so if you need 1st stage bootloader and u-boot as separate files and gadget has those, as separate files. Then you should be good, just make sure gadget.yaml represent correctly your part table

[Shubham_Pushpkar]

Thanku @ogra & @ondra for being supportive,

@ondra I added one more disk(second-stage) volume in my gadget.yaml in order to generate first-stage bootloader & u-boot binary separately.

But when i tried to create images using dragonboard-builder, still i am having system-boot & writable images only.

I mean still i am unable to segregate first-stage and u-boot image.
Any help is really appreciable.

Thank you!