[Xperia Z5 General] :
[MENTION=6584695]CTXz[/MENTION] [MENTION=3037651]zacharias.maladroit[/MENTION]

okay this is the deal so far, with the afore-re-mentioned toolchain :silly:

changed -02 to -03 in makefile to deal with inline fubar from what i read.

Still "experimenting" and putting unecessary quotes "around" things. xD

The seperate dtb seems to fail due to what appears to be [at least for z5p] not all the dtb's being combined for a "regular" build. [outside of cm build system], butt when using the concatenated compressed zimage-dtb-gz , from following the output in terminal, all dtbs seem combine "correctly", BUT when using seperated dtb.img and zImage as "usual" the result is PPPPBBBTTT :p

SYSMAP System.map
make[1]: Nothing to be done for 'dtbs'.
[COLOR="Olive"] DTC arch/arm64/boot/dts/qcom/../msm8994-v2.0-kitakami_satsuki_generic.dtb
DTC arch/arm64/boot/dts/qcom/../msm8994-v2.1-kitakami_satsuki_generic.dtb
DTC arch/arm64/boot/dts/qcom/../msm8994-v2.0-kitakami_satsuki_dsds.dtb
DTC arch/arm64/boot/dts/qcom/../msm8994-v2.1-kitakami_satsuki_dsds.dtb[/COLOR]
OBJCOPY arch/arm64/boot/Image
GZIP arch/arm64/boot/Image.gz
CAT arch/arm64/boot/Image.gz-dtb
Building modules, stage 2.
MODPOST 0 modules
DTB combiner:
Input directory: './arch/arm/boot/dts/'
Output file: 'build_satsuki/out/boot.img-dtb'
Found file: msm8994-v2.0-kitakami_satsuki_dsds.dtb ... chipset: 207, rev: 131072, platform: 8, subtype: 0
Found file: msm8994-v2.1-kitakami_satsuki_dsds.dtb ... chipset: 207, rev: 131073, platform: 8, subtype: 0
Found file: msm8994-v2.1-kitakami_satsuki_generic.dtb ... chipset: 207, rev: 131073, platform: 8, subtype: 0
... duplicate info, skipped
Found file: msm8994-v2.0-kitakami_satsuki_generic.dtb ... chipset: 207, rev: 131072, platform: 8, subtype: 0
... duplicate info, skipped
=> Found 2 unique DTB(s)

Generating master DTB... completed
-----snip snip--------------
-rw------- 1 root root 768000 Apr 7 09:54 boot.img-dtb
-rwxr-xr-x 1 root root 18843064 Apr 7 09:54 boot.img-zImage
-rw-r--r-- 1 root root 8552456 Apr 7 09:54 boot.img-zImage_gz

Inside cm build system , again for z5p specifically, the result is still the same when using zImage and dt.img. No pickup of mmcblk1.

As i said i am still experimenting, but this commit may or may not be interfering with external card detection, though i haven't proved it yet, meaning hit and miss. I reverted it and it does seem unecessary for satsuki, so maybe no need on sumi and suzy.

But yeah vold is still boned and i can't feature the selinux theory as i've murdered selinux on other devices/builds and not had the external card issue. Meaning you have selinux functional [enforcing or permissive] , I don't [disabled, deader than disco], we still have the same problem.

In defconfig of my working kernel source for satsuki. which cm does not respect so perhaps time for a modified/custom mkbootimg script, gumble.mumble.

#

# Boot options

#

CONFIG_CMDLINE=""

CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE=y

# CONFIG_BUILD_ARM64_UNCOMPRESSED_APPENDED_DTB_IMAGE is not set

CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE_NAMES="msm8994-v2.0-kitakami_satsuki_generic msm8994-v2.1-kitakami_satsuki_generic msm8994-v2.0-kitakami_satsuki_dsds msm8994-v2.1-kitakami_satsuki_dsds"

# CONFIG_EFI is not set

also

# Device Tree and Open Firmware support

#

CONFIG_PROC_DEVICETREE=y

Note a 32gib fat32/vfat card still does not automagically mount though is present.

Manually mounted:

root@satsuki:/ # mount -o rw,remount /
root@satsuki:/ # mkdir /mnt/media_rw/sdcard1
root@satsuki:/ # mount -o rw -t vfat /dev/block/mmcblk1p1 /mnt/media_rw/sdcard1
root@satsuki:/ # ln -s /mnt/media_rw/sdcard1 /sdcard1
root@satsuki:/ # ls /sdcard1
Tunes
root@satsuki:/ #

Total commander recognizes the card @ /mnt/media_rw/sdcard1

when navigate to Tunes directory on-card, thumbnails for mp4 files display correctly so perms are square and tap and play does bring up appropriate options to choose preferred media app, just once,always, etc. And read/write is good.

Output of cat /proc/devices

root@satsuki:/ # cat /proc/devices
Character devices:
1 mem
256 msm_rng
5 /dev/tty
5 /dev/console
5 /dev/ptmx
10 misc
13 input
21 sg
29 fb
81 video4linux
89 i2c
108 ppp
116 alsa
128 ptm
136 pts
180 usb
189 usb_device
216 rfcomm
221 wwan_ioctl
222 hidg
223 adsprpc-smd
224 sensors
225 pft
226 avtimer
227 roccat
228 hidraw
229 smdpkt
230 smd
231 jpeg3
232 jpeg2
233 jpeg1
234 jpeg0
235 rmi
236 ttyGS
237 usb_ext_chg
238 uio
239 qseecom
240 kgsl
241 dia
242 ttyHSL
243 ttyHS
244 system_health_monitor
245 subsys
246 voice_svc
247 bsg
248 ipaNatTable
249 ipa
250 media
251 rtc
252 msm_thermal_query
253 msm_sps
254 pmsg

Block devices:
1 ramdisk
259 blkext
7 loop
8 sd
65 sd
66 sd
67 sd
68 sd
69 sd
70 sd
71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
179 mmc
254 device-mapper
root@satsuki:/ #

Output of cat /proc/partitions

root@satsuki:/ # cat /proc/partitions
major minor #blocks name

179 0 30535680 mmcblk0
179 1 2048 mmcblk0p1
179 2 16384 mmcblk0p2
179 3 81920 mmcblk0p3
179 4 128 mmcblk0p4
179 5 128 mmcblk0p5
179 6 1 mmcblk0p6
179 7 1024 mmcblk0p7
179 8 256 mmcblk0p8
179 9 256 mmcblk0p9
179 10 1 mmcblk0p10
179 11 512 mmcblk0p11
179 12 512 mmcblk0p12
179 13 1536 mmcblk0p13
179 14 8 mmcblk0p14
179 15 1024 mmcblk0p15
179 16 1024 mmcblk0p16
179 17 1536 mmcblk0p17
179 18 1536 mmcblk0p18
179 19 256 mmcblk0p19
179 20 256 mmcblk0p20
179 21 128 mmcblk0p21
179 22 128 mmcblk0p22
179 23 1024 mmcblk0p23
179 24 1024 mmcblk0p24
179 25 512 mmcblk0p25
179 26 512 mmcblk0p26
179 27 1024 mmcblk0p27
179 28 1024 mmcblk0p28
179 29 65536 mmcblk0p29
179 30 32768 mmcblk0p30
179 31 32768 mmcblk0p31
179 32 65536 mmcblk0p32
179 33 1024 mmcblk0p33
179 34 512 mmcblk0p34
179 35 1 mmcblk0p35
179 36 512 mmcblk0p36
179 37 102400 mmcblk0p37
179 38 10240 mmcblk0p38
179 39 16384 mmcblk0p39
179 40 307200 mmcblk0p40
179 41 204800 mmcblk0p41
179 42 24182784 mmcblk0p42
179 43 5384192 mmcblk0p43
179 48 4096 mmcblk0rpmb
179 96 3872256 mmcblk1
179 97 3871232 mmcblk1p1

So yeah still stumped. Syncing Omni and will give it a go in a few days when it's done syncing. :p

So your external card will probbaly not register when you build your boot.img through cm, but when you do an outside kernel build, using CONFIG_BUILD_ARM64_APPENDED_DTB_IMAGE, then hey, maybe? heres my build script for kernel

#!/bin/bash
./clean
rm -fr build_satsuki
mkdir -pv build_satsuki/out/modules
export ARCH=arm64
export PATH=/storage/toolchains/aarch64_ubertc_kernel_5.3/bin/:$PATH
export CROSS_COMPILE=aarch64-linux-android-
export STRIP=aarch64-linux-android-strip
make madkow_satsuki_defconfig
make menuconfig
make
tools/dtbTool --force-v2 -o build_satsuki/out/boot.img-dtb -s 2048 -p ./scripts/dtc/ ./arch/arm/boot/dts/
cp arch/arm64/boot/Image build_satsuki/out/boot.img-zImage
cp arch/arm64/boot/Image.gz-dtb build_satsuki/out/boot.img-zImage_gz
make modules
find -type f -name *.ko -exec cp {} build_satsuki/out/modules/ \;
ls -al build_satsuki/out/modules/
cd build_satsuki/out/modules/
$STRIP --strip-unneeded *.ko
cd ../../../
ls -al build_satsuki/*
echo Done !

Maybe experiment with an alternate source?

C, i tried scripting but permissions seem to revert, though the mount remains.