Arch Linux ARM Related Discussion / Arch Linux ARM 相关讨论

[Scirese]

Hi @ophub, 之前我看到了 #358, 我本人也是 Arch 用户，很想把 Arch Linux ARM 装到安卓盒子上。 折腾几天后我写出了这篇简单的教程:

中文 English

请加个documentation的 tag, 希望能帮到别人😉

我最近会造一个打包好的镜像 I'll make a prebuild package recently

另附上系统桌面:

[ophub]

感谢你的分享，不仅热心，还有完善的文档说明，你不仅直接帮助到很多人，也给很多人带来启发。

[Scirese]

感谢你的分享，不仅热心，还有完善的文档说明，你不仅直接帮助到很多人，也给很多人带来启发。

应该的 其实我还试了安装NixOS

[ophub]

我学习了下你的教程，其中/boot 让它空着这点没理解，如果这目录下没启动文件，Arch Linux ARM是通过什么完成启动的呢？ 你最终的/boot目录下是什么结构？ 你有没制作好的镜像或者ddbr的文件我学习下。

[Scirese]

我学习了下你的教程，其中/boot 让它空着这点没理解，如果这目录下没启动文件，Arch Linux ARM是通过什么完成启动的呢？ 你最终的/boot目录下是什么结构？ 你有没制作好的镜像或者ddbr的文件我学习下。

/boot 需要挂载到独立的fat分区, 这点和 Armbian 一样. 你看看 fstab 就明白了. 最终的 boot 就是你包里的, 你可以试着操作一遍

[ophub]

/boot/
/etc/fstab
/usr/lib/modules
/usr/lib/firmware
/usr/lib/u-boot

也就是说在Armbian里打包使用的这几个目录，和Arch Linux ARM相同？ /boot/Initrd根据你的方法重新生成？ 这样就可以使用了？

[Scirese]

/boot/
/etc/fstab
/usr/lib/modules
/usr/lib/firmware
/usr/lib/u-boot

也就是说在Armbian里打包使用的这几个目录，和Arch Linux ARM相同？

是

/boot/Initrd根据你的方法重新生成？ 这样就可以使用了？

更新内核时需要按我的方法重新生成, 不更新不用动. 实际上你可以修改mkinitcpio脚本来让它自动生成uboot格式的镜像, 不过我拿不太准，就没说.

[ophub]

根据你的教程操作，打包 Arch Linux ARM 很容易，具有很多通用性。

[Scirese]

根据你的教程操作，打包 Arch Linux ARM 很容易，具有很多通用性。

Arch 还算是很简单的(起码比NixOS要简单的多), 而且桌面体验比 Ubuntu Jammy 好太多了 对于那些喜欢自己折腾的用户可以用 Arch, 比较小白的用可以 Manjaro 不如在Readme里提一下？

[ophub]

我不熟悉这个系统，我见群里暴躁老哥好像用的是这个系统，你根据经验多指导指导，文档越具体，新同学越少摸索。我觉得你熟悉这个系统的使用，可以做个仓库把他直接落地了。

[Scirese]

我不熟悉这个系统，我见群里暴躁老哥好像用的是这个系统，你根据经验多指导指导，文档越具体，新同学越少摸索。我觉得你熟悉这个系统的使用，可以做个仓库把他直接落地了。

可以在这个项目的Readme里提一下其他发行版的教程，让有兴趣的用户尝试一下。我慢慢完善文档（ 我不想开个新项目，我是高中学生，不像您这么有时间。大部分时候我没空鼓捣这些东西的 🥲

[ophub]

好的，我初中也得抓紧学习。 这个网址我访问起来很不稳定。你能不能把在github建一个仓库，把你的这个文章发在你github里，我链接到你的仓库去。

[Scirese]

好的，我初中也得抓紧学习。 这个网址我访问起来很不稳定。你能不能把在github建一个仓库，把你的这个文章发在你github里，我链接到你的仓库去。

here it is https://github.com/Scirese/alarm 那个链接在 vercel 上，应该不会不稳的

[ophub]

https://github.com/ophub/amlogic-s9xxx-armbian/commit/4b1d7d67c2d14465075d4d4b06bfee4c718064d5

加好了

[Scirese]

4b1d7d6

加好了

谢谢你的认可！

[akiwong-cn]

arch可以用显卡加速吗？我用server版本装了xfce，浏览器卡的不行，看视频cpu占用也很高，估计都是用cpu解码，没有用到显卡

[Scirese]

arch可以用显卡加速吗？我用server版本装了xfce，浏览器卡的不行，看视频cpu占用也很高，估计都是用cpu解码，没有用到显卡

