Open Minionguyjpro opened 3 months ago
/vendor/etc/init
:
/system/etc/init
(there's more on the top of the directory but it doesn't seem relevant):
Same Issue of Few partitions not mounting because \Data is part of internal storage (sdcard or emulate/0 or storage) and the device manage both so external_sd (MicroSD or sdcard1) too.
The external SD card also doesn't mount, but looking at the dmesg logs it does seem that the driver was loaded and it is looking to detect the card. It finds the slot but never the card...
USB-OTG works fine!
For know the adress to MicroSD and place in the twrp.flags or recovery.fstab https://github.com/TeamWin/android_device_samsung_j7xelte/blob/b0c65814289a4d3e7bd2e7089ec498993fa7cce7/recovery/root/etc/recovery.fstab#L21-L23
https://github.com/physwizz/m10lte-TWRP-11-dt/tree/main/recovery/root/system/etc
so you need search that in your device:
https://gist.github.com/lopestom/3c1f3eaa66248c56e61acf19ddd4b96c#android_device_brand_devicename
Read recovery
in the android_device_brand_devicename/recovery/root/system/
part of
The recovery.fstab, twrp.fstab or twrp.flags files must.........
and 2.3.4 \recovery\root\system\ specially in the
If the Custom Recovery not mount MicroSDCard and or OTG, you..........
About \Data so look two conditions like same in the https://github.com/KekHunterOS/Samsung-DT/blob/8ce60a4f4614c372238d08d9b7bccaea4d7a4aa9/universal7870-common/rootdir/etc/fstab.samsungexynos7870#L11-L12
What I know?! You think writing TW_ flags the Custom Recovery decrypt the device??!! LOL Need stock files in the DT for decrypt so need more in the script decrypt too. Some notes I made prior to this message but I still have doubts because I didn't see any folders\files.
https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/621ec0c09fc091f615f66665162fcc7b49b1ad30/recovery/root/prebuilt_file_contexts#L546
https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/621ec0c09fc091f615f66665162fcc7b49b1ad30/recovery/root/prebuilt_file_contexts#L854
https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/621ec0c09fc091f615f66665162fcc7b49b1ad30/recovery/root/prebuilt_file_contexts#L1392
/dev/ecryptfs u:object_r:ecryptfs_device:s0
/system/bin/trustonic_tee_proxy u:object_r:trustonic_tee_proxy_exec:s0
/system/bin/mcDriverDaemon u:object_r:mobicoredaemon_exec:s0
/system/bin/mcDriverDaemonQC u:object_r:mobicoredaemon_exec:s0
# conflict with Qcom BSP, /system/bin/qseecomd u:object_r:qseecomd_exec:s0
#SEC use qseecom_device, not tee_device. neverallow Google CTS-android-5.0.2_r1 :
/dev/qseecom u:object_r:qseecom_device:s0
/system/bin/qseecomd u:object_r:tee_exec:s0
/system/vendor/bin/qseeproxydaemon u:object_r:qseeproxy_exec:s0
/data/misc/qsee(/.*)? u:object_r:data_qsee_file:s0
/data/misc/sshdcpapp(/.*)? u:object_r:data_qsee_file:s0
/teesst(/.*)? u:object_r:teesst_data_file:s0
/data/tee(/.*)? u:object_r:tee_data_file:s0
# for tz
/system/bin/teec_sstd_ca u:object_r:teecsstdca_exec:s0
https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/621ec0c09fc091f615f66665162fcc7b49b1ad30/recovery/root/init.rc#L99-L107
With time I answer your messages 1/2/3........
I don't think that it's that easy, it's just that this device is a bit apart from some of the other ones. I will however try adding the ext4 thing to the fstab. Should I however add it to the fstab.samsungexynos7870
or one of the others? I don't feel like TWRP sources the fstab.samsungexynos7870
file, but I could be wrong.
EDIT: I feel like the recovery.fstab is the best suited for this.
Mounting the USERDATA as F2FS gives permission denied, with EXT4 gives invalid argument.
Oh also a bit confusing, I copied that prebuilt_file_contexts from another tree (may not have been the smartest but it at least made the recovery boot, I had no idea where else to get it from) so it may contain things that aren't relevant to the tree with the Exynos 7870 SoC here.
This small video showing a bit of the main structure may help (I here my microphone was on, OOPS):
https://github.com/user-attachments/assets/fad2c92b-d2f7-4858-bfe7-ac7dfa62feb2
Also I have done stuff but under the hood without pushing it yet. I will now so you can see.
EDIT: All right so now the init.recovery.samsungexynos7870.rc
file is working. Data is however still returning those mount errors, SD is still not working, USB-OTG is and MTP is not.
EDIT 2: Interesting, I think SELinux is in the way:
[ 15.360894] [5: logd.auditd: 2421] type=1400 audit(1723564145.109:127): avc: denied { open } for pid=2375 comm="recovery" path="/sys/devices/13540000.dwmmc0/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p26" dev="sysfs" ino=19253 scontext=u:r:recovery:s0 tcontext=u:object_r:sysfs:s0 tclass=dir permissive=1
Although it's on permissive so I'm not sure...
/vendor/etc/init
gatekeeper@1.0-service.so & keymaster@3.0-service.so files
/system/etc/init
(there's more on the top of the directory but it doesn't seem relevant):
hwservicemanager.rc & servicemanager.rc files maybe more....
Need look in the \bin\ folder too.....
This small video showing a bit of the main structure may help (I here my microphone was on, OOPS):
Your luckly because my sound is muted. in the boot.img and recovery.img not have files to decrypt.... In some Xiaomi and Realme already has.
In the video, the \vendor\ is good but since A8.1 has \system as principal so some files in that and \vendor is the way.
If your files in the DT is from stock firmware so as I wrote before so device has trustonic
mode. You can confirm in the init.rc file.
In the \vendor\tee has files?
so if has any firmware repo in the github or gitlab so link that.....
Your luckly because my sound is muted. in the boot.img and recovery.img not have files to decrypt.... In some Xiaomi and Realme already has.
Ah yeah great :joy:.
In the video, the \vendor\ is good but since A8.1 has \system as principal so some files in that and \vendor is the way. If your files in the DT is from stock firmware so as I wrote before so device has trustonic mode. You can confirm in the init.rc file.
I don't seem to find anything about trustonic mode back in any of the init.rc files. I will double check.
In the \vendor\tee has files?
Yes, it does:
so if has any firmware repo in the github or gitlab so link that..... https://github.com/Rabikishan001/a2corelte_dump Probably another firmware version but it's pretty much but the same (I checked multiple files, all were identical in both that dump and my local one). Do mind though that some mount directories were kept back there. E.g. in my video you see that there's a data folder, which you won't see in this dump. But that's because it's just an empty folder as placeholder for the mount point. So not important.
/vendor/etc/init
gatekeeper@1.0-service.so & keymaster@3.0-service.so files
/system/etc/init
(there's more on the top of the directory but it doesn't seem relevant):hwservicemanager.rc & servicemanager.rc files maybe more....
Need look in the \bin\ folder too.....
Files have been added, will push the changes.
EDIT: Used ldcheck
to find out that I had to add ld-android.so
in system/lib
and vendor.samsung.security.skeymaster@3.0_vendor.so
in vendor/lib
.
Don't know whether it helps but this is what /proc/mounts
returns from within the booted system:
rootfs / rootfs ro,seclabel,size=420272k,nr_inodes=105068 0 0
proc /proc proc rw,relatime,gid=3009,hidepid=2 0 0
sysfs /sys sysfs rw,seclabel,relatime 0 0
magisk /sbin tmpfs rw,seclabel,relatime,mode=755 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,seclabel,relatime,mode=600 0 0
selinuxfs /sys/fs/selinux selinuxfs rw,relatime 0 0
/dev/block/platform/13540000.dwmmc0/by-name/ODM /odm ext4 ro,seclabel,relatime 0 0
/dev/block/platform/13540000.dwmmc0/by-name/SYSTEM /system ext4 ro,seclabel,relatime 0 0
/dev/block/platform/13540000.dwmmc0/by-name/VENDOR /vendor ext4 ro,seclabel,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
none /dev/memcg cgroup rw,relatime,memory 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,seclabel,relatime 0 0
tmpfs /mnt tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
none /config configfs rw,relatime 0 0
tmpfs /mnt/secure tmpfs rw,seclabel,relatime,mode=700 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
pstore /sys/fs/pstore pstore rw,seclabel,relatime 0 0
/dev/block/platform/13540000.dwmmc0/by-name/CACHE /cache ext4 rw,seclabel,nosuid,nodev,noatime,discard,journal_checksum,journal_async_commit,noauto_da_alloc,errors=panic,data=ordered 0 0
/dev/block/platform/13540000.dwmmc0/by-name/EFS /efs ext4 rw,seclabel,nosuid,nodev,noatime,journal_checksum,journal_async_commit,noauto_da_alloc 0 0
/dev/block/platform/13540000.dwmmc0/by-name/OMR /omr ext4 rw,seclabel,nosuid,nodev,noatime,journal_checksum,noauto_da_alloc 0 0
tmpfs /storage tmpfs rw,seclabel,relatime,mode=755,gid=1000 0 0
adb /dev/usb-ffs/adb functionfs rw,relatime 0 0
tracefs /sys/kernel/debug/tracing tracefs rw,seclabel,relatime 0 0
/dev/block/dm-0 /data f2fs rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=12800,reserve_core=10240,resuid=0,resgid=5555,usrquota,grpquota,alloc_mode=reuse,fsync_mode=nobarrier 0 0
/data/media /mnt/runtime/default/emulated sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid 0 0
/data/media /storage/emulated sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,multiuser,mask=6,derive_gid 0 0
/data/media /mnt/runtime/read/emulated sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=23,derive_gid 0 0
/data/media /mnt/runtime/write/emulated sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,multiuser,mask=7,derive_gid 0 0
/dev/block/platform/13540000.dwmmc0/by-name/HIDDEN /preload ext4 ro,seclabel,nosuid,nodev,relatime 0 0
/dev/block/vold/public:179,33 /mnt/media_rw/EC9B-086E sdfat rw,dirsync,nosuid,nodev,noexec,noatime,fs=vfat:32,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,utf8,shortname=winnt,namecase=0,delay,smart,ausize=32768,adj_hid,adj_req,symlink=0,bps=512,errors=remount-ro 0 0
/dev/block/vold/public:179,33 /mnt/secure/asec sdfat rw,dirsync,nosuid,nodev,noexec,noatime,fs=vfat:32,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,utf8,shortname=winnt,namecase=0,delay,smart,ausize=32768,adj_hid,adj_req,symlink=0,bps=512,errors=remount-ro 0 0
/mnt/media_rw/EC9B-086E /mnt/runtime/default/EC9B-086E sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,mask=6 0 0
/mnt/media_rw/EC9B-086E /storage/EC9B-086E sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=1015,mask=6 0 0
/mnt/media_rw/EC9B-086E /mnt/runtime/read/EC9B-086E sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,mask=18 0 0
/mnt/media_rw/EC9B-086E /mnt/runtime/write/EC9B-086E sdcardfs rw,nosuid,nodev,noexec,noatime,fsuid=1023,fsgid=1023,gid=9997,mask=18 0 0
Maybe it helps troubleshoot some of the mount issues. I just reinstalled the stock system (did a try to install an arm 32 bit with 64 bit binder GSI but failed, keeps booting into download mode without any messages). So I can better test the decryption, but last attempt failed.
I don't seem to find anything about trustonic mode back in any of the init.rc files.
admore so \vendor \tee\ has tz file.....
I don't seem to find anything about trustonic mode back in any of the init.rc files.
admore so \vendor \tee\ has tz file.....
The .tzar file? I think I should add just the whole tee directory.
Also, mcRegistry is in vendor/app
. Add or not? It contains the file to which the Mobicore part in the init file is referencing to.
I don't seem to find anything about trustonic mode back in any of the init.rc files.
https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/twrp-9.0/recovery/root/init.recovery.samsungexynos7870.rc#L98-L102 admore so \vendor \tee\ has tz file.....
The .tzar file? I think I should add just the whole tee directory.
no. copy folder&files to DT \vendor Obvius create a new DT.........
Also, mcRegistry is in
vendor/app
. Add or not? It contains the file to which the Mobicore part in the init file is referencing to.
yes! that and other files too......
Need look in the \bin\ folder too.....
I don't seem to find anything about trustonic mode back in any of the init.rc files.
https://github.com/Minionguyjpro/android_device_samsung_a2corelte/blob/twrp-9.0/recovery/root/init.recovery.samsungexynos7870.rc#L98-L102 admore so \vendor \tee\ has tz file.....
The .tzar file? I think I should add just the whole tee directory.
no. copy folder&files to DT \vendor Obvius create a new DT.........
Also, mcRegistry is in
vendor/app
. Add or not? It contains the file to which the Mobicore part in the init file is referencing to.yes! that and other files too......
Need look in the \bin\ folder too.....
That file where the Qualcomm case is referring to doesn't exist however. The other one does.
That file where the Qualcomm case is referring to doesn't exist however. The other one does.
so no copy..... Lmao
You can have similar reference here 3.2 Trustkernel
mcDriverDaemon_static
also nowhere in sbin or anywhere in the dump...
It's not Trustkernel is it? It has some comparable files but not all of them (I guess that's why you say similar).
It's not Trustkernel is it? It has some comparable files but not all of them (I guess that's why you say similar).
Similar case.... only to have reference files.......
mcDriverDaemon_static
also nowhere in sbin or anywhere in the dump...
https://github.com/Rabikishan001/a2corelte_dump/blob/main/vendor/bin/tzdaemon
Look https://github.com/search?q=repo%3ARabikishan001%2Fa2corelte_dump%20mcdriver&type=code
Added some more changes.
Eyyy, seems like adding that event-log-tags file fixed nano and logcat!
I still have no idea what to do about that unable to load crc32 driver error (it's the data partition by the way, dmesg spams this):
[ 11.850451] [4: recovery: 2379] F2FS-fs (mmcblk0p26): Cannot load crc32 driver.
EDIT: I can add a patch to a file in the kernel which preloads some of the things, related to crypto and crc32. Will test.
Now is the time to read and learn a little more about decryption.
Don't go too fast, because the pain will be greater in disappointments.
Let's take a moment and look at the files, references and something in script files like rc or xml so we can get our bearings. https://github.com/Rabikishan001/a2corelte_dump/blob/fe01b6c7f321e48d22fbee30027db0ed1be5e406/recovery/ramdisk/res/recovery.do#L428-L429
Add keystore files to DT https://github.com/Rabikishan001/a2corelte_dump/tree/fe01b6c7f321e48d22fbee30027db0ed1be5e406/system/lib/hw
vendor.samsung.security.skeymaster@3.0.so
Also, I don't know if the TeamWin twrp-9.0 repo is good for decryption. Everything will be tests and confirmations.
Compile img file with CRYPTO enable. After unpack that img file and look if has libicui18n.so
this is good?? libsec_ode_integirty.so libsec_ode_keymanager.so libsec_ode_keymaster.so libsec_ode_keystorage.so libsec_ode_keystorage_fbe.so libsec_ode_keystorage_fde.so libsec_ode_pbkdf.so libsec_ode_sdcardencryption.so libskeymaster.so
That's a samsung keymater? for secure (sec) mode?
SD is still not working, USB-OTG is and MTP is not.
Compile img file with CRYPTO enable. After unpack that img file and look if has libicui18n.so
this is good?? libsec_ode_integirty.so libsec_ode_keymanager.so libsec_ode_keymaster.so libsec_ode_keystorage.so libsec_ode_keystorage_fbe.so libsec_ode_keystorage_fde.so libsec_ode_pbkdf.so libsec_ode_sdcardencryption.so libskeymaster.so
That's a samsung keymater? for secure (sec) mode?
SD is still not working, USB-OTG is and MTP is not.
It doesn't have a libicui18n.so. Am I supposed to add all of the things you listed here?
Yup, my dump also contains those libraries.
Am also not sure why an FBE library file is included, the device has Secure Startup and supports SD-card encryption (optional but my current SD card isn't) AND it's Android 8.1 so it's supposed to use FDE.
For MTP, there is usb_mtp_gadget
in /dev
. My phone shows up on my computer but mounting it however is not working... Maybe because data nor the SD card mounting and thus there's nothing to list which causes this? Or should it mount then but just show Internal and SD as 0MB without any files?
It doesn't have a libicui18n.so
Need add in the omni_ with
# Additional Libraries
TARGET_RECOVERY_DEVICE_MODULES += libicui18n
RECOVERY_LIBRARY_SOURCE_FILES += $(TARGET_OUT_SHARED_LIBRARIES)/libicui18n.so
add in \vendor android.hardware.gatekeeper@1.0-impl.so android.hardware.keymaster@3.0-impl.so gatekeeper.exynos7870.so keystore.mdfpp.so vendor.samsung.security.skeymaster@3.0-impl.so libMcClient.so
libion_exynos.so libkeymaster2_mdfpp.so libkeymaster_helper.so libteecl.so vendor.samsung.security.skeymaster@3.0_vendor.so
maybe others so files?!
Read/Searh and look about, not know about prepare_param.sh
It doesn't have a libicui18n.so
Need add in the omni_ with
# Additional Libraries TARGET_RECOVERY_DEVICE_MODULES += libicui18n RECOVERY_LIBRARY_SOURCE_FILES += $(TARGET_OUT_SHARED_LIBRARIES)/libicui18n.so
add in \vendor android.hardware.gatekeeper@1.0-impl.so android.hardware.keymaster@3.0-impl.so gatekeeper.exynos7870.so keystore.mdfpp.so vendor.samsung.security.skeymaster@3.0-impl.so libMcClient.so
libion_exynos.so libkeymaster2_mdfpp.so libkeymaster_helper.so libteecl.so vendor.samsung.security.skeymaster@3.0_vendor.so
maybe others so files?!
Read/Searh and look about, not know about prepare_param.sh
Added all of those files (will push). The param partition is a completely different thing, it contains images for the boot process like the Samsung boot logo, bootloader warning etc.
EDIT: PUSHED!
Am also not sure why an FBE library file is included, the device has Secure Startup and supports SD-card encryption (optional but my current SD card isn't) AND it's Android 8.1 so it's supposed to use FDE.
Android Souce Code Security say put FDE but with future support to FBE after A8 so your device has A8.1.........
For MTP, there is
usb_mtp_gadget
in/dev
. My phone shows up on my computer but mounting it however is not working... Maybe because data nor the SD card mounting and thus there's nothing to list which causes this? Or should it mount then but just show Internal and SD as 0MB without any files?
Your PC already has MTP drivers installed? Always changed manually to confirm that's working? So maybe need looking usb.rc file in DT??
Am also not sure why an FBE library file is included, the device has Secure Startup and supports SD-card encryption (optional but my current SD card isn't) AND it's Android 8.1 so it's supposed to use FDE.
Android Souce Code Security say put FDE but with future support to FBE after A8 so your device has A8.1.........
For MTP, there is
usb_mtp_gadget
in/dev
. My phone shows up on my computer but mounting it however is not working... Maybe because data nor the SD card mounting and thus there's nothing to list which causes this? Or should it mount then but just show Internal and SD as 0MB without any files?Your PC already has MTP drivers installed? Always changed manually to confirm that's working? So maybe need looking usb.rc file in DT??
Oh well I'm using Xubuntu right now, so Linux and not Windows. But yes it works when booted into the system. I think indeed looking into the USB rc file is a good idea.
EDIT: PUSHED!
from your firmware obviusly?!
Next step is creating a script file to start and execute the binary files..... Example with android.hardware.keymaster@3.0-service.rc
service keymaster-3-0 /vendor/bin/hw/android.hardware.keymaster@3.0-service
class early_hal
user root
group root drmrpc
disabled
seclabel u:r:recovery:s0
on post-fs-data
mkdir /efs/DAK 0775 root root
restorecon -R /efs/DAK
android.hardware.gatekeeper@1.0-service.rc
service gatekeeper-1-0 /vendor/bin/hw/android.hardware.gatekeeper@1.0-service
class hal
user root
group root
disabled
seclabel u:r:recovery:s0
and others..... But now I haven't time to do more.
EDIT: PUSHED!
from your firmware obviusly?!
Next step is creating a script file to start and execute the binary files..... Example with android.hardware.keymaster@3.0-service.rc
service keymaster-3-0 /vendor/bin/hw/android.hardware.keymaster@3.0-service class early_hal user root group root drmrpc seclabel u:r:recovery:s0 on post-fs-data mkdir /efs/DAK 0775 root root restorecon -R /efs/DAK
android.hardware.gatekeeper@1.0-service.rc
service gatekeeper-1-0 /vendor/bin/hw/android.hardware.gatekeeper@1.0-service class hal user root group root disabled seclabel u:r:recovery:s0
and others..... But now I haven't time to do more.
I added those already.
I added those already.
Now you can understand this?
I added those already.
Now you can understand this?
I think so.
I will probably compile the kernel with the patch tomorrow.
I think I will have to add a seclabel
to the init file(s) so SELinux will allow the services to start:
[ 809.956768] [0: init: 1] init: Could not ctl.start for service keymaster-3-0: File /vendor/bin/hw/android.hardware.keymaster@3.0-service(labeled "u:object_r:rootfs:s0") has incorrect label or no domain transition from u:r:init:s0 to another SELinux domain defined. Have you configured your service correctly? https://source.android.com/security/selinux/device-policy#label_new_services_and_address_denials
New kernel image has been built, time to test!
I also have the following in the keymaster init file:
on post-fs-data
mkdir /efs/DAK 0775 system system
restorecon -R /efs/DAK
How's this relevant? My device has an EFS partition, but hmm...
Patched kernel with change is still not working, hmm...
Is it me or should vold be used here?
service vold /system/bin/vold \
--blkid_context=u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 \
--fsck_context=u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0
class core
socket vold stream 0660 root mount
socket cryptd stream 0660 root mount
ioprio be 2
## Frigatebird
socket frigate stream 0660 system system
writepid /dev/cpuset/foreground/tasks
shutdown critical
## Samsung ODE >>>
socket dir_enc_report stream 0660 root mount
## Samsung ODE <<<
Ah now comes the next problem! The system partition is 32 bit and the SoC is 64 bit (I compiled TWRP for 64 bit). Now some binaries like vold and mtpd freak out (and so does the recovery when running them) because they need a library that's 32 bit, but one of 64 bit was found. Can I maybe overwrite binaries like vold and mtpd with 64 bit versions? I have the dump of another ROM that also contained the vold binary, and it's 64 bit so...
Time to enable some debug configs in the kernel for MMC, I'm done. I just want to find this cause.
I also have the following in the keymaster init file:
on post-fs-data mkdir /efs/DAK 0775 system system restorecon -R /efs/DAK
How's this relevant? My device has an EFS partition, but hmm...
I not know because i only put reference by file from your link firmare dumped.
Search in your firmware and analize. You know about EFS so maybe can knew about DAK..............
Is it me or should vold be used here?
service vold /system/bin/vold \ --blkid_context=u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 \ --fsck_context=u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0 class core socket vold stream 0660 root mount socket cryptd stream 0660 root mount ioprio be 2 ## Frigatebird socket frigate stream 0660 system system writepid /dev/cpuset/foreground/tasks shutdown critical ## Samsung ODE >>> socket dir_enc_report stream 0660 root mount ## Samsung ODE <<<
Look TWRP source code and you find vold.rc integrate?!
Ah now comes the next problem! The system partition is 32 bit and the SoC is 64 bit (I compiled TWRP for 64 bit). Now some binaries like vold and mtpd freak out (and so does the recovery when running them) because they need a library that's 32 bit, but one of 64 bit was found. Can I maybe overwrite binaries like vold and mtpd with 64 bit versions? I have the dump of another ROM that also contained the vold binary, and it's 64 bit so...
Some devices arm32-binder64-ab or a64 has TWRP with decryption working, How TWRP was compiled is the question? For me the way is putting informations and files correctly. After can compile 64 or 32 to tests......
Is it me or should vold be used here?
service vold /system/bin/vold \ --blkid_context=u:r:blkid:s0 --blkid_untrusted_context=u:r:blkid_untrusted:s0 \ --fsck_context=u:r:fsck:s0 --fsck_untrusted_context=u:r:fsck_untrusted:s0 class core socket vold stream 0660 root mount socket cryptd stream 0660 root mount ioprio be 2 ## Frigatebird socket frigate stream 0660 system system writepid /dev/cpuset/foreground/tasks shutdown critical ## Samsung ODE >>> socket dir_enc_report stream 0660 root mount ## Samsung ODE <<<
Look TWRP source code and you find vold.rc integrate?!
Ah now comes the next problem! The system partition is 32 bit and the SoC is 64 bit (I compiled TWRP for 64 bit). Now some binaries like vold and mtpd freak out (and so does the recovery when running them) because they need a library that's 32 bit, but one of 64 bit was found. Can I maybe overwrite binaries like vold and mtpd with 64 bit versions? I have the dump of another ROM that also contained the vold binary, and it's 64 bit so...
Some devices arm32-binder64-ab or a64 has TWRP with decryption working, How TWRP was compiled is the question? For me the way is putting informations and files correctly. After can compile 64 or 32 to tests......
I compiled TWRP targeting 64 bit, so ARMv8. The OS (so the ROM, Samsung Experience) however is 32 bit, running the SoC in ARM-V7a or like armeabi-v7a using the 32 bit mode integrated into the kernel. The vendor partition also only seems to contain 32 bit libraries.
I compiled TWRP targeting 64 bit, so ARMv8. The OS (so the ROM, Samsung Experience) however is 32 bit, running the SoC in ARM-V7a or like armeabi-v7a using the 32 bit mode integrated into the kernel. The vendor partition also only seems to contain 32 bit libraries.
Are you writing a report for other people to read?
If not, remember who started helping you with DT and saw the firmware images containing only \vendor\lib ?!
I didn't understand why you wrote that.....
You say how TWRP was compiled is the question?
, which is confusing me. I already thought like I'd said that just before it. (But next time I won't give any info that's already there, then it's up to the reader to just look well to find out). Anyways, what to try next?
You say
how TWRP was compiled is the question?
, which is confusing me.
Me too because Exynos is not my expertise so if you search DT to that so you look arm(32) & arm(64) and arm32-binder64-ab or a64 with TWRP so u can look encrypt/decrypt working good and others not. All doubts about kernel should be tested by u.
For me, it's indifferent but I undertand if some process not working with 32 but working with 64. All depend by device and what the company make settings/process/executables for encrypt/decrypt work.
You say
how TWRP was compiled is the question?
,
Therefore only you can answer the doubts about kernel.
About this
Look TWRP source code and you find vold.rc integrate?!
All is clean and directlly.
Upd: here's to android-9.0 https://github.com/search?q=repo%3ATeamWin%2Fandroid_bootable_recovery%20vold&type=code
You say
how TWRP was compiled is the question?
, which is confusing me.Me too because Exynos is not my expertise so if you search DT to that so you look arm(32) & arm(64) and arm32-binder64-ab or a64 with TWRP so u can look encrypt/decrypt working good and others not. All doubts about kernel should be tested by u.
For me, it's indifferent but I undertand if some process not working with 32 but working with 64. All depend by device and what the company make settings/process/executables for encrypt/decrypt work.
You say
how TWRP was compiled is the question?
,Therefore only you can answer the doubts about kernel.
About this
Look TWRP source code and you find vold.rc integrate?!
All is clean and directlly.
Upd: here's to android-9.0 https://github.com/search?q=repo%3ATeamWin%2Fandroid_bootable_recovery%20vold&type=code
It would work with arm32, but I found using aarch64 just the best option, so that if someone manages to patch the vendor it can integrate well with 32 bit and 64 bit at the end. I see vold is available there, but I also saw a reference in the regular init file that was looking to import /init.recovery.vold_decrypt.rc
, which was missing. I made this file in my local environment (not sure whether I pushed this change yet) With details to start the vold service. Best bet is to set the option to include the SBIN vold with crypto (which is probably 64 bit) and change the reference in the RC file to the one in /sbin.
I feel like this device isn't that different from other Exynos 7870 devices. It's just that this device seems to need some patches in the kernel to let it boot (there was a hardcoded max. ramdisk length in this device. I am pretty sure since I had a recovery image that could fit on the device with the correct offset flags and everything but it said invalid ramdisk length. Compressing it with LZMA and enabling the config for it in the kernel made it boot. It still boots actually pretty quickly so I'm happy). And e.g. the Synaptics driver containing an if statement which prevented it from loading in the recovery. Fortunately both of these issues are fixed, but I'm pretty sure that the external SD card does NOT depend on the data partition. It uses a seperate driver for the host controller (pretty much any device does).
I have read about a kernel patch that could allow MMC to work when using device trees or ACPI. Maybe it's worth trying this and see?
EDIT: Okay I managed to patch a few C files of the dw_mmc host controller driver. Will push changes now and check later on.
EDIT 2: okay I failed and reverted the changes. I don't expect it to be the cause since I see other trees with the same code for the driver and those don't seem to have any issues with it.
@lopestom, the new issue. So far I tried: