yashsingh1/xdaforums huggingface dataset:
[BLU R1 HD Guides, News, & Discussion] vampirefo:
You have to unpack stock boot.img before you even run script. The ramdisk is in stock boot.img

---------- Post added at 06:41 PM ---------- Previous post was at 06:18 PM ----------

fastboot boot vamp_boot.img
[BLU R1 HD Guides, News, & Discussion] KazuDante:
Will it be posible to convert it fir twrp?
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Yes but why? It's stock kernel no different than the kernel you already have.
[BLU R1 HD Guides, News, & Discussion] N00b-un-2:
damn... compiled a new kernel, built boot.img with Carliv Image Kitchen... still won't boot from my kernel. It just silently fails and boots from the stock boot.img. I noticed that you are building with arm-eabi 4.8 as opposed to arm-linux-androideabi 4.9. pulling down the AOSP code to grab the prebuilts from it, will try again... :(
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Won't boot on 4.9 you have to use what BLU used 4.8.

Any time you go to build a kernel, see what the company that built the tablet used.

cat /proc/version

This is will tell you what gcc version to use, notice stock boot.img says 4.8?

Next look at android.mk file in kernel source it tells you what version to use, in this case arm-eabi.
[BLU R1 HD Guides, News, & Discussion] AtomicFizzle:
Very nice work, [MENTION=2472806]vampirefo[/MENTION]! One thing i'm missing now is what you added for the DTB output. I saw this referenced a few pages back, but not what you ended up doing-

MTK_APPENDED_DTB_SUPPORT:= yes
BOARD_KERNEL_IMAGE_NAME := zImage-dtb
[BLU R1 HD Guides, News, & Discussion] N00b-un-2:
Yeah, I kinda figured that was the case. as a Linux guy, I try to stay on the bleeding edge. But android is not as forgiving as a regular linux kernel :-S
[BLU R1 HD Guides, News, & Discussion] vampirefo:
That is only needed if when we get to compiling cm13 or aosp, as we would want kernel compiled through our device tree.

Stand alone compiling as we are now doing doesn't need this we simple use command make

all three kernels are built, then we just garb the dtb one via script.
[BLU R1 HD Guides, News, & Discussion] kal250:
I'm reading all this, and understand the concepts, but still no idea (Im linux retarded) what exactly is going on :p, so the million dollar question, how close before we make it to custom roms?? And thanks for all the work you guys are putting in...
[BLU R1 HD Guides, News, & Discussion] N00b-un-2:
re-sync the git repo. looks that change was committed already

---------- Post added at 03:30 AM ---------- Previous post was at 03:15 AM ----------

Well... it depends. the first step to porting a ROM is generally to be able to compile the kernel (yes, there are some ROMs built off of prebuilt kernels, but that's much less common now than back in the froyo/gingerbread days). there are two devs who are currently working on device trees for the p6601 (the technical name for R1 HD). I myself have been on Apple devices for the last year + and am a bit rusty on my Android chops, so I'm a little behind the power curve. Depending on several factors, not the least of which being whether this phone uses proprietary binary drivers (usually called "blobs") and how difficult it is to make the CyanogenMod source code jive with how the Blu devs put everything together. sometimes, this part is easy. sometimes, it requires a whole lot of reverse engineering, but in the end it's not impossible. In the case of some devices, eg; the LG Gpad 8.3 LTE (the last device I did any dev work on) there were no other devices that used that particular 4G modem to reference, the drivers were "blobs" and the hardware manufacturer never released the source code. The tablet's 15 minutes of fame came and went, and despite receiving Cyanogenmod 11, 12 and 13, the LTE modem was never figured out and dev work ended due to lack of interest. That being said, the Blu R1 HD is currently one of the best selling ITEMS on Amazon, if not one of the best selling PHONES, so there will be enough people with their hands on the device that I believe it will attract enough attention from devs that ROMs are an inevitability. We're already 3/4 of the way there and have the added bonus of an unlocked bootloader (most phones I've dev'd on don't have that luxury), so it's really just a matter of time.

so in a roundabout way... I guess I'm saying "don't worry baby birdies... we'll feed you."

or in other words:

First Rule of CyanogenMod: Don't ask for ETA's
[BLU R1 HD Guides, News, & Discussion] vampirefo:
I just got the phone yesterday, too early to say, next step is to get a working device tree, that correctly compiles kernel and packs boot.img and recovery.img.
[BLU R1 HD Guides, News, & Discussion] jasonmerc:
If by proprietary blobs you mean things like features.h, uio.h, etc... I've been getting issues during building saying they don't exist. I've found those files on the web but like I said, if those are proprietary (meaning device specific) then I can't use the web ones.

Clearly you guys know what you're doing more than some of us from the general thread. I've been speaking with someone who's been trying to build his own device tree but is running into his own errors along the way when trying to compile. He hasn't uploaded it to GitHub yet but it'll happen soon. I'll link it here when it does happen, and perhaps we can see if anything from one can be added to the other to make it work better (by some small chance).

Some of us birdies are trying to feed ourselves but keep hitting our own sets of branches on the way down ;)
[BLU R1 HD Guides, News, & Discussion] jasonmerc:
Whoever Ryan is tell him he did one hell of a job
[BLU R1 HD Guides, News, & Discussion] KazuDante:
one last question....is this soc able to OC/UC and OV/UV?
[BLU R1 HD Guides, News, & Discussion] vampirefo:
The source code is available for you to look at.

---------- Post added at 05:35 AM ---------- Previous post was at 05:27 AM ----------

The device tree you are talking about builds working twrp and compiles kernel correctly and packs bootable recovery.img?

Everyone stumbles, my next project is to get adb remount working, and create flashable stock ROM, I have had my phone the least amount of time in this thread, so in many aspects I far behind others.

I have my own personal goals though.

1. adb remount working

2. flashable stock rom via twrp

3. device tree that can build twrp and correctly pack kernel.

Anyway good luck on your project.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Why aren't you running 6.5? You are using 6.4?

My phone updated directly to 6.5, which has lasted security update.
[BLU R1 HD Guides, News, & Discussion] jrk190:
Bootloader unlock and simplicity probably.

Congrats to whoever Ryan is, I'm assuming that's a successful build and boot of a kernel, one step in the right direction
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Your reply doesn't make sense to me.

Why run older version of software?
[BLU R1 HD Guides, News, & Discussion] jrk190:
Probably just didn't bother to update. It's a dev phone, probably not daily used.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Again your reply doesn't make sense to me, he used my script to build kernel says he lives on the edge yet runs out of date firmware.
[BLU R1 HD Guides, News, & Discussion] jrk190:
The point being, he successfully built and has the custom kernel. That in itself is a milestone. The kernel can always be updated and improved, it was likely just for proof.

Just give it time and it can only get better from here
[BLU R1 HD Guides, News, & Discussion] vampirefo:
He only did so cause I told him how, I guess you skipped right over my posts, as I was the one who compiled the kernel and posted the kernel, and gave instructions and script on building the kernel my point is why run out of date firmware, my guess you don't know why.
[BLU R1 HD Guides, News, & Discussion] jrk190:
Oh sorry, I read the posts but think I skipped over the names. Thanks for clearing that up.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Not a problem, see when developing people who are developing should be using and developing on the latest firmware.

I work on many devices, always use the latest firmware.
[BLU R1 HD Guides, News, & Discussion] N00b-un-2:
vampirefo is correct. I could not have figured out packing the boot image without his assistance. Credit where credit is due. As far as why I'm running 6.4 and not 6.5, I just got the phone yesterday and didn't bother updating it before flashing TWRP, rooting and unlocking the bootloader. When going through that process, all of the tools seemed to be built for 6.4 firmware and I didn't want to risk losing the ability to do so. My general approach to any device is that OTA updates are BAD BAD BAD and you should never do them. Here's a blog post I wrote last year that explains my stance on OTAs http://ryancuda.blogspot.com/2015/05/why-ota-updates-are-bad.html Besides, with any luck, I'll be flashing custom firmware on it soon. firmware 6.5 wasn't even a point release for Android (still build MRA58k, the FIRST release of Marshmallow which is nearly a year old now), so defer to rule #1 NEVER ACCEPT OTA UPDATES. And yes this is not my main phone. daily driver is a jailbroken iPhone 6S+, this phone is just for dev purposes.
[BLU R1 HD Guides, News, & Discussion] jrk190:
What's the next step now in development?
[BLU R1 HD Guides, News, & Discussion] vampirefo:
I disagree OTA are the best, you get almost all the info you need from them, to develop on a particular device correct placement of partitions, correct permissions, security updates.

Thanks to the OTA I know the correct permissions to place in my update script for my flashable stock rom and or any custom rom.