Arch桌面体验要比这个Ubuntu好的多 桌面需要用 wayland, 不能用x11 视频解码可以试试mpv，目前Linux下除了coreelec和librelec没有支持硬解的

[Scirese]

@ophub 大佬, 你们有什么讨论群吗, 有的话能不能让我进一下（

[ophub]

我没有群，f大仓库有他的群链接，欢迎大家加入折腾

[univerioiln233]

大佬nb，感谢！ 另外，以后会有opensuse micro leap的安装教程麽？

[univerioiln233]

好的，我初中也得抓紧学习。 这个网址我访问起来很不稳定。你能不能把在github建一个仓库，把你的这个文章发在你github里，我链接到你的仓库去。

啊？初中?

[Scirese]

大佬nb，感谢！ 另外，以后会有opensuse micro leap的安装教程麽？

我之前没接触过suse，可能得研究一下

[JFLim1]

Hi @Scirese,

Good work. Any possibility of building a Fedora 37 Workstation or KDE for Amlogic TV Box?

[Scirese]

If Fedora got a prebuild arm64 rootfs, you can follow my tutorial and replace the arch rootfs to fedora one. I can't make tutorial because I am not familiar with it.

As for KDE, you can install it directly in Arch. Maybe head to ArchWiki for instructions?

JFLim1 @.***> 于 2022年10月18日周二 下午3:48写道：

Hi @Scirese https://github.com/Scirese,

Good work. Any possibility of building a Fedora 37 Workstation or KDE for Amlogic TV Box?

[JFLim1]

Thanks @Scirese

[7Ji]

For an ArchLinux installation, I'm not a fan of having a lot of out-of-tree stuffs that do not align with the official packages' style and relies on manual interference instead of Pacman hooks to update files. Addtionally I don't like not being able to utilize 100% of the eMMC due to limitation of the armbian-install script: https://github.com/ophub/amlogic-s9xxx-armbian/blob/0e588fc22ec9480b33554dd958d334834c03b145/build-armbian/common-files/rootfs/usr/sbin/armbian-install#L238

A more Arch-way of doing the installation, with much more freedom to setting up the booting mechanism and partitions layout is documented in my blog, written in both English and 中文 side-by-side, with 17052 words and 68690 characters, https://7ji.github.io/embedded/2022/11/08/alarm-install.html. The post is more than an installation guide, but with most of the knowledges enough to know why some booting mechanism works and some not on some devices, and Amlogic's trivia here and there.

I've made the following kernel package and aligned the files with official Arch kernels so the kernel can be tracked by Pacman and mkinitcpio hooks will work for them, which is a split PKGBUILD for kernel, dtb and headers: https://aur.archlinux.org/packages/linux-aarch64-flippy-bin

The following package for firmware: https://aur.archlinux.org/packages/linux-firmware-amlogic-ophub

