Hey Everyone,
I was just wondering that if we have a build to which we have BOTH RamHack kernels and the non-ramhack kernel, would there be a way to write a quick app or script to switch between them.
I guess we could store both kernels on the /sdcard and use a .sh script to flash_image between them, and reboot. I dont believe we can "hot-swap" between kernels, but if anyone knows a method, please respond here
If anyone can think of a better or more efficient method of doing this, I believe the whole community would benefit. Lets see if we can get something like this going....
zimphishmonger said:
Hey Everyone,
I was just wondering that if we have a build to which we have BOTH RamHack kernels and the non-ramhack kernel, would there be a way to write a quick app or script to switch between them.
I guess we could store both kernels on the /sdcard and use a .sh script to flash_image between them, and reboot. I dont believe we can "hot-swap" between kernels, but if anyone knows a method, please respond here
If anyone can think of a better or more efficient method of doing this, I believe the whole community would benefit. Lets see if we can get something like this going....
Click to expand...
Click to collapse
is it really that hard to boot into recovery and flash an update.zip?
I guess this is what you're looking for:
http://wootroot.com/blog/?page_id=1463
Ive seen it implemented on one other rom on xda, but can't remember which one ..
I am trying to make it easier and more efficient to switch between them. The uneek switch seems exactly what im looking for
I put together a version of uneeks script that can be flashed over SuperD or FastTest3.1.
ISSUE THOUGH, I cant get it to flash correctly, as I get the "update-script not found" error, even though I signed it and created the appropriate META-INF directories.
Here is the file, if anyone thinks they can fix it
Uneek Script (needs to be fixed\signed) : http://www.4shared.com/file/257220832/8b6c2940/uneek.html
Alpha release
Here is a very alpha release of a working port of uneek's RamHack/NonRamHack Toggle script ported to SuperD 1.10.2 by myself.
http://www.4shared.com/file/257253893/a61182a2/Uneek_Script.html
Instructions
extract zip file to /sdcard/uneek
Launch terminal
type 'su'
type 'sh /sdcard/uneek/install-uneek.sh' -should see no errors/messages
execute 'uneek' from /system/bin
Chose Ram option or JIT (not tested) options, all others prob dont work as I didnt modify them
reboot (you must do so to see effects take place, the kernel doesn't "hot-swap" :-( )
WiFi still works, CC & Swap work.
Issues
Switch breaks boot screen - not sure why as its stored in framework-res.apk, but still a bug
Leave me feedback\ improvements\whatever......
You still have to boot into recovery so you might as well flash a zip containing a rhack or noram-hack kernel.
I did some scripts based off Kings,
get gscript from the market ( donate if you like it )
and drop script into the gscript folder
with a little uname query you could have just one script, which switches based on the current running kernel
Edit: , actually if your kernel needs different kernel modules, then you will have to build in a copy ( which I suspect is where king got his rwsystem bit from , he copied from a script which updates the kernel modules )
Firerat said:
...<snip>...
my faster, much safer script
Code:
#!/system/bin/sh
if [ -e /data/kernels/full3d.img ];
then
if [ "`md5sum /data/kernels/full3d.img|cut -d " " -f1`" != "061284119d4ce46cbe0b585e0a8b2d0b" ];
then
echo "/data/kernels/full3d.img isn't the version I was expecting"
echo "I'm not going to flash it, as it may have become corupt"
exit 1
else
flash_image boot /data/kernels/full3d.img
echo "full3d Kernel Flashed..."
echo "Rebooting now"
sleep 1
shutdown -r now
fi
else
echo "Sorry, /data/kernels/full3d.img"
echo "seems to be missing....."
exit 1
fi
and yeah, I could never spell corrupt , is it one or two 'r's?
PS , the md5sums in the scripts are for the power off fix boot.img's I did for you guys
if you are wanting to switch to different boot.imgs then update the md5sum its checking for ( or remove the check )
Click to expand...
Click to collapse
If you have an engineering SPL installed, there isn't any need for the recovery partition, so might as well install your second kernel to the recovery partition. Boot normal = normal, boot recovery = ramhack.
lbcoder said:
If you have an engineering SPL installed, there isn't any need for the recovery partition, so might as well install your second kernel to the recovery partition. Boot normal = normal, boot recovery = ramhack.
Click to expand...
Click to collapse
and then have a script switch wlan.ko if incompatible
might as well switch with script and keep recovery for the odd times when you just want to quickly flash some zips from a list and not at your pc.
yeap, I've downloaded and flashed a rom while 'out and about' before.
Firerat said:
and then have a script switch wlan.ko if incompatible
might as well switch with script and keep recovery for the odd times when you just want to quickly flash some zips from a list and not at your pc.
yeap, I've downloaded and flashed a rom while 'out and about' before.
Click to expand...
Click to collapse
If the only difference is ramhack on one but not the other, then the wlan module will be fine -- there is NO REASON to be switching modules around with your kernel unless you use a kernel that is binary incompatible -- which means DIFFERENT VERSION.
lbcoder said:
If the only difference is ramhack on one but not the other, then the wlan module will be fine -- there is NO REASON to be switching modules around with your kernel unless you use a kernel that is binary incompatible -- which means DIFFERENT VERSION.
Click to expand...
Click to collapse
yeap, true but why not keep options open?
What if they decide they want to switch between binary incompatible kernels?
They would need to switch kernel modules anyway.
so get a script that works, and is simple to 'generate'.
I know you are trying to keep it simple, but you are actually needlessly setting up restrictions, which would then require a script to get around.
So why not use a script from the start, keeping the added convenience of a recovery image?
Firerat said:
yeap, true but why not keep options open?
What if they decide they want to switch between binary incompatible kernels?
They would need to switch kernel modules anyway.
so get a script that works, and is simple to 'generate'.
I know you are trying to keep it simple, but you are actually needlessly setting up restrictions, which would then require a script to get around.
So why not use a script from the start, keeping the added convenience of a recovery image?
Click to expand...
Click to collapse
If the only objective is to be able to easily toggle between ramhack and noramhack, then the recovery solution is (1) more reliable, (2) doesn't require reflashing NAND, (3) just easier to activate. With the reflashing approach, you have to either go into recovery and flash something, or pause-and-wait-and-autoreboot.
lbcoder said:
If the only objective is to be able to easily toggle between ramhack and noramhack, then the recovery solution is (1) more reliable, (2) doesn't require reflashing NAND, (3) just easier to activate. With the reflashing approach, you have to either go into recovery and flash something, or pause-and-wait-and-autoreboot.
Click to expand...
Click to collapse
did you ever read anything?
the script is as easy as a couple of taps, maybe home button, swipe tap tap.
( the key app here is gscript )
the flash is over very quickly, it checks md5sum first, it reboots.
you have to reboot with the recovery method anyway
recovery method restricts to binary compatible kernels, or require a script to switch kernel modules.
It is a no brainer imo, keep it flexible and keep the convenience of a true recovery.img
ok, so nand only gets what, on average 10,000 writes, is it really going to reduce its life in practice?
I like your idea, it will work but it just isn't as flexible as a script.
It is however more suited to an mt3g, offering duel ROM
I'm thinking mtdblock3 for one ROM, block4 for the other
errm, data , yeah might need to section that up somehow
any reason why a loopback can't sit on yaffs?
oh, and the ramdisk will need tweaking, obviously.
Sorry back on topic
Guys,
Either will work, if you do have incompatible kernels, and are having problems with scripts just let me know, I can probably make a script to generate a script for you.
1) Booting into recovery to change out your kernel image is totally unnecessary. You can do it via CLI with the flash_image command -- most every modded ROM already includes it.
2) Removing the recovery image just to put up a second install also seems somewhat overkill for devices as heavily limited on storage as most Android phones -- especially the G1.
3) I don't know about loopback on yaffs2 -- but I don't see any reason why it couldn't work.
4) It really seems to me that what we need is some kernel hacker who's familiar with hotswapping patched files -- a la ksplice ( http://www.ksplice.com/ ) -- to hack together a genuine, non-rebooting, RAMhack switch.
5) In all seriousness; what makes gscript superior to ASE ( http://code.google.com/p/android-scripting )?
IConrad01 said:
5) In all seriousness; what makes gscript superior to ASE ( http://code.google.com/android-scripting )?
Click to expand...
Click to collapse
Nothing, apart from its easy, it works and I haven't looked at ase yet
btw , you missed a p/ in that link
http://code.google.com/p/android-scripting/
btw , you missed a p/ in that link
http://code.google.com/p/android-scripting/
Click to expand...
Click to collapse
>_<
Pesky perniciously persistently phantasmagoric P!!!
I just keep on seeing people referring to gScript when ASE is a vastly more robust offering. It can run its scripts as daemons, run in background, run in terminal, it offers the same desktop shortcut option -- and more importantly, it can run Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, and shell scripts. (It loads the interpreters onto your /sdcard.) I've asked this question more than once before and I've never gotten an answer. It really seems like people just aren't aware of ASE -- which is kinda sad, considering the fact that ASE is still seeing continuing development whereas development ended on gScript sometime at the end of last year.
IConrad01 said:
>_<
Pesky perniciously persistently phantasmagoric P!!!
I just keep on seeing people referring to gScript when ASE is a vastly more robust offering. It can run its scripts as daemons, run in background, run in terminal, it offers the same desktop shortcut option -- and more importantly, it can run Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, and shell scripts. (It loads the interpreters onto your /sdcard.)
Click to expand...
Click to collapse
no, I am very interested in it,
I have been meaning to have a proper look at it for sometime
, I think I first saw it on @google
gscript is just handy,
unzip this, gscript from market,add, load, tick su, save , tap
But I promise , I will look at ASE
Firerat said:
and then have a script switch wlan.ko if incompatible
might as well switch with script and keep recovery for the odd times when you just want to quickly flash some zips from a list and not at your pc.
yeap, I've downloaded and flashed a rom while 'out and about' before.
Click to expand...
Click to collapse
Glad this is getting your attention....My script was pretty dirty anyways.
Anyway you can package it up in signed-zip format for easy access and modification of boot.imgs. Im having some issues with the update-script portion during the signing process tos keeping me from getting mine to be "flashable"
zimphishmonger said:
Glad this is getting your attention....My script was pretty dirty anyways.
Anyway you can package it up in signed-zip format for easy access and modification of boot.imgs. Im having some issues with the update-script portion during the signing process tos keeping me from getting mine to be "flashable"
Click to expand...
Click to collapse
still having update-script issues?
if you post it, I'll be happy to take a look for you
Oh, I've started a kernel switch script
I'll do some testing when its done and post it here for you
Related
Just throwing an idea out there, and since it's for developers (specifically people who make their own recovery images) I assume this is the right section.
Since we have 'control' over the recovery image on our phones, would it not be possible to add a little script to an update.zip that a suitably modified recovery image could extract and run to interactively prompt the user for various Rom options? I'm thinking specifically of kernel choices, but it could be extended to almost anything that needs to be done prior to booting the installed image.
Imagine installing a rom, and during the install you got a little menu like this:
1: RamHack, BFS Kernel
2: RamHack, CFS Kernel
3: No-RamHack, BFS....
etc...
inefficient, it adds extra baggage to rom, and more things can go wrong. what would you rather downlaod a 90mb file or a 110 mb file.
Which would you rather download, one 110MB ROM or 2 90MB ROMS?
I'm pretty sure there's more than a few people who'll download different variations of the same ROM so they can see which is faster, how much easier would it be to just download one thing and then choose which options you want in there without downloading anything else.
I believe it is entirely possible. As a matter of fact, I was working on a ROM project that would have an interactive installer from the update.zip that would selectively install different features, apps, customization, themes, etc., based on the recovery menu application. It would use a lot of the /cache for temp space, though, as the installer application and its resources and configuration file, and later, the necessary parts of the ROM itself, would need to be unzipped before the install can run, if I recall correctly.
Does anyone have a good link to a reference for the command syntax for the /META-INF/com/google/android/update-script file? I'll go search for it in a few moments myself. I could probably make a simple ROM installer that chooses between ROM X and ROM Y based on a key input, as a proof of concept. I'll test it myself, I don't really mind half-bricking my device for science. (As long as I don't need to touch the SPL/Radio, that is.)
Update: Some creative searching finds me this:
JesusFreke said:
Assuming you mean update-script in an update.zip update, you will need to either look at existing update-script files for an example of the syntax, or look at the source of the recovery program in the android source
Click to expand...
Click to collapse
There's also a "make-update-script.c" file I'm seeing here and there, I'm trying to find the file in the Android source.
Update 2: From install.c at donut from cyanogen's android_bootable_recovery:
Code:
#define ASSUMED_UPDATE_SCRIPT_NAME "META-INF/com/google/android/update-script"
#define ASSUMED_UPDATE_BINARY_NAME "META-INF/com/google/android/update-binary"
and in commands.c, toward the bottom at register_update_commands is all the commands defined, and above that are all the functions they carry out.
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
markolo25 said:
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
Click to expand...
Click to collapse
Well, on the 32B platform with the Death SPL (my phone) we have the following partitions of the internal NAND memory (mtdblock*) from the df and mount command:
NAND 3: /system 92160kb - OS partition, static and read-only
NAND 5: /data 91904kb - User, system config, app config, and apps (without a2sd)
NAND 4: /cache 30720kb - OTA cache, Recovery/update config and temp
And I'd assume NAND 1 and 2 are the kernel, ramdisk, and bootloader config.
So the ROM wouldn't exceed 92MB installed (most leave some room in /system for hacks and updates). And the update process doesn't ever really "flash", per se; it just formats, copies files, and sets permissions and initialization configs, like Windows or Mac.
So the files that are common to the different ROMs being packaged don't need to be duplicated, only the ones that are changed (like a boot.img, or 32A/B compatibility, or different apps). The update script and chooser menu will decide which files to copy. Meaning the ROM package in and of itself shouldn't really need to exceed 128MB, even if choosing from a wide variety of platforms. And upon installation, the system might take less than 32 MB.
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Deicist said:
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Click to expand...
Click to collapse
I could download them all, and find the differences of each. It would be cool if a ROM like this were available in a single download, from which you would choose the content from the device before flashing.
Also, inspired by talking about this, I wrote up a guide on the update-script in the package file. It's still not finished, but it'll be the only guide available for that syntax yet (trust me, I couldn't find one myself ). Link's in my sig.
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
how big of a ROM are you thinking about?
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
jmhalder said:
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
Click to expand...
Click to collapse
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
domenukk said:
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
Click to expand...
Click to collapse
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
TylTru said:
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
Click to expand...
Click to collapse
You could just have flashed the original rom without wipe.
Would be a step forward if you could simply put roms and additional files in folders... maybe even whole zip files containing some updates and an xml like file to describe them. This would guarantee compatibility with earlier boot images (just unpack the updates in the zip). Tar might work better than zip as it is not compressed thus faster afaik.
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
TylTru said:
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
Click to expand...
Click to collapse
This is pretty awesome. I was going to say, we could easily run bash scripts but this is so much better.
This needs to be merged with both Amon_ra's recovery and the new 2.x based recovery...
Dual Boot Support
DualBoot Helper APP is now on the market! (See bottom of this post for more info)
DISCLAIMER: I am not responsible for anything, ever. It is not my fault if you do not read. I do not explain things because I enjoy banging on the keyboard. If you do not read this entire post before jumping in then do not expect me or anyone else to be much help. By following this guide and any links YOU assume all responsibility for your device and anything that happens with it.
What is it?
Dual booting allows you to run two separate roms on your device at one time. It is done by intercepting the mount points during the startup of the device. This is accomplished by checking the sdcard for a specifically named file when the kernel first loads and uses the appropriate files to boot with the correct partitions. Reading from the sdcard is slower than reading from the internal memory of the phone so the speed of your sdcard will drastically determine the speed any rom runs. On the same note a rom flashed to the sdcard will take longer than usual on the first boot.
What does it do for me?
Running two separate roms has many uses for just about everyone. Users can use dual booting to try different roms, themes, apps, modifications, or anything while keeping their existing installation intact. The uses are just about endless. Besides testing different roms, this allows the user try these things and make sure they are compatible and stable before pushing the changes to their internal memory. Rom developers have all of the above options plus a few. Rom developers can additionally use dual booting to test builds of their roms without fear of soft bricking their device. For advanced users, you can mount the partitions of the other rom (be it sdcard or internal) and fix bad apk files or messed up files. The options really are limitless!
What do I need?
Sdcard 2GB or larger
Dual boot compatible kernel
Other things I should know...
*The kernel MUST support BOTH roms you flash. Unfortunately this means you can NOT mix froyo and gingerbread roms. Make sure you know what the kernel supports before you flash anything!
*If you compare roms, benchmarks will hold no value due to the sdcard being so much slower than internal memory.
*Faster sdcards will perform better than slower ones. Note: the stock 16GB sdcard is a class 2 which simply classifies it's minimum speed. A higher class sdcard will more than likely perform faster but the class rating is a minimum and not a maximum. It is entirely possible that a certain class 2 card can out perform a different class 6 card. Keep this in mind when researching to buy a new faster sdcard. More info in this post.
*First boot takes longer than usual. Up to 15 minutes! Please wait until the rom boots and the initial media scanner is done before you judge usability.
*Using a rom from the sdcard will cause the sdcard to wear faster. This is due to many more reads and writes of data than normal. The Epic simply does not have the internal capacity to run dual roms on the NAND. That being said the sdcard is our next option. While it may reduce the over all life of the sdcard keep in mind there are other android devices like the Nook Color and the other Galaxy S phones that have internal sdcards running the Android operating system. My personal opinion with is with other devices running off internal sdcards and with the price of sdcards getting cheaper and cheaper it was worth it to explore this option for the Epic.
Ok ok, so how do I get started?
I am going to break the steps down into sections. Please read everything to ensure you understand what all is involved in getting everything working. I recommend making a backup in Clockwork Mod and saving it to your PC before you even get started.
Section 1 - Setting up the environment
Step 1. Flash a compatible kernel (Kernel developers, PM me if you add my dual boot support to your kernel and I will update the list below) Remember you can NOT mix a eclair, froyo, or gingerbread roms and the kernel MUST support both roms!
Currently compatible kernels:
Genocide 2.0 Supported Roms: EC05, EB13, and DK28
Section 2 - Preparing sdcard
Important information!!!! This will destroy ALL data on your sdcard so if you lose pictures of your dog, cwm backups, nudies of your spouse, etc then you can't blame me. BACKUP YOUR SDCARD!
The easy way:
Reboot into recovery mode with a program like Rom Manager, Quick Boot, or type 'reboot recovery' from a terminal. (NOT 3-finger boot to recovery...this will NOT work)
The easy way WILL erase your sdcard with NO confirmation....you have been warned!
Choose one of the following flashable zips to automatically partition your sdcard
DualBoot_Partition_RFS.zip
DualBoot_Partition_EXT4.zip
The manual way:
Reboot into recovery mode with a program like Rom Manager, Quick Boot, or type 'adb reboot recovery' from a command line. (adb commands assume you have a working install of the Android SDK)
While in recovery issue the following commands:
Code:
adb shell
cd /sbin
./dbpart.sh --help
I put many hours into the partitioning script to make it as simple to use as possible. Simply follow program usage instructions.
Section 3 - Preparing a rom
Since we have blank partitions on the sdcard we need to populate them with data. There are multiple ways to accomplish this and you can choose which solution best suits your needs. I am not going to cover ALL methods here but enough to suffice any likely scenario needed.
The dd method will clone your current setup to the sdcard (these commands may take up to 15 minutes)
The easy way:
Flash this dd script: DualBoot_Clone_to_sdcard.zip
The manual way:
Code:
adb shell
dd if=/dev/block/stl9 of=/dev/block/mmcblk0p2
dd if=/dev/block/stl10 of=/dev/block/mmcblk0p3
dd if=/dev/block/stl11 of=/dev/block/mmcblk0p4
Preparation is complete. Please skip down to booting from sdcard.
The flash method is for flashing a new rom to the sdcard.
The easy way:
There is no sure fire easy way just yet. Stay tuned though.
The manual way:
This method is not that difficult so there is no need to be intimidated by it. It requires editing a few lines of the script that Clockwork Mod executes when flashing a rom or addon. For this example I am going to use a file named epicrom.zip but you can use any name you wish.
Step 1. On your PC, open epicrom.zip (I recommend using a program like 7zip)
Step 2. Navigate to the META_INF\com\google\android\ folder.
Step 3. Drag the file updater-script out of the zip to your desktop.
Step 4. Open the updater-script file with a text editor such as notepad (I recommend notepad++ or textpad)
Step 5. Change every instance of /dev/block/stl9 to /dev/block/mmcblk0p2
Step 6. Change every instance of /dev/block/stl10 to /dev/block/mmcblk0p3
Step 7. Change every instance of /dev/block/stl11 to /dev/block/mmcblk0p4
Step 8. Delete the entire line for any lines that contain /dev/block/bml7 or /dev/block/stl7 to disable flashing another kernel and breaking dual boot support.
Step 9. Save the file and drag and drop it back into epicrom.zip and let it replace the old one.
Note: If you get a status 6 or some other error when trying to flash it is likely you made a typo or your text editor did no save the updater-script file correctly. Recommended action is to correct the typo and/or use one of the recommended text editors note in Step 4.
Section 4 - Flashing to sdcard
Flashing a rom from this point is the same as you usually do. Put the modified rom on your sdcard and flash with Clockwork Mod like usual. I recommend doing a backup in Clockwork Mod BEFORE you flash in case you messed anything up by accident and end up flashing over internal memory when you meant to flash to the sdcard.
Section 5 - Booting sdcard
To boot from the sdcard place a file in the root of your sdcard called 'bootsdcard'. If you named it correctly upon reboot, the kernel will load the rom from the sdcard and not internal memory.
To boot back into internal memory simply remove this file from your sdcard and reboot.
You can switch back and forth using this method. If the file is there it boots sdcard, if the file is not there it boots normally. Pretty simple right?
Section 6 - Other flashables (not roms)
Themes, addons, and anything else that is flashable with Clockwork Mod must be modified in the same fashion as the rom. Use the same procedure documented in Section 3, The flash method.
Kernel Developers:
If you would like to add dual boot support to your kernel please refer to this commit: https://github.com/Rodderik/Genocide-Kernel/commit/a5dfd9f369ae4f2c90c1e7fc7d8995f88f72bd01
I will update this section if I push any specific changes to dual booting.
Now with an APP!
DualBoot Helper
VenumX coded up an APK to work with Clockwork Mod to run the scripts.
http://forum.xda-developers.com/showthread.php?p=15486144#post15486144
Questions, concerns, gripes, or complaints can be left in this thread. If you need to report any problems please be as detailed as possible.
woot
Thats my boy!!!! Make me proud!!!!!!!!!!
w00t! go man go!
Holy ****! This is huge! Thanks!
Sent from my SPH-D700 using Tapatalk
OMFG this is way amazing ;P
Thr genious once again with another first
Sent from my SPH-D700 using XDA Premium App
Edit
nevermind...
good work!!!!!!!!!!!!
davidrules7778 said:
I got a question...
Would i be able to run dual versions of android
Ex 2.1 and 2.2
or 2.2 and 2.3
if the kernal is compatible?
Click to expand...
Click to collapse
if the kernEl was compatible yes...but none of them are...and likely won't be
Good damn job bro.. Let's keep the dev community developing
Rodderik said:
if the kernEl was compatible yes...but none of them are...and likely won't be
Click to expand...
Click to collapse
what if u made one of the eclair kernal compatible or gingerbread whenever we get custom kernals for it?
Or is it not possible to make eclair kernals compatible?
i think i could make a GB kernel now.. but you wouldnt be able to mix gb with froyo or eclair, because a GB kernel wont boot those builds..
Awesome work bro! Amazing...simply amazing!
chris41g said:
i think i could make a GB kernel now.. but you wouldnt be able to mix gb with froyo or eclair, because a GB kernel wont boot those builds..
Click to expand...
Click to collapse
yup i'm going to help chris41g put together a gb kernel for you guys
as far as eclair...honestly who still uses eclair? and why?
Rodderik said:
as far as eclair...honestly who still uses eclair? and why?
Click to expand...
Click to collapse
Just what I was thinking.
Tested on EC05 just now. I uhh... likey? =)
to bad no multi android versions though =(
why cant the kernel read off the sdcard? do you need drivers from samsung once again?
Shoulon said:
Tested on EC05 just now. I uhh... likey? =)
to bad no multi android versions though =(
why cant the kernel read off the sdcard? do you need drivers from samsung once again?
Click to expand...
Click to collapse
well the kernel is stored in bml7 and called by sbl/param during boot so unless we can get a bootloader to intercept the initial loading of the kernel and pass it off we are stuck with one kernel at a time
Very Nice Work !!!
Hey rodd... I think you should work on an aosp gingerbread kernel ... this is a great advancement in devlopment man... right when it was slowing again
Sent from my SPH-D700 using XDA App
this is amazing, thanks for this!!
You cannot make a cross OS kernel. We cannot integrate this into GB yet because there is no GB source, no GB source, no custom kernel. This is Froyo only, and well, someone else can make an eclair only kernel, but that is stupid.
Updates
10/1/2011 - Added 00remounti9001 to remount the major partitions to noatime and disabled barriers for as well as delayed journaling to every 60 seconds (as opposed to 5) to /data, /persist, /cache. Added Acid Tweaks - Removed Useless Stuff i9001.zip to remove journaling from /cache and /system (It's safe). Also added JournalingOn.zip to revert back the two partitions to being journaled.
For the 00remount script, here's the how to:
0. Wait till Android finishes loading everything.
1. Install Script Manager from Market
2. Point script manager to the script you placed in the sdcard.
3. Run as root.
4. Do this at every boot, as mount points are reset to its default as set by the type of your lagfix. Voodoo (from what I am using will set barriers for /data and atime for every mount point except /system, /data, /cache, /dbdata which puts a slight risk at your disk for using atime.
5. You can add a widget to your home screen for the script so that you can
activate it easily.
The other two are CWM zips. You should know how to flash CWM zips right?
Introduction
I've made a Definite Guide on Android thread for i9000 that focuses on a few optimizations/scripts I've picked up over the months I've spent on XDA. I truly enjoyed sharing my knowledge with the i9000 community and since the tips/guide/scripts can also be applied here (save some exceptions that I would list down below),I would like to share this with the Captivate community too.
Exceptions
Take note that the guide is primarily for i9000 units. There are a few differences I can note here that you should be aware of:
1. The guide points out some kernels/ROMs that are for i9000. Hence the phones you are using may have different ROMs/kernels that may or may not correlate with the one in the guide.
2. The guide also mentions some apps/tweaks that are particularly alien to your unit and you may have never encountered it in your use of your phone or in XDA. Please ignore them for now, I'll make an effort to make the guide compatible in the future (with feedback from you guys of course )
3. Journaling scripts that are attached like the JournalingOn.zip and Acid Tweaks - Removed Useless Stuff and 00remount may not work well with your unit or it may completely brick it. I don't know this, but if you can post your mount partition configuration, I am willing to make the scripts work for you. You only have to type "mount" on your Terminal Emulator and provide the output to me, and I'll provide the rest. Zach's script however, have high compatibility towards a lot of phones, and thus can be used for your unit. Take note that there is a slight risk that it won't work well. If it doesn't, please post your problems here, and I'll try to fix it. Hence, it's best that you make a nandroid backup before attempting to use any tweaks here.
3. I've compiled a guide on a few notable tweaks in XDA here: LINK. If you would like me to evaluate scripts/tweaks/anything that you do not understand due to their terms being alien to you, I'll be glad to explain it here
Guide
You can refer to the guide here:
LINK
Hi pikachu!
I've made a screenshot of the terminal output after entering the mount command. Hope it provides you the needed informations!?
reneph said:
Hi pikachu!
I've made a screenshot of the terminal output after entering the mount command. Hope it provides you the needed informations!?
Click to expand...
Click to collapse
Thank you
I'll get to work on the scripts. Give me an hour or two
pikachu01 said:
Thank you
I'll get to work on the scripts. Give me an hour or two
Click to expand...
Click to collapse
Updated the scripts. Please read my guide before flashing any of those zips/scripts to know about its risks.
I am not responsible for any damages/bootloops if you did not read the guide before flashing those scripts/zips.
UPDATE 10/1/2011 - Added 00remounti9001 to remount the major partitions to noatime and disabled barriers for as well as delayed journaling to every 60 seconds (as opposed to 5) to /data, /persist, /cache. Added Acid Tweaks - Removed Useless Stuff i9001.zip to remove journaling from /cache and /system (It's safe). Also added JournalingOn.zip to revert back the two partitions to being journaled.
For the 00remount script, here's the how to:
0. Wait till Android finishes loading everything.
1. Install Script Manager from Market
2. Point script manager to the script you placed in the sdcard.
3. Run as root.
4. Do this at every boot, as mount points are reset to its default as set by the type of your lagfix. Voodoo (from what I am using will set barriers for /data and atime for every mount point except /system, /data, /cache, /dbdata which puts a slight risk at your disk for using atime.
5. You can add a widget to your home screen for the script so that you can
activate it easily.
First of all, thanks for the work.
I have tried to execute the remount-script using the script manager as root as you mentioned, but something fails. When running the script it outputs "mount: No such file or directory, mount: Invalid argument" and then the predefined echos of the script.
I had to remove following lines of code to get an output without the mount-errors:
mount -o noatime,remount,rw /mnt/.lfs /mnt/.lfs;
mount -o noatime,remount,rw /sys/kernel/debug /sys/kernel/debug;
Click to expand...
Click to collapse
more scripts and tweaks!
http://forum.xda-developers.com/showthread.php?t=1227269
reneph said:
First of all, thanks for the work.
I have tried to execute the remount-script using the script manager as root as you mentioned, but something fails. When running the script it outputs "mount: No such file or directory, mount: Invalid argument" and then the predefined echos of the script.
I had to remove following lines of code to get an output without the mount-errors:
Click to expand...
Click to collapse
Thanks for the heads up. I forgot to remove those lines actually. I reupload the script with those two lines remoevd.
sakindia123 said:
more scripts and tweaks!
http://forum.xda-developers.com/showthread.php?t=1227269
Click to expand...
Click to collapse
Thanks for the link. Yes, I've read this one before. My guide would explain more about what some of the tweaks do, and the script incorporates more than the link that you provided. You can edit the script and take a look if you want
is this working?
larry200ro said:
is this working?
Click to expand...
Click to collapse
Which tweak are you specifically asking about?
They should work provided you read the guide to know what those tweaks are
can i use this in my rom?thanks
sakindia123 said:
can i use this in my rom?thanks
Click to expand...
Click to collapse
Why not?
Let me know how good it is working for you. Remember to read the guide, as the scripts might not work well with other scripts (if your ROM also implements other scripts)
pikachu01 said:
Which tweak are you specifically asking about?
They should work provided you read the guide to know what those tweaks are
Click to expand...
Click to collapse
Honestly, I am at work now, I tried to read some things really quickly from your guide but I think that this is to technical for me. In a few words can you please describe what are they doing? I own a i9001 with Kernel 2.6.35.7-perf [email protected] #1 and build number gingerbread.xxkg1 android 2.3.3.
Sorry if my english is not to good, I am at work , have no time to concentrate, I am Romanian
larry200ro said:
Honestly, I am at work now, I tried to read some things really quickly from your guide but I think that this is to technical for me. In a few words can you please describe what are they doing? I own a i9001 with Kernel 2.6.35.7-perf [email protected] #1 and build number gingerbread.xxkg1 android 2.3.3.
Sorry if my english is not to good, I am at work , have no time to concentrate, I am Romanian
Click to expand...
Click to collapse
Umm, if you only want to use the scripts, you could scroll down to Zach's scripts and 00remount (Hint: They are in quoted text form). They are pretty short and simple to read. All the others in the guide would reinforce the things that are explained in there. If you don't understand something in the guide, post it here, and I'll offer up a simpler more laymen explanation of it
And you'll need a custom kernel with init.d support if you want to use the scripts.
pikachu01 said:
Umm, if you only want to use the scripts, you could scroll down to Zach's scripts and 00remount (Hint: They are in quoted text form). They are pretty short and simple to read. All the others in the guide would reinforce the things that are explained in there. If you don't understand something in the guide, post it here, and I'll offer up a simpler more laymen explanation of it
And you'll need a custom kernel with init.d support if you want to use the scripts.
Click to expand...
Click to collapse
Sorry but you lost me in the bold section. Where do I get a custom kernel with init.d support? I am searching for a month now for a custom kernel/custom rom/custom anything for my phone but found nothing than the successfull rooting guide in this forum.
Am I so stupid?
pikachu01 said:
And you'll need a custom kernel with init.d support if you want to use the scripts.
Click to expand...
Click to collapse
But not for the remount-script!?
Anyways, is there an existing custom kernel for the phone at all?
larry200ro said:
Sorry but you lost me in the bold section. Where do I get a custom kernel with init.d support? I am searching for a month now for a custom kernel/custom rom/custom anything for my phone but found nothing than the successfull rooting guide in this forum.
Am I so stupid?
Click to expand...
Click to collapse
Ahh, it appears that i9001 doesn't have a custom kernel If supercurio or chainfire is free, they could patch the initramfs with theirs and publish it here. I'm not an expert in initramfs and I don't have this phone
reneph said:
But not for the remount-script!?
Anyways, is there an existing custom kernel for the phone at all?
Click to expand...
Click to collapse
The remount script will always work, yes with Script Manager. No, I can see that i9001 doesn't have a custom kernel for it. Too bad
Actually, even without init.d support, you could use Script Manager to launch the scripts at boot. The only thing is that the screenstate_scaling would need the Script Manager to be on all the time, which will drain more battery than save it.
pikachu01 said:
Actually, even without init.d support, you could use Script Manager to launch the scripts at boot. The only thing is that the screenstate_scaling would need the Script Manager to be on all the time, which will drain more battery than save it.
Click to expand...
Click to collapse
So, you are saying that it's better not to use any scripts until a custom Kernel will appear?
larry200ro said:
So, you are saying that it's better not to use any scripts until a custom Kernel will appear?
Click to expand...
Click to collapse
You can use the scripts with Script Manager. A custom kernel only makes it easier to apply the scripts.
pikachu01 said:
You can use the scripts with Script Manager. A custom kernel only makes it easier to apply the scripts.
Click to expand...
Click to collapse
Ok, This I understood very well but, as you said before, this will need Script manager to be running all the time which will result in more battery spent.
Isn't the purpose of all tweaks/scripts to improve performance without lose of battery life and the phone to run the applications that you need and freeze/uninstall those you never use?(I've uninstalled the applications that I don't need with Titanium Backup and I have improved my battery life significantly).
Thanks very much pikachu for all the scripts and for the good work but I think this is not worth it because 1. galaxy s plus i9001 has a good 1.4Ghz processor and runs almost anything perfect. 2. You can safely improve the battery time with a simple software available on the market for free without risking with scripts.
Many thanks again, if you need any information from my phone for development purposes just let me know. I am willing to help
i want to create a rom for i9001..i have already started a thread for this.
and init.d will be one of the first things i would do!
all ur scripts will load automatically at startup!
Hi there,
I am fairly new to custom ROMs etc and recently installed LeeDroid 4.3.0 successfully. However, I also wanted to try out a custom ROM and installed Faux' kernel too (mainline).
Battery drain became a lot better, but there's an optional feature to under voltage the CPU. According to the guide in the thread, I have to put
Code:
echo "-25000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
somewhere. Can someone tell me in where I have to put this in detail? Any other things I should take care of / should be aware of?
If this topic was discussed already (sure it was), please don't hesitate to link me to it, I just couldn't find anything via forums search.
Thanks!
You can run it with a terminal emulator directly on your phone or through adb/shell on your pc.
Either way, it's not going to stick and you should repeat the operation after every reboot if you want to keep the UV.
You can add that line to a script, though, so that it is executed automatically after every boot.
I usually add that line to the init.post_boot.sh script in /system/etc (between the other MSN8660 tweaks). The alternative is adding a file in the init.d folder.
nTraum said:
Hi there,
I am fairly new to custom ROMs etc and recently installed LeeDroid 4.3.0 successfully. However, I also wanted to try out a custom ROM and installed Faux' kernel too (mainline).
Battery drain became a lot better, but there's an optional feature to under voltage the CPU. According to the guide in the thread, I have to put
Code:
echo "-25000" > /sys/devices/system/cpu/cpufreq/vdd_table/vdd_levels
somewhere. Can someone tell me in where I have to put this in detail? Any other things I should take care of / should be aware of?
If this topic was discussed already (sure it was), please don't hesitate to link me to it, I just couldn't find anything via forums search.
Thanks!
Click to expand...
Click to collapse
you could just get System Tuner Pro from the market and UV that way
Thanks, got it with Grandelama's method.
Grandelama said:
You can run it with a terminal emulator directly on your phone or through adb/shell on your pc.
Either way, it's not going to stick and you should repeat the operation after every reboot if you want to keep the UV.
You can add that line to a script, though, so that it is executed automatically after every boot.
I usually add that line to the init.post_boot.sh script in /system/etc (between the other MSN8660 tweaks). The alternative is adding a file in the init.d folder.
Click to expand...
Click to collapse
how did u put it in the init.post_boot.sh?
i cant do that cuz cannot write to that
and writing tool have super user permissions,
that file cannot be editing
or can? if - how?
Warning/disclaimer: This thread is intended for those who already know how to compile a kernel and have a working knowledge of Linux and its derivatives. There shouldn't be a great deal of risk involved, but you are responsible for what happens if you decide to follow these instructions.
Polite request: Please don't post replies to this thread that aren't of a technical nature directly related to compiling, modifying, or testing the kernel.
Introduction:
It appears as if Lenovo have released a buildable and bootable kernel source. I've done some preliminary testing with it. However, it would be better if we could get lots of people building and running the kernel, so that we can spot any remaining problems. This is also an opportunity to start hacking it to add/fix features such as USB OTG, etc.
Kernel source:
Get it from the Github repository at: https://github.com/gmarkall/lenovo_a1_07_kernel
Toolchain:
The Makefile seems to suggest that Codesourcery 2010q1 has been used by Lenovo to compile the kernel. Get it from https://sourcery.mentor.com/sgpp/lite/arm/portal/release1293, and make sure that the arm-none-linux-gnueabi-* binaries are on your path.
Building the source:
You may wish to edit the Makefile around line 192 to set CROSS_COMPILE=arm-none-linux-gnueabi- instead of the hardcoded path that is the default.
Then, to build the kernel:
Code:
make distclean
make a1_07_defconfig
make uImage
Booting the kernel
Normally, Android devices have two boot images that consist of a kernel and a ramdisk. One boot image is for the recovery, and the other is for the Android system. This makes it safe to flash a new boot image containing an untested kernel for the Android system, since the recovery can always boot up using the other boot image. However, the A1, by some bad design decision, only has one kernel - the bootloader always loads the same kernel, and just loads a different ramdisk depending whether it is to boot into recovery or system. As a result, it is not safe to flash a kernel to your A1 unless it's already been tested, since a bad kernel will make it impossible to boot from the internal memory, and you'll need a bootable SD card.
The solution to this problem is to make a bootable SD card for loading the kernel and ramdisk from. A bootable SD card consists of two partitions:
* A small bootable VFAT partition, that holds the X-Loader (MLO), U-Boot (u-boot.bin) and the kernel (uImage).
* An ext2 partition that holds the root filesystem.
In order to create a bootable SD card, use the omap3-mkcard.sh script that is attached below. To invoke it for making /dev/mmcblk0 a bootable SD card:
Code:
sudo omap3-mkcard.sh /dev/mmcblk0
You may need to hack the script if your SD card device isn't a /dev/mmcblk* one, since the script searches for partitions denoted "p1" and "p2" - this may need changing to just "1" and "2" respectively (thanks Xbdesign and Brancaleone for this).
This will create the necessary partitions, set the bootable flag, and format them. You will then need to mount the first partition (e.g. /dev/mmcblk0p1), and copy MLO and u-boot.bin to it (also linked below). Then, copy the uImage that you built from your kernel tree, which will be located in /arch/arm/boot. You can now unmount this partition.
Next, mount the second partition (e.g. /dev/mmcblk0p2). This will need to contain the same set of files that the initial ramdisk contains. There are two different ramdisks that you might want to use - one is from the Cyanogenmod 7 build, and the other one is from the stock system. Download links for these are also below. To extract the ramdisk, copy it onto the SD card second partition, then run the following commands (assuming the ramdisk is called ramdisk.ub):
Code:
dd if=ramdisk.ub of=ramdisk.img.gz bs=64 skip=1 # Strip off the U-Boot header
gunzip ramdisk.img.gz # Unzip
sudo cpio -idmv < ramdisk.img # Extract the cpio archive
Then, unmount the second partition of the SD card.
You should now be able to remove the SD card and insert it into your A1. Power down the A1 and power up again, and it should hopefully boot from the SD card and load your kernel. If it's booted from the SD card and loaded your kernel, you should be able to see that it was compiled on your host by looking in Settings -> About Phone -> Kernel Version.
Troubleshooting:
This is not a comprehensive guide, just a few pointers to where a problem might be - please post replies to the thread to get troubleshooting suggestions.
System boots up, but is not running my kernel - it didn't boot from the SD card. If the A1 is plugged into the charger/USB, you sometimes need to reboot multiple times before it boots off the SD card (I think it doesn't always turn off fully when the charger is plugged in).
The static Lenovo logo flashes up over and over again - it's booted from the SD card, but didn't manage to load your kernel
The static Lenovo logo comes up and stays there/goes to a black screen - it's probably loaded your kernel and mounted the root file system, but failed to mount /system. Try running adb shell to see what happens. If you get something like
Code:
/system/bin/sh: no such file or directory
then your kernel is running but /system isn't mounted.
IRC Channel
Join #ideapad-a1 on irc.freenode.net to discuss the kernel and other A1 development-related topics!
Download Links:
MLO
u-boot.bin
omap3-mkcard.sh
Ramdisk for Cyanogenmod 7
Ramdisk for ROW 2643 stock release
I've added the two ramdisks that I suspect will be most common - if you need another ramdisk, you'll have to extract it from an OTA.
Also, I compiled a tun.ko - www.doc.ic.ac.uk/~grm08/ideapad/tun.ko
Here's a cifs.ko - http://www.doc.ic.ac.uk/~grm08/ideapad/cifs.ko
EDIT: AutobahnA1 and infraredevans have confirmed that tun.ko works on ROW_2643.
EDIT 2/3: Please test out cifs.ko! (It doesn't work - it needs slow-work.ko. Will get that done when I can. Thanks to Ilikecokethree on the Lenovo forums for pointing that one out).
你懂中文吗,大神!
我是中国人 关注你的帖子很久了,我不懂英文,用翻译软件看的大概,我们这里很多人支持你,都在用你的rom 很棒!比联想官方的好多了,谢谢!
I think I did exactly the steps as you told, but it still boots the original kernel, may something be wrong? Thank you very much.
PS: I'm a chinese too, and my English is not good either
gmarkall said:
This is also an opportunity to start hacking it to add/fix features such as USB OTG, etc.
Click to expand...
Click to collapse
Please do not forget to try the WiFi-based geolocation, which is also missing!
I wish I had the knowledge to work on it myself but I am far from taking over such tasks...do not have the slightest idea about how these things work.
Good luck and please keep us informed!
geoponer said:
Please do not forget to try the WiFi-based geolocation, which is also missing!
Click to expand...
Click to collapse
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
betabox said:
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
Click to expand...
Click to collapse
Also, it's working in CM7.
hohoxu_hao115 said:
I think I did exactly the steps as you told, but it still boots the original kernel, may something be wrong?
Click to expand...
Click to collapse
Sounds like it's booting from eMMC instead.
Can you post the partition table of the SD card as listed by fdisk, and also a directory listing of each of the two partitions? I ask this to confirm what's happened - seems like you're the first person to follow these instructions, and it's quite possible I made a mistake somewhere.
betabox said:
Geolocation bug has nothing to do with kenerl. It's a missing entry in framework-res.apk in ROM from Lenovo
see : forums.lenovo.com/t5/IdeaPad-Slate-Tablets/A1-Geocode-Bug-in-Firmware-Solution/td-p/709701
Click to expand...
Click to collapse
Apologies for the off-topic, but I think that we are discussing two different things here: I am referring to the Geolocation bug, which prevents me from e.g. checking in with Foursquare by using only WiFi location information (active GPS signal is needed) while you have solved the Geocoding bug, which has nothing to do with the Geolocation one...
Please correct me if I am wrong.
@Graham: I plan to install the CM7 that you have been working on (with the feedback from other users - I keep an eye on that thread!) but since I use my A1 for professional purposes as well, I would like to make sure that everything is working fine before moving to CM7. Apologies for not being able to contribute to the beta testing of CM7 but I am really looking forward to seeing a version based on the source code provided by Lenovo, which I think will lead to a more stable version of your CM7. I cannot thank you enough for taking the time to work on this, really!
geoponer said:
Apologies for the off-topic, but I think that we are discussing two different things here: I am referring to the Geolocation bug, which prevents me from e.g. checking in with Foursquare by using only WiFi location information (active GPS signal is needed) while you have solved the Geocoding bug, which has nothing to do with the Geolocation one...
Please correct me if I am wrong.
Click to expand...
Click to collapse
I think that whether it works in CM7 or not, it almost certainly isn't a kernel issue. I'll test it by signing up for Foursquare and give it a try out on CM7 to see if it works later on. Will post my findings in the CM7 thread.
Hi Graham,
just gonna pile up several questions/thinkings and feel free to comment them the or answer on your liking
We do have few hickups on CM7 but I am more excited about idea of having proper recovery then ironing current CM rom that works more than satisfactory right now. Do we have enough code (I assume that target here is u-boot) on our hands that someone can implement necessary changes to internal partitions and boot procedures?
what is your opinion on replacement of u-boot with something else? for example LK loader or to be more precise with its current HD2 implementation known as cLK. it allready has some neat features like HBOOT like GUI, ability to change partition sizes on device itself (without computer), ability to boot from different partitions (would be nice to have android and ubuntu side by side loaded on our devices) and last but not least it has fastboot support enabled...or is it better way fill up u-boot with desired features if possible?
so...just my wishful thinking...not enough knowledge on my side to do anything regarding all this just hoping that some of you, more capable guys gets interested in this
dusko_m said:
Hi Graham,
just gonna pile up several questions/thinkings and feel free to comment them the or answer on your liking
We do have few hickups on CM7 but I am more excited about idea of having proper recovery then ironing current CM rom that works more than satisfactory right now. Do we have enough code (I assume that target here is u-boot) on our hands that someone can implement necessary changes to internal partitions and boot procedures?
what is your opinion on replacement of u-boot with something else? for example LK loader or to be more precise with its current HD2 implementation known as cLK. it allready has some neat features like HBOOT like GUI, ability to change partition sizes on device itself (without computer), ability to boot from different partitions (would be nice to have android and ubuntu side by side loaded on our devices) and last but not least it has fastboot support enabled...or is it better way fill up u-boot with desired features if possible?
so...just my wishful thinking...not enough knowledge on my side to do anything regarding all this just hoping that some of you, more capable guys gets interested in this
Click to expand...
Click to collapse
I do want to implement something that's pretty much as you describe. My biggest motivation is that it's currently not safe to flash a kernel since you can break both system and recovery that way in one go - I really want to make the boot process more robust.
gmarkall said:
Also, I compiled a tun.ko - tun.ko
I haven't tested it yet - is anyone able to try it please?
Click to expand...
Click to collapse
The module loaded without a problem on my 2643_ROW Kernel. Installed "Rooted AnyConnect" from the "Play Place". Now I can connect to my company VPN.
gmarkall: YOU ROCK! THANK YOU!!!
tun.ko
Graham
The tun.ko module works perfectly with openvpn on 2643_ROW.
I can now access my Amahi home server,awsome.
Thanks a lot you are doing a great job.
Dont want to sound presumptuous but any chance of a cifs.ko to go with it .
Cheers
Infraredevans said:
Dont want to sound presumptuous but any chance of a cifs.ko to go with it .
Click to expand...
Click to collapse
I'll give it a whirl... give me a few minutes.
gmarkall said:
I'll give it a whirl... give me a few minutes.
Click to expand...
Click to collapse
Here it is: http://www.doc.ic.ac.uk/~grm08/ideapad/cifs.ko
To compile it I had to copy md5.h from another kernel source to fs/cifs in the kernel tree. I also had to edit init/Kconfig so that CONFIG_SLOW_WORK defaulted to yes. I configured the module with the options:
Support Legacy LANMAN servers which use weaker security
CIFS Extended attributes
CIFS POSIX attributes
and without statistics, debugging, or experimental features. Let me know if this is a suitable config - I could always tweak it and build another one.
arm-2010q1-202-arm-none-linux-gnueabi.bin
Did someone manage to install arm-2010q1-202-arm-none-linux-gnueabi.bin on 64bit system?
xbdesign said:
Did someone manage to install arm-2010q1-202-arm-none-linux-gnueabi.bin on 64bit system?
Click to expand...
Click to collapse
I did - I didn't have any problems, but my random guess about how to solve it could be to install ia32-libs. If installing that doesn't solve it, can you post a bit more detail about the problem?
I am using ubuntu 10.04 LTS and just cant install / find Getlibs to install a 32-bit version of xulrunner :-(
xbdesign said:
I am using ubuntu 10.04 LTS and just cant install / find Getlibs to install a 32-bit version of xulrunner :-(
Click to expand...
Click to collapse
Do you need that to run the installer? I just downloaded the tar version instead and extracted it. I saw there was an installer as well, but I thought it would be more hassle than using the tarball so I just ignored it.