[BLU R1 HD Guides, News, & Discussion] linuxsociety:
Most of this is TLDR;

I don't like to reply to myself, but for reference this .config file on lines 186 and 187 contains:

CONFIG_CUSTOM_KERNEL_IMGSENSOR="ov13850_mipi_raw hi842_mipi_raw imx258_mipi_raw_liteon imx258_mipi_raw_sunny s5k4h8_mipi_raw ov5670_mipi_raw_sunwin ov5670_mipi_raw_cmk"

CONFIG_CUSTOM_KERNEL_CAM_CAL_DRV="hi842_otp imx258_eeprom"

I'd suspect the camera not to work since the original source code is specifying binary blobs for the camera or it appears that way, and if those drivers aren't included precompiled with the 7.x ROMS in a common location such as /lib/modules then the camera can't work, if the kernel modules with the right vermagick from our working kernel is used then it will work. If we have working 64bit ROM all except the camera then we need these .ko's:

hi842_otp imx258_eeprom ov13850_mipi_raw hi842_mipi_raw imx258_mipi_raw_liteon imx258_mipi_raw_sunny s5k4h8_mipi_raw ov5670_mipi_raw_sunwin ov5670_mipi_raw_cmk

I need a little clarification on all this 32bit vs 64bit stuff I've been seeing on here. Developing for this phone will really be hard on me as I DO use it for a hotspot, and I don't have it in my hands to perform basic grep/cat commands to pull up some simple things I could just easily get from another developer (if we have one available). My only internet at home is through this phone, and I can't easily test things without losing internet connection.

Anyways - I have dug up some info on my own and from the looks of it we need the same arch (32bit / 64bit arm) ROM from another device of MT6735 that has working 7.x (from what i read we have just that in the 'discontinued lineage rom' right?)

If so, Then we need to keep our original Stock working kernel for now and add the missing blobs of the precompiled kernel modules /proprietary drivers, stick them in the familiar location for them to be insmod during init.

After that a device node should be populated for the camera that is attached to the board and there should be no more Unknown Device 'Camera0" <<example

But if our stock kernel and rom is only 32bit, and the ROM being ported is 64bit it will not work.. There is no need to mix 32/64 bit sources anyway. I'm almost certain that the kernel sources I took that config snippet from is the proper kernel source for the R1 HD, and that config file I linked to should be the actual configuration file used by BLU. Compiling it for 64 bit at compile time would simply solve all those issues. (Unless we only have a 32bit camera kernel module available and it depends on 32bit libraries to function for some reason in which are also dependencies of other things on the phone - in that case it would be a worse DepHell than redhat ever dreamed of having, if thats the case BLU took the easy way out and just recompiled the sucker entirely as 32bit to resolve the entire issue. That would be a sad development move from the company standpoint, but in reality it doesn't effect us much as there isn't any hardware this phone has that is limited by only using a 32bit OS)

Truly the cleanest way to do this would to build both the rom and kernel from source and forget about 'porting' any of it. So if someone can build that kernel using the config here: https://github.com/anpage/android_k.../blob/master/arch/arm/configs/p6601_defconfig the source is in the parent dirs. After the zImage and modules are created if you can create the boot.img and flash only the boot.img to the appropriate partition using custom recovery, if it boots and works then you will know we have the right source. That will mean everything else will be straightfrom there... I understand what I"m asking is a bit much for the average joe on here, but I really am not in a situation where I can easily do those things and lose my internet while using adb on the device. So really I need an experienced dev here that knows how to write a simple update-script to flash boot.img. I need someone that knows how to compile a kernel with arm-eabi toolchain plus compile the modules and then create a custom boot.img from those. If someone here can do those things and provide details we'll move from there.

Unfortunately I can't currently afford to buy a spare R1 HD to tinker with and figure all this out on my own, but I can tell you right now this device is capable of running much newer releases of android than what it officially supports, and it greatly saddens me that such a device's 3rd party development ends because of a kernel related issue. I just can't come to accept that!