duhow
Is this the correct image?
I have a MDZ-25-DT, according to the documentation I exported the image, run binwalk command, and displayed
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UBI erase count header, version: 1, EC: 0xC, VID header offset: 0x800, data offset: 0x1000
Is this the correct image? I copy it from /dev/mtd4.
UBI is the writable partition (config and data).
Run dmesg and cat /proc/mtd, you're looking for the system / rootfs partition.
- in fact I would keep a backup of all partitions just in case need to recover anything.
UBIis the writable partition (config and data). Rundmesgandcat /proc/mtd, you're looking for the system / rootfs partition.
- in fact I would keep a backup of all partitions just in case need to recover anything.
I run cat /proc/mtd and displayed
dev: size erasesize name
mtd0: 00200000 00020000 "nandboot"
mtd1: 01000000 00020000 "boot0"
mtd2: 01000000 00020000 "boot1"
mtd3: 06040000 00020000 "system0"
mtd4: 06040000 00020000 "system1"
mtd5: 01780000 00020000 "data"
I copied every partition except for mtd0 because it showed dd: /dev/mtd0: No such device,and run binwalk command, and displayed
mdt1
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Android bootimg, kernel size: 8633480 bytes, kernel addr: 0x10008000, ramdisk size: 1357840 byte
s, ramdisk addr: 0x11000000, product name: ""
2048 0x800 Linux kernel ARM64 image, load offset: 0x1080000, image size: 9744384 bytes, little endian, plac
e kernel close to DRAM base
91408 0x16510 SHA256 hash constants, little endian
106720 0x1A0E0 AES S-Box
106976 0x1A1E0 AES Inverse S-Box
5716112 0x573890 Linux kernel version 3.14.2
5738824 0x579148 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null d
ate)
5886568 0x59D268 DES SP2, little endian
5887336 0x59D568 DES SP1, little endian
7127536 0x6CC1F0 Unix path: /home/jenkins/mico/platform/s12/build_dir/target-aarch64_armv8-a_glibc-2.19/linux-mes
on_gxl/linux-3.14.29/arch/arm64/include/asm
7146704 0x6D0CD0 Unix path: /dev/vc/0
7197456 0x6DD310 xz compressed data
7219968 0x6E2B00 Unix path: /lib/firmware/updates/3.14.29
7463104 0x71E0C0 Neighborly text, "NeighborSolicits"
7463128 0x71E0D8 Neighborly text, "NeighborAdvertisementsErrors"
7469938 0x71FB72 Neighborly text, "neighbor %.2x%.2x.%pM lost rename link %s to %s"
7487133 0x723E9D Neighborly text, "Neighbor"
8055504 0x7AEAD0 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null d
ate)
8108032 0x7BB800 ELF, 64-bit LSB shared object, version 1 (SYSV)
8113408 0x7BCD00 CRC32 polynomial table, little endian
8193976 0x7D07B8 Unix path: /dev/block/instaboot
8272688 0x7E3B30 Intel x86 or x64 microcode, sig 0xffffffc0, pf_mask 0xfffffff6, 1970-01-28, size 1
8636416 0x83C800 gzip compressed data, maximum compression, from Unix, last modified: 2019-11-11 03:59:59
9996288 0x988800 Flattened device tree, size: 32190 bytes, version: 17
10014263 0x98CE37 eCos RTOS string reference: "ecos"
10014314 0x98CE6A eCos RTOS string reference: "ecos_memory"
mdt2
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Android bootimg, kernel size: 8633480 bytes, kernel addr: 0x10008000, ramdisk size: 1357901 byte
s, ramdisk addr: 0x11000000, product name: ""
2048 0x800 Linux kernel ARM64 image, load offset: 0x1080000, image size: 9744384 bytes, little endian, plac
e kernel close to DRAM base
91408 0x16510 SHA256 hash constants, little endian
106720 0x1A0E0 AES S-Box
106976 0x1A1E0 AES Inverse S-Box
5716112 0x573890 Linux kernel version 3.14.2
5738824 0x579148 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null d
ate)
5886568 0x59D268 DES SP2, little endian
5887336 0x59D568 DES SP1, little endian
7127536 0x6CC1F0 Unix path: /home/jenkins/mico/platform/s12/build_dir/target-aarch64_armv8-a_glibc-2.19/linux-mes
on_gxl/linux-3.14.29/arch/arm64/include/asm
7146704 0x6D0CD0 Unix path: /dev/vc/0
7197456 0x6DD310 xz compressed data
7219968 0x6E2B00 Unix path: /lib/firmware/updates/3.14.29
7463104 0x71E0C0 Neighborly text, "NeighborSolicits"
7463128 0x71E0D8 Neighborly text, "NeighborAdvertisementsErrors"
7469938 0x71FB72 Neighborly text, "neighbor %.2x%.2x.%pM lost rename link %s to %s"
7487133 0x723E9D Neighborly text, "Neighbor"
8055504 0x7AEAD0 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null d
ate)
8108032 0x7BB800 ELF, 64-bit LSB shared object, version 1 (SYSV)
8113408 0x7BCD00 CRC32 polynomial table, little endian
8193976 0x7D07B8 Unix path: /dev/block/instaboot
8272688 0x7E3B30 Intel x86 or x64 microcode, sig 0xffffffc0, pf_mask 0xfffffff6, 1970-01-28, size 1
8636416 0x83C800 gzip compressed data, maximum compression, from Unix, last modified: 2020-11-27 10:53:40
9996288 0x988800 Flattened device tree, size: 32190 bytes, version: 17
10014263 0x98CE37 eCos RTOS string reference: "ecos"
10014314 0x98CE6A eCos RTOS string reference: "ecos_memory"
mtd3
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UBI erase count header, version: 1, EC: 0xA, VID header offset: 0x800, data offset: 0x1000
mtd4
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UBI erase count header, version: 1, EC: 0xC, VID header offset: 0x800, data offset: 0x1000
mtd5
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UBI erase count header, version: 1, EC: 0x14, VID header offset: 0x800, data offset: 0x1000
192096 0x2EE60 Unix path: /usr/share/mico/mediaplayer.cfg
192912 0x2F190 Unix path: /usr/share/mico/player.cfg
Which is the rootfs partition?
Can you copy /dev/mtdblock + N instead of /dev/mtd ?
Not expecting to see UBIfs in system partitions...
Can you copy
/dev/mtdblock+ N instead of/dev/mtd? Not expecting to see UBIfs in system partitions...
When i copy /dev/mtdblock3 and /dev/mtdblock4 displayed dd: /dev/mtdblock3: Input/output error
/dev/mtdblock1 and /dev/mtdblock2 displayed
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Android bootimg, kernel size: 8633480 bytes, kernel addr: 0x10008000, ramdisk size: 1357840 byte
s, ramdisk addr: 0x11000000, product name: ""
2048 0x800 Linux kernel ARM64 image, load offset: 0x1080000, image size: 9744384 bytes, little endian, plac
e kernel close to DRAM base
91408 0x16510 SHA256 hash constants, little endian
106720 0x1A0E0 AES S-Box
106976 0x1A1E0 AES Inverse S-Box
5716112 0x573890 Linux kernel version 3.14.2
5738824 0x579148 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null d
ate)
5886568 0x59D268 DES SP2, little endian
5887336 0x59D568 DES SP1, little endian
7127536 0x6CC1F0 Unix path: /home/jenkins/mico/platform/s12/build_dir/target-aarch64_armv8-a_glibc-2.19/linux-mes
on_gxl/linux-3.14.29/arch/arm64/include/asm
7146704 0x6D0CD0 Unix path: /dev/vc/0
7197456 0x6DD310 xz compressed data
7219968 0x6E2B00 Unix path: /lib/firmware/updates/3.14.29
7463104 0x71E0C0 Neighborly text, "NeighborSolicits"
7463128 0x71E0D8 Neighborly text, "NeighborAdvertisementsErrors"
7469938 0x71FB72 Neighborly text, "neighbor %.2x%.2x.%pM lost rename link %s to %s"
7487133 0x723E9D Neighborly text, "Neighbor"
8055504 0x7AEAD0 gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null d
ate)
8108032 0x7BB800 ELF, 64-bit LSB shared object, version 1 (SYSV)
8113408 0x7BCD00 CRC32 polynomial table, little endian
8193976 0x7D07B8 Unix path: /dev/block/instaboot
8272688 0x7E3B30 Intel x86 or x64 microcode, sig 0xffffffc0, pf_mask 0xfffffff6, 1970-01-28, size 1
8636416 0x83C800 gzip compressed data, maximum compression, from Unix, last modified: 2019-11-11 03:59:59
9996288 0x988800 Flattened device tree, size: 32190 bytes, version: 17
10014263 0x98CE37 eCos RTOS string reference: "ecos"
10014314 0x98CE6A eCos RTOS string reference: "ecos_memory"
/dev/mtdblock5
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UBI erase count header, version: 1, EC: 0x14, VID header offset: 0x800, data offset: 0x1000
192096 0x2EE60 Unix path: /usr/share/mico/mediaplayer.cfg
192912 0x2F190 Unix path: /usr/share/mico/player.cfg
Despite the Input/output error in partitions 3 and 4, it does not generate any file? Should be readable anyway.
Did you connect the device to Wifi? Do you know if it upgraded system?
Despite the
Input/output errorin partitions 3 and 4, it does not generate any file? Should be readable anyway. Did you connect the device to Wifi? Do you know if it upgraded system?
I try to do it.
/dev/mtdblock3 and /dev/mtdblock4 displayed
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UBI erase count header, version: 1, EC: 0xC, VID header offset: 0x800, data offset: 0x1000
I had connect the device to Wifi, I don't know if the system has been upgraded, the version is 1.56.xx.
So they really have another format... Can you share those files with me so I can do some research? They don't use the usual squashfs which is expected.
So they really have another format... Can you share those files with me so I can do some research? They don't use the usual squashfs which is expected.
Please download from this link https://cowtransfer.com/s/8e18cf3704ac48
I managed to extract part of the rootfs files, cannot find a proper tool at the moment.
From the boardupgrade.sh you can see the commands involved ruing the update process:
dd if=root.ubi.lzma of=len.bin bs=1 count=4 skip=5 2&>1 > /dev/null
len=`hexdump -e '1/4 "%d"' len.bin`
[ -z "$len" ] && {
klogger "Unable to get image length"
return 1
}
klogger "Burning $dev rootfs Block, image length "$len""
unlzma -c root.ubi.lzma | ubiformat "$dev" -s 2048 -O 2048 -S "$len" -y -f -
klogger "Done"
klogger "Verify burning..."
# Try attach the device
ubiattach /dev/ubi_ctrl -d "$devn" -O 2048 -p "$dev"
if [ "$?" = "0" ]; then
klogger "PASSED"
ubidetach -d "$devn"
fi
What would be expected is having the mtd or a dd command flashing directly the squashfs image, but since here it's using (LZMA +) UBI formatted images, means that the S12 / MDZ-25-DT speaker has a different way of generating and flashing the image.
What's more strange is, from the files you provided, the images have huge different sizes, I was expecting 2 rootfs with 40MB but instead there are 87 MB and 55 MB. Either the dump is invalid or the system transforms the data filesystem (decompressed?) while dumping.
I'll continue looking.
Been able to get some more info, having problems to access to /etc folder as mounting the UBI file describes as damaged. I'll guess next step is to get the update firmware file and try from there.
ARM aarch64 GLIBC_2.19 OpenWrt/Linaro GCC 4.8-2014.04 unknown 4.8.3
S12 1.54.1 b9e9b6640c2491c7a77a22612e47790e6c8c0356 11 Nov 2019 11:18:09 +0800
(Note S12 is different to S12A)
apt-get install mtd-utils
modprobe nandsim first_id_byte=0xec second_id_byte=0xa1 third_id_byte=0x00 fourth_id_byte=0x15
modprobe ubi mtd=0
ubidetach /dev/ubi_ctrl -m 0
ubiformat /dev/mtd0 -f mtd3.bin -s 2048 -O 2048 -y
ubiattach /dev/ubi_ctrl -m 0 -O 2048
mount -t ubifs ubi0 /mnt
https://www.right.com.cn/forum/thread-4049274-1-1.html https://bbs.hassbian.com/thread-7060-1-1.html
@Mybrc91 can you provide output of the device when attaching to serial port and booting, and dmesg output as well? That will output some hardware info useful as well.
root@nukevim:~# ubinfo -a
UBI version: 1
Count of UBI devices: 1
UBI control device major/minor: 10:61
Present UBI devices: ubi0
ubi0
Volumes count: 1
Logical eraseblock size: 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks: 1024 (130023424 bytes, 124.0 MiB)
Amount of available logical eraseblocks: 0 (0 bytes)
Maximum count of volumes 128
Count of bad physical eraseblocks: 0
Count of reserved physical eraseblocks: 20
Current maximum erase counter value: 2
Minimum input/output unit size: 2048 bytes
Character device major/minor: 244:0
Present volumes: 0
Volume ID: 0 (on ubi0)
Type: dynamic
Alignment: 1
Size: 1000 LEBs (126976000 bytes, 121.0 MiB)
State: OK
Name: rootfs
Character device major/minor: 244:1
I've added support for extract and building images in 1cea2d41aa8c99d58ecef59ec974c01938153b60 , if you want to try it out. Do triple check before flashing!
@Mybrc91 can you provide output of the device when attaching to serial port and booting, and
dmesgoutput as well? That will output some hardware info useful as well.
boot log: https://cowtransfer.com/s/91121554434840 dmesg: https://cowtransfer.com/s/f287be90a17b47
Memory hardware is different. Other speakers I've tried use a 1Gb Flash memory, which leaves about 128MB of space, and 32-40MB size for each system partition. As described in your bootlog, hardware is 2Gb Flash Memory (256MB), which explains why the images are bigger.
NAND: nand id: 152 218
256MiB, SLC, page size: 2048, OOB size: 64
Creating 6 MTD partitions on "A revision NAND 2Gib TC58BVG1S3HTA00 ":
0x000000000000-0x000000200000 : "nandboot"
0x000000800000-0x000001800000 : "boot0"
0x000001800000-0x000002800000 : "boot1"
0x000002800000-0x000008840000 : "system0"
0x000008840000-0x00000e880000 : "system1"
0x00000e880000-0x000010000000 : "data"
This is about 98560 KB per system partition. UBI image cannot exceed this size. Data partition is 24064 KB.
[ 0.636960@3] UBI: attaching mtd4 to ubi0
[ 0.917568@3] UBI: scanning is finished
[ 0.922464@0] UBI: attached mtd4 (name "system1", size 96 MiB) to ubi0
[ 0.922473@0] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 0.922478@0] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 0.922482@0] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 0.922486@0] UBI: good PEBs: 768, bad PEBs: 2, corrupted PEBs: 0
[ 0.922489@0] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
[ 0.922494@0] UBI: max/mean erase counter: 12/7, WL threshold: 4096, image sequence number: 150629729
[ 0.922499@0] UBI: available PEBs: 0, total reserved PEBs: 768, PEBs reserved for bad PEB handling: 38
[ 0.922509@1] UBI: background thread "ubi_bgt0d" started, PID 680
[ 0.926288@1] UBIFS: background thread "ubifs_bgt0_0" started, PID 683
[ 0.946440@3] UBIFS: recovery needed
[ 1.014255@3] UBIFS: recovery completed
[ 1.014334@3] UBIFS: mounted UBI device 0, volume 0, name "rootfs"
[ 1.014339@3] UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[ 1.014345@3] UBIFS: FS size: 90787840 bytes (86 MiB, 715 LEBs), journal size 9023488 bytes (8 MiB, 72 LEBs)
[ 1.014349@3] UBIFS: reserved for root: 0 bytes (0 KiB)
[ 5.262138@2] UBI: attaching mtd5 to ubi1
[ 5.329494@2] UBI: scanning is finished
[ 5.334259@0] UBI: attached mtd5 (name "data", size 23 MiB) to ubi1
[ 5.334269@0] UBI: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[ 5.334274@0] UBI: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[ 5.334278@0] UBI: VID header offset: 2048 (aligned 2048), data offset: 4096
[ 5.334282@0] UBI: good PEBs: 188, bad PEBs: 0, corrupted PEBs: 0
[ 5.334286@0] UBI: user volume: 1, internal volumes: 1, max. volumes count: 128
[ 5.334290@0] UBI: max/mean erase counter: 27/19, WL threshold: 4096, image sequence number: 504609476
[ 5.334294@0] UBI: available PEBs: 0, total reserved PEBs: 188, PEBs reserved for bad PEB handling: 40
[ 5.334306@3] UBI: background thread "ubi_bgt1d" started, PID 914
[ 5.339239@3] UBIFS: background thread "ubifs_bgt1_0" started, PID 917
[ 5.359643@0] UBIFS: recovery needed
[ 5.419568@0] UBIFS: recovery completed
[ 5.419645@0] UBIFS: mounted UBI device 1, volume 0, name "data"
[ 5.419650@0] UBIFS: LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[ 5.419656@0] UBIFS: FS size: 17014784 bytes (16 MiB, 134 LEBs), journal size 1015809 bytes (0 MiB, 7 LEBs)
[ 5.419660@0] UBIFS: reserved for root: 803650 bytes (784 KiB)
So, in order to prepare a custom image, do the following steps:
Since the backup files seem to have problems while mounting, we'll start patching from clean image, download the update firmware.
In your case the system0 image is using latest firmware 1.54.1, so I'd go there.
https://bigota.miwifi.com/xiaoqiang/rom/s12/mico_firmware_f07b1_1.54.1.bin https://bigota.miwifi.com/xiaoqiang/rom/s12/mico_firmware_0d292_1.52.1.bin
Extract update content from bin file with https://github.com/NyaMisty/mkxqimage_rev tool . Decompress the root.ubi.lzma file.
mkxqimage -r -x update.bin
unlzma root.ubi.lzma
You can build all programs you want to copy to speaker with package.sh, or use default set.
Remember to run this inside a Docker container by using the provided Dockerfile.
After that you should be able to run the rest of the patching as usual. If you want to keep Xiaomi programs working (voice assistant), please edit scripts and patches before applying.
sudo make clean all MODEL=s12 FILE=root.ubi
Once you have this, copy the patched image to the speaker RAM /tmp and perform update.
Remember to flash the system partition that is not in use.
Check ls -l /dev/root or df, if it says mtd3 (in use), flash mtd4.
Following the upgrade script, it should be something like:
# get bytes size of update file
len=$(stat -c %s patched.ubi)
# apply upgrade
ubiformat /dev/mtd4 -s 2048 -O 2048 -S "$len" -y -f patched.ubi
# Try attach the device 2 (static) to check flash works
ubiattach /dev/ubi_ctrl -d 2 -O 2048 -p /dev/mtd4
# if works, unmount.
ubidetach -d 2
# change boot to the next partition.
# mtd3 = boot0, mtd4 = boot1, as in partition name.
fw_setenv boot_part boot1
sync
reboot
@duhow Sorry, I was very busy some time ago and never had time to try. I'm ready to try it recently and I have the following questions.
- Do I need to downgrade the firmware version to 1.54.1 or 1.52.1 first? I run the
cat /usr/share/mico/versioncommand which shows the following
config core 'version'
# ROM ver
option ROM '1.56.5'
# channel
option CHANNEL 'release'
# hardware platform
option HARDWARE 'S12'
# Bootload
option UBOOT '1.0.2'
# Linux Kernel ver
option LINUX '0.0.1'
# RAMFS ver
option RAMFS '0.0.1'
# SQUASHFS ver
option SQAFS '0.0.1'
# ROOTFS ver
option ROOTFS '0.0.1'
#build time
option BUILDTIME 'Fri, 27 Nov 2020 18:15:22 +0800'
#build timestamp
option BUILDTS '1606472122'
#build git tag
option GTAG 'commit b9e9b6640c2491c7a77a22612e47790e6c8c0356'
config miio 'miio'
#product id from iot.mi.com
option product_id '0000'
option module 'xiaomi.wifispeaker.s12'
option ssid_prefix 'xiaomi-wifispeaker-s12_miap'
config player 'player'
option VOLUME '100'
- When i run the command
ls -l /dev/rootor 'df' which shows the following
root@S12:~# ls -l /dev/root
ls: /dev/root: No such file or directory
root@S12:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
rootfs 81312 40772 40540 50% /
/dev/ubi0_0 81312 40772 40540 50% /
devtmpfs 512 0 512 0% /dev
tmpfs 120464 932 119532 1% /tmp
tmpfs 512 0 512 0% /dev
/dev/ubi1_0 14676 1800 12092 13% /data
So, i don't know which system partition that is not in use.I find UBI: attached mtd4 (name "system1", size 96 MiB) to ubi0 in dmesg, is it means mtd4 is in use?
@Mybrc91: You can do cat /proc/mtd to get an overview of the partitions on the device and what they're used for. fw_env -g boot_part shows you which boot partition is in use currently (boot0 or boot1). The partitions come in pairs, so boot0 and system0 are one, boot1 and system1 the other.
You can switch to the other partition pair using fw_env -s boot_part bootX with the number that is currently not in use. Make sure to have bootdelay set to 3 though, in case the other partition is empty. You can check with fw_env -g bootdelay.
@Mybrc91: You can do cat /proc/mtd to get an overview of the partitions on the device and what they're used for. fw_env -g boot_part shows you which boot partition is in use currently (boot0 or boot1). The partitions come in pairs, so boot0 and system0 are one, boot1 and system1 the other.
You can switch to the other partition pair using fw_env -s boot_part bootX with the number that is currently not in use. Make sure to have bootdelay set to 3 though, in case the other partition is empty. You can check with fw_env -g bootdelay.
@hillbicks Thank you. The fw_env is not found in s12 device, but i found fw_printenv boot_part ,it runs well, i got the boot partition with your help.
Also you can check cat /proc/cmdline which is set from Uboot and contains the root partition that is booting at the moment.
Each speaker has a different way of showing the current partition used.
Regarding firmware version mismatch, I think it is a mix of both the application and rootfs files, regarding Linux system they should not differ too much unless they add new security measures to SSH login and stuff. So no worries in here. The purpose in here is to add your built binary programs and allow you to access to the speaker via SSH.
You can flash the Kernel partition if you want with the one bundled in the update binary file (just to downgrade Kernel to same version as the rootfs base), but I don't think it is needed.
When i run docker run -it -v $PWD:/xiaoai xiaoai-patch, some errors have occurred. I run it on Mac os( Intel cpu).
make[2]: *** [../o-iterator.mk:9: /xiaoai/build-packages/build/armv7/glibc-build/dlfcn/stamp.oS] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/xiaoai/build-packages/build/armv7/glibc/dlfcn'
make[1]: *** [Makefile:215: dlfcn/subdir_lib] Error 2
make[1]: Leaving directory '/xiaoai/build-packages/build/armv7/glibc'
make: *** [Makefile:9: all] Error 2
make_package returned error
Build for package 'glibc' not completed
Try rebuilding that package, delete file build-packages/build/armv7/glibc.status and start docker process again?
Try rebuilding that package, delete file
build-packages/build/armv7/glibc.statusand start docker process again?
The same error. I delete file delete file build-packages/build/armv7/glibc.status and restart the build.
Try rebuilding that package, delete file
build-packages/build/armv7/glibc.statusand start docker process again?
I am building it in a Linux os, just wait for the results.
Unfortunately the docker build failed, my cloud hosting configuration is too low and the build got stuck much times.I give up.Can i use the actions's build output? Which directory to extract to？
Yes, the generated artifact files in Github are the same that will be copied. Files need to be available in this folder. https://github.com/duhow/xiaoai-patch/blob/e584099699f7ea3ae316e763f3e63f76107f063c/scripts/92_copy_build_packages.sh#L3
When i run sudo make clean all MODEL=s12 FILE=root.ubi which shows the following
umount -q /mnt/ubi.tmp || true
umount: /mnt/ubi.tmp: no mount point specified.
rmmod ubifs ubi nandsim || true
rmmod: ERROR: Module ubifs is not currently loaded
rm -rf /mnt/ubi.tmp 2>/dev/null
modprobe nandsim first_id_byte=0xec second_id_byte=0xa1 third_id_byte=0x00 fourth_id_byte=0x15
modprobe ubi mtd=0
umount -q /mnt/ubi.tmp || true
umount: /mnt/ubi.tmp: no mount point specified.
ubidetach /dev/ubi_ctrl -m 0
ubiformat /dev/mtd0 -f root.ubi -s 2048 -O 2048 -y
ubiformat: mtd0 (nand), size 134217728 bytes (128.0 MiB), 1024 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 1023 -- 100 % complete
ubiformat: 712 eraseblocks have valid erase counter, mean value is 1
ubiformat: 312 eraseblocks are supposedly empty
ubiformat: warning!: only 712 of 1024 eraseblocks have valid erase counter
ubiformat: mean erase counter 1 will be used for the rest of eraseblock
ubiformat: use erase counter 1 for all eraseblocks
ubiformat: warning!: VID header and data offsets on flash are 512 and 2048, which is different to requested offsets 2048 and 4096
ubiformat: use new offsets 2048 and 4096? yes
ubiformat: use offsets 2048 and 4096
ubiformat: flashing eraseblock 448 -- 100 % complete
ubiformat: formatting eraseblock 1023 -- 100 % complete
make: *** [Makefile:45: extract_ubifs] Error 255
What FILE are you using? Is that the one dumped from your speaker or did you extract it from the update file?
Can you try running the step extract_ubifs commands manually?