And a package with hooks for uboot legacy initrd (only booting mechanism that'll use booti under the hood needs legacy initrd, the syslinux config /extlinux/extlinux.conf which is booted with sysboot does not need it): https://aur.archlinux.org/packages/uboot-legacy-initrd-hooks

I've written a tool for manipulation of Amlogic's proprietary eMMC partition table (EPT) earlier this year: https://github.com/7Ji/ampart, which is a dependency for EmuELEC's eMMC installation tool. I don't have enough time outside of maintaining EmuELEC and for my life&study, but I'm open with its inclusion in other open-source projects (it's licensed as GPL3). It has a simple CLI interface that script can interact with dsnapshot and esnapshot to get partition layout (Documentation available at https://github.com/7Ji/ampart/tree/ampart/doc). This is also available on AUR: https://aur.archlinux.org/packages/ampart-git, although you can just git clone and make easily on probably every distro. You could turn a EPT like this:

===================================================================================
ID| name            |          offset|(   human)|            size|(   human)| masks
-----------------------------------------------------------------------------------
 0: bootloader                      0 (   0.00B)           400000 (   4.00M)      0
    (GAP)                                                 2000000 (  32.00M)
 1: reserved                  2400000 (  36.00M)          4000000 (  64.00M)      0
    (GAP)                                                  800000 (   8.00M)
 2: cache                     6c00000 ( 108.00M)         46000000 (   1.09G)      2
    (GAP)                                                  800000 (   8.00M)
 3: env                      4d400000 (   1.21G)           800000 (   8.00M)      0
    (GAP)                                                  800000 (   8.00M)
 4: logo                     4e400000 (   1.22G)           800000 (   8.00M)      1
    (GAP)                                                  800000 (   8.00M)
 5: recovery                 4f400000 (   1.24G)          1800000 (  24.00M)      1
    (GAP)                                                  800000 (   8.00M)
 6: misc                     51400000 (   1.27G)           800000 (   8.00M)      1
    (GAP)                                                  800000 (   8.00M)
 7: dtbo                     52400000 (   1.29G)           800000 (   8.00M)      1
    (GAP)                                                  800000 (   8.00M)
 8: cri_data                 53400000 (   1.30G)           800000 (   8.00M)      2
    (GAP)                                                  800000 (   8.00M)
 9: param                    54400000 (   1.32G)          1000000 (  16.00M)      2
    (GAP)                                                  800000 (   8.00M)
10: boot                     55c00000 (   1.34G)          1000000 (  16.00M)      1
    (GAP)                                                  800000 (   8.00M)
11: rsv                      57400000 (   1.36G)          1000000 (  16.00M)      1
    (GAP)                                                  800000 (   8.00M)
12: metadata                 58c00000 (   1.39G)          1000000 (  16.00M)      1
    (GAP)                                                  800000 (   8.00M)
13: vbmeta                   5a400000 (   1.41G)           200000 (   2.00M)      1
    (GAP)                                                  800000 (   8.00M)
14: tee                      5ae00000 (   1.42G)          2000000 (  32.00M)      1
    (GAP)                                                  800000 (   8.00M)
15: vendor                   5d600000 (   1.46G)         14000000 ( 320.00M)      1
    (GAP)                                                  800000 (   8.00M)
16: odm                      71e00000 (   1.78G)          8000000 ( 128.00M)      1
    (GAP)                                                  800000 (   8.00M)
17: system                   7a600000 (   1.91G)         74000000 (   1.81G)      1
    (GAP)                                                  800000 (   8.00M)
18: product                  eee00000 (   3.73G)          8000000 ( 128.00M)      1
    (GAP)                                                  800000 (   8.00M)
19: data                     f7600000 (   3.87G)       1c27600000 ( 112.62G)      4
===================================================================================

to this with dclone mode (ampart /dev/mmcblk2 --mode dclone data::-1:4):

===================================================================================
ID| name            |          offset|(   human)|            size|(   human)| masks
-----------------------------------------------------------------------------------
 0: bootloader                      0 (   0.00B)           400000 (   4.00M)      0
    (GAP)                                                 2000000 (  32.00M)
 1: reserved                  2400000 (  36.00M)          4000000 (  64.00M)      0
    (GAP)                                                  800000 (   8.00M)
 2: cache                     6c00000 ( 108.00M)                0 (   0.00B)      0
    (GAP)                                                  800000 (   8.00M)
 3: env                       7400000 ( 116.00M)           800000 (   8.00M)      0
    (GAP)                                                  800000 (   8.00M)
 4: data                      8400000 ( 132.00M)       1d16800000 ( 116.35G)      4
===================================================================================

so then much more space can be used (4M-36M, 100M-116M, 117M-end) or even like this with another run in ecreate mode (ampart /dev/mmcblk2 --mode ecreate data:::)

===================================================================================
ID| name            |          offset|(   human)|            size|(   human)| masks
-----------------------------------------------------------------------------------
 0: bootloader                      0 (   0.00B)           400000 (   4.00M)      0
 1: env                        400000 (   4.00M)           800000 (   8.00M)      0
 2: cache                      c00000 (  12.00M)                0 (   0.00B)      0
    (GAP)                                                 1800000 (  24.00M)
 3: reserved                  2400000 (  36.00M)          4000000 (  64.00M)      0
 4: data                      6400000 ( 100.00M)       1d18800000 ( 116.38G)      4
===================================================================================

so even more space can be used (5-36M, 100M-end)

[ophub]

@7Ji

Thank you very much for your dedication.

For example, you mentioned in the article that deleting old versions every week will cause some file paths to fail, etc. I don't want to waste github space. If you need to save for a long time, you can appropriately extend the storage time (in fact, the new firmware and kernel are used, most people will not use the old version)

Since I don't know enough about the ArchLinux system and your project, you write a project introduction, including a link, and I will add an introduction to the homepage of the repository, so that more people can pay attention and use it.

Since I'm a beginner, I'm not familiar with many aspects. I'll keep working on it and try to learn more about your tutorial.

[7Ji]

I don't want to waste github space

It's a good thing, my reply in the AUR pacakge page https://aur.archlinux.org/packages/linux-firmware-amlogic-ophub was to FabioLolix, explaining why I couldn't use an easy-to-parse git tag in the source, so the AUR package could pull the source from e.g. https://github.com/ophub/amlogic-s9xxx-armbian/raw/Armbian_Aml_bullseye_11.07.0649/build-armbian/amlogic-armbian/firmware.tar.xz instead of https://github.com/ophub/amlogic-s9xxx-armbian/raw/099c353680b9f4584a7f71152b0a15d70d8fe114/build-armbian/amlogic-armbian/firmware.tar.xz. But it works either way as long as it uses a versioned link.

For the firmware package, nothing is stored on the AUR except a plain PKGBUILD file you can check here, which just downloads the firmware package from your repo and re-organize the files in the Arch style (i.e. no files should go under top-level /lib, /bin, /sbin, as Arch combined /usr long time ago). AUR is the beauty of ArchLinux as everyone can submit their PKGBUILD so many softwares you thought impossible to find and had to build from sources on other distros are maintained by users, and other users can just download these PKGBUILDs and use simple makepkg to build them, and the package manager Pacman will maintain it like other packages. With the help of AUR helpers like yay, even these AUR packages can be automatically upgraded.

project introduction

ampart: A partition tool that can read and edit Amlogic's proprietary eMMC partition table and DTB partitions, unleash 100% utilization of your eMMC capacity ampart：能读取并编辑Amlogic的专有eMMC分区表和DTB内分区的分区工具，100%利用eMMC 7Ji's blog: Reverse engineering and development on the Amlogic platform. ArchLinux ARM installation done in the ArchLinux way with thorough introduction to Amlogic platform's booting machanism and trivia 7Ji的博客：Amlogic平台上的逆向工程和开发，以ArchLinux的方式安装ArchLinux ARM，对Amlogic平台的启动等机制的介绍

[ophub]

https://github.com/ophub/amlogic-s9xxx-armbian/commit/98336ded42ede4096cc00576342a5005d65c1b23

你的博客和ampart项目介绍已经添加。你的文章写的很棒，很细致。

[Scirese]

@7Ji well，thanks for your attention. My article is just a shabby work completed in one day. I'm trying to make it simpler so many steps don't follow Arch's Style. I'm studying Manjaro's CI configuration to bring a Auto Build CI to my project like this one with a more Arch Linux way using pacstrap. And try to make anything I added in the package tree.

Personally I'm not good at tweaking Aml devices , so your article will definitely helps me a lot 👍 (And it's suggested to write English and Chinese tutorials separately)

