Database Users

[ATTN] - 3991 and 4349+ VIEWSONIC-RECALLED BOOTLOADER INFO here - UPD 5/8/11

Updated 05/08/11
ATTENTION - IF YOU ARE ON STOCK 4349+ or any MOD BASED OFF 4349+ USING THE NEW RECALLED BOOTLOADER! READ PLEASE!
Starting with the most recent but recalled update to Tap N Tap Viewsonic has introduced a new Bootloader being called the 1.2 bootloader. This bootloader is not compatible with mods or Roms based off of the Viewsonic Current Bootloader being called the 1.1 bootloader! This bootloader provides absolutely no known advantage other than being able to boot any new STOCK kernels. If you would like to use any of our stable ROM's (i.e. Vegan 5.1.1, Vegan GingerEdition and currently CM7) using Viewsonics currently supported and shipping bootloader (1.1) you must Downgrade your bootloader and TNT Version before you flash a new kernel or a new ROM.
Please download the following downgrade update.zip and place it on your sdcard renaming it to "update.zip".
http://www.gtabdevs.com/releases/4349_Downgrade.zip
Then power down your device. And power back up while holding the power button and vol + till your display says "recovery key detected" in the top left corner.
Using the volume keys to navigate up/down in the menu highlight "Apply Internal update.zip" if you copied the update.zip to the internal memory or "Apply External SDCard update.zip" if you happened to place it on an external SDCard and then inserted it before booting to recovery. Now select the menu choice using the menu key.
This process will take a few minutes. You will see a Box with an arrow and a progress bar while it applies the update.... when it is finished it will reboot to make the changes. Once the changes are complete your tablet will boot into Tap N Tap version 3588.
You are now free to follow all the tutorials about installing CWM and/or Kernels/Roms.
Thank you and good luck.
Be aware. I am not connected with Viewsonic in any way. I make no assertions as to the validity nor the safety of anything in this post. Do anything above at your risk.

That is a handy utility to have. Thanks!

How do we check if the bootloader is locked? I'm curious if the bootloader.bin in 3991 (which is based off the same branch) has this same issue.
Thanks!

Strange. One step forward and two steps back for Viewsonic. But, maybe, this means there is still some interest from Viewsonic for our tablet and chance for further development (maybe even Honeycomb).

roebeet said:
How do we check if the bootloader is locked? I'm curious if the bootloader.bin in 3991 (which is based off the same branch) has this same issue.
Thanks!
Click to expand...
Click to collapse
If it too will not boot any other kernel besides a stock kernel built specifically for their new bootloader. That bootloader.bin also appears to be locked.

gojimi said:
If it too will not boot any other kernel besides a stock kernel built specifically for their new bootloader. That bootloader.bin also appears to be locked.
Click to expand...
Click to collapse
Does that mean it's locked, or does that mean that we just don't have the new source code to build custom kernels? I just want to distiguish because, if it's the latter, we can just ask them to release that like they did the 1.1-based source. EDIT: Already tweeted them. I see "1.1" in the source that's there, and we know that this is "1.2", so maybe there's new source code to be requested? Not sure.
I know that we can check for a locked bootloader with something like fastboot, but I don't think that works here. That's why I was asking.
Thanks again!

gojimi said:
If it too will not boot any other kernel besides a stock kernel built specifically for their new bootloader. That bootloader.bin also appears to be locked.
Click to expand...
Click to collapse
what could the thinking possibly be to locking the bootloader on a product like ours?
I'm seriously asking, besides being dicks, what would the reasoning be?

roebeet said:
Does that mean it's locked, or does that mean that we just don't have the new source code to build custom kernels? I just want to distiguish because, if it's the latter, we can just ask them to release that like they did the 1.1-based source.
I know that we can check for a locked bootloader with something like fastboot, but I don't think that works here. That's why I was asking.
Thanks again!
Click to expand...
Click to collapse
By all means ask for their new source... though I do not believe at this point they are required to give... maybe they are. So for the purposes of everyone else's understanding this is a LOCKED bootloader in the sense that we are LOCKED to their kernel...... nothing ever stays locked forever.... this is not however LOCKED in the terms that a select few who already know what's going on with this bootloader typically use the term LOCKED. Take it as you will.

snapz54 said:
what could the thinking possibly be to locking the bootloader on a product like ours?
I'm seriously asking, besides being dicks, what would the reasoning be?
Click to expand...
Click to collapse
To be honest they are probably tired of all the people calling viewsonic support with issues that are not on OFFICIAL viewsonic software... most companies try to do something to deter this activity in some regards.

Does nv flash still works to downgrade everything?

gojimi said:
To be honest they are probably tired of all the people calling viewsonic support with issues that are not on OFFICIAL viewsonic software... most companies try to do something to deter this activity in some regards.
Click to expand...
Click to collapse
I understand this for "most companies" but Viewsonic is the company that openly linked on their product page that XDA is the place to be if you need support or any real use from your gtab.
We had to fight them to finally stop doing that. It doesn't really add up.
The only thing this does if it works is effectively pull the plug on the life support that was pumping any further life into the tablet.
We still have great "legacy" roms and infrastructure that make the tablet great. but moving forward all this does is concentrate our efforts towards them. releasing a workable open solution keeps us busy tinkering with it for months. Locking things down only sends us back to twitter and the like but now we have more members thanks to the new OD, TD, and amazon users.

