• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root Huawei Valiant Development Thread

EagerestWolf

EagerestWolf

Android Enthusiast
Yup, you saw that right. As it turns out, we have the wrong kernel source code. The source code that Huawei uploaded was actually the kernel source for Android 2.3.5, as evidenced by this line in the build.prop
Code: 
#ro.build.description=msm7627a-eng 2.3.5 GRJ90 eng.hongtao.20111013.064550 test-keys
However, if you are a good observer, you will notice that there is a hash symbol at the beginning of that line, and anyone with any amount of programming experience can tell you that in makefiles and properties files (basically makefiles not used to build software), a hash symbol indicates a comment. So what is the actual build then? Well, if you look at the very bottom of the build.prop file, you will find a line that reads
Code: 
ro.build.fingerprint=MetroPCS/Y301A1/hwY301A1:4.1.1/HuaweiY301A1/C85B132:user/ota-rel-keys,release-keys
So, allow me to read that line for you in plain english, the manufacturer of this device is MetroPCS, it is identified by board Y301A1, has model number hwY301a1, runs Android 4.1.1, can also be referred to as Huawei Y301A1. And the rest is just programming stuff that doesn't matter.

What is important however is that this device was never supposed to have Jellybean, it was supposed to have Gingerbread, but MetroPCS put Jellybean on it. This leads me to wonder, do I actually have the correct kernel source for this phone?
 
thats the source provided by the manufacturer.

im not experienced enough to know how much of a diffence the find makes but it also doesnt suprise me much either after dealing with huawei before.
 
The main reason I say that is because the kernel source will not compile, and I wondered why. So, I started poking around and found that.
 
this kernel was made for jelly bean
all gingerbread devices had 2.6 kernels
most ics had 3.0.X
and now jellybean+ have 3.4 kernels
this is a 3.4 kernel
they prolly recycled one of their old device trees to make your "stock" rom
remember, android is open source, so the OEMs have to build and hack together roms just like us so its not odd for them to do this either.



Kernel compiles fine for me, im guessing you have to use "hw_msm7x27a_defconfig " for which it makes the zImage
I compiled with linaro 4.7.3 also

i will upload my patches for linaro compile in a few minutes to my repo:
https://github.com/rbheromax/android_kernel_huawei_valiant
 
Well I cannot do Linaro because I am doing a Cyanogenmod integrated kernel build, but I think I was using the wrong defconfig. I was using the msm7627a_defconfig
 
thats pretty normal for huawei, even the vitria which is a MSM8930 device has that same exact fingerprint commented yet the valiant is not very similar hardware wise to the vitria, you need to use the defconfigs that start with "hw" or pull the config.gz and extract it from the device(if it has one) I was able to build the A1 kernel with the source also with no errors, unlike the A2 kernel which will build but not boot because the source is a nightmare.

I'm just wondering but did you look at dazzozo's work, he builds cm for many devices that are extremely similar to the valiant.
https://github.com/Dazzozo?tab=repositories
 
Yeah, I'm taking a look into it now, and doing another build. This time, I am actually using the correct defconfig, so hopefully all goes well...
 
Got my error, although it isn't even an error, it's a warning, but there seems to be a makefile flag somewhere (possibly in the Cyanogenmod stuff) that is telling it to treat warnings as errors.

Code: 
/home/seth/android/cm-10.1/kernel/huawei/y301a1/arch/arm/mach-msm/board-msm7x27a.c: In function 'msm7x2x_init':
/home/seth/android/cm-10.1/kernel/huawei/y301a1/arch/arm/mach-msm/board-msm7x27a.c:1506:2: error: implicit declaration of function 'msm7627a_bt_power_init' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

make[3]: *** [arch/arm/mach-msm/board-msm7x27a.o] Error 1
make[2]: *** [arch/arm/mach-msm] Error 2
make[2]: *** Waiting for unfinished jobs....
 
KainXS said:
thats pretty normal for huawei, even the vitria which is a MSM8930 device has that same exact fingerprint commented yet the valiant is not very similar hardware wise to the vitria, you need to use the defconfigs that start with "hw" or pull the config.gz and extract it from the device(if it has one) I was able to build the A1 kernel with the source also with no errors, unlike the A2 kernel which will build but not boot because the source is a nightmare.

I'm just wondering but did you look at dazzozo's work, he builds cm for many devices that are extremely similar to the valiant.
https://github.com/Dazzozo?tab=repositories
Click to expand...


As it turns out, some of this is exactly what I need to finish Cyanogenmod, and the rest will be super awesome and secret for my next project (it may or may not be Cyanogenmod 11/AOSP 4.4)
 
Anyway, I am gonna get some sleep for now. I will resume the grind tomorrow. also, just a heads up to all the Valiant Owners who may be following this thread. Today I got my developer recognition from Android Forums, so over the next few days/weeks/months/wheneverthehellifeellikeit my stuff will get moved over to my developer forum Eagerestwolf (<== shocking I know, cause it's not like that's my username or anything)
 
