Dev build - minor fix to ampart sha-256


PKG_SHA256="5c9f145ed2cbe77bd34e5c4b0415d5cba43c1e1850be9cae5a8adc33829eafbd "

should just be (without space on end):


That sha256 in the latest commit is already fixed, have you tried to pull dev branch first?

Also can you test ampart on S905X3 or later devices? The only -ng capable device in my hand is a S905L BesTV R3300L, and I can’t valid if everything works on other devices. My only test regarding S905X3 is to run ampart on a dumped image sent by shantigilbert and force the corresponding modified partition table and dtb onto my S905L box to check if anything breaks.

You can check the doc of ampart at the github repo:

What am I testing? Can you write the case steps to test ampart on my S922X device?

Wait a sec, is this going to modify my internal memory of my device? Sorry but I won’t risk bricking my machine. Someone who actually wants to use this feature will have to test.

In dry-run mode no actual writing will happen (–dry-run)

Any without any partition argument ampart will only print the partition table, just like you would expect from fdisk -l, also no actual writing will happen. (ampart /dev/mmcblk0) you can use this to know the partition layout of your emmc

And in snapshot mode, there’s also no writing, you can get an emmc partition table snapshot you can later use in clone mode to restore emmc in case anything is messed up (ampart --snapshot /dev/mmcblk0)

These are all the modes that won’t modify your emmc, you can do without any risk

Then if you change your mind and decide to actually change it, you can delete the last partition entry from the partition table (only the entry, the data is not affected) via ampart --update /dev/mmcblk0 ^-1? and reboot to check if the table will be reverted by u-boot. If it’s reverted then nothing actually happened, ampart does not work on your device and your Android installation will work just like how it workded. If the table wasn’t reverted, then you can use clone mode to restore the table, or do any fancy stuffs you can do with ampart.

I tried cloning the product partition but it’s coming up with a read-only error.

EMUELEC:~ # ampart --clone product:4462M:128M:1 --snapshot /dev/mmcblk0 -o test.img
Notice: running in clone mode, partition arguments won't be filtered, reserved partitions can be set
Notice: running in snapshot mode, new partition table won't be parsed
Notice: output to will be written to test.img
Path 'product:4462M:128M:1' seems a dumped image, checking the head bytes to distinguish it...
ERROR: Can not open path 'product:4462M:128M:1' as read-only, check your permission!
  1. –output argument is not actually implemented since I think it does not have too much use. If you want to do test without breaking anything, you can dump the disk image, and operate on dumped image instead. dd if=/dev/mmcblk0 of=emmc.img or dd if=/dev/reserved of=reserved.img, then you can use ampart on emmc.img or reserved.img. You can do these test on X86-64 platforms with a corresponding binary of ampart, just git clone ampart and make, and you get a X86 executable
  2. –clone sets a mode clone mode for ampart, it does not mean “clone a partition”, it means, parse anything defined in [partitions], and do a binary replica of it. This is mainly used for recreate a snapshot, but can also be used for certain devices for mass-production (e.g. If you are a manufacturer)
  3. – snapshot prints the partition layout at the last two lines and early quit. The first of which can be used by human to record, the last of which can be used by scripts to parse around. e.g. You can take a snapshot of mmcblk0 with ampart --snapshot /dev/mmcblk0. You’ll get the following two snapshots:
    a human-readable one that you can record on paper/PC
bootloader:0B:4M:0 reserved:36M:64M:0 cache:108M:512M:2 env:628M:8M:0 logo:644M:32M:1 recovery:684M:32M:1 rsv:724M:8M:1 tee:740M:8M:1 crypt:756M:32M:1 misc:796M:32M:1 boot:836M:32M:1 system:876M:2G:1 data:2932M:4524M:4

a machine friendly one that a script can read and do fancy stuffs based on this (it can get partition name, offset, size, etc)

bootloader:0:4194304:0 reserved:37748736:67108864:0 cache:113246208:536870912:2 env:658505728:8388608:0 logo:675282944:33554432:1 recovery:717225984:33554432:1 rsv:759169024:8388608:1 tee:775946240:8388608:1 crypt:792723456:33554432:1 misc:834666496:33554432:1 boot:876609536:33554432:1 system:918552576:2147483648:1 data:3074424832:4743757824:4
  1. Proper usage of clone mode is to apply a snapshot to the disk, it is named “clone mode” because the output partition table will be a 1:1 binary replica of the old partition table (or a manipulated one if you are a script and have modified some arguments):