I thought VS said they were going to work with the devs. Didnt they contact you guys? I thought they would of asked or told you guys what the best way for them to go would be. Did this never happen?

Pazzu510 said:
Does nv flash still works to downgrade everything?
Click to expand...
Click to collapse
Yes, maybe. I had to NVflash mine because I accidentally flashed CWM over 4349 while i was playing in the 4349 recovery screen. The NVflash process worked, but for some reason my touch screen was borked (no touches were registered). Couldn't do anything. In the past a couple restarts with calibration.ini on the external SD would clear that for me, but didn't this time. I ended up doing NVflash with CWM as part9.img and then repartitioned with CMW and NVflashed again with stock recovery part9.img. Screen was still borked but cleared up with a couple restarts with calibration.ini on an external SD. So the answer is yes you can, but it may not be as smooth as you are used to. Of course it may work fine for you.
Matt

jasco13 said:
Yes, maybe. I had to NVflash mine because I accidentally flashed CWM over 4349 while i was playing in the 4349 recovery screen. The NVflash process worked, but for some reason my touch screen was borked (no touches were registered). Couldn't do anything. In the past a couple restarts with calibration.ini on the external SD would clear that for me, but didn't this time. I ended up doing NVflash with CWM as part9.img and then repartitioned with CMW and NVflashed again with stock recovery part9.img. Screen was still borked but cleared up with a couple restarts with calibration.ini on an external SD. So the answer is yes you can, but it may not be as smooth as you are used to. Of course it may work fine for you.
Matt
Click to expand...
Click to collapse
I've nvflashed back to 1105 at least a dozen times since last night (was doing upgrade / downgrade scenarios). So far, so good.

The bootloader is provided by viewsonic I think, it may be the key for some chipset feature, some other brand of tablet like the adam already has the same exact one
it's probably not locked but only doing something different like you said!

if I had to guess, they didn't lock it to be pricks...odds are it is locked to prevent people from flashing our current kernels to this to avoid messing things up...
so here's prolly how we'll be structuring our ROMs/Kernels now...1.1-based Froyo ROM; 1.2-based Froyo ROM; 1.1-based Froyo Kernel; 1.2-based Froyo Kernel and so on for GB if we're lucky HC in the future.
It's going to be a pain in the butt in the short-term, but long-term it'll only benefit current and future gTab owners as a whole if we stick to the 1.2 path alongside the vendor. This will keep confusion to a minimum, features to a maximum, and upgradability easy.
Thanks to all devs for their future support even through some of the PITA times

i have no options to choose between, aka no menu when i do all that, it just goes to a box picture and then reboots and loads normally.

Edited...You can't fix stupid

iamnottypingthis said:
i have no options to choose between, aka no menu when i do all that, it just goes to a box picture and then reboots and loads normally.
Click to expand...
Click to collapse
There is no menu. It takes you back to 3588 and the ability to flash all current roms.

So this "rollback" is jsut a stock 3588 image, or is it something different?

[MOD][BOOTLOADERS] I9000 GB Bootloaders

