Closed Mybrc91 closed 4 months ago
duhow
commented
3 years ago UBI is the writable partition (config and data).
Run dmesg and cat /proc/mtd, you're looking for the system / rootfs partition.
Mybrc91
commented
3 years ago
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: 0x1000mtd4
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 UBI erase count header, version: 1, EC: 0xC, VID header offset: 0x800, data offset: 0x1000mtd5
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.cfgWhich is the rootfs partition?
duhow
commented
3 years ago Can you copy /dev/mtdblock + N instead of /dev/mtd ?
Not expecting to see UBIfs in system partitions...
Mybrc91
commented
3 years ago 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.cfgDespite 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?
Mybrc91
commented
3 years ago 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: 0x1000I had connect the device to Wifi, I don't know if the system has been upgraded, the version is 1.56.xx.
duhow
commented
3 years ago 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.
Mybrc91
commented
3 years ago 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
duhow
commented
3 years ago 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"
fiWhat 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.
duhow
commented
3 years ago 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 /mnthttps://www.right.com.cn/forum/thread-4049274-1-1.html https://bbs.hassbian.com/thread-7060-1-1.html
duhow
commented
3 years ago @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.
duhow
commented
3 years ago 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:1I've added support for extract and building images in 1cea2d41aa8c99d58ecef59ec974c01938153b60 , if you want to try it out. Do triple check before flashing!
Mybrc91
commented
3 years ago @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
duhow
commented
3 years ago 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.lzmaYou 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.ubiOnce 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
rebootHi @Mybrc91 , any luck with this?
Mybrc91
commented
3 years ago @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.
cat /usr/share/mico/version command 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'
option product_id '0000'
option module 'xiaomi.wifispeaker.s12'
option ssid_prefix 'xiaomi-wifispeaker-s12_miap'config player 'player' option VOLUME '100'
2. When i run the command `ls -l /dev/root` or 'df' which shows the following
```bash
root@S12:~# ls -l /dev/root
ls: /dev/root: No such file or directoryroot@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% /dataSo, 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?
hillbicks
commented
3 years ago @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
commented
3 years ago @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.
duhow
commented
3 years ago 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.
duhow
commented
3 years ago 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.
Mybrc91
commented
3 years ago 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 completedTry rebuilding that package, delete file build-packages/build/armv7/glibc.status and start docker process again?
Mybrc91
commented
3 years ago 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.
Mybrc91
commented
3 years ago 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.
Mybrc91
commented
3 years ago 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？
duhow
commented
3 years ago 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
Mybrc91
commented
3 years ago 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 255What 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?
Mybrc91
commented
3 years ago What
FILEare you using? Is that the one dumped from your speaker or did you extract it from the update file? Can you try running the stepextract_ubifscommands manually?
FILE is from the update file 1.54.1.bin. I run sudo make extract FILE=root.ubi commands, which shows the following
nsquashfs -d squashfs-root root.ubi
Can't find a SQUASHFS superblock on root.ubi
make: *** [Makefile:40: extract_squashfs] Error 1Do i need to running the following
extract_ubifs: modprobe_mtd
-umount -q $(BUILD_DIR)
ubidetach /dev/ubi_ctrl -m 0
ubiformat /dev/mtd0 -f $(FILE) -s 2048 -O 2048 -y
ubiattach /dev/ubi_ctrl -m 0 -O 2048
mkdir -p $(BUILD_DIR)
mount -t ubifs ubi0 $(BUILD_DIR)step by step?
duhow
commented
3 years ago Yes, be sure to change the variables to its matching value - BUILD_DIR=/mnt/ubi.tmp.
Please check if using other BUILD_DIR works for you and no errors appear?
Check error running echo $? after ubiformat command (should be 0, not 255 as you shared earlier)
Mybrc91
commented
3 years ago Yes, be sure to change the variables to its matching value -
BUILD_DIR=/mnt/ubi.tmp. Please check if using otherBUILD_DIRworks for you and no errors appear? Check error runningecho $?afterubiformatcommand (should be 0, not 255 as you shared earlier)
How to get the BUILD_DIR ? I ran every step with BUILD_DIR=/mnt/ubi.tmp and BUILD_DIR=squashfs-root. When i running echo $? after ubiformat command is show 255.
Mybrc91
commented
3 years ago Yes, be sure to change the variables to its matching value -
BUILD_DIR=/mnt/ubi.tmp. Please check if using otherBUILD_DIRworks for you and no errors appear? Check error runningecho $?afterubiformatcommand (should be 0, not 255 as you shared earlier)
I find some information about this error. ubiformat returned 255 even without encountering an error condition. And i input - before ubiformat command to ignore error,the image is release. How to confirm it is the right image? I have flashed in the image and boot from boot0, but it seems that the image is not being generated correctly.
When i run ubiformat /dev/mtd3 -s 2048 -O 2048 -S 63307776 -y -f xxx.ubi ,which shows the following
ubiformat: mtd3 (nand), size 100925440 bytes (96.2 MiB), 770 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 769 -- 100 % complete
ubiformat: 768 eraseblocks have valid erase counter, mean value is 6
ubiformat: 2 bad eraseblocks found, numbers: 701, 703
ubiformat: flashing eraseblock 482 -- 100 % complete
ubiformat: formatting eraseblock 769 -- 100 % completeand run ubiattach /dev/ubi_ctrl -d 2 -O 2048 -p /dev/mtd3, which shows the following
UBI device number 2, total 768 LEBs (97517568 bytes, 93.0 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)Then i reboot from boot0, which shows the following from tty log
Starting kernel ... [216/1918]
uboot time: 1666763 us
[ 0.136498@0] genirq: Setting trigger mode 8 for irq 241 failed (gic_set_type+0x0/0xb4)
[ 0.138967@0] genirq: Setting trigger mode 8 for irq 242 failed (gic_set_type+0x0/0xb4)
[ 0.147201@0] genirq: Setting trigger mode 8 for irq 241 failed (gic_set_type+0x0/0xb4)
[ 0.155066@0] genirq: Setting trigger mode 8 for irq 242 failed (gic_set_type+0x0/0xb4)
domain-0 init dvfs: 4
[BL31]: tee size: 0
[BL31]: tee size: 0
[BL31]: tee size: 0
[BL31]: tee size: 0
WARNING: Unimplemented Sip Call: 0x82000036
[`get key is 0x00 , curr_boot is boot0
Booting from boot0
UBI device number 0, total 768 LEBs (97517568 bytes, 93.0 MiB), available 0 LEBs (0 bytes), LEB size 126976 bytes (124.0 KiB)
/dev/mtd3 is ready now.
/sbin/init: error while loading shared libraries: librt.so.1: wrong ELF class: ELFCLASS32
[ 1.128637@0] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00
[ 1.128637@0]
[ 1.132454@0] CPU: 0 PID: 1 Comm: init Tainted: G W 3.14.29 #1
[ 1.139092@0] Call trace:
[ 1.141688@0] [<ffffffc00108896c>] dump_backtrace+0x0/0x12c
[ 1.147202@0] [<ffffffc001088aa8>] show_stack+0x10/0x1c
[ 1.152379@0] [<ffffffc0015e8838>] dump_stack+0x74/0xc4
[ 1.157551@0] [<ffffffc0015e5d64>] panic+0xe8/0x220
[ 1.162382@0] [<ffffffc00109ee84>] do_exit+0x990/0x994
[ 1.167469@0] [<ffffffc00109fc7c>] do_group_exit+0x3c/0xcc
[ 1.172903@0] [<ffffffc00109fd18>] SyS_exit_group+0xc/0x10
[ 1.178338@2] CPU2: stopping
[ 1.181183@2] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G W 3.14.29 #1
[ 1.188253@2] Call trace:So the system reboot from boot1. I find the librt.so.1 is ELF 32-bit LSB shared object and the librt.so.1 in boo1 is ELF 64-bit LSB shared object. Is it related to this?
Mybrc91
commented
3 years ago I can't build the image for aarch64 with many error, anybody can help ?
duhow
commented
2 years ago Working in building aarch64 binaries. This is special for this speaker, hopefully it works without additional changes...
https://github.com/duhow/xiaoai-patch/runs/5013065791?check_suite_focus=true
Mybrc91
commented
2 years ago Working in building
aarch64binaries. This is special for this speaker, hopefully it works without additional changes... https://github.com/duhow/xiaoai-patch/runs/5013065791?check_suite_focus=true
Thank you, but the building is fail.
JetP1L0t
commented
5 months ago tried to build for MDZ-25-TD (accidentally got brand-new) ssh not working but UART is fine. seemed to compile all stuff successfully, there were small issues but all goes fine at end. uploaded original & generated squashfs, compiled binaries and boot log here mb someone could check if it correct & suggest how to flash it?
duhow
commented
4 months ago @JetP1L0t just saw this, the original image is gzip compressed, the new one is xz so it will be likely incompatible.
Fix the mksquash command.
❯ binwalk mico_original_image_mtd4
Squashfs filesystem, little endian, version 4.0, compression:gzip, size: 30326337 bytes, 1494 inodes, blocksize: 131072 bytes, created: 2018-07-24 08:56:17
❯ binwalk mico_patched_image_mtd4
Squashfs filesystem, little endian, version 4.0, compression:xz, size: 29027298 bytes, 2662 inodes, blocksize: 131072 bytes, created: 2024-05-14 18:44:29EDIT: updated in d75bbbd5525406d4062926982e55a404dfcc1123 for model S12A .
I have a MDZ-25-DT, according to the documentation I exported the image, run
binwalkcommand, and displayedIs this the correct image? I copy it from
/dev/mtd4.