[Scirese]

On devices with a mainline uboot, It's possible to boot the system through u-boot's EFI mode through GRUB, like the picture I attached in my previous post. And We will no longer need to process the initrd image every time we update kernel.

[7Ji]

It's possible to boot the system through u-boot's EFI mode through GRUB

With mainline, GRUB as a bootloader is not needed at all, u-boot has built-in support for syslinux (partiall, mainly for compatible configuration parsing), which can just load a syslinux-formated configuration file /extlinux/extlinux.conf or /boot/extlinux/extlinuconf.conf from a bootable partition: https://github.com/u-boot/u-boot/blob/77b5cc2948f5d93fe3d275302f596ffd8701a875/include/config_distro_bootcmd.h#L511

Which is documented in the blog, especially in the part #booting-configuration where syslinux, booting script and aml_autoscript are compared (EFI is omiited as it is really not needed, and there're too many EFI-compatible bootloaders, in which I would prefer kernel as EFISTUB or systemd-boot rather than a bootloader compatible with both legacy and EFI like GRUB. Also EFI is tried the last in the booting priority, after extlinux and script):

https://7ji.github.io/embedded/2022/11/08/alarm-install.html#booting-configuration--%E5%90%AF%E5%8A%A8%E9%85%8D%E7%BD%AE

with just some simple context like this:

LABEL   Arch Linux
LINUX   /boot/vmlinuz-linux-aarch64-flippy
INITRD  /boot/initramfs-linux-aarch64-flippy.img
FDT     /boot/dtbs/linux-aarch64-flippy/amlogic/meson-sm1-bananapi-m5.dtb
APPEND  root=UUID=5b6e6d63-686e-4ce0-a51d-22f8e68db73a rootflags=data=writeback rw rootfstype=ext4 console=ttyAML0,115200n8 console=tty0 fsck.fix=yes fsck.repair=yes

Take note of the file INITRD /boot/initramfs-linux-aarch64-flippy.img, which is a plain initramfs file, and not in the u-boot legacy initrd format, which is also documented there. I wrote cleanly only the booting scheme that relies on booti under the hood needs a u-boot legacy initrd. Even if booting with script, if you use sysboot or bootefi instead of booti under the hood, the legacy initrd is not required

That's also the reason why the pacakge uboot-legacy-initrd-hooks is just an optional dependency for linux-aarch64-flippy-bin: https://aur.archlinux.org/packages/uboot-legacy-initrd-hooks. The hooks are not needed for linux-aarch64-flippy-bin as long as the booting scheme does not rely on booti as written in the latter's package description: https://aur.archlinux.org/packages/linux-aarch64-flippy-bin