I am not responsible for any damage to your phone, computer, home network, work network, social network, family pet, significant other, insignificant other, car, home, boat, or anything else in your life. By downloading and executing this software you release the creator from any and all liability, including civil, uncivil, and criminal.​
First, Thanks to:
Cezar This is another of my projects that wouldn't have been possible were it not for his help.
Watsa
If anyone feels I may have left them out, pm me.
Several people have asked "Where can I get the I9000 bootloaders?" I know there is a thread here that has them, but to get them you have to flash an entire ROM. I decided to extract just the bootloaders (boot.bin and Sbl.bin) and the param.lfs file from JVB factory firmware (downloaded from www.samfirmware.com) and package them in a Full Odin version (1.82) for those wanting them.
Flashing bootloaders is dangerous. They are one of the few things that has the possibility of hard bricking your phone. For that reason, here are some good things to do to prepare for flashing them.
Have a good, reliable data cable. Interruption of communication between your phone and pc will most likely cause a hard brick with bootloaders.
Use a usb port on the back of your computer (or #1 on a laptop). Communication, again.
Have a jig. Not much help if you hard brick, but if you soft brick its very nice to have.
I personally flash bootloaders from a good laptop with a fully charged battery. If there is a power outage, the battery in the laptop will have saved my phone.
When flashing bootloaders,or anything with Odin, don't touch your phone after you connect it in dl mode. Goes back to the communication issue.
After flashing new GB bootloaders, do not ever, ever, ever flash the old 3 button fix. If you do you will HardBrick your phone. If you flash any rom that contains a secondary bootloader (Sbl.bin) only, you will brick your phone
New button combo's
Vol down+power= Download mode
Vol up + power= Recovery mode
Powered off, vol down then insert usb= download mode
You will need 7zip to unpack files. Need 7zip? Get it >>HERE<<
If you need Drivers look >>HERE<<
If your computer's security software recognize's Odin as a threat, just create an exception for it.
I9000 GB Bootloaders
Installation:
*optional* Backup everything on your phone, just in case
*optional* Charge battery to at least 80%.
Download Bootloaders from above link
Extract files with 7zip
Open Odinv1.82 (Do not check/uncheck any of the boxes)
Click PDA tab (NOT bootloader tab)
Find the PDA.tar.md5 file included in the package, then click on it. Now click open
Put phone into download mode.
Connect your phone to your computer
Once you see a box turn yellow with a com port number, hit start. DO NOT touch your phone at this point.
Phone should reboot on its own to your home screen
IF your phone takes you to a screen with a Phone--!--Computer with a message about firmware installation failed and use recovery, DO NOT FREAK OUT. A lot of people have reported seeing this after flashing bootloaders. Simply disconnect your phone, close Odin. Reflash from previous directions. Odin should recognize your phone as beeing in Download mode, allowing you reflash.

Reserved, just in case.

Very nice thanks for this!
I just linked you in the OP of my ROM, will save people countless of questions about getting the i9000 Bootloaders.
Thanks!

Dlev7 said:
Very nice thanks for this!
I just linked you in the OP of my ROM, will save people countless of questions about getting the i9000 Bootloaders.
Thanks!
Click to expand...
Click to collapse
I appreciate that.
I had thought about doing a 1 click, but Ive noticed more and more people are having problems with them. Also, my kf1 thread has only had 2 downloads on the 1 click I put there. So full odin it is.

Bootloaders
Thank you, just what I was looking for
Great instructions and what to be careful of

It's worth noting that there's also a similar package for the Captivate-specific GB bootloaders, which carry a few advantages:
-They preserve the original button combinations.
-Phone+!+Computer is download mode, making it virtually impossible to soft-brick your phone, even if your three-button combos don't work and you don't have a JIG.
-They're specifically designed for the Captivate. As Cezar points out in his thread, it's unknown what, if any, difference this makes but it's not impossible that using incorrect bootloaders might impact stability or performance.

lowlymarine said:
It's worth noting that there's also a similar package for the Captivate-specific GB bootloaders, which carry a few advantages:
-They preserve the original button combinations.
-Phone+!+Computer is download mode, making it virtually impossible to soft-brick your phone, even if your three-button combos don't work and you don't have a JIG.
-They're specifically designed for the Captivate. As Cezar points out in his thread, it's unknown what, if any, difference this makes but it's not impossible that using incorrect bootloaders might impact stability or performance.
Click to expand...
Click to collapse
Point 1 is a disadvantage

lowlymarine said:
It's worth noting that there's also a similar package for the Captivate-specific GB bootloaders, which carry a few advantages:
-They preserve the original button combinations.
-Phone+!+Computer is download mode, making it virtually impossible to soft-brick your phone, even if your three-button combos don't work and you don't have a JIG.
-They're specifically designed for the Captivate. As Cezar points out in his thread, it's unknown what, if any, difference this makes but it's not impossible that using incorrect bootloaders might impact stability or performance.
Click to expand...
Click to collapse
I am aware of that thread. If you had read it you would have noticed I posted 2 upload links for people in that thread, while answering a lot of questions.
It should also
Be pointed out that at least 2 rom developers recommend using I9000 bootloaders with their rom. There are also more than few questions about where to get these bootloaders in the q&a section.

It should also be noted that the 3rd post in this thread is a developer linking this thread to his OP.

Thanks everyone, 100 downloads in 4 days. So much more than I expected.
Also, If you have used this, how about a little feedback.

Doesn't this REALLY improve batterylife? I saw a thread in team-continumm about this
I'm on continuum6 with ATT bootloader does it safe to do this?

I'm not convinced that bootloaders improve battery life. Background data, screen brightness, auto sync, and a bunch of other things will, but loaders? I don't think so.
Yes, it is safe to use these with Continuum, or any other GB rom (except cm7 and miui).

bootloaders
mrhaley30705 said:
Thanks everyone, 100 downloads in 4 days. So much more than I expected.
Also, If you have used this, how about a little feedback.
Click to expand...
Click to collapse
Been so busy keeping up with Dlev's rom updates,
I finally got a chance to flash them this evening.
I am running Dlev 4.1 and wanted to see if there was any difference in things
I will keep you posted
btw - flash was butter smooth
Again thank you

Your very welcome.

mrhaley30705 said:
It should also be noted that the 3rd post in this thread is a developer linking this thread to his OP.
Click to expand...
Click to collapse
So the difference between extracts, yours and his bootloaders
Yours from..........
JVB factory firmware
His from........
I897UCKF1
Correct?

Palmetto_X said:
So the difference between extracts, yours and his bootloaders
Yours from..........
JVB factory firmware
His from........
I897UCKF1
Correct?
Click to expand...
Click to collapse
Yes, mine came from jvb (see op). I don't know what Dlev was using before.

Bumpin it up here, boss

lowlymarine said:
It's worth noting that there's also a similar package for the Captivate-specific GB bootloaders, which carry a few advantages:
-They preserve the original button combinations.
-Phone+!+Computer is download mode, making it virtually impossible to soft-brick your phone, even if your three-button combos don't work and you don't have a JIG.
-They're specifically designed for the Captivate. As Cezar points out in his thread, it's unknown what, if any, difference this makes but it's not impossible that using incorrect bootloaders might impact stability or performance.
Click to expand...
Click to collapse
I'm pretty sure the Phone-!-Computer is recognized as download mode on the I9000 bootloaders too.
What people think of stability based of which bootloaders you are using differs depending on who you ask and what ROM you're using. Some say using the I897 bootloaders would theoretically provide better stability because they were made for our phone while others say using the I9000 bootloaders with an I9000 based ROM would ideally provide better stability since the bootloaders were designed for the phone the ROM is based off of. Neither of these points have been proven and as far as I can see neither really impact stability with one noted exception and that brings me to my next point.
The I897 bootloaders are known to break the I9000 stock music player but some say this can be fixed by replacing it with the I897 stock music player. I however have not tested this since I don't really use the stock music player (no real reason as to why I don't I just don't).
So my opinion on this whole "Which bootloaders should I use?" issue is use the ones with the button combo you like most. I personally use the I897 bootloaders because I'm used to those button combos.
Also most devs generally recommend using the I9000 bootloaders because it's what they're using and it generally eliminates the bootloaders as being the cause of any issues you may have with their ROM.

It worked!
It worked great! Thanks.
Just out of curiosity, it booted into CWM after it installed lol...not a problem but kinda like a "wtf" moment. Still worked so its perfect thanks!

Links Updated due to technical issues with Multiupload
Happy Flashing

Issues/Things to note about 4.04 (not brick related)

Ok been running 4.04 for a sometime now. I got it as it first came out.
Some issues that u have noted outside of the bricking issue. **disclaimer I am running my own built version of this ROM deoxeded zipaligned bla bla bla plenty of tweaks etc and the ROM is faultless(not really it has its faults and I am about to list them) with exception of a few things that may or may not be kernel related. IT DID NOT flash the new .pit file. I have built the ROM as according to 4.03 builds and used Siyah kernel.
1. initial boot and dalvik cache build takes an extremely long time. Easily mistaken for bootloops and possibly another reason people prematurely ejected this ROM
2. Android is upgrading/updating splash does not exist. Further adds to the concern that phone has enternal bootloops...it doesn't it just doesn't warn you. It goes back to the gingerbread days where you wore a big question mark ? on your head "What is my device doing?"
3. Bluetooth enablement does not work. We go from 4.03 that had wifi issues much similar to fixed wifi and issues with bluetooth. Sux. Guess you cant win eh?
My guess is that this is specifically related to the kernel and framework. Ihave the framework decompiled now and I will be looking into maybe making some adjustments to allow for the bluetooth drivers in 4.03 kernels to interact with 4.04, rather than a whole new re-reslease of kernels just to combat this issue.
4. USB not detectable in Windows 7? Hmmm I am not sure what happened here? It worked flawlessly for 2 days and then all of a sudden not recognised? USB speeds were perfect when it did work, reflashing the ROM did not fix this? My guess is that this is also kernel<->framework related. Also to note here that within the siyah recovery you can mount USB no issues and transfere, so no eMMC corruptions before you freak out.
5. Vol down + power button for screen capture does not work? This again maybe because of the kernel used?
Can anyone give any reason for me not running the new pit and flashing stock kernel? Does the stock kernel require that there is a repartition or is this an assumption?
Additional notes: Further testing my eMMC with Gotbrickbug *MASSIVE thanks to chainfire for this support* personal thanks from me. Thanks Chainfire you're a legend! After testing it revealed oddly enough that my eMMC was inconclusive, so not that it helped me much, but I have flashed this firmware now several times and have not had any issues. Everything working smoothly and 100% except for the above mentioned.
I am tempted to flash the standard kernel now (again no repartition) and then do CFroot for the stock kernel image on this firmware to see if these issues are alleviated in 4.04?
Additional to this is that I have the 15 toggles mod by Jkay translated and compiled with exception of the last file on systemUI for 4.04. I would REALLY love to have this ROM running for everyone.
Any input suggestions warnings (besides the brick scare - I am not scared cause I doubt my phone will brick considering I have flashed it so many times now with the phone acting the same every single time)are welcomed. Please use your head when you respond and not your bricked phone, I would like intelligent answers and discussions. Preferrably not from n00bs or those that are only rehashing all that has spilled out across the petition thread already.
My understanding is that it is a repartition issue with bricking not a kernel or ROM issue its self. My understanding is that I can flash any kernel I like I can flash the stock one and I should be able to flash a rooted one after it to get back if I want?
Proceedure now:
Flash ROM
Flash kernel
Flash CFroot
Flash Modded recovery
Happy days?

I think most of those issues are due to Siyah, because I've tried the same builds running the stock kernel, and I didn't encounter most of them. Bluetooth fine, USB fine, etc. Nothing major. Still went back to LGP because the 4.0.4 implementations are quite ugly at this point.

Again flashed this ROM no problems.
I also attempted to run 4.04 czech republic version of this ROM to which it did not boot or run. Just to let those know that were considering doing this. I had 3 apks from that 4.04 build that refused to deodex? Also the sizes of all apks in this version of 4.04 (which does not come with a supplied .pit file) are vastly different to those in the Euro 4.04 supplied with .pit?
Yet to download and try 4.04 Chinese version? I figured someone else has probably already done this....the chinese are fast lil buggers. They don't much around! haha. If anyone has feel free (and please I would like you to contribute) to comment in this thread on your findings?
James
PS: Just about to flash standard kernel on unpartitioned GS2 if all goes well I will implement CF-Root. Cheers

donalgodon said:
I think most of those issues are due to Siyah, because I've tried the same builds running the stock kernel, and I didn't encounter most of them. Bluetooth fine, USB fine, etc. Nothing major. Still went back to LGP because the 4.0.4 implementations are quite ugly at this point.
Click to expand...
Click to collapse
Did you re-partition when you flashed stock kernel? I like the sounds of this. I have the 4.04 working nicely.....if i can achieve the above I will create a ROM and upload. Thank you for your valuable input
I may even test with the czec 4.04 kernel and see what happens there? Hmmm
Kernels are identicle sizes but not the same?
czec zimage: MD5 2A4AE1B758D934E2AD1791E318F94424
europe zimage: MD5 FCB26E67AE9E7F701793B6014E4AF7D2
see attached for additional size details? I am wondoering if czec might be better for no repartition was/is used in this 4.04 build?
James

WOW! I flashed standard kernel and I now have bluetooth enabled and I STILL kept root access. yeeeeeeeew! stoked!

Jarmezrocks said:
WOW! I flashed standard kernel and I now have bluetooth enabled and I STILL kept root access. yeeeeeeeew! stoked!
Click to expand...
Click to collapse
No fix for USB enablement? I have switched the customboot.sh for the MTP application. I however don't have MTP.apk in system? I may place this apk and then re-try to see if I might be able to get the thing to be recognised by my PC.

USB Mass storage is now working via the old method. I need to have the MTP client in system/app for this to work. No longer getting the USB device not recognised which is great.
Any kernel devs want to share with me how to embed the correct components in the kernel to allow for customboot.sh to work? I am certain then that USB mass storage will work when that script can be run and enabled at boot. I dare say that boot animations should work then also.
4.04 is starting to shape up nicely now

(Q)Confused about 4.18 bootloader

Do all custom 4.2.2 custom ROMSs need updating to 4.18 bootloader before installing the ROM?
A friend said it's not required if installing an AOKP ROM?
I've looked at the ROM threads and very little has been said about the bootloader.
TIA.

the git commit suggests that the change are not that crtical
https://android.googlesource.com/platform/bootable/recovery/

Absent information to the contrary, it is possible that you can continue to use the 4.13 bootloader with 4.2.2 kernels.
Bootloaders are proprietary however - so there is nobody here that can tell you for sure just how important the changes from 4.13 -> 4.18 are. Simply put, the only people who know what those changes are are a few engineers at Asus.
I look at it this way - flashing a boot loader is the single most perilous flashing operation that can be performed. So - for Asus/Google to decide "let's put our entire customer base at risk by having them flash the boot loader as part of an OTA install" - well, that indicates that Asus/Google thought the bug fixes or capability changes in the new version were important - not trivial.
---------- Post added at 07:02 AM ---------- Previous post was at 07:00 AM ----------
chimpanzeexda said:
the git commit suggests that the change are not that crtical
https://android.googlesource.com/platform/bootable/recovery/
Click to expand...
Click to collapse
That is the recovery, not the bootloader. The bootloader is proprietary code.

bftb0 said:
I look at it this way - flashing a boot loader is the single most perilous flashing operation that can be performed. So - for Asus/Google to decide "let's put our entire customer base at risk by having them flash the boot loader as part of an OTA install" - well, that indicates that Asus/Google thought the bug fixes or capability changes in the new version were important - not trivial.
Click to expand...
Click to collapse
This is why I get confused about different Android devices and custom ROMs.
I assume with the Samsung Galaxy series of phones that the bootloader is built into the ROM at base level as it's something we never have to with them.
As you stated it's the 'most perilous flashing operation that can be performed' so allowing that as an OTA is even more of a concern, slight corruption during the download and it'll be a right pain to sort out.

Fuctifino said:
This is why I get confused about different Android devices and custom ROMs.
I assume with the Samsung Galaxy series of phones that the bootloader is built into the ROM at base level as it's something we never have to with them.
As you stated it's the 'most perilous flashing operation that can be performed' so allowing that as an OTA is even more of a concern, slight corruption during the download and it'll be a right pain to sort out.
Click to expand...
Click to collapse
In my experience it is sort of unusual for an OTA to include a bootloader update, but the amount of risk involved depends on the details of how the operation is performed.
In the case of a pure-stock OTA, the downloaded package is crypto-signed and verified by the stock recovery. Not even a single bit can be off as a result, so there is absolutely zero risk of a "bad download". Using a custom recovery though, all bets are off - it is my impression is that neither CWM or TWRP can perform jar-signing checks correctly, and it is unclear whether they can actually verify the alternate Android-centric zip signing (turned off by default anyway)
The way the bootloader flash is performed by the N7 OTA is that the bootloader image is dropped into the USP partition. It would appear (because it is no longer in there after some time) that the pre-existing boot loader checks this partition for the presence of a replacement bootloader, and flashes it into it's final destination. I have to imagine that this process also protected by some kind of crypto/checksum - otherwise that behavior would be an automated "brick-maker".
So the OTA delivery method for bootloader install is pretty darn safe - but this is probably NOT TRUE for flashing with fastboot. The latter method (fastboot) may have absolutely zero protections against flashing garbage or truncated files to the device, resulting in a brick at the next hardware reset.
If you want to use fastboot for bootloader flashing, use a laptop to avoid the tiny risk of a power failure during the flashing operation, and TRIPLE-CHECK the MD5 signature of the image file you are planning on sending.
It also goes without saying that if you have been experiencing occasional data transfer failures when using fastboot, you should not be using fast boot for flashing the bootloader.
If you want to do it the safest way possible, revert to pure stock 4.2.1, make sure your battery is well charged, and take the OTA.
cheers

[KERNEL] ghost swipes (tentative) fix

NOTE (2014-10-08): All the downloads here are obsoleted by official builds. However, I'll keep updating the OP with news about this issue as they happen
Background: if you have this problem:
Try the attached kernel (boot.img). You can flash it permanently from fastboot mode:
Code:
fastboot flash boot boot.img
Or test it temporarily (will be gone in the next reboot/poweroff):
Code:
fastboot boot boot.img
I tested it with this app (YAMTT) and so far I'm not getting any of the ghost swipes.
About the kernel
Some insight: this is basically the stock XNPH25R kernel with the default touchpanel driver disabled and replaced with synaptics' official driver. Note the synaptics driver is quite generic (aka clean) and it doesn't have the screen-off gestures, but that means your flashlight won't burn through your skin because it turned itself on in your pocket or some other random bs.
Screen going berserk (registering random tappings all over, total / regional insensitiveness) might also be fixed by the synaptics driver, but it's too early to say.
Grounding issues (aka 5 fingers not working on pillows) will NOT fixed by this.
Disclaimers
The touchpanel driver plays around with internal voltage regulators. Don't blame me for bricks or anything bad happening.
EDIT: This needs stock XNPH25R. If you flash the kernel on top of bacon nightlies (or any 4.4.4) you will softbrick / bootloop the phone.
EDIT 2: After a few hours into the new driver I noticed the following bugs:
Ghost swipes do appear from time time time, but in my opinion it's much less irritating than before.
Sometimes the screen will stop responding, but sleeping/waking up the device a couple of times brings it back to life. Still very annoying though.
My opinion
Overall I'm starting to think this is more a synaptics firmware issue than a driver issue and I really hope both OnePlus and Synpatics are working together on this. However, the 3508 chip used in the OPO doesn't even appear in the Synaptics' product listing, which makes me think it was a custom part specifically developed for OnePlus/OPPO and it will get marginal attention when it comes to bugfixing. The "good" news is that Synaptics is actively developing the driver (last commit from them is about 24 hours old), the bad ones is that OnePlus looks totally deaf-mute and overwhelmed by problems.
EDIT 3: Github link (branch bacon-55):
https://github.com/jamarju/android_kernel_oneplus_msm8974/tree/bacon-55
Whoever wants to add this to their own kernel, be warned of bugs (above). Also, I don't think I'm doing further development on this.
EDIT 4: Ricardo Cerqueira (cyanogen) has just pushed a commit to the oneplus kernel that supposedly mitigates bacon-55 problems. It does so by resetting the touchscreen when blanking the screen. It should go into tonight's CM11 nightly and presumably into the next OTA. I've backported it so that anyone can have it NOW with the current CM11S (XNPH25R). In Ricardo's words:
This is not a fix or a workaround, just a recovery mechanism
Click to expand...
Click to collapse
So now you have two kernels to choose from: boot.img with synaptics driver (ie. no gestures), or boot-82ea57.img with the original Oneplus driver (ie. yes gestures) + Ricardo's patch.
EDIT 5: 33R is out with a new touchpanel firmware but it doesn't seem to fix BACON-55. Just out of curiosity I tried the 33R kernel with the aforementioned driver patched in and ghost swipes momentarily go away, but they come back after a few minutes. It's so bad that I don't even think it's worth uploading a new boot.img.
Bottom line, if you're looking for a fix for BACON-55, look elsewhere. I'll keep updating this post if there's any news regarding this issue, though.
EDIT 6: As of sep-10 there is a new synaptics firmware upgrade (version 18): http://review.cyanogenmod.org/#/c/72720/. I'm 10 minutes into this firmware (maybe too early to say), but ghost swipes are gone. The boot-33r-f367c1f.img file below is the stock 33R kernel with this patch in. Try it out if you are on the stock 33R and don't want to wait for the OTA or migrate to the CM11 nightlies.
EDIT 7: Nevermind... ghost swipes are still there. Typing experience looks slightly better. Looked promising, but still not a real solution.
EDIT 8: Franco Kernel #17 (http://franciscofranco.minooch.com/OnePlusOne/4.4/) also has the latest synaptics firmware.
EDIT 9: A new synaptics firmware (version 19) went in today (sep-12), see here: http://review.cyanogenmod.org/#/c/72880/. Commit description is not too descriptive but I'd say it further mitigates BACON-55. With before yesterday's firmware (18) I got occasional swipes between keys that were 2 keys apart. Now I get none on those. However, it still swipes between keys that are very close together (0 or 1 keys apart). Flash "boot-33r-synfw-19.img" to test it.
EDIT 10: franco kernel r18 is out with Synaptics firmware v19.
EDIT 11: OTA 38R is out with the latest synaptics firmware (v19) built in, so all of the above is again obsolete. As expected, the touchscreen in 38R behaves exactly the same as in previous custom ROMs/kernels that also had firmware 19. Ie: big improvement over 33R, but not 100% fix for lots of people, including myself. See BACON-55).
EDIT 12: Franco Kernel r30 has the latest firmware (21). Like always, there are mixed reports as to whether the TS works any better with this or not. My own experience: here.
EDIT 13: OTA 44S is out with firmware 21. Also, there are signs that Oneplus is silently switching touchscreen manufacturers, from TPK to WINTEK.
Now, to the downloads (obsolete - forget this, read above):

