yashsingh1/xdaforums huggingface dataset:
[Fascinate Android Development] bmeek:
No, the tar package is what ODIN expects, and for a bootloader update one uses the bootloader slot... You're probably remembering important admonishments to use the PDA slot rather than the Phone slot for ODIN-ready full-wipe roms (in tar format).

---------- Post added at 03:59 PM ---------- Previous post was at 03:45 PM ----------

How would you recommend getting all partitions formatted to ext4 then? I seem to recall a flashable .ZIP file that formats all volumes to ext4, so perhaps I'll look around for that, then flash your rom from the .ZIP version.

[EDIT] - nevermind - I found the option in GW Recovery to convert the partitions to EXT4 :).

BTW, regarding the CWM version, I flashed "cwm4_fixed_for_cm7-ODIN.tar" and completed a nandroid backup of the GW3.3 image. Later, when attempting to restore this, it couldn't mount the system volume, but I was able to restore just the data...

Meanwhile, the reboot crash when NPR News transitions between playlist items has repeated itself (although it doesn't happen every time)... Unfortunately, I was out on a walk and couldn't remember your instructions to "Take bug report". Next time.

Thanks again for the wonderful efforts...
[Fascinate Android Development] djp952:
OK, I have to admit I think this is the FIRST time anyone has ever asked for something on the Fascinate to work LESS :p It's always the opposite! I've never looked at that, but I'm sure there is either a setting cooked into android that can be enabled OR the kernel can be modified to have a couple different settings. I'm not sure when I'll be able to look at that, but don't let me forget (which I tend to do - lol)

As far as the other stuff, yeah, my goal was to do the least amount of modifications to AOSP as possible so there isn't any add-ons like clocks, meters, etc. Basically, this ROM makes the Fascinate look and feel just like a stock Galaxy Nexus (or perhaps a Galaxy 4 at this point). There are some light edits, and there may be more to come, but I'm relatively certain I'll never have ambition to stray too far from AOSP.

I've started working on Android 4.2 a bit, and will probably wait until that works (so far so good, but a lot of work to do) before really looking at requests for modifications. One reason is that 4.2 completely changes the status bar, which is typically what most requests target. The AOSP 4.2 status bar doesn't do a couple things right IMO, so those elements are pretty likely to get changed if I can :)

Oh, and for anyone reading, I can already confirm that the gradient background in Settings is fixed in 4.2 -- nice and smooth :victory: If I can figure out how to make Bluetooth work again, I'll be rolling!
[Fascinate Android Development] djp952:
I can also use your guys' (and gals'!) help with something. There is a user out here on XDA, my buddy swapnilss, that has been desperately trying to use this, or any, Jelly Bean ROM for his India-based SCH-I500 phone. It's CDMA like ours, but requires that he stay with the same modem revision he's got for the Reliance network over there. He's tried pretty much everything he could, and reached out to me a couple months ago.

He can use custom ROMs properly up through Gingerbread by setting his phone up stock (Froyo) and then upgrading without wiping data. I believe he's still using GeeWiz 2.9, as a matter of fact. Trying that trick with 4.x ROMs doesn't work, typically it won't boot as the stale data is too incompatible. If he wipes data, he loses the CDMA data connectivity. This happens with all ROMs he's tried (AOKP/CyanogenMod/GeeWiz/etc).

I have a basic understanding of the APNs and whatnot, but the stock Reliance CDMA Froyo ROM uses a different, older, format for the APN configuration that doesn't seem to have 1:1 correlation with the current format. I have been unable to find a copy of an apns-config.xml for Android 4.0+ on that network, and even if I had one I'm stumped how to set up the CDMA settings that go into the build.prop (my Verizon ones are copied from Cyanogenmod). It kinda blows my mind that it's almost 2013 and Reliance doesn't have a single CDMA phone updated beyond Gingerbread. And here I thought Verizon was terrible about updates!

If anyone has experience successfully changing the CDMA APNs for this device on Jelly Bean OR knows of a working 4.0+ ROM for the Reliance CDMA network in India, I would greatly appreciate any input you could provide. I'd love to help this guy out. Getting data would make him a very happy camper, we can deal with MMS afterwards (should be an easier problem to solve)
[Fascinate Android Development] A-L31:
Sorry if i'm wrong.