And it's suggested to write English and Chinese tutorials separately

In which case I would prefer to just omit one of them completely. Writing them side-by-side meaning they can be updated at the same time. A de-sync in the two versions is never a good idea, not like when one of them is maintained by a thrid transltater

[7Ji]

@Scirese

On devices with a mainline uboot, It's possible to boot the system through u-boot's EFI mode through GRUB, like the picture I attached in my previous post. And We will no longer need to process the initrd image every time we update kernel.

Adding to EFI, it's totally possible to just boot kernel itself as an EFI-STUB just like on x86-64, with minor tweaks that initrd should be specified with / instead of \ as path seperator, unlike x86-64:

U-Boot 2022.10-00001-g1563219ecf (Nov 09 2022 - 17:09:21 +0800) r3300l

Model: Amlogic Meson GXL (S905L) BesTV R3300L demo port by 7Ji
SoC:   Amlogic Meson GXL (S905L) Revision 21:c (c4:2)
DRAM:  1 GiB
Core:  169 devices, 23 uclasses, devicetree: separate
MMC:   mmc@70000: 2, mmc@72000: 0, mmc@74000: 1
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
[BL31]: tee size: 0
[BL31]: tee size: 0
Net:   eth0: ethernet@c9410000
Hit any key to stop autoboot:  0 
=> load mmc 1:4 ${fdt_addr_r} /boot/dtbs/linux-aarch64-flippy/amlogic/meson-gxl-s905x-p212.dtb
39634 bytes read in 3 ms (12.6 MiB/s)
=> load mmc 1:4 ${kernel_addr_r} /boot/vmlinuz-linux-aarch64-flippy
28541440 bytes read in 619 ms (44 MiB/s)
=> setenv bootargs 'initrd=/boot/initramfs-linux-aarch64-flippy.img root=UUID=9f75c223-4ebe-48b7-b4cb-f3823ed5f96f rootflags=data=writeback rw rootfstype=ext4 console=t
tyAML0,115200n8 console=tty0 fsck.fix=yes fsck.repair=yes'
=> bootefi ${kernel_addr_r} ${fdt_addr_r}
Card did not respond to voltage select! : -110
No EFI system partition
Booting /\boot\vmlinuz-linux-aarch64-flippy
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from command line option
EFI stub: Exiting boot services...
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 6.0.7-flippy-78+ (root@univm25) (Ubuntu clang version 14.0.0-1ubuntu1, Ubuntu LLD 14.0.0) #25 SMP Fri Nov 4 18:12:48 CST 2022
[    0.000000] Machine model: Amlogic Meson GXL (S905X) P212 Development Board
[    0.000000] efi: EFI v2.90 by Das U-Boot
[    0.000000] efi: RTPROP=0x3cf2f040 SMBIOS=0x3cf2b000 RNG=0x3cf24040 MEMRESERVE=0x3cf23040 
[    0.000000] efi: seeding entropy pool

And unlike sysboot, bootefi only supports standard initramfs where sysboot supports both standard and u-boot legacy. Since in sysboot and booti u-boot would unpack a legacy initrd to a standard initramfs, where in bootefi the kernel itself needs to read the un-parsed initrd from the underlying disk directly (which is a plus, though. And still as I said only those booting schemes that relies on booti needs legacy u-boot initrd and those hooks)

But the benifit of EFI on Aarch64 is really limited as there are only these variables available, comparing to x86-64 where there would be tens of useful efivars:

[nomad7ji@bestv7Ji ~]$ ls /sys/firmware/efi/efivars
AuditMode-8be4df61-93ca-11d2-aa0d-00e098032b8c               PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c       SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
DeployedMode-8be4df61-93ca-11d2-aa0d-00e098032b8c            PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c  VendorKeys-8be4df61-93ca-11d2-aa0d-00e098032b8c
OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c  SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c

I've added another part in the doc to describe how to encapsule this logic in a booting script: https://7ji.github.io/embedded/2022/11/08/alarm-install.html#efi-stub in the following commit: https://github.com/7Ji/7ji.github.io/commit/99c90aab0438cddac185415e8640e1ecadc808f6

A bare-minimum booting script to load kernel as EFI-STUB while keeping essential variables in a plain-text file:

[nomad7ji@bestv7Ji ~]$ cat /boot/boot.cmd 
load mmc 1:4 ${loadaddr} /boot/uEnv.txt
env import -t ${loadaddr}
load mmc 1:4 ${fdt_addr_r} ${FDT}
load mmc 1:4 ${kernel_addr_r} ${LINUX}
setenv bootargs "initrd=${INITRD} ${APPEND}"
bootefi ${kernel_addr_r} ${fdt_addr_r}
[nomad7ji@bestv7Ji ~]$ hexdump -C /boot/boot.scr 
00000000  27 05 19 56 d7 15 cf 24  63 6c 70 70 00 00 00 e7  |'..V...$clpp....|
00000010  00 00 00 00 00 00 00 00  fe dd 28 41 05 16 06 00  |..........(A....|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000040  00 00 00 df 00 00 00 00  6c 6f 61 64 20 6d 6d 63  |........load mmc|
00000050  20 31 3a 34 20 24 7b 6c  6f 61 64 61 64 64 72 7d  | 1:4 ${loadaddr}|
00000060  20 2f 62 6f 6f 74 2f 75  45 6e 76 2e 74 78 74 0a  | /boot/uEnv.txt.|
00000070  65 6e 76 20 69 6d 70 6f  72 74 20 2d 74 20 24 7b  |env import -t ${|
00000080  6c 6f 61 64 61 64 64 72  7d 0a 6c 6f 61 64 20 6d  |loadaddr}.load m|
00000090  6d 63 20 31 3a 34 20 24  7b 66 64 74 5f 61 64 64  |mc 1:4 ${fdt_add|
000000a0  72 5f 72 7d 20 24 7b 46  44 54 7d 0a 6c 6f 61 64  |r_r} ${FDT}.load|
000000b0  20 6d 6d 63 20 31 3a 34  20 24 7b 6b 65 72 6e 65  | mmc 1:4 ${kerne|
000000c0  6c 5f 61 64 64 72 5f 72  7d 20 24 7b 4c 49 4e 55  |l_addr_r} ${LINU|
000000d0  58 7d 0a 73 65 74 65 6e  76 20 62 6f 6f 74 61 72  |X}.setenv bootar|
000000e0  67 73 20 22 69 6e 69 74  72 64 3d 24 7b 49 4e 49  |gs "initrd=${INI|
000000f0  54 52 44 7d 20 24 7b 41  50 50 45 4e 44 7d 22 0a  |TRD} ${APPEND}".|
00000100  62 6f 6f 74 65 66 69 20  24 7b 6b 65 72 6e 65 6c  |bootefi ${kernel|
00000110  5f 61 64 64 72 5f 72 7d  20 24 7b 66 64 74 5f 61  |_addr_r} ${fdt_a|
00000120  64 64 72 5f 72 7d 0a                              |ddr_r}.|
00000127
[nomad7ji@bestv7Ji ~]$ cat /boot/uEnv.txt 
LINUX=/boot/vmlinuz-linux-aarch64-flippy
INITRD=/boot/initramfs-linux-aarch64-flippy.img
FDT=/boot/dtbs/linux-aarch64-flippy/amlogic/meson-gxl-s905x-p212.dtb
APPEND=root=UUID=9f75c223-4ebe-48b7-b4cb-f3823ed5f96f rootflags=data=writeback rw rootfstype=ext4 console=ttyAML0,115200n8 console=tty0 fsck.fix=yes fsck.repair=yes

[ophub]

[ophub]

https://github.com/7Ji/ampart/releases/download/v1.0/ampart-aarch64-static.xz

https://github.com/7Ji/ampart#usage

According to this usage, if it is readjusted, it can be used after 117M. The information I output after executing this command is as follows:

./ampart-aarch64-static /dev/mmcblk2 --mode dclone data::-1:4

LI mode dclone: No valid DTB, refuse to work

Is it possible to directly put the ampart binary file (ampart-aarch64-static) into the armbian system, after booting the system from usb, use

./ampart-aarch64-static /dev/mmcblk2 --mode dclone data::-1:4

Do a partition adjustment?

If it can be used in this way, before executing armbian-install, first perform partition adjustment, and then use the 117m of emmc for partition use.

[7Ji]

@ophub Are you using ampart on Phicomm N1? (because I saw s905d) N1's DTB is encrypted (and there's no one who can decrypt it yet) so it's impossible to edit the DTB on it, this is a known issue: https://github.com/7Ji/ampart/issues/2 Since Amlogic's u-boot will "helpfully" fix the EPT according to DTB, if DTB is not editable ampart will refuse to work on devices like this

[ophub]

Phicomm N1

Is there any standard output that returns success/failure to the interface?

[7Ji]

Unfortunately Phicomm N1 and post-Android 7 Xiaomi devices are the only devices with encryped DTB and therefore the EPT on them can't be be modified as ampart can't modify the encrypted DTB, and the stock u-boot will "helpfully" fix the EPT according to the stock DTB, which will effectively revert the EPT to what it's like before ampart modified the partiton table.