ampart --clone /dev/mmcblk0 bootloader:0B:4M:0 reserved:36M:64M:0 cache:108M:512M:2 env:628M:8M:0 logo:644M:32M:1 recovery:684M:32M:1 rsv:724M:8M:1 tee:740M:8M:1 crypt:756M:32M:1 misc:796M:32M:1 boot:836M:32M:1 system:876M:2G:1 data:2932M:4524M:4
  1. To actually duplicate a partition, you need to use update mode as this is the mode where only minor details of the old partition table will be changed. You need to select the old partition you want to duplicate and use special operator to define special behaviour
ampart --update /dev/mmcblk0 ^product%:clonedProduct

The command above selects product partition with a ^product selector, if it’s the last one/15th partition, you can also select it with ^14 or ^-1, and the % special operator duplicates the partition just like the two o in the symbol.
After this operation, /dev/clonedProduct and /dev/product will co-exist and is actually two block-devices, however there actually point to the same underlying part of mmcblk0

Also, I’ve already written everything in ampart’s doc and I think you misunderstood the arguments.

ampart [reserved/emmc] ([partition] ...) ([option [optarg]]...) 

--clone, --snapshot are in-positional arguments (options) that can be placed anywhere
[reserved/emmc] ([partition[...) are positional arguments, the first of the positional arguments is always parsed as path to emmc/reserved/dump images of them, the second onward are always parsed as partitions.
In your case, --clone enabled clone mode, but ‘product:4462M:128M:1’ is parsed as the path to emmc/reserved/dumped images, and ampart failed to open it as it does not exist. --snapshot enabled snapshot, ampart will early-quit after it prints the snapshots. So --clone does not work here, as the partitions arguments won’t be parsed (new partitions will only be parsed after a check of snapshot mode).

There’s three main modes in ampart: normal mode, clone mode and update mode

In normal mode you re-partition the emmc just like a new one, like you how use fdisk/ GNU/parted. ampart will try its best to preserve the reserved partitions (bootloader, reserved, env, misc, logo), and do some insertion optimization so all these reserved partitions will be placed at the beginning of the emmc, and migrates them for you. Infos in partition arguments can be incomplete and will be auto-set by ampart.

ampart /dev/mmcblk0 data:::

This command puts a big chunky data partition on emmc, and optimises the layout so you can utilize as much as disk space as you like

In clone mode (enabled with --clone), partitions should be set explictly, no optimization is done, ampart treats the partition arguments as-is. All details about a partition must be set by user. Has auto-migration in case location of reserved partitions are changed. The output of snapshot mode is a valid input for this mode, thus making reverting partition table easy and possible.

In update mode (enabled with --update), you can select partitions and do operations on them, you can adjust their name, offset, size, mask, and delete or clone them. No insertion optimization, still has auto-migration. Without selector, partition argument works like normal mode and will create new partitions.
A command like this will achive a same partition layout like what ceemmc would do:

ampart --update /dev/mmcblk0 ^-1:::-512M: ^-1%:CE_STORAGE CE_FLASH:::

ampart is not a feature of EmuELEC, it’s a full blown partition tool just like fdisk, GNU/parted, cfdisk, etc that’ll work on Amlogic’s proprietary emmc partition format. It’s not limited to be used on EmuELEC only, it works on therotically any Linux device that runs on Amlogic SoC, but I chose to officially support it on EmuELEC because I love EmuELEC. It even works on those don’t, with dumped images.

It has its own grammer that makes it more script-friendly than GNU/parted in script mode, check aminstall, a new installation script that utilizes it, and the lines that invoke ampart, you’ll know its powerfullness.

It’s never limited to be just something you call it with aminstall. No, I wrote ampart first. Then I wrote aminstall since I love EmuELEC and hate the situation that no good installation to internal methods are available anymore. With ampart you can 100% utilize your emmc just like what you want for a disk on real Linux machines. The installation script just hides it from the sight of users.

1 Like