Believe that's a MIUI problem, not a kernel issue.
So... what you're doing wrong is using MIUI?
So... what you're doing wrong is using MIUI?
[KERNEL] Basic with a Twist SGS4G KJ6 1.1.3
- Thread starter AntonX
- Start date
-
- Tags
- development
I'm running 1.1.0 w/o OC/UV. I went into CWM to disable lagfix, rebooted, but my /system, /cache, & /data are still ext4. I tried it a few times but it never converts back to rfs. I know most people probably don't revert the file system back to the Samsung standard stuff, but is anyone else seeing this or is this a known bug? I searched the thread but didn't see any mention of it. I don't know if it's a problem for just this kernel & the version of CWM it uses or if the problem is more widespread.
Thanks.
----
Update: It helps to search the forum without typos. I saw in one of Bryan's threads that FB said it can't be disabled & they haven't taken it out of the CWM menu. Ignore me
Thanks.
----
Update: It helps to search the forum without typos. I saw in one of Bryan's threads that FB said it can't be disabled & they haven't taken it out of the CWM menu. Ignore me
Last edited:
Update: It helps to search the forum without typos. I saw in one of Bryan's threads that FB said it can't be disabled & they haven't taken it out of the CWM menu. Ignore me
Yeah the initramfs he used is based off the changes I made. At the time I made them, Bryan and I were discussing it and we decided that there was no real good reason for anyone to go back to RFS, so you're stuck with the same ext4 conversion you'd get if you used any rom that used AROMA since I based it off of bonsai rom's conversion.
I'm running 1.1.0 w/o OC/UV. I went into CWM to disable lagfix, rebooted, but my /system, /cache, & /data are still ext4. I tried it a few times but it never converts back to rfs. I know most people probably don't revert the file system back to the Samsung standard stuff, but is anyone else seeing this or is this a known bug? I searched the thread but didn't see any mention of it. I don't know if it's a problem for just this kernel & the version of CWM it uses or if the problem is more widespread.
Thanks.
----
Update: It helps to search the forum without typos. I saw in one of Bryan's threads that FB said it can't be disabled & they haven't taken it out of the CWM menu. Ignore me
Use one of their old kernels..i believe the one included in bhunds one click still lets you disable voodoo lagfix and all that
Sent from my SGH-T989 using XDA
bhundven
Inactive Recognized Developer
yea, one of my older one-clicks will do it.
You can find them on my sourceforge page. All of my new one-clicks will go on the teamacid sourceforge page.
First of all i just want to give thank's to Antonx for this great kernel....
I've been using the OC/UV version sense it was release and i didn't encounter any
issue, i am using VC to run it, but on my observation, i notice in the cpu history
the level 900Mhz and 1100Mhz shows no activity at all.. I'm sorry for putting this comment and this is not a complaint it's just an observation..
I've been using the OC/UV version sense it was release and i didn't encounter any
issue, i am using VC to run it, but on my observation, i notice in the cpu history
the level 900Mhz and 1100Mhz shows no activity at all.. I'm sorry for putting this comment and this is not a complaint it's just an observation..
Attachments
are you using ondemandx for scaling? If so that is the reason... Antonx said earlier that it ramps up and down in 200 mhz intervals
Sent from my SGH-T959V using xda premium
Sent from my SGH-T959V using xda premium
I'm on deadline/Smartassv2...@1300.. I'm not really sure if that the explanation to what i am wondering.. but for me no matter what scheduler or governor you are using it should
pass each level or just show some activity, correct me if i wrong..
pass each level or just show some activity, correct me if i wrong..
No, it does not work like that. Governors have certain patterns when they ramp frequencies up and down. Smartass uses 200Mhz steps, so it's very unlikely that "uneven" 900 and 1100 will be hit. If you switch to Ondemand, you'll see a different pattern. Smartass can be adjusted to use 100Mhz steps, but then you'll lose some responsiveness.
Anyway, don't worry about that. I have a tablet with much larger frequency table, and more than half of them never get hit. Having more frequencies doesn't hurt and just gives more choices to governors, but let then do their job the way they want.
Anton, I've been messing with compiling your kernel source against bryan's initramfs tree:
https://github.com/bhundven/android_initramfs_samsung_galaxys4g
Got down to 20 second boot times, but some of the startup scripts were lost in the process, namely install su. It does come with CWM 5.0.2.8 though and as far as I've tested everything works fine.
https://github.com/bhundven/android_initramfs_samsung_galaxys4g
Got down to 20 second boot times, but some of the startup scripts were lost in the process, namely install su. It does come with CWM 5.0.2.8 though
and as far as I've tested everything works fine.Anton, I've been messing with compiling your kernel source against bryan's initramfs tree:
https://github.com/bhundven/android_initramfs_samsung_galaxys4g
Got down to 20 second boot times, but some of the startup scripts were lost in the process, namely install su. It does come with CWM 5.0.2.8 though
What roots and installs su then? Aroma? I can switch to the new initramfs, just have few concerns. If there's no Voodoo, what's converting to ext4, Aroma as well?
Regarding Voodoo - as far as I remember it does some useful things upon boot, like checking SD for errors, etc. So we are not doing this anymore? If not, maybe it's a better idea to spend just few more seconds during boot but do it more safely.
I wonder if it's enough just to replace the recovery binary (and maybe some scripts if they are changed) to switch to 5.0.2.8.
Well, since most roms are using AROMA, I can implement a lot of this in it.
Root, a lot of roms already come with the su binary, but I can add this into aroma too, even make it an option whether to root with supersu or superuser.
Ext4, we're going to be doing in AROMA. I talked to Bryan about this and it's the best way to do it since I don't see a compelling reason to go back to RFS.
As far as not using the voodoo intiramfs, I think it'd be better overall to get away from it since it's so cluttered. We can copy over the useful boot scripts into bryan's initramfs and we'd have the benefits of both. I know for a fact that I'm going to want the root script in the kernel itself since it reduces the hassle for new users.
Root, a lot of roms already come with the su binary, but I can add this into aroma too, even make it an option whether to root with supersu or superuser.
Ext4, we're going to be doing in AROMA. I talked to Bryan about this and it's the best way to do it since I don't see a compelling reason to go back to RFS.
As far as not using the voodoo intiramfs, I think it'd be better overall to get away from it since it's so cluttered. We can copy over the useful boot scripts into bryan's initramfs and we'd have the benefits of both. I know for a fact that I'm going to want the root script in the kernel itself since it reduces the hassle for new users.
The kernel has got to have auto root for new users, especially if they want to stay on stock ROM. So su must be installed somehow, and not during the installation because somebody could be ODINing. Same actually goes for ext4, the conversion has got to happen even after ODINed kernel.
We don't need to use Voodoo per se and can probably kill 70-80% of its scripts, but some of them need to make to the new initramfs.
We don't need to use Voodoo per se and can probably kill 70-80% of its scripts, but some of them need to make to the new initramfs.
Well I already did most of the work in terms of scripts. We can just modify aroma's data backup/restore scripts to copy over /system also (/cache won't matter for me, it's better if it gets rebuilt anyway) and we can throw in the mkfs.ext4 binary along with all the other ext4 conversion binaries into the initramfs.
The compiled kernel is 5.1mB so we have a lot of room to work with.
The compiled kernel is 5.1mB so we have a lot of room to work with.
Updated CWM to 5.0.2.8 in the initramfs. Seem to work fine, but don't see any differences except the color Because of that don't see any point of releasing right now, unless somebody really wants it. Does anybody know what changed from 5.0.2.7?
Because of that don't see any point of releasing right now, unless somebody really wants it. Does anybody know what changed from 5.0.2.7?
bhundven
Inactive Recognized Developer
Updated CWM to 5.0.2.8 in the initramfs. Seem to work fine, but don't see any differences except the color
As far as the /sbin/recovery is concerned... check the repository.
Wrt the rest of the initramfs, no more voodoo lagfix. The updater-script you use needs to format with ext4, or stuff won't work.
EDIT: whoops, I mean to say... it will still try to mount rfs if ext4 doesn't mount. So if you flash a stock rom with rfs it will still boot. But if your rom expects ext4 and stuff is rfs, it will be wack.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
69Basic with a Twist SGS4G KJ6 Kernel
BML, don't flash if you have partitions converted to MTD.
Use at your own risk, I take no responsibility for anything that may happen to your phone because of this kernel.
This kernel is for those who don't want to be on the very cutting edge (CM7) but rather want stability without sacrificing too many recent features. It is based mostly on Bryan's 0.0.2d commit that supposedly never had problems with silent reboots. I made some changes to the config to bring it even more to the standard Samsung VibrantPlus in terms of hardware settings, but at the same time to optimize it for speed. I will add only tried and true features to this kernel, the ones that other kernel developers have used successfully.
Special thanks to bhundven (Bryan), FBis251, TeamAcid.
Features
- initramfs from TeamAcid, including CWM5, SuperSU, forced ext4, etc.
- Usual CIFS, TUN. I didn't include FUSE, if anybody needs it let me know.
- BLN. Use BLN Control app from market to activate.
- Voodoo Sound so paid app is not needed. Voodoo Sound app from market is required. Once installed, enable Smart Amplifier, it's the best thing you can do to improve music listening experience with our phone.
- jhash3 for faster hash calculations. Used widely across the kernel, especially in networking.
- OC/UV support with extended frequency table. Added 600Mhz, 900Mhz, 1.1Ghz, 1.2 Ghz, 1.3 Ghz, 1.4 Ghz. Use SetCPU or Xan's Voltage Control to enable and control frequency and voltages. Tegrak can be used only with no-OC/UV version.
- ondemandX and smartassV2 governors. One of these should probably be preferred over stock ondemand. Change with SetCPU or similar.
- TinyRCU. More lightweight version, it fits better our single CPU system.
- Swap support, although I don't recommend using it.
- SIO and BFQ I/O schedulers in addition to noop, deadline, and cfq that we already have.
Install
Flash with CWM or SGS Kernel Flasher. ODIN version is available only for OC/UV kernel.
Download
CWM:
v1.1.3
v1.1.3 (no OC/UV)
v1.1.2
v1.1.2 (no OC/UV)
ODIN:
v1.1.3
v1.1.2
Notes
* OC/UV version is very conservatively undervolted to -25mV. The preset voltages are still higher than on regular I9000, which has the same CPU. I'm running additional -50mV (total -75mV) for all frequencies without issues, but you may have them, every CPU is different!
* It is recommended to create a CWM recovery file before modifying voltages. This option is available in both SetCPU and VoltageControl.
* OC-ing to 1.4 Ghz is not recommended, especially for extended periods of time.
* Voodoo ext4 conversion, or "lagfix", is enabled and forced by default. There is not way and no need to go back to RFS.
Source
www.github.com/AntonX
Changelog
1.1.3
CWM 5.0.2.8 (blue) in initramfs
Disabled a little more of Samsung debugging
1.1.2
Minor changes to initramfs voodoo extension scripts
More neutral boot logo
1.1.0
Initramfs script will not force su update
Couple of small changes
1.1rc2
Few small changes
1.1rc1
Added BFQ and SIO I/O schedulers
Switched to TinyRCU
Added Swap support
Small change to Vibetonz
1.0b5
Some changes to OC/UV
Better BLN fix
Increased write timeout for bad SDHC cards
Added ondemandX and smartassV2 governors
Renamed the title, it's becoming less and less Basic...
1.0b4
Added native OC/UV support
1.0b3
Minor BLN changes
Replaced jhash.h with jhash3 code
Updated initramfs with SuperSU 0.88
1.0b2
Added BLN, first attempt
1.0b1
Original release
1312I've decided to keep BLN. I looked at the code, didn't find anything that could cause troubles if BLN if not used. Found the issue with "I2C write error", there were attempted writes to unpowered controller, so I fixed it. Removed some unnecessary debug tracings too.
Updated jhash to faster jhash3, there can be slight performance boost for data, but probably not easily noticeable.
Updated initramfs to latest SuperSU. Couldn't figure out how to easily update busybox to 1.20 (it needs to have bunch of links created), any help?
OP updated to 1.0b3.
Will try to post code on github today.
EDIT: Added source code link to OP. Unfortunately because I used a little unorthodox method of getting the old Bryan's commit, I cannot easily and safely attach my modified code to it anymore. So the kernel code it posted as a new repo. If somebody needs to know exactly what's changed, let me know and I'll point to correct files. I was able to fork from the initramfs repo though, there were not too many of my changes.11Updated OP to version 1.1 rc1 with few more featured for completeness.
Added two I/O schedulers, SIO and BFQ. You don't have to use them, especially if you don't exactly know what they are.
Added native swap support (somebody asked), but I don't recommend ever using it. They system will become too unresponsive with it. Native swap doesn't go well with Android memory management, it doesn't work well with slow flash drives, plus you trash your SD card a lot sooner.
Switched config to smaller faster TinyRCU, seems to be a logical change for one CPU systems.
Things that didn't make to the kernel:
Tiny Preempt RCU - it will not make the phone any faster, and it seems that some kernel devs have problems with it.
zRam (compcache) - I actually added it, it kind of worked, but was sometimes crashing the phone during initialization. It's probably not a good thing to have on our phone anyway. So I took it away.
Unless somebody comes with an idea what else to add to the kernel, I'm going to freeze the changes, wait few days for bug reports, and name it a release.11Updated OP to 1.1.0. Didn't see anything wrong with it over last few days, so let's call it a stable release and go from here.
Small change to VoodooSound to remove ADC oversampling when doing VOIP and recognition. Probably really unnecessary, just a little paranoia.
Looked at Vibetonz again, but didn't find anything wrong. Looks like MIUI knows about it, tries to use it, but does it incorrectly.
Removed forced superuser update.
If you used a OC/UV version prior to a test release that introduced extra frequencies (600, 900, 1100), review and update your voltage table!
New posts
-
Question Oneplus 11 Chinese version after update to cph2449 NFC issues- Latest: tudobembom
-
