[ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal][f2fs]bigsuperROM-thunderc-4.4.4

Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

An update - the sprint fixes actually work for me too (even the one I complained about - the errors didn't seem to stop it from applying). I couldn't fully test because the SD card I was using turned out to be crap. Got a new one and things are looking good - running 20140623-os2sd with very few issues worth mentioning. It's not my primary phone so I haven't done much with it but everything I tried so far seems to work (opera mini mostly).

I did notice a crash during shutdown once, as it apparently locked itself up and watchdog reset (causing a reboot instead of shutdown). Also, is screen autorotate not working? Maybe an accelerometer problem - I tried "Into Accelerometer" and it is running very very slow compared to my evo 4g. [Edit: problem went away after reboot, seems to reappear after some screen sleep/wakeups, but definitely seems accelerometer related]

I suppose most of you guys know this already, but if you're looking for a google maps that runs without graphics issues, grab a copy of the 5.5.0 apk - supposedly this is the last one before they switched to 3d display. It runs well on here, just make sure the play store doesn't update it away on you! You can try looking here - I have no way to verify its authenticity though.

One thing that could make this better is an ability to boot the internal OS without reflashing boot (for purposes of activation). Maybe this isn't very straightforward to accomplish unless the kernel has a fallback root option or something... hell I don't even know if this kernel can even run the stock rom. I suppose then it would need an early boot trick to load the kernel from SD if present instead of from internal.
 
Last edited:
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

Here's my thought... with many pros and cons. How hard would it be to get the /system/app folders in the ROM and gapps to flash instead to /data/sdext2/system/app (i.e. the ext4 partition created by Link2SD)? If that's easily doable, I can do up something to tell the phone to look there on next boot, and something that'll enable moving it back to internal after making a few apps user instead of system apps.
Would that even save enough space?
Is the /system/app folder the space hogging culprit, or is it another folder?
Wouldn't help those on internal without an ext4 partition I know.
I don't really understand -O3, but it sounds cool, and I'd love to have it on non-OS2SD.

Edit: Even crazier idea. What if ALL of /system from the ROM could flash to /data/sdext2/system? I could create an init.d script that would move anything on /system to this new directory, and point the ROM there. Thus, we'd have a way to test what fits and what doesn't by the size of the system folder on the ext4 partition. Nothing would have to be changed in the gapps package either, as after it flashes, contents would be moved into the ext4 system folder on init.d. This all assumes that init.d scripts are run before anything from the system partition is read, which may not be the case.

Sent from my Nexus 7 using AC Forums mobile app
pa_gapps checks /system/build.prop for version in recovery with busybox, no linking there.
Also, if you have to have the card in for /system apps, android might crash if the card is removed. the system would at least have to be aware of what was there and politely kill everything running from sd, which is coding in an area I haven't dug into yet.
It'd be easier for me to make a user-transparent overlay with aufs to the card, allow tiny extra partitions to support the stock 2GB card, and drop the internal install making the whole release os2sd with aufs instead of direct mounting. That would solve
...One thing that could make this better is an ability to boot the internal OS without reflashing boot (for purposes of activation). Maybe this isn't very straightforward to accomplish unless the kernel has a fallback root option or something... hell I don't even know if this kernel can even run the stock rom. I suppose then it would need an early boot trick to load the kernel from SD if present instead of from internal.
Although this kernel doesn't play very nice with the stock ROM and probably can't handle the internal LG wangling needed for activation, having enough on internal to run would protect phones running this from card failure completely crippling them.
Option to boot another kernel could only be handled with kexec which I haven't gotten to work in the past playing around. That would enable easy, full multiboot from the card.
 
Last edited:
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

Sounds way more complex than it's worth, so don't worry about it. One other thought: as system is 158.5MB and data is 164.9MB, could you switch'm? Again, novice suggesting things that probably don't make any sense at all, but maybe I'll hit gold with one of them.

Sent from my Nexus 7 using AC Forums mobile app
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

Sounds way more complex than it's worth, so don't worry about it. One other thought: as system is 158.5MB and data is 164.9MB, could you switch'm? Again, novice suggesting things that probably don't make any sense at all, but maybe I'll hit gold with one of them.

Sent from my Nexus 7 using AC Forums mobile app
they could be switched.

I just made a nice -Os thumb, everything else -O3 internal build which I'm testing. 143MB used. Should fit everything.

BTW, from what I've read, -Os is optimize for size, -O0 is no optimization, -O1 basic optimization for speed, -O2 decent speed, -O3 pretty good, -Ofast not yet supported in several android libs and can't use it without patches.
JustArchi's info says that most of android is thumb, some arm. that's why only changing the -O3 thumb to -Os thumb cut 15MB off the build.
-O2 might fit, I'll see.
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

Sounds way more complex than it's worth, so don't worry about it. ...
You could modify the installer zip.
Take what you want, all of /system/app that you see in the app drawer if you want, put it in a new nested folder data/sdext2/system/app in the root of the zip. (you'll need that folder, with what you want in it, ready to paste into the zip, if it's like zarchiver or file-roller)
Add to updater script after where it unmounts /system,
Code:
run_program("/sbin/busybox","sh", "-c","busybox mount /dev/block/mtdblock6 /data ;");
ui_print("Extracting data files...");
package_extract_dir("data", "/data");
unmount("/data");
and try next line after that because of selinux, but I haven't tested,
Code:
set_metadata_recursive("/data/sdext2/system/app", "uid", 0, "gid", 2000, "dmode", 0755, "fmode", 0755, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
put any init.d scripts into /system/etc/init.d

/system/lib has stuff that could move, too, if you wanted to set that up the same way.
You might be able to move all but a few bits out of /system/app since the permissions have changed with the new priv-app getting the good ones.
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

new internal build up. archi-opt, -O3 (-Os thumb for size.)
should fit your zvj Optimus S's.
still have to toggle adb for it to see the cable. Still dunno why.
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

I know sometimes -Os is competetive with -O2 and -O3 because it generates code that might fit in cache better (and does most of the -O2 optimizations anyway), but it is probably helped by more advanced instruction decoding and pipelining. I'm not sure what it would do to ARMv6 in terms of performance. It probably varies per code. A really masochistic compilation tuner could try to identify code hotspots and try different optimizations on those individual files for speed while using blanket -Os for size.

Any idea on what could be messing up the accelerometer? It seems like once it glitches out, it only gives an update once very 5 seconds, making it unusable for screen orientation.
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

It goes bad after sleep. That's why I went messing with the thunderg ami304d code.

If you look at logcat, it goes into a recalibration loop. Suggestions are welcome.
 
Last edited:
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

Forgot to mention, new os2sd build up.
Too lazy to clean ccache make clobber and rebuild, so it's -Os thumb -O3 everything else like the internal.
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

INFORMATIONAL

since the general format of the ROM has changed as much as it has, and the archive is taking up a lot of room on Drive, in a while I will be removing all the recent month's worth of ROM files from the archive. The kernel and recovery don't take up much room and I will leave them.

Feel free to download before that. I'll give another warning before I get rid of em. And, I won't be keeping any local archive either.
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

I haven't looked at the code, but possible accelerometer suggestions: Instrument the code and compare a run on a working device and a non-working device (especially with timestamping to detect race conditions), look for kernel interface changes, compare code with older drivers, look for bad interactions from other drivers (esp. if other stuff shares the same hardware), try making a self-reset workaround if the calibration loop is detected. Is it possible the accelerometer needs to be shut off before going to sleep, and it's still running and overflowing a buffer? Maybe going to sleep or wake-up is having some side effect outside of the driver (power gating / clock gating / etc).

Again, just talking out my *** here, but sometimes random ideas help.
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

the accelerometer was glitchy even in stock gingerbread for the optimus s.
It shares hardware with the ecompass and maybe proximity sensor.
with the thunderg setting in drivers/input/sensor/ami304.h

//new Addr=0x0E(Low), old Addr=0x0F(High)
#define AMI304_I2C_ADDRESS 0x0F
for thunderc, (it's 0x0E for thunderg.)

then using the thunderg ami304d binary gets great accelerometer response and totally dorks the compass.
Maybe there's a way to split them apart in the kernel driver but I dunno.

//edit: sleep mode=0 (power collapse) may have fixed it.

oh, and I finally found the adb/charging detection glitch. a prop was somehow getting adb copied twice (persist.sys.usb.config=mtp,adb,adb) and was also able to hunt down in the older Feb release code how to turn on adb on first boot without having to enable it in developer settings.

added
TARGET_EXTRA_CFLAGS += $(call cc-option,-mtune=arm1136j-s) $(call cc-option,-mcpu=arm1136j-s)

to BoardConfig.mk to (hopefully) force the toolchain to build specifically for the armv6 we have. After doing it my internal build seemed to smooth out while running, dropped a couple more MB, and didn't show any fc's in logcat. Play even cooperated well with that one.
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

bugfix/tuning flags release uploaded.

not seeing any ami recalibration in logcat, takes a little longer to kill accelerometer.
charges and connects adb even on first boot as soon as cm logo comes up.

and the emoticons work again in messaging, don't know when that got fixed but it bugged me.

also putting up test kernel with lowered wifi power supply voltage. see kernel thread for details. try it out, tell me what you think.
 
Last edited:
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

you can choose between the 627 bugfix release...
or the 628 lower-power wifi (&fresher repo sync) release.

I was testing the wifi with youtube app, it was streaming very pretty and fast. On internal, which runs slower for me.
(all the streaming Gapps I've tried on this kitkit look awesome, like they're over-resolution or something.)
didn't seem to get as hot as usual though it did still get pretty warm.
 
Last edited:
Ugh!!! Had a random reboot happen. This caused all sorts of problems:
1. Quick Settings button won't work, neither will Quick Settings ribbon buttons (except for Owner, which behaves like Clear Notifications; the real one won't work).
2. Home key stopped working.
3. Multiple dirty flashes didn't correct anything...
4. Expanded power menu seems missing, only options are reboot & power off; can't find screenshot anyway.
5. Attempts to change wallpaper via Gallery weren't the best: the first rebooted my phone and made the picture pixelated, the second caused blue screen and needed a battery pull.
6. Lock screen won't work.
7. Auto-rotate seems spotty at best now, it was just fine at first.
8. Restoring apps in TB has been a pain: even with Toucanscript active, it won't restore ALL my apps (there are 41 apps still considered "missing"), and a lot of them did NOT have data restored with them...have to go in each one to do it, and the data only restore option is spotty at best.
9. Some apps aren't compatible with this level of KitKat yet. MX Player is one of them.
10. Browser doesn't seem to work. Crashes without even trying to start up.

At least I got rid of that FC: in TB, there was "Themes provider" and "Themes Provider". Different versions, too. Got rid of them both, now there's just one that's called "Themes". Seems like this stuff doesn't belong here to begin with as it's T-Mobile. At this point, I am tempted to just abandon ship for now and go back to the nand of the old skinbark ROM. :(

Edit: Uh-oh. This doesn't seem good. I keep getting 492 errors from Play Store. According to some spots online, that means the sd card is damaged.

Posted via Android Central App
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

Ugh!!! Had a random reboot happen...

It sounds like it could be SD card issues - if I suspect problems I fill the drive with random data (md5'd as it's going in), then read it back and md5 it. No match = crappy card.

About to try out the low power wifi version on os2sd...
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

@red:
sounds like a bad flash, and using tibu is known to cause all kinds of weird errors. So is dirty flashing.
Plus your internal storage never seems to flash well.

Try:
step 1:
wipe system, data, cache.
flash just the ROM, boot it. Give it a minute to finish booting after the lockscreen comes up. Even if it responds, it's not fully started for a minute or so.
2:
Mess around with apps and watch for fc's. If none or few, go back to recovery and flash the skinny internal gapps. If you get several fc's, go to recovery, back to step 1.
3:
reboot, give it a couple minutes this time to settle down. Play runs in the background for a while the first time it's installed. Open play store, sign in, download something to make sure Play works.
4:
If it seems ok, then move on to tibu. This process will help nail down which step is causing issues, it could be any of them.

Make sure you have the latest versions of everything, all the zips and recovery. And the md5sum files. If you push them to the card with the zip files TWRP will check the md5s itself and not flash if the zips are incorrect.
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

I flashed 0629 os2sd but build number has internal. Can you fix this?
 
Re: [ROM+Kernel][CM-11.0][4.4.4][OS2SD/internal]bigsuperROM-thunderc-4.4.4

The 0628 os2sd build seems broken - md5 mismatch and won't boot. 0629 runs and doesn't seem to have a huge impact on wifi (haven't tested much though; I was fighting a bad stick of ram - maybe you should check memtest in case that's where these file corruptions are coming from! I managed to chew up my sd card contents by backing up through that computer during troubleshooting... not fun!)

Anyway, yeah the accelerometer problem seems about the same as before (unless 0629 doesn't have that patch) :(

I'm really impressed with the rom otherwise - everything else that can be expected to work so far works!
 

Trending Posts

Forum statistics

Threads
956,524
Messages
6,968,727
Members
3,163,558
Latest member
mikiotty