Any chance of a version to work with mahdi? There is a culkin patch to make stock kernels work with aosp roms... But not sure how to combine the 2 if this is a boot image... Flash it in recovery then boot into bootloader to fastboot boot. Img I suppose? I'll try it tonight.
http://forum.xda-developers.com/showthread.php?t=2814265

Would you be able to create a flashable zip? ?

MontAlbert said:
Any chance of a version to work with mahdi? There is a culkin patch to make stock kernels work with aosp roms... But not sure how to combine the 2 if this is a boot image... Flash it in recovery then boot into bootloader to fastboot boot. Img I suppose? I'll try it tonight.
http://forum.xda-developers.com/showthread.php?t=2814265
Click to expand...
Click to collapse
Looks like OP edited his post,
EDIT: This needs stock XNPH25R. If you flash the kernel on top of bacon nightlies (or any 4.4.4) you will softbrick / bootloop the phone.
Click to expand...
Click to collapse
Would you be able to create a flashable zip?
Click to expand...
Click to collapse
https://play.google.com/store/apps/details?id=com.cgollner.flashify use that to flash the boot.img

MontAlbert said:
Any chance of a version to work with mahdi?
Click to expand...
Click to collapse
i'll try to fork the kernel on github so that any cm11-based kernel can benefit from it., but to be honest, Oneplus should jump in and get this fixed themselves, which is why we paid them money so that customers don't have to fix **** ourselves. /rant off