Also, d-prefixed modes are used to edit DTB, then update EPT according to the DTB with the same logic Amlogic uses in their u-boot. If DTB intergrity is not needed, then e-prefixed modes are more prefered (e.g. ampart /dev/mmcblk2 --mode ecreate data::: will just say f-word to Amlogic's 8M gap and 32M gap non-sense and insert those small partitions you can't remove into the gap between bootloader and reserved, and place data right after reserved)

[7Ji]

@ophub

Is there any standard output that returns success/failure to the interface?

Return code 0 is always for success, and others each with their meanings

The stdout and stderr in ampart has their specific usage. All of Amlogic's logs are printed to stderr, and stdout is kept for snapshot modes. An external script can run dnapshot mode to get the partition layout in DTB, and esnapshot mode to get the partition layout in EPT. The snapshots always 3, sepeareted by '\n', first script-friendly decimal, second script-friendly hex-decimal, third human-readable

IFS=$'\n'
dtb_partition_snapshots=($(ampart /dev/mmcblk2 --mode dsnapshot 2>/dev/null))
ept_partition_snapshots=($(ampart /dev/mmcblk2 --mode esnapshot 2>/dev/null))
unset IFS

Then these two arraies will give your DTB and EPT layout, with each partition seperated by space ' ' Then if you just want the partitions snapshot with decimal which you can parse with scripts:

dtb_decimal_snapshot=${dtb_partition_snapshots[0]}
ept_decimal_snapshot=${ept_partition_snapshots[0]}

The partitions can then be gotten as an array:

dtb_partitions=(${dtb_decimal_snapshot})
ept_partitions=(${ept_decimal_snapshot})

And then each partition in the array can be splitted on :, first is name, second is offset, thrid is size, fourth is masks. So you can analyze the partitions in bash natively

With this, you can e.g. compare the snapshot and check if the table is already modified; apply a pre-defiend snapshot in dclone or eclone mode according to the specific device, and etc

[ophub]

After using this tool to adjust the partition, if the user uses the usb_burning_tool to flash into the original Android TV system. Will the partition be restored to its original state?

[7Ji]

Yes, a flashing with the stock firmware with either USB burning tool or a SD burning card can just revert everything ampart has done.

[ophub]

Besides the N1, which device did you find not working?

[7Ji]

Only the following devices, as checked, has encrypted DTB so their partition layout can't be modified:

• Phicomm N1 (any firmware)
• Xiaomi device with a >=Android 8 firmware, Android 7 is OK

The following devices, as checked, work fine as their DTB is not encrypted:

• HK1 Box
• HK1 Rbox X3
• Xiaomi mibox3/3c
• BesTV R3300L
• Bananapi BPi M5
• Beelink GT2mini1

[7Ji]

Also it's probably possible to use ampart on Phicomm N1, if the on-eMMC DTB is replaced with an unencrypted one

Also, the modes dclone and eclonde are mainly used to restore a snapshot taken in dsnapshot and esnapshot modes. It's better to get a better template dtb snapshot with dedit mode, and probably per-device ept snapshot with eedit and ecreate mode if some specific layouts are more preferred

ophub @.***> 于 2022年11月10日周四 下午1:40写道：

Besides the N1, which device did you find not working?

— Reply to this email directly, view it on GitHub https://github.com/ophub/amlogic-s9xxx-armbian/issues/620#issuecomment-1309803817, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF2CYEX5YJWISSGIDOLYB2TWHSDE5ANCNFSM6AAAAAAREKDM2M . You are receiving this because you were mentioned.Message ID: @.***>

[ophub]

This tool is a gem for amlogic's TV boxes with only a few gigabytes of emmc space. Not only does it use more space, it also reduces concerns about writing to unsafe data areas.

https://github.com/7Ji/ampart/releases/download/v1.0/ampart-aarch64-static.xz

Download and unzip, upload to Armbian system in USB. After booting from USB, execute the following command to adjust the partition.

01. Resize partition

./ampart-aarch64-static /dev/mmcblk2 --mode dclone data::-1:4

02. If the adjustment is successful, it will output information:

CLI write EPT: Write successful

03. Modify the [ armbian-install ] of the a script, set your own device id to use the full partition

    elif [[ "${boxid}" -eq "xxx" ]]; then
        BLANK1="117"
        BOOT="256"
        BLANK2="0"

[ophub]

ampart /dev/mmcblk2 --mode dclone data::-1:4

IFS=$'\n'
dtb_partition_snapshots=($(ampart /dev/mmcblk2 --mode dsnapshot 2>/dev/null))
unset IFS

dtb_decimal_snapshot=${dtb_partition_snapshots[0]}

dtb_partitions=(${dtb_decimal_snapshot})

[[ ${dtb_partitions[@]} == "data::-1:4"  ]] && echo "CLI write EPT: Write successful"