EagerestWolf said:
Got my error, although it isn't even an error, it's a warning, but there seems to be a makefile flag somewhere (possibly in the Cyanogenmod stuff) that is telling it to treat warnings as errors.

Code: 
/home/seth/android/cm-10.1/kernel/huawei/y301a1/arch/arm/mach-msm/board-msm7x27a.c: In function 'msm7x2x_init':
/home/seth/android/cm-10.1/kernel/huawei/y301a1/arch/arm/mach-msm/board-msm7x27a.c:1506:2: error: implicit declaration of function 'msm7627a_bt_power_init' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

make[3]: *** [arch/arm/mach-msm/board-msm7x27a.o] Error 1
make[2]: *** [arch/arm/mach-msm] Error 2
make[2]: *** Waiting for unfinished jobs....
Click to expand...

That's wat making it linaro compliant fixes. M moms make a zimage suitable for CM compile with stock defconfig
 
oops i thought i had commited them
sorry for my last post, idk why it was all broken english and stuff
looks like i was drunk typing it (not really cuz i dont drink :D im 17 )
i'll push them up soon.
 
Found an interesting bug while messing with my device. The CPU identifier app from the Play Store actually recognizes this device as having a Qualcomm msm8225 chip set, which if memory serves correctly is actually the same as the Vitria. Another point of interest, evidently this phone has an Adreno GPU, however Huawei hard coded into the kernel that CPU/GPU switching is not allowed. However, having a dedicated GPU does make KitKat look like a much better option than Jellybean no thanks to the 4.2/4.3 memory leak.
 
Found all of my errors. I have been using the wrong defconfig. For some reason, even though the build.prop says it does, this device does NOT have a Qualcomm msm7x27a chipset. It has a Qualcomm msm8x25 chipset. Found this in the /proc/config.gz

Code: 
CONFIG_MACH_MSM8X25_Y301_A1=y
 
So what's the logical thing to do when you build a new phone with a new chipset? What's that you say Huawei? Build on top of the old one? That will never work. And it doesn't. That is what has been causing the errors all aliong. Huawei built the config for the msm8x25 chipset on top of the config (and source) for the msm7x27a chipset. This is a nightmare. I feel ya pain KainXS. We are working with the same kernel source now.
 
GCC is dumb. I have been crawling through the source of this kernel looking for this function of doom. Wanna know what's funny? IT ISN'T AN IMPLICIT DECLARATION. It clearly takes in type void and puts out type void. That is the very definition of an explicit function. Anyhow, here it is, "The function of doom"

Code: 
void __init msm7627a_bt_power_init(void)
{
	int i, rc = 0;
	struct device *dev;


#ifndef CONFIG_HUAWEI_KERNEL
    gpio_bt_config();
#endif

	rc = i2c_register_board_info(MSM_GSBI1_QUP_I2C_BUS_ID,
				bahama_devices,
				ARRAY_SIZE(bahama_devices));
	if (rc < 0) {
		pr_err("%s: I2C Register failed\n", __func__);
		return;
	}

	rc = platform_device_register(&msm_bt_power_device);
	if (rc < 0) {
		pr_err("%s: device register failed\n", __func__);
		return;
	}

	dev = &msm_bt_power_device.dev;

	for (i = 0; i < ARRAY_SIZE(bt_vregs); i++) {
		bt_vregs[i].reg = regulator_get(dev, bt_vregs[i].name);
		if (IS_ERR(bt_vregs[i].reg)) {
			rc = PTR_ERR(bt_vregs[i].reg);
			dev_err(dev, "%s: could not get regulator %s: %d\n",
					__func__, bt_vregs[i].name, rc);
			goto reg_get_fail;
		}
	}

	dev->platform_data = &bluetooth_power;

	return;

reg_get_fail:
	while (i--) {
		regulator_put(bt_vregs[i].reg);
		bt_vregs[i].reg = NULL;
	}
	platform_device_unregister(&msm_bt_power_device);
}
 
While that would easily fix the issue, I also have a feeling it would break bluetooth, so I am trying to avoid that. The solution I am trying now is that I added a

Code: 
-Wno-implicit

to the kernel makefile, which in theory should squash that error.
 
So, first and foremost, I updated the thread title so it is a bit more relevant. Secondly. I found out what is causing the issue with the function of doom. In C, if you have a function that takes no arguments, but reterns something, that is an implicit function declaration, and that is bad because you can return things that may overload the memory. So, I have changed the function, removing the return statements and adding an else block around the for loop (that last bit won't execute unless called because that is a goto tag). I cannot test it riight now, because I am in a full build of Cyanogenmod, but I believe this may fix the compile issue with the kernel.
 
You must log in or register to reply here.
Back
Top Bottom