javideslomao said:
i'll try to fork the kernel on github so that any cm11-based kernel can benefit from it., but to be honest, Oneplus should jump in and get this fixed themselves, which is why we paid them money so that customers don't have to fix **** ourselves. /rant off
Click to expand...
Click to collapse
I feel like companies should start hiring people off of XDA and not resumes

thanks OP!
i've been following up the BACON-55 https://jira.cyanogenmod.org/browse/BACON-55 bug for a long time as this is by far the biggest issue for me.
i made a backup and flashed your boot.img and so far so good
the one small thing i want to report is that i use the hardware keys - and it looks like when you disable the backlight for the keys ( i dont like them being on ) the buttons seem less responsive (takes a couple taps before it registers)
maybe its just me, but when i re-enable the backlight it works fine
aside from that the typing has so far been a lot better, but i just noticed the phantom swipes happen once or twice again (i use swiftkey and it was deleting the last word)
It's definitely a lot better but still not 100% for me..
but I appreciate all the research you've done
i really hope the OPO devs have noticed and are ACTUALLY working on a fix for the next OTA

Much thanks OP. My biggest issue with this device was the ghost swipe. At least I know it's software thanks to you.

javideslomao said:
Background: if you have this problem:
Try the attached kernel (boot.img). You can flash it permanently from fastboot mode:
Code:
fastboot flash boot boot.img
Or test it temporarily (will be gone in the next reboot/poweroff):
Code:
fastboot boot boot.img
I tested it with this app (YAMTT) and so far I'm not getting any of the ghost swipes.
About the kernel
Some insight: this is basically the stock XNPH25R kernel with the default touchpanel driver disabled and replaced with synaptics' official driver. Note the synaptics driver is quite generic (aka clean) and it doesn't have the screen-off gestures, but that means your flashlight won't burn through your skin because it turned itself on in your pocket or some other random bs.
Screen going berserk (registering random tappings all over, total / regional insensitiveness) might also be fixed by the synaptics driver, but it's too early to say.
Grounding issues (aka 5 fingers not working on pillows) will NOT fixed by this.
Disclaimers
The touchpanel driver plays around with internal voltage regulators. Don't blame me for bricks or anything bad happening.
EDIT: This needs stock XNPH25R. If you flash the kernel on top of bacon nightlies (or any 4.4.4) you will softbrick / bootloop the phone.
Now, to the downloads:
Click to expand...
Click to collapse
actually my touchscreen is still not working sometimes. must be a hardware issue. tested multiple kernels and roms and still having problem.s