First, the stock ROM he use is reliance base. My idea ...

Back to stock with Verizon network. Inject HIS number with cdma tool. i'm outside US. i use my local provider, and i do some modification in the phone so i can have my number and my data with my provider (Note: my phone still detect i'm using verizon, and i can download kindle app even i'm outside US. i have some android device using a sim card with the same provider, and i can't download kindle. SO my opinion as a user is kindle restricted to US only, correct me if i'm wrong). if the operator won't help, i don't know any other way.

As far as i know, the operator just need the IMEI (and many restricted data to the user e.x :akey) :D

The idea is still using Stock verizon but data and voice with our Network. Every time i'm back to stock i don't need to dial 228. EVEN if i'm dialing 228, it will refresh my number and still connected with my network not verizon. the downside is you need a patch, luckily there IS a patch :good: and the mms, i never use MMS so i never bother it, but i'm sure there's work around

IF he can manage to get his data and call with Verizon Stock ROM, then he just need using the patch to make 3g working with other ROM beside GB. No need a patch with stock GB or Froyo

What i'm doing with this phone.

- Buy it. (Stock ROM)

- Bring the phone to my local provider

- and viola, i have my data and call

- ventures custom ROM :p

Oh one more thing, i never modified the APN, there's no changes if i modified the APN, meaning useless. no matter what i edit i still get my 3g connection.

There's always a way i believe. but there's a thing that really secret in Company especially Telecommunication. Based on my experience, he need to work it out with the provider, consider that i'm lucky that my provider is "kinda" generous :D.

There's a way to get voice call and data, using Verizon Stock ROM with local provider and with stock phone to :laugh:

this is important to ventures other ROM and for those who are not using verizon network

Sorry if my explanation confuse you. Hope this help :cowboy:
[Fascinate Android Development] djp952:
If anyone is interested, I have posted a pre-release of GeeWiz based on Android 4.2.1 (JOP40D) to post #3 of this thread:

http://xdaforums.com/showpost.php?p=33011176&postcount=3

It has problems still and should be considered ALPHA quality. The main things that are completely broken are Bluetooth and the Compass, so if you need either of those, DON'T INSTALL IT. Wifi is also having some problems with being turned on and off again, but I seem to have worked out most of the other stuff that stopped working with Android 4.2.

if you install it and find additional problems, even if they are cosmetic, please feel free to post them here, all I ask is that you clarify that you are discussing the Android 4.2 ALPHA rom, not the GeeWiz 3.3 4.1.2 ROM. I don't want to scare anyone off unnecessarily because of things that are going wrong with something that's a work in progress.
[Fascinate Android Development] djp952:
FYI on a couple new known issues for v3.3 that I've added to the main post:

USB Gadgets will not work after the device has been docked

After undocking the device from the Fascinate Dock, USB Gadgets (common ones are USB Mass Storage and ADB) will no longer work. Charging is not affected. The only workaround for this issue is to power the device off and back on again, rebooting is not sufficient. The problem is an incompatibility with the USB Gadget code I ported into the GeeWiz Kernel to modernize it and the Kernel code for the dock.
​

Compass can be inaccurate

The compass device can be inaccurate, even with calibration. The problem is that the proprietary geomagneticd service is typically started before the compass sensor has been accessed for the first time, which leads to inaccurate readings. I have a fix for this, but am waiting to release a patch hoping I can roll a couple other fixes in at the same time. To work around this issue, stop and restart the 'geomagneticd' service while the application that is using the compass is active.
​

I've already fixed the compass (same problem I was having with Android 4.2 in the build mentioned in my last reply), but would like to try and deal with the USB/Dock issue at the same time. I won't wait too long before patching the compass if the other problem is going to take me a while -- I haven't really looked into that one yet.
[Fascinate Android Development] djp952:
I added the ability to control the vibration intensity to the kernel this morning and it seems to work quite well. I need to add something to control it the Settings/Advanced tool, but that shouldn't be too difficult. Next patch / release will have this ability for ya ;)
[Fascinate Android Development] DJAscendance:
Any idea why im getting md5 checksum errors?
[Fascinate Android Development] djp952:
While flashing via ODIN or checking the MD5 of a specific download? For the former, it should be 99.9% a bad download .. for the latter, I'd be happy to double check the MD5 of the original file if you let me know which one. AFAIK, the posted MD5s are correct.