If the partition is successful, its value is a fixed value: data::-1:4 right?

[7Ji]

@ophub

[[ ${dtb_partitions} == "data::-1:4"  ]] && echo "CLI write EPT: Write successful"

This is not correct due to the Bash syntax for array

For bash arrays, if you just use its name, that'll be only the first item, to refer to the whole array, use a [@], the line should be changed to like this:

[[ "${dtb_partitions[@]}" == "data::-1:4"  ]] && echo "CLI write EPT: Write successful"

An example script to only do the adjustment once:

# $1: the eMMC device, or the block device for reserved partition, or a DTB block device or the dumpped image of these three devices
SNAPSHOT='data::-1:4'
LOG=$(ampart "$1" --mode dsnapshot 2>/dev/null)
if (( $? )); then
  echo 'Failed to get DTB snapshot!'
  exit 1
fi
readarray -d $'\n' -t DTB_SNAPSHOTS <<< "${LOG}"
# 0 is decimal, 1 is hex, 2 is human-readable
echo "Please use the following snapshot to restore the DTB partitions if anything goes wrong:"
echo "${DTB_SNAPSHOTS[2]}"
# Note an addtional ' ' here, it's implicitly added after each partition. The comparasion could also be done after the new array PARTITIONS is created, but that's not neccessary if we can do it here right?
if [ "${DTB_SNAPSHOTS[0]}" == "${SNAPSHOT} " ]; then
  echo 'DTB partitions layout has already been modified, no need to update it'
  exit 0
fi
readarray -d ' ' -t PARTITIONS < <(printf '%s' "${DTB_SNAPSHOTS[0]}")
if ! (( ${#PARTITIONS[@]} )); then
  echo 'No partitions in DTB, this is impossible, did you use ampart to modify the DTB yourself?'
  exit 2
fi
echo "Existing partitions in DTB:"
for i in $(seq 0 $(("${#PARTITIONS[@]}"-1)) ); do
  readarray -d ':' -t PARTINFO < <(printf '%s' "${PARTITIONS[$i]}")
  echo "Partition $i: ${PARTINFO[0]}, size ${PARTINFO[2]}, masks ${PARTINFO[3]}"
done
ampart "$1" --mode dclone ${SNAPSHOT} 2>/dev/null
if (( $? )); then
  echo 'Failed to adjust DTB partitions!'
  exit 3
fi
echo 'Successfully adjusted DTB partitions'

Two continous runs yield the following output:

[nomad7ji@laptop7ji images]$ sh ../scripts/dclone_once.sh x3_emmc.img 
Please use the following snapshot to restore the DTB partitions if anything goes wrong:
logo::8M:1 recovery::24M:1 misc::8M:1 dtbo::8M:1 cri_data::8M:2 param::16M:2 boot::16M:1 rsv::16M:1 metadata::16M:1 vbmeta::2M:1 tee::32M:1 vendor::320M:1 odm::128M:1 system::1856M:1 product::128M:1 cache::1120M:2 data::-1:4 
Existing partitions in DTB:
Partition 0: logo, size 8388608, masks 1
Partition 1: recovery, size 25165824, masks 1
Partition 2: misc, size 8388608, masks 1
Partition 3: dtbo, size 8388608, masks 1
Partition 4: cri_data, size 8388608, masks 2
Partition 5: param, size 16777216, masks 2
Partition 6: boot, size 16777216, masks 1
Partition 7: rsv, size 16777216, masks 1
Partition 8: metadata, size 16777216, masks 1
Partition 9: vbmeta, size 2097152, masks 1
Partition 10: tee, size 33554432, masks 1
Partition 11: vendor, size 335544320, masks 1
Partition 12: odm, size 134217728, masks 1
Partition 13: system, size 1946157056, masks 1
Partition 14: product, size 134217728, masks 1
Partition 15: cache, size 1174405120, masks 2
Partition 16: data, size -1, masks 4
Successfully adjusted DTB partitions
[nomad7ji@laptop7ji images]$ sh ../scripts/dclone_once.sh x3_emmc.img 
Please use the following snapshot to restore the DTB partitions if anything goes wrong:
data::-1:4 
DTB partitions layout has already been modified, no need to update it

[ophub]

OK, the syntax error has been fixed.

[Scirese]

@ophub Why not enable discussion for this repo? There's something probably should not be talked in issues.

[ophub]

i will not set

[xiayang0521]

感谢你的分享，不仅热心，还有完善的文档说明，你不仅直接帮助到很多人，也给很多人带来启发。

应该的 ~其实我还试了安装NixOS~

见过N1的CentOS安装教程，这么详细的arch安装教程很棒！