Correct permissions are the key to successful flashing firmware.

As far as root tools and so forth.

How I rooted my device.

I unboxed the phone, charged phone, after an hour, started flash tool loaded unlock.img hooked phone up to computer pressed power.

Phone was immediately flashed, this was the first start of phone.

Now let phone boot up, skip everything that can be skipped only do the least possible to get to developer options, check USB debugging.

adb reboot bootloader,

fastboot oem unlock

reboot, setup phone.

adb reboot bootloader

fastboot boot twrp

make backup

Reboot system download OTA, after download copy OTA to computer, now allow OTA to install, after installed.

adb reboot bootloader

fastboot boot twrp

make backup

now flash SuperSU zip and reboot.

I now have two completely stock back ups one that came with phone other one 6.5 updated via OTA.

Now with rooted file manager remove, amazon crap, and anything else you want to remove.

If at anytime another OTA is available.

adb reboot bootloader

fastboot boot twrp

use twrp to restore the system and boot from 6.5, reboot.

Download new OTA save to computer, then install, once installed make a backup of it.

Just repeat the process for every OTA,

These backups can be transferred to your computer.

Always have the most current firmware without any problems.

---------- Post added at 09:45 AM ---------- Previous post was at 09:44 AM ----------

My next step is to make a flashable stock rom, I figured out adb remount last night.
[BLU R1 HD Guides, News, & Discussion] N00b-un-2:
Thanks for the info. OTA updates may be useful to gather info from, sure. but there is a very distinct possibility that an OTA update in the future can break things like the bootloader unlock, recovery, root, etc. Case in point; The LG G3. druing the time I owned the phone, the Lollipop bootloader was never unlocked, so to flash CM12 or above you had to roll the bootloader back to the kitkat one. Not worth losing root over. In my opinion, staying on the lowest (and thus most exploitable) firmware is best if you modify your device. Not only that, but as I pointed out on my blog, most OTA updates are inherently designed to slow your phone down.

I'm not saying that either policy is more or less correct than one or the other. But in my case, as a practice I do not ever accept OTA updates.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
All you have to do is look inside the OTA update and see what it does, say for example it replaced bootloader, thus would prevent bootloader unlocking.

In that case simply remove that part of the OTA, zip and flash modified OTA via twrp now you have the update minus the bootloader part.

You can always review the OTA zip make changes if needed then flash it.

Too each their own.

Anyway we are off topic, my fault.[emoji12] [emoji12] [emoji12]
[BLU R1 HD Guides, News, & Discussion] KazuDante:
Wich file or files are need to be modified to attempt enabling a few more 4G bands?
[BLU R1 HD Guides, News, & Discussion] vampirefo:
That is the modem, up to BLU on what bands they allow.
[BLU R1 HD Guides, News, & Discussion] KazuDante:
Sadly i cant return this phone...my stupid contry refuse to share info on which bands 4g they work on, and Blu reponded to me that they dont have futur plans on unveiling more bands
[BLU R1 HD Guides, News, & Discussion] jasonmerc:
Well no more Band 12 for us then. Probably no more Nougat as well.
[BLU R1 HD Guides, News, & Discussion] jrk190:
Exciting! I wonder with our current sources if it'll be possible to build nougat and later versions of Android. It's always confused me as to why some devices have kernel sources but can't be updated via custom Roms... I guess too much code changes between kernels? I don't know.
[BLU R1 HD Guides, News, & Discussion] KazuDante:
band 12 is already released tho.

---------- Post added at 04:12 PM ---------- Previous post was at 04:09 PM ----------
[BLU R1 HD Guides, News, & Discussion] jasonmerc:
You need to enable it in engineering mode every time the phone starts though. Its not automatically enabled on boot.
[BLU R1 HD Guides, News, & Discussion] KazuDante:
Yea thats the stupid part...wich is one reason i wanted to know if its possible to unveil more bands since Blu wont.

---------- Post added at 04:42 PM ---------- Previous post was at 04:14 PM ----------

Android 7.0 would def be a nice addition to this phone.[emoji12]
[BLU R1 HD Guides, News, & Discussion] jasonmerc:
Once this device tree is done, I can't imagine cm14 being too far off ;)
[BLU R1 HD Guides, News, & Discussion] KazuDante:
I found an article on cross-porting , i used to port rom on mt6572 so i will try to cross port the one from the j3 that someone already got it to boot. Dont know how that will work out since it was back in 2013 i ported roms