Thanks a lot man!
Sent from my One

Nice to see ghost problem disappear now only the grounding issues are in place.
Although grounding issues are probably a H/W defect, I'll receive my opo in a week or sooner hopefully this can be solved/masked through software
Weird I can't seem to find a "grounding" issue on jira(cyanogenmod), the ghost problem is known and cm team is working to solve this.

Can you pls add your github account link or source code?

I haven't had ghost touches for 1,5 hour so that's a good sign! Hope it stays that way. My back button looks to be as responsive as before. I will report if I get any ghost touches.
Sent from my One

The wording in this commit seems to imply that a fixed firmware is something that's in the works. I've been looking through sources for the S3508A controller in particular, but I can't find any datasheets, though Chinese websites knew about it back in November, which means it's a pretty new part, but not _that_ new. It looks like the One/Find7 series are the first devices to ship with the controller, at least as far as I'm aware, so it's quite likely the issue just wasn't caught in pre-release testing.
Update: trying to diff the CM11 kernel with the Find 7 kernel. Fun fact: Oppo programmers can't spell. Also, potential for more gestures? Sure is.
#define UnkownGestrue 0
#define DouTap 1 // double tap
#define UpVee 2 // V
#define DownVee 3 // ^
#define LeftVee 4 // >
#define RightVee 5 // <
#define Circle 6 // O
#define DouSwip 7 // ||
#define Left2RightSwip 8 // -->
#define Right2LeftSwip 9 // <--
#define Up2DownSwip 10 // |v
#define Down2UpSwip 11 // |^
#define Mgestrue 12 // M
#define Wgestrue 13 // W
Click to expand...
Click to collapse
Update 2: it seems the driver in the CM11 kernel is simply a cleaner version of the Find7a driver. Oppo's changes stand out because of how bad the code is - and because of how much cleaner it is in the CM11 kernel. I wonder who wrote that stuff...