If you are using ODIN and it's giving you that message that you should **definitely** not flash the file as something has gone awry and bad things are likely to occur. I would try downloading it again since I haven't heard of any issues with the ODIN files to date, but the MD5 hash is there to prevent issues from download corruption.
[Fascinate Android Development] djp952:
Since the 4.2-based build isn't ready yet (Bluetooth and Superuser problems are the remaining holdouts), I took some time to back-port a handful of changes to the GeeWiz 3.3 build:

GeeWiz 3.3.1 Patch (EDIFY Update-Zip)

- Adds ability to control Vibration Intensity to Settings/Advanced

- Mostly fixes the compass

- Disables 360 degree tablet-style rotation

- Changes description of Settings/Display/Pulse Notification Lights to simply "Notification Lights"

- Emulates a Digital dock audio device instead of an Analog dock audio device

- Addresses a potential race condition with voice call audio in the audio HAL

http://www.mediafire.com/file/318p15zm3eqtmrz/geewiz-3.3.1-patch-12282012.zip

MD5: dcc2814ae4d13419d74cf6eda13a9f8c
​

A couple notes ....

- I removed the part of the patch that wipes the Google Services Framework data this time around. I started doing this to solve problems with patches issued against Android 4.1.1 that changed the Kernel as for some reason that would trash all things Google until that data was wiped. I've tested it a number of times and the 4.1.2-based builds don't seem to suffer from the same issues. If after applying this patch your Data/Wifi indicator doesn't eventually turn blue, you can't access any web sites through the browser, or Google sync is failing, manually wipe data on Google Services Framework and reboot immediately afterwards. Let me know if that happens so I can add the code back into future patches.

- The compass is "fixed", but this is the Verizon Fascinate ... therefore it's not perfect. The compass seems to have the same basic issues as the GPS on the device, the services that control them just don't work right sometimes after the device has been rebooted. This was the real underlying cause, I was starting the compass service (geomagneticd) during boot, but if it felt like being evil, the compass would just never work right. Now the service is controlled by the sensor HAL, so it will start when an app requests the compass and stop when it's done. You may still have to wait a while after the device reboots for it to be accurate and close/reopen the application using it, but at least now it won't be broken forever.
[Fascinate Android Development] rich_e:
Thank you for taking the time to keep up with the Fascinate! This is a great ROM. I applied the update...all seems well. I was previously having a problem with Wi-Fi not being able to toggle back on without a reboot. I still had the issue after the update was applied. I wiped the Google Services Framework and rebooted (as you suggested) and the issue has been resolved.
[Fascinate Android Development] djp952:
You're welcome, I'm always very happy to have 'satisfied customers' :D It ain't the coolest thing out here, but I like it too!

As for Wifi toggle issue ... ugh ... that has been an on-again/off-again problem (pun intended) from day one on GeeWiz 3. I really appreciate the reminder as well, since I back-burnered that again and almost forgot about it!! I didn't want to forget about it again, so I worked on it tonight ...

I still can't duplicate the problem on demand (still 'random' for me as well), or find any steps that guarantee the problem will occur, so I've taken a different approach to try and completely resolve it. What I *think* is happening is that somehow the value of the 'wlan.driver.status' property and the actual status of the wifi driver are getting out of sync. If this should occur, when Android asks to turn Wifi ON, the driver is already loaded, and bad things start to happen.

I've done a couple things to try and prevent this. Neither truly solve the core problem, since I can't find it, but I'm hopeful these changes will let Android just deal with it and keep rolling .... 1) Don't rely upon that 'wlan.driver.status' property being correct; always check to see if the wifi driver is really loaded or not. 2) If a request comes in to load the wifi driver and it's already loaded, don't fail anymore; just unload the driver and keep going. So far, these changes have proven to be quite successful in un-screwing-up things I manually force into a bad state, so I have a good feeling that they will be an acceptable workaround for whatever the underlying condition happens to be.

I quite literally just finished testing these changes for Android 4.2, and will back-port them to Android 4.1 (GeeWiz 3.3) after they've been checked in and get a patch out to you guys ASAP. Probably tomorrow (or rather later today, it's 1AM here - LOL). I'm very hopeful that this will be the end of the Wifi Toggle problems :silly:

edit: For those that like browsing code, this is what I think will resolve the problem ... https://github.com/djp952/android-p...mmit/3dd11a39fe68ee1a572626ddddc96828c3f348c5
[Fascinate Android Development] djp952:
Another quick end-of-the-year patch for you guys ....

GeeWiz 3.3.2 Patch (EDIFY Update-Zip)

- Resolves continuing occasional issues with Wifi Toggle ON appearing to hang up

http://www.mediafire.com/file/xjnl0p55r3h17xv/geewiz-3.3.2-patch-12312012.zip

MD5: bccbfdcd7f187dc64e25cdad32bb050f
​

I'm hopeful that this patch will completely resolve the occasional issues encountered when toggling Wifi ON/OFF. What I found was that Android relies upon the status of a property, 'wifi.driver.status', to determine if the kernel Wifi driver is loaded or not, and if that property is wrong for some reason, bad things will happen. I've modified Android to not trust that property and always check to see if the driver is really loaded or not, and changed it so if a request to turn Wifi ON comes in and the driver is already loaded, it will just unload/reload the driver instead of failing. While I cannot replicate whatever scenario happens to actually cause this, I'm hopeful that these mitigation steps will be successful in putting the issue to rest once and for all :cowboy:
[Fascinate Android Development] rich_e:
I applied the 3.3.2 patch this morning. Wifi wont activate without a reboot. It'll turn off but won't restart.
[Fascinate Android Development] djp952:
Oh no! Sorry! :crying:

As soon as I get home tonight I'll have another crack at it, or at minimum post a rollback for you.

What the heck ... that shouldn't have happened. I probably made a stupid mistake staying up too late working on that. BUMMER
[Fascinate Android Development] djp952:
Well, I tested and re-tested and tested again, and I honestly don't know why that patch made things worse for you. So, first things first, let's get you back to way you were:

GeeWiz 3.3.2 Rollback

http://www.mediafire.com/file/cennge7kcbtqw4k/geewiz-3.3.2-rollback-12312012.zip

MD5: 452ffc515941e04872a2575fffd09853

This just replaces the modified file with the one from GW 3.3.0. Since I can't duplicate the problem at this time, I'm going to leave 3.3.2 out there ... i think it still solves A problem, but obviously not THE problem. Sigh.

I was wondering if you could help me try to track down what's still going wrong before you roll back? Totally up to you, but if you wouldn't mind duplicating the problem where Wifi won't turn on, wait about 5 minutes, then go into Settings/Developer Options and click Take Bug Report? The bug report takes a few minutes to generate and you won't see much happening other than some Superuser pop-ups saying that "shell has been granted Superuser permissions". Once it's done, GMail will open and have the bug report ready to send. By default, it will send it to your own account ... I'll PM you my gmail address.

If you don't want to do the bug report thing, no worries (seriously)

My sincere apologies for making things worse for you, I know it's understood that things are rarely if ever perfect with these custom ROMs and kernels and whatnot, but I still feel bad regardless :silly:
[Fascinate Android Development] rich_e:
The bug report is on its way! Thanks for checking into to this. The roll back worked. It takes a minute or two for the wifi to toggle back on but it did come back on this time. The second time I toggled it, it came back on all most instantaneously. If no one else is reporting a problem, it must have just been my device. You probably don't need to spend any more time on it.
[Fascinate Android Development] djp952:
Got it! Thank you very much sir!

One thing is jumping out at me immediately in the logs ... the wifi driver module (bcmdhd) is actually crashing on your device when it's trying to load, some type of memory allocation failure. It has a stack trace, so it shouldn't be a problem to find where in the kernel code this is occurring and see what the deal is. Definitely different than what I was trying to fix, and I can clearly see how the change I made for 3.3.2 would have exacerbated this.

I don't dig into the logs too much (trying to respect privacy), but I did check the running application list and I see a couple apps that I would like to download and install to see if maybe they are contributing factors. I seriously doubt they are at fault in any way, but if they do some manner of optimization or monitoring, they may be getting the kernel driver into trouble. My hope is to directly duplicate the driver fault, but failing that and now being armed with the stack trace of the fault, at least I can try to add something to prevent the problem from occurring :good:

Thanks again, this information is extremely valuable and has absolutely revealed a completely new place to look!! :fingers-crossed:

edit: The good news is that this is seemingly an issue that many have faced and dealt with in various ways. Once I can manage to duplicate it, it shouldn't take long to choose one of those solutions and run with it for everyone....
[Fascinate Android Development] rich_e:
There must be some process on my phone causing the conflict because the wifi toggle issue comes and goes. Yesterday, after rolling back the patch, it was behaving normal. But I tried toggling it later on after the phone had been running an hour or so and it wouldn't work.
[Fascinate Android Development] djp952:
I think what's happening is something that has affected other devices, memory fragmentation, which would explain the semi-random nature of the issue. I looked at the original Gingerbread kernel code from Samsung, and they used to pre-allocate chunks of memory for wifi stuff on boot. This pre-allocation still exists, but the driver code I'm using doesn't know about it anymore, so it's going unused. I've seen a handful of hacks out there that try to address the problem a number of ways, but I'm leaning towards fixing the pre-allocated memory before resorting to any hacks as they may affect other things.

The amount of memory that's needed where your device is crashing is a seemingly trivial 70KB or so. The old pre-allocation is much bigger than that, so I think I can get us past this particular issue ... if I'm right about it, of course :)

I'll post some kind of experimental kernel update (and a corresponding rollback) once I unravel this the rest of the way and apply some pre-allocated goodness to the current driver. :fingers-crossed:

edit: that wasn't quite accurate ... first I'm going to fix the pre-allocated stuff and make sure it still works, then probably add some more pre-allocation for the 70KB that is failing. If "fixing" it doesn't work, I would then try to re-use it for the purpose at hand rather than adding more.
[Fascinate Android Development] djp952:
Alright, let's see what happens ...

GeeWiz 3.3.3 Patch -- EXPERIMENTAL

- Alleviates kernel memory pressure when Wifi is toggled ON by using pre-allocated memory buffers

- Requires GeeWiz 3.3.1 patch already be installed; 3.3.2 patch is optional but recommended

http://www.mediafire.com/file/89vncr44n826er0/geewiz-3.3.3-patch-01022013.zip

MD5: 7b20992352b3916b811bfd53d204f380

GeeWiz 3.3.3 Rollback

- Apply if the 3.3.3 patch causes problems; please try and take a bug report (Settings / Developer Options / Take Bug Report) first for me

- Reverts the kernel back to the 3.3.1 revision

http://www.mediafire.com/file/d12cktkqvhaipbi/geewiz-3.3.3-rollback-01022013.zip

MD5: 244683636e633791d06aabac57872181
​

While I can't say I was ever able to properly duplicate the page allocation error encountered by rich_e, I'm hopeful this may do the trick. What this patch does is re-enable some boot-time memory buffers the Atlas (Fascinate) device had lying around that used to be important in the stock Gingerbread kernel. The newer wifi driver had support for them after all, but I never turned it on.

In addition, and arguably the more important change, is that I added a new 96K pre-allocated buffer to the Atlas (Fascinate) device code that is now used to deal with the bulk of the memory that gets allocated when you turn Wifi ON. This will theoretically allevate the kernel from needing to find a large block of free RAM to enable Wifi, but it does still need some (specifically it should reduce the allocation that was failing from about 70KB to more like 2KB).

I've provided a rollback patch that will restore the kernel to the previous version (GeeWiz 3.3.1), should something bad happen. Please consider this patch to be EXPERIMENTAL in nature. I have not tested every possible Wifi state yet, and since I was unable to duplicate the original problem, even if it solves that, there may be additional ones that are now exposed.

Let me know! If you have a problem and can take a bug report for me, that would be fantastic, PM me and I'll send you an e-mail address you can forward it to.
[Fascinate Android Development] hhp_211:
Just have to say " wow ".... the way you develop and issue out posts in detail and updates just amazes me...

Got to be honest I have never tried your geewiz . Yet... It sounds so tempting and i love to know all about the whys and hows :) even if i don't always understand it

So props to you ;) :thumbup::thumbup::thumbup:
[Fascinate Android Development] rich_e:
I installed the patch and have been testing it for a couple of hours. No driver crashes. Wi-Fi toggles smoothly. I think you squashed that bug.

Thanks!