---------- Post added at 06:43 PM ---------- Previous post was at 05:48 PM ----------

Would a 4.8 linaro work when compiling the kernel?
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Most likely the linaro tool chain would work.

I can't think of any reason to use it, unless that's the only tool chain you have.
[BLU R1 HD Guides, News, & Discussion] KazuDante:
It was the first i downloaded when i was setting up my vm for taking a crack at building the kernel
[BLU R1 HD Guides, News, & Discussion] superdragonpt:
No OC ( cpufreq is locked on board) unlocking those via sw does nothing, just placebo

UV, ye, you need to find the register, but on this SoCs ate rather unstable

Any new kernel source released by BLU?

(Sorry I didn't had time to read previous post, too busy )

Cheers
[BLU R1 HD Guides, News, & Discussion] superdragonpt:
??

Will never work .

If the ROM is 32bit, it'll only run @32

Nothing you can do on kernel

32, 64 bit ROM sources differ a lot just so you know.

I'm amazed (?) Why did the phone came with 32bit only?

The SoC yes does support 64bit, the only possible reason is a limitations. Is one(or more) of the hardware .

But still

Cheers

Edit; About bands, those are locked via modem MOLY. You can't unlock more than the ones already available via mediatek engineer menu

( *#*#3646633#*#*) .

If it lacks any band, then its due to licensing , and/or platform not support .

You may yes have the case that some bands are supported , but just not enabled.
[BLU R1 HD Guides, News, & Discussion] KazuDante:
But will modifying the modem moly file(s) possibly enveil more bands , since the 4g ones that are enabled dont work for me ?

by all mean its most likely illegal but can it be done?
[BLU R1 HD Guides, News, & Discussion] superdragonpt:
You can't modify modem ..

Even if you had modem source, device needs to be compatible, and may also need some changes.

cheers
[BLU R1 HD Guides, News, & Discussion] N00b-un-2:
superdragonpt is correct. without source code for the modem you can't modify it. and yes, depending on which bands you are trying to enable you are either in breach of A) Licensing (each band is licensed on a per chip basis much in the same way particular features of the ARM instruction set are licensed to different ARM CPUs)

B) federal law -- the FCC regulates which bands of radio communication can be used in which jurisdictions (outside the US other regulatory agencies handle this). EG; Wifi. There are more wifi channels and bands in existence than are in use in the US. The use of bands not authorized for use in a given jurisdiction could interfere with other types of radio transmissions. The obvious case that comes to mind is aircraft communication. if your laptop is broadcasting noise in a frequency used by aircraft and you cause a plane to crash, you are at fault. Hence why it's illegal.

---------- Post added at 08:53 PM ---------- Previous post was at 08:49 PM ----------

not sure why you would. You can just grab the prebuilts from the AOSP github, or the official NDK.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
I already said you can't modified bands, what bands BLU allows is it period.

Only BLU can modify bands.

---------- Post added at 04:02 PM ---------- Previous post was at 04:01 PM ----------

Correct, but he wants to use linaor tool chain for one reason or other.

There used to be hype about this tool chain a few years ago, but it was mainly just false hope.
[BLU R1 HD Guides, News, & Discussion] bullet25:
Just in case any Dev who knows what they are doing is watching this thread. This is my current error in my attempt to build.

make: * No rule to make target '/home/bob/workspace/CM13/out/target/product/p6601/obj/STATIC_LIBRARIES/libminui_intermediates/libminui.a', needed by '/home/bob/workspace/CM13/out/target/product/p6601/obj/EXECUTABLES/healthd_intermediates/LINKED/healthd'. Stop.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
You most likely could get answers from here

http://xdaforums.com/showthread.php?t=2274332

They probably need to see your device tree, before they can help you, the key to compiling anything is a complete tree, I compiled cm12.1 for my blu energy x plus phone, took a while to get the tree correctly, and cm12.1 source had to be patched several times.

https://plus.google.com/101944948426591597599/posts/ZSCcTy2Us9t

so no doubt cm13 and cm14, must be patched before you can build it for your device.

my guess the vendor blobs for this phone will be close to 300, almost that many buliding cm12.1 for my older phone.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
I have made a stock rom flashable via twrp, have adb remount working.

So now need to compile a twrp recovery.
[BLU R1 HD Guides, News, & Discussion] KazuDante:
Did you upload the twrp flashable stock rom?
[BLU R1 HD Guides, News, & Discussion] vampirefo:
No when I do, I will make it's own thread.

0cee0d831502a2a867f036d951c3c78c /home/vampirefo/Desktop/R1HD/stock_rom/stock_rom_R1HD_6.5.zip

I have downloaded [MENTION=5355478]ColtonDRG[/MENTION] normal-stock-oob which is V12 non prime version, I checked the permissions on the system to see if 6.5 and V12 used different permission they use the same.

So a V12 rom can be made from my exact stock_rom_R1HD_6.5.zip, I may or may not provide a non prime version, even if I don't all a user has to do it open my stock_rom_R1HD_6.5.zip replace system and boot.img with non prime zip and flash.

There are two twrp recoveries one I just made and one made by [MENTION=4939713]lopestom[/MENTION] I had to get the rom compliant with both recoveries, [MENTION=4939713]lopestom[/MENTION] was the first recovery available for R1HD and allows backing up and restoring of many partitions, I am going to use his recovery.fstab, but remove the partitions backup and restore I don't use.

both recoveries at one time or other would throw an error

ApplyParsedPerms: lsetfilecon of /system/lost+found to u:object_r:system_file:s0 failed: Operation not supported on transport endpoint
script aborted: set_metadata_recursive: some changes failed
set_metadata_recursive: some changes failed

I have now fixed that so neither recovery error, any other recovery that might show up, that person will have to fix his own, for now two recoveries can flash my rom, the one I made and [MENTION=4939713]lopestom[/MENTION] I will release rom after more testing.
[BLU R1 HD Guides, News, & Discussion] KazuDante:
Awsome.....ive seen some cm13 related git , is it being worked on since the kernel can be compiled now?
[BLU R1 HD Guides, News, & Discussion] vampirefo:
There are several people working on cm13 right now, I will build my own device tree soon for compiling roms, right now my device tree correctly builds and packs twrp.

I am not sure how far the people compiling cm13 for R1HD are, I have other goals and projects first, Honestly I am not a big fan of CM, I have compiled cm12.1 for my older phone, mainly cause people wanted it, but I don't continue to update it and so forth far to much time and work for a rom I don't even use.

I wont use cm13 on this phone either, the rom that's on it is great, nothing that cm13 would improve, cm13 would just be another rom I won't use.
[BLU R1 HD Guides, News, & Discussion] KazuDante:
So would it be safe to guess that Android Nougat (stock) would be a possible project for the R1 HD , since Blu wont do it? also is there a huge difference between the MT6753 and our 6735.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
I can't say as I don't know, Nougat is just another half bake OS. Works great on google phones, and other priority phones. Unlikely to ever work great on mtk.

I am sure some one has made Naougat for mtk, take notice of stuff that don't work.

If your phone is a permanent dev phone, have fun, build away, I like to use my phone as a phone.[emoji12] [emoji12] [emoji12]
[BLU R1 HD Guides, News, & Discussion] KazuDante:
True
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Here is rom.

http://xdaforums.com/newthread.php?do=postthread&f=5621
[BLU R1 HD Guides, News, & Discussion] KazuDante:
Looks like it was taken down
[BLU R1 HD Guides, News, & Discussion] vampirefo:
I Posted wrong link, below is correct link.

http://xdaforums.com/showthread.php?t=3455532
[BLU R1 HD Guides, News, & Discussion] LeMagicien:
Thank you for this post :)
[BLU R1 HD Guides, News, & Discussion] moriel5:
If you want to build a x64 rom, you should take a look at SnowCat4PDA's kernel sources.

True, it's for a different device, but it's the same chipset.

By the way, we would like help over at our threads with the Doogee X5 Pro (again, same chipset, the MT6735P), it definitely needs some roms, such as a stable CyanogenMOD (preferably CM13).

About Nougat, I'm currently on a hunt for kernel sources for our chipset (currently hoping for a leak from either Moto or BLU, although any vendor will do).

https://github.com/SnowCat6/android_kernel_ark_benefit_m7

About differences between chipsets, the MT6735P is basically an underpowered version of the MT6735M, hence their kernel sources are practically the same.

However, the MT6735 is completely different, so it won't help you at all.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
This isn't a 64 bit phone.
[BLU R1 HD Guides, News, & Discussion] kal250:
Its a 64bit capable SoC, but a 32 bit OS, so either some hardware does not support it or BLU chose to develop for 32, hard to say....