K900 said:
The wording in this commit seems to imply that a fixed firmware is something that's in the works.
Click to expand...
Click to collapse
I've also looked for the datasheet, even asked synaptics for it, but nothing so far. The closest thing publicly available is the RMI4 spec, but the last revision ("E") is missing lots of functions that are actually present in the controller. There is some potential in that spec, though, like some registers to control the overall sensitivity, etc. They are accessible from user space via a /dev/rmi* node, but I haven't really tinkered with it. Nor I think it's worth the hassle given the official confirmation that the firmware is buggy.

javideslomao said:
I've also looked for the datasheet, even asked synaptics for it, but nothing so far. The closest thing publicly available is the RMI4 spec, but the last revision ("E") is missing lots of functions that are actually present in the controller. There is some potential in that spec, though, like some registers to control the overall sensitivity, etc. They are accessible from user space via a /dev/rmi* node, but I haven't really tinkered with it. Nor I think it's worth the hassle given the official confirmation that the firmware is buggy.
Click to expand...
Click to collapse
Agreed. Maybe we can pull the firmware off a Find7a system dump or something though? I don't think the issue is present there.

javideslomao said:
EDIT: This needs stock XNPH25R. If you flash the kernel on top of bacon nightlies (or any 4.4.4) you will softbrick / bootloop the phone.
EDIT 2: After a few hours into the new driver I noticed the following bugs:
Ghost swipes do appear from time time time, but in my opinion it's much less irritating than before.
[Sometimes the screen will stop responding, but sleeping/waking up the device a couple of times brings it back to life. Still very annoying though.
Click to expand...
Click to collapse
That was the initial problem, I still haven't had them until now, but it wont surprise me if they just came back. Having the same problem with my previous phone made me a bit of a pessimist. I have no hope that there will be a permanent software fix.

Hallo I was using your kernel but I still experience ghost touches (not swipes) and now I am on stock kernel I can see ghost touches very often ,immediately after a reboot.
I can tell that because I use all the time the cm touch tools

DerRomtester said:
Can you pls add your github account link or source code?
Click to expand...
Click to collapse
Done, see OP.

K900 said:
The wording in this commit seems to imply that a fixed firmware is something that's in the works.
Click to expand...
Click to collapse
FWIW I've just backported that commit into the stock XNPH25R kernel and attached a new boot.img it to the first post, in case someone wants to have the patch before the next OTA rolls out.