m6 config needed

[stevetuc]

Thanks for releasing android 7 source. 

However,I still think the Exynos config file is not quite correct for m6

The config for exynos 

https://github.com/FiiOapp/FiiO_Kernel_Android_7.0/blob/master/arch/arm/configs/exynos_defconfig

Does not contain any reference to:

CONFIG_SND_USB_AUDIO = y 

Or equivalent to this line from X5iii config that instead configures ES9018 for m6: 

CONFIG_SND_RK29_SOC_AK4490 = y 

So I think there needs to be a customised config file for m6 in order for the kernel to successfully compile for m6

Can you release the actual config file used to create the m6 kernel

[sploders101]

If it's any help, I've been able to get a booting (albeit panicking) kernel using the open source android-4.9 kernel from Google by splicing that defconfig in and following the AOSP docs. In particular, this one might help with your question. This kernel is also missing half its source code, so there's no use trying to make it work. It's probably best to just splice these files into the open-source kernel.

I'm sick of this stupid audio delay when resampling, and I don't want to reconfigure every computer I use my m6 with, and I'm tired of waiting for FiiO to do anything (they've demonstrated quite a bit of apathy in terms of support), so I'm attempting to compile my own kernel to disable dm_verity, root, remove the usb dac app, and replace it with my own that can do it better. I'd also like to turn this thing into a flash drive emulator for live USB images, and a password manager that can type them in for me (USB gadget drivers are pretty cool).

If I find out anything else, I'll be sure to post it here. For now, here are a few more things that may help:

• Key combinations
  • Startup
  • Fastboot can be accessed by holding volume up and power simultaneously, and releasing power when the red light turns on.
    • This method can still be used when the device is unable to boot; just be careful not to flash the bootloader
  • Recovery can be accessed by holding volume down and power, and releasing power when the red light turns on
  • A restart can be forced by holding play/pause, volume up, and power.
• The recovery verifies a FiiO signature when installing zips.
• Fastboot has no verification of any kind (from what I can tell) when flashing images/kernels/dtbs
• The default kernel includes dm_verity, which runs hashing algorithms on every chunk of data that is read from the internal flash memory (eMMC), meaning no system data can be modified without bricking the device (not permanently, thankfully. It can be restored from fastboot)
• The OTA package is a zip signed with SignApk with images in it. Among these are the kernel, the dtb (describes information about where to access certain devices) the ramdisk (cpio archive wrapped in a uboot header, used as initramfs), the recovery (another uboot-wrapped cpio archive that includes the recovery binary and supporting files). These can all be flashed via fastboot using their filenames as the partition names.
  • The system image can be decompressed using sdat2img (accessible on XDA Developer Forums), but the full image cannot be flashed via fastboot due to poor implementation.
• Fastboot bugs
  • fastboot boot does not work. It acts like it will, and then doesn't. If a reboot is requested via fastboot reboot, this will also silently fail, appearing to succeed. If requested again, the system will lock up, requiring a forceful reboot.
  • fastboot reboot ignores the second argument. It will only reboot to the system.

[stevetuc]

Thanks for this detailed comment, and any updates on compiling a replacement kernel. This could open the way to potentially increasing avail ram and possibly overclocking. Its a great pity (and presumably illegal) that Fiio don't honour the GPL and waste everyones time by posting useless incomplete source code.

[sploders101]

Just hooking my FiiO back up at work after my lunch break and had an idea... Given that the exynos chip used in the FiiO is a standard chip for use in wearables, I wonder if they've really done any kernel patching. This weekend, I might try making an AOSP kernel with some config tweaks (namely adding the uac2 gadget device for the DAC function) using the defconfig provided here for the majority of the options. I'll let you know if I find anything. I think some of the spotty results I've been seeing could be due to dm-verity, but as mentioned in another issue here, someone has gotten past that and rooted the device. I have now been able to extract the ramdisk, make changes as I please, and stick it back in without a problem, so I wonder if the kernel had the same limitation before.

I'm not sure how much of an effect dm-verity would have made since my research suggested it was part of the kernel, but it's possible I misunderstood, because the WETA ROM doesn't seem to make any changes to the kernel, and still manages to get past it.

[stevetuc]

I think dm-verity can be disabled in the build.prop in the ramdisk, or by unticking the Magisk option Preserve DM-Verity (which modifies the build.prop file) Im using the Weta rom and patched the ramdisk to use the latest Magisk. I did try load the M7k kernel as it's virtually identical hardware to the M6. It didn't boot but that may be due to my faulty technique.

[sploders101]

Wow. I wish I knew that before... I could have patched it myself. I figured out the ramdisk long ago but couldn't do anything because of dm-verity. I was trying to disable it in the kernel config :facepalm:

I don't do a lot of Android hacking, just generic Linux mostly

[stevetuc]

Took me a while to find this too! Also, I meant to say default.prop..not build.prop

The relevant lines are: ro.secure=0 security.perf.harden=0 ro.adb.secure=0 ro.debuggable=1 persist.sys.usb.config=mtp,adb

These properties can be set in the ramdisk copy of default.prop or using setprop persist in a terminal . As I mentioned, magisk can set or unset dm-verity. More on that here: https://www.didgeridoohan.com/magisk/MagiskInstallationIssues#