Related
This thread is for help and support related to ubuntu on the eeepad transformer, all questions not related to development should be asked here, please be friendly and do not flame each other or I will request the thread be closed.
Download links are in the third post.
There is a wiki entry here that has a bit more detailed explanation. Please note though that as it is a wiki information
quoted in there may or may not be entirely accurite.
you will need to download an nvflashable rom, like prime.
Please read the README before attempting this. The readme is below as well as in the kit, YOU WILL LOSE DATA.
Download links are in the second post.
OLiFE for the ASUS transformer
------------------------------------------------------------------
(c) 2011 Steven Barker <[email protected]>
This package should have only been linked to from xda-developers
or rootzwiki if you got the links to this package from anywhere
but those sites please send an email to the above email
address with the subject: "unauthorised posts"
DISCLAIMER
------------------------------------------------------------------
Steven Barker (lilstevie) nor anybody will take any responsibility
for any damage, data loss, fire, death of a loved one, or loss of
data resulting from using this mod for your device. Using this mod
may void your warranty.
NVFLASH
------------------------------------------------------------------
nvflash is the intellectual property of nvidia, and remains the
property of nvidia. Any questions or queries regarding the usage
and licence of nvflash should be directed to nvidia.
abootimg
------------------------------------------------------------------
abootimg is by Gilles Grandou <[email protected]> and is
unmodified. The source is available from online at
http://gitorious.org/ac100/abootimg
usage
------------------------------------------------------------------
Usage has changed since the release of the last kit, please read
these instructions carefully, as the install method is a little
more complex, (but easier once you use it).
If you downloaded OLiFE.tar.gz you will need to inject the android
rom and ubuntu image. You can use any nvflashable rom with this.
I recommend that you use prime as that is the configuration that
I have tested myself, and the ROM that I support for use with this
device. You can download the ubuntu image from
http://lilstevie.geek.nz/ports/ubuntu.img.gz.
If you downloaded OLiFE-Prime-Edition.tar.gz you will not need to
download the ubuntu image or an nvflash rom as they are seeded into
the image.
Install instructions:
1) Download the specific flavour of OLiFE that you want to use, and
extract it with "tar xvf <filename>".
2) If needed inject android rom and ubuntu image.
3) From the directory that OLiFE was extracted in run the main script
with the command ./OLiFE.sh.
4) Read the text that comes up and answer the question it asks.
5) Follow the menu to the option you want (below is a breakdown of
what each menu item is) and follow the instructions prompted. (also below
is instructions on how to get into the modes requested).
Menu items:
1) Backup Menu:
1) Full Backup (stock)
- Full backup (stock) takes a full backup of a stock
android system. This gives you an option to also back
up your user data(this will take a while).
2) Full Backup (ubuntu)
- Full backup (ubuntu) takes a full backup of a system
that dualboots android and ubuntu, this backs up your
system, and the ubuntu image. This gives you an option
to also back up your user data(this will take a while).
3) User data only
- This backs up the user data partition on your device.
(This option takes a while)
4) Android ROM
- This option backs up the android system only. This
option generates all the files (minus bootloader, and BCT)
required to flash a rom via nvflash.
5) Ubuntu Install
- This option backs up the ubuntu install on your device.
2) Flash Device:
1) Dualboot:
- This option will install ubuntu to your device in a
dualbooting configuration with android. During the
installation process it asks you which OS you would like
to boot by default.
2) uboot (linux only):
- This option will install ubuntu with u-boot and the
ChromeOS kernel that supports acceleration. This option
is currently unavailable, but should be available soon.
3) asus boot (linux only):
- This option will install ubuntu with the asus bootloader
with this configuration you will use all the eMMC for ubuntu
and there will be no android system installed on your device.
4) stock:
- This option will partition the device in a stock way and
install the android system that is in ./images. Use this
option if you no longer want ubuntu on your device.
3) Update Device:
1) Android Kernel:
- This option will update the android kernel on your device
with the boot.img from ./images/. This allows you to install
your own kernel on the device for android rather than the one
that comes with your chosen rom.
2) Ubuntu/Linux Kernel:
- This will update the ubuntu kernel on your device to the version
included in this flashkit. This option is for updating just the
kernel with nvflash rather than using the blob method. This method
is also good for if you flash a bad ubuntu kernel to the device.
3) Android ROM:
- This option will update the android rom on the device with the
one from ./images/. This is good for if the ROM you use is updated
or you would like to change ROMs and there is an nvflash image for it.
This option does not destroy your data.
4) Ubuntu Rootfs:
- This will update your ubuntu image on the device. This is destructive
to data stored in the ubuntu image.
5) Advanced (Unsupported):
- Any option in this menu is not supported and should be considered
unstable. There may be bugs in these options and they are not maintained
at this point in time.
1) Flash ChromeOS Kernel (Primary Boot):
- This option will flash the ChromeOS kernel to the primary boot
partition. This option may not currently work in it's current
configuration.
2) Flash ChromeOS Kernel (Secondary Boot):
- This option will flash the ChromeOS kernel to the secondary boot
partition. This option may not currently work in it's current
configuration.
3) Update Uboot Partition:
- This option will update the u-boot boot partition that u-boot
reads the kernel and boot script from. This option does work if
you have installed u-boot by compiling it from source and installed
it yourself.
4) Flash ClockworkRecoveryMod:
- This option allows you to temperarily flash CWR to the device so
you can update the installed rom. It backs up the current kernel in
the recovery kernel position and then flashes CWR. When you have finished
using CWR you then push any key and put the device back in APX mode and
it will restore the kernel that was in that position. (This only works if
android is your primary boot option at this time).
4) Inject Firmware:
1) Bluetooth firmware (default install):
- This option will inject the Bluetooth firmware from the
android ROM located at ./images/ in to the ubuntu of your
currently running system.
2) Bluetooth firmware (CrOS Kernel):
- This option will inject the Bluetooth firmware from the
android ROM located at ./images/ in to the ubuntu of your
currently running system and flashes the proper u-boot kernel
if you no longer need adb support.
5) Onscreen Keyboard:
- This runs OnBoard so that you can run through oem-config properly
you only need to use this option if you do not have a keyboard dock
and on the first boot.
1) Standard Kernel:
- This will invoke oem-config on the standard kernel installed
on the device.
2) ChromeOS Kernel:
- This will invoke oem-config on the u-boot kernel that is
installed on the device and flashes the proper u-boot kernel
if you no longer need adb support.
Device Modes:
APX Mode:
-This mode is used by nvflash to write files to the eMMC device.
To boot in this mode you press Power and Vol-Up.
Recovery Mode:
- This mode is where CWR or Asus recovery normally lives, but is
replaced by the secondary OS in the dualboot configuration.
To boot in this mode you press Power and Vol-Down, then Vol-Up when prompted.
Normal Boot:
-This mode is where android normally lives.
To boot in this mode you press the Power button until the screen turns on.
Changelog
------------------------------------------------------------------
1.2a - Release name: Odyssey
* New name for kit: OLiFE
* New menu system
* Updated README
* Better handling of platform detection
* Bluetooth support in ubuntu.img
* Preliminary support for ChromeOS kernel
* Preliminary support for uboot
* Fixed touchpad
* Fixed network manager
* Updated to ubuntu oneiric
* More options for flashing and updating
* OTB Wireless support (No more injecting)
* Smaller ubuntu.img for faster upload to device
* Auto resizing of rootfs on first boot
* Larger partition size (6GB) for ubuntu
* Refactored to more easily between devices
* Maybe something else I have missed
1.1 - Release name: Daedalus
* Firmware injector for BT and wifi firmwares
1.0 and silent updates - Release name: Prometheus
* Support for x86_64 linux distributions
* Updated README for release on xda-developers
* Fixes to install scripts
* Initial Release
Downloads:
RootFS md5sum(1a9fa8a698e4a96245a3c08511841eb4)
OLiFE md5sum(c30263fd8271a23bb211fd9fdd69fa45)
OLiFE Prime Edition md5sum(767779ccfa200e5e00b2f1e33a3d73a9)
Sources:
http://gitweb.lilstevie.geek.nz
To clone the repos "git clone git://lilstevie.geek.nz/$(name of repo).git"
lilstevie said:
This is running natively and from the eMMC so no µSD card required,
The video is a class2 µSD card and speeds are not an example of speeds from this kit.
Click to expand...
Click to collapse
Thanks for your hard work, but I'm a bit confused by those 2 statements, contradicting each other :/
Also, if I understood properly, there is no CWM after selecting dual boot
Finally, is this a final release, or for testing purpose only ?
If final, a step by step guide would be very welcome
Edit : Just saw there is the tag [DEV] so forget about my last question (guide)
Wow, amazing work here. Haven't been able to do much to my Transformer as of late (due to uni starting up again, and been seeing how the TF goes as a substitute for my usual netbook), but absolutely can't wait to try this out when I got some time.
And yeah, I'm a tad confused here as well. I'm assuming that you mean the video was of Ubuntu running of your microSD drive using Jhinta's scripts but now this allows us to run it off the internal drive... am I right?
And how is the speed difference so far, running off internal vs class 2 microSD?
EDIT: Also, I'm assuming the same things that didn't work on Jhinta's aren't working on this (network-manager gui, touchpad etc)? Or have you changed things up a bit? And the tegra ppa you talk about; that contain the proprietary 3D drivers you were talking about having a lack of in the video?
Nice to see the post in XDA Good work !
bud77 said:
Thanks for your hard work, but I'm a bit confused by those 2 statements, contradicting each other :/
Also, if I understood properly, there is no CWM after selecting dual boot
Click to expand...
Click to collapse
The video was taken before I was stable enough to even think about using internal memory, where as this kit is not using the µSD
and yeah you lose recovery after selecting dual boot, not much we can do about that for the time being.
poltak11 said:
Wow, amazing work here. Haven't been able to do much to my Transformer as of late (due to uni starting up again, and been seeing how the TF goes as a substitute for my usual netbook), but absolutely can't wait to try this out when I got some time.
And yeah, I'm a tad confused here as well. I'm assuming that you mean the video was of Ubuntu running of your microSD drive using Jhinta's scripts but now this allows us to run it off the internal drive... am I right?
And how is the speed difference so far, running off internal vs class 2 microSD?
EDIT: Also, I'm assuming the same things that didn't work on Jhinta's aren't working on this (network-manager gui, touchpad etc)? Or have you changed things up a bit? And the tegra ppa you talk about; that contain the proprietary 3D drivers you were talking about having a lack of in the video?
Click to expand...
Click to collapse
I started back at uni this week myself, and have been using my transformer as a netbook replacement with ubuntu. The video is using my stuff but before I had it running on the internal memory.
speed diference is massive between the class2 and internal. It was so great of a difference that I forget that it is arm now that it is on internal
the PPA will have things such as kernel updates, bluetooth enabler and all that. as for what is working in the release, things are pretty similar to Jhintas release, touchpad does not work correctly network manager gui doesn't work, I have something to enable bluetooth, that works nicely, but it isn't in the fs or up on the ppa yet. 3D drivers are a work in progress, still no EGL and the likes with the L4T releases, so it is really just acceleration for normal use, I have been working on them but as of yet no dice.
So using the PPA, in theory we won't have to flash the device again (at least for the ubuntu part), it will be able to auto-update itself ?
ErGo_404 said:
So using the PPA, in theory we won't have to flash the device again (at least for the ubuntu part), it will be able to auto-update itself ?
Click to expand...
Click to collapse
yes, that is the plan anyway
lilstevie said:
the PPA will have things such as kernel updates, bluetooth enabler and all that. as for what is working in the release, things are pretty similar to Jhintas release, touchpad does not work correctly network manager gui doesn't work, I have something to enable bluetooth, that works nicely, but it isn't in the fs or up on the ppa yet. 3D drivers are a work in progress, still no EGL and the likes with the L4T releases, so it is really just acceleration for normal use, I have been working on them but as of yet no dice.
Click to expand...
Click to collapse
Ah lovely idea with the PPA. When new 3.2 based Prime gets released, I'll try to get a few hours to myself to get this all working together.
Just a few quick questions first:
How do your scripts change the eMMC layout? Does eMMC work the same as a standard HDD/SSD partitioned with a GPT? As in, have you made separate partitions for Android and Ubuntu, or is it somehow shared?
And also related, how much room will it take up on the eMMC (as I've only got a 16GB TF)?
And finally, since you've been using yours at uni running Ubuntu, have you got any idea of the battery life running Ubuntu? I'm assuming it'd be pretty similar to stock, but yeah the battery indicator wasn't working last time I was playing around with Ubuntu from the microSD. Also, does the second keyboard battery work?
poltak11 said:
Ah lovely idea with the PPA. When new 3.2 based Prime gets released, I'll try to get a few hours to myself to get this all working together.
Just a few quick questions first:
How do your scripts change the eMMC layout? Does eMMC work the same as a standard HDD/SSD partitioned with a GPT? As in, have you made separate partitions for Android and Ubuntu, or is it somehow shared?
And also related, how much room will it take up on the eMMC (as I've only got a 16GB TF)?
And finally, since you've been using yours at uni running Ubuntu, have you got any idea of the battery life running Ubuntu? I'm assuming it'd be pretty similar to stock, but yeah the battery indicator wasn't working last time I was playing around with Ubuntu from the microSD. Also, does the second keyboard battery work?
Click to expand...
Click to collapse
The second battery does work, unless you get one of those dodged ones that just randomly stops charging which happened to me, with the dock connected and the battery in it refusing to charge my battery lasted 6 hours.
the layout is different to standard, UDA(User DAta partition) is 4.2GB smaller than what it was, so you have 9.99gb for android and 4.2 for ubuntu, the kernel and recovery kernels are moved up to the end of the flash as well so that they are accessible through /dev
Just finished installing it. Yea, from internal memory it's working much faster. ~20 second boot time!(I didn't have timer with me, so I counted in the head) That's like my laptop with SSD + 10 second bios booting. With a dock it feels like a true netbook. I think I'll even dare to test c/c++ IDE on this thing. Good job!
Used online timer. It's 21 seconds.
Hmm how do I start wifi? eth0 is not even showing in the list of devices.
aligatro2010 said:
Just finished installing it. Yea, from internal memory it's working much faster. ~20 second boot time!(I didn't have timer with me, so I counted in the head) That's like my laptop with SSD + 10 second bios booting. With a dock it feels like a true netbook. I think I'll even dare to test c/c++ IDE on this thing.
Used online timer. It's 21 seconds.
Hmm how do I start wifi? eth0 is not even showing in the list of devices.
Click to expand...
Click to collapse
Sorry forgot to mention in the first post, firmwares are not included in this release due to potential licensing issues, you can push the wifi firmware via adb to /lib/firmware and also the nvram, they are located in /system/vendor/fw_bcm4329.bin and /system/etc/nvram.txt on your android system, the module will autoload on boot once you have the firmware in place, and the interface will be named wlan0
lilstevie said:
Sorry forgot to mention in the first post, firmwares are not included in this release due to potential licensing issues, you can push the wifi firmware via adb to /lib/firmware and also the nvram, they are located in /system/vendor/fw_bcm4329.bin and /system/etc/nvram.txt on your android system, the module will autoload on boot once you have the firmware in place, and the interface will be named wlan0
Click to expand...
Click to collapse
nvram.txt to /etc right? I copied them straight from android partition, but it still doesn't load. Could it be because of the bcm4329_sta.bin or nvram should be placed in /lib/firmware ?
It works now.
So basically we will be able to dual boot Windows 7 and Android?
liorry said:
So basically we will be able to dual boot Windows 7 and Android?
Click to expand...
Click to collapse
No, Windows 7 doesn't have arm version. Windows 8 maybe in future, long future ....
aligatro2010 said:
nvram.txt to /etc right? I copied them straight from android partition, but it still doesn't load. Could it be because of the bcm4329_sta.bin or nvram should be placed in /lib/firmware ?
It works now.
Click to expand...
Click to collapse
the wifi firmware should be called fw_bcm4329.bin and nvram.txt should be in /lib/firmware, I probably should have been a little clearer, but I posted that just before going to bed, and was a little tired
lilstevie said:
the wifi firmware should be called fw_bcm4329.bin and nvram.txt should be in /lib/firmware, I probably should have been a little clearer, but I posted that just before going to bed, and was a little tired
Click to expand...
Click to collapse
"bcm4329_sta.bin" was already there before I even copied 2 modules and it was also loaded as module when I did modprobe. (not 100% sure about the second)That's why I thought it was conflicting with android's modules.
Wow, great work! Can't wait to try it.
Sent from my Transformer TF101 using XDA Premium App
I've probably missed something obvious.. But I get this.
file not found: linux.img
failed executing command 2147483647 NvError 0x4
command failure: create failed
rm: cannot remove `linux.img': No such file or directory
Click to expand...
Click to collapse
After like 5 minutes of NvFlash installing stuff.
11/6/11 Update: Added statically-linked kexec to kexec_patches.tar.gz and example update.zips. Now works in stock recovery and CM7 CWM (with a kexec-patched kernel).
10/19/11 Update: Added patches for the recently released GB sources to kexec_patches.tar.gz.
Attached is a set of patches (kexec_patches.tar.gz) against EC05, and the recently released GB sources, to implement kexec syscall support in the Epic's kernel. kexec enables the booting of kernels "directly" from the SD card or over USB without having to flash them to the device first. This allows us to easily use, test, and switch between many kernels, not just the one (two with recovery) there's room for on flash.
When used in conjuction with modified init.rc scripts, this allows entire ROMs (with their own kernels) to run from SD card. In short, this allows us to run custom-kernel ROMs (e.g,. CyanogenMod) alongside each other or a stock kernel without having to flash back and forth.
Also attached is a modified version of the kexec userspace tool (also in kexec_patches.tar.gz, along with source and patches) that facilitates the proces of loading and kexecing a kernel image. Finally, attached is a demo EC05 kernel with kexec enabled (demo_kernel.tar.gz; mostly stock: RFS support only, testkeys recovery w/adbd, but does inlcude the keyboard patches), example update.zips that kexec an SD-card kernel from recovery--either as a normal boot (boot_zImage.zip) or recovery boot (boot_zImage_recovery.zip), and a script (patch_decomp_cachebufram.sh) to binary patch unmodified kernels to kexec boot faster.
Note, this thread is primarilly intended for kernel developers. Kexec probably won't be of great utility to end users until commonly-used kernels are patched. Also, although stock kernels can be kexec'd, they need some init.rc modifications boot an entire ROM from SD card. Hopefully the fine folks here will come up with a user-friendly implementation of this work that's easy for everyone to use.
Instructions:
Flash a kexec-enabled kernel (e.g., the attached demo kernel) to either /dev/block/bml7 or /dev/block/bml8. For testing purposes, this kernel needs either "ro.secure=0" or "ro.debuggable=1" set in default.prop, and also needs recovery.rc/fota.rc modified to spawn the adbd service, so that an adb root shell is available while in recovery. Also copy the attached kexec tool to a convenient location on the device (e.g., /data/local/tmp/kexec).
Reboot into recovery. If the kexec kernel is installed to bml7, run "adb reboot recovery" while the phone is running. If installed to bml8, power down and boot into recovery by holding the volume-down, camera, and power buttons.
Make sure adb is running as root. If it's not, try running "adb root".
Find the kernel (zImage) you wish to boot. These can be extracted from a kernel update.zip or Odin .tar file, or use the demo kernel again.
Push the zImage into RAM (tmpfs) with:
Code:
adb push zImage /tmp
Now, open an adb root shell with "adb shell" and run the commands:
Code:
mount -ro remount /dev/block/stl6 /mnt/.lfs
mount -ro remount /dev/block/stl9 /system
mount -ro remount /dev/block/stl10 /data
mount -ro remount /dev/block/stl11 /cache
/data/local/tmp/kexec --load-hardboot --mem-min=0x50000000 --append="console=ttySAC2,115200 loglevel=4" /tmp/zImage
sync
/data/local/tmp/kexec -e
after which the phone will reboot, show the SAMSUNG logo, and eventually boot the kexec'd kernel. Do note that when booting unmodified kernels (see below), the SAMSUNG logo will persist for ~30 seconds longer than usual.
Also note that kexec performs an "abrupt" reboot, i.e., it doesn't shutdown the system normally. Hence it's important to kexec from recovery where few services are running. It's also prudent to remount file systems read-only and sync them to avoid any potential (although unlikely) of corruption.
In the future, kexec could be better integrated into the Android framework to allow for a clean shutdown. Otherwise, probably the best way to deploy kexec is through an update.zip file that boots a kernel from the SD card. See the attached example update.zips.
Technical details:
kexec is feature of Linux that allows it to directly execute (boot) a new kernel in place of itself, allowing Linux to effectively serve as its own bootloader.
The kexec procedure is two step. The first "kexec" command loads a zImage from disk, constructs parameters (e.g., the kernel command line), and stages it in memory, after which Linux continues to run as normal. The second "kexec" command tells Linux to execute (boot) the staged kernel.
In the standard implementation, Linux "soft boots" kexec'd kernels. That is, on "kexec -e" the running instance of Linux shuts-down all devices, drivers, and goes through the process of unloading itself as it does during a normal reboot. However, instead of invoking a hardware reboot, Linux, at the final stage of unloading itself, jumps to start executing the new kernel.
This soft boot process requires that Linux hardware drivers are fully capable of unloading, reloading, and reinitializing the associated hardware without hardware-reboot or bootloader assistance. Since, for many built-in drivers, this capability is only used by kexec, hardware is often left in an unexpected or unknown state on unload, and thus the kexec'd kernel hangs on boot. Unfortunately this is the case with the Epic kernel, and soft booting doesn't work.
To work around this, the attached patches implement a "hard boot" method for kexecing kernels. Here, we use kexec to stage a kernel in memory as usual. On "kexec -e", Linux shuts-down as before, and at the very end of the unloading process it does two things: (i) scribble some information on how to boot the kexec'd kernel to a "special place" in memory, and (ii) performs a hardware reboot, invoking the Epic bootloader as a normal reboot does.
On reboot, the bootloader loads the (previously-running) bml7 or bml8 kernel and starts executing it. Here, the hardboot patch modifies the Linux the zImage decompressor code to check the "special place" in memory to see if we're actually kexecing a different kernel. If so, it switches over to the other kernel, already staged elsewhere in memory.
Known Issues:
Kernel Command Line:
Kexec (via hardboot) can boot stock or non-kexec-modified custom kernels. However, unless the copy_atags patch is applied, they can only use the kernel command line provided by the bootloader, as opposed to the custom command line provided by kexec. Although this isn't a problem when kexecing from a bml7 boot kernel, kexecing from a bml8 kernel runs recovery (fota.rc) instead of a normal boot (init.rc).
With the copy_atags patch, the command line for the kexec'd kernel must be provided by with kexec's --append option. These are the command lines provided by the bootloader in normal boot and recovery scenarios, any of which may be used:
Code:
Normal boot (init.rc):
console=ttySAC2,115200 loglevel=4
"adb reboot recovery" (recovery.rc):
bootmode=2 console=ttySAC2,115200 loglevel=4
Three-finger recovery boot (fota.rc):
bootmode=3 console=ttySAC2,115200 loglevel=4
Slow Booting:
Kexec booting of a stock or non-kexec-modified custom kernel is known take significantly longer than a regular boot, sitting at the SAMSUNG logo for 35 seconds instead of 8. The decomp_cachebufram patch resolves this issue for modified kernels. In addition, the attached patch_decomp_cachebufram.sh script will binary patch the decompressor code for any (to my knowledge) Epic kernel.
Many more details on the patches themselves are in the accompanying READMEs.
Mirror links:
Kernel & kexec-tools patches: kexec_patches.tar.gz
Kexec EC05 demonstration kernel: demo_kernel.tar.gz
Recovery script to boot /sdcard/zImage (normal boot): boot_zImage.zip
Recovery script to boot /sdcard/zImage (recovery boot): boot_zImage_recovery.zip
Script to binary patch decompressor code: patch_decomp_cachebufram.sh
Is this different in function than rodderik's dual boot support?
I know his didn't include usb booting support, but sdcard booting appears to be the same...although this seems a little cleaner, possibly
Sent from my SPH-D700 using xda premium
squshy 7 said:
Is this different in function than rodderik's dual boot support?
I know his didn't include usb booting support, but sdcard booting appears to be the same...although this seems a little cleaner, possibly
Sent from my SPH-D700 using xda premium
Click to expand...
Click to collapse
His uses a modified init, which then choses to load which init.rc, the one names init.rc.sdcard or normal init.rc. This (kexec method) reminds me A LOT like how they ran linux/android on winmo devices...it shuts down android and then runs the kernel they want (if I read correctly).
squshy 7 said:
Is this different in function than rodderik's dual boot support?
I know his didn't include usb booting support, but sdcard booting appears to be the same...although this seems a little cleaner, possibly
Sent from my SPH-D700 using xda premium
Click to expand...
Click to collapse
Yes. The genocide implementation allows a ROM to boot from the sd card as long as the kernel on the main ROM supports the sd ROM. this means you cannot dual boot a gingerbread and a froyo ROM because the need different kernels .
With this patch that limitation is removed as the sd based ROM can use its own separate kernel. This you may run stock ec05 and keep cyanogen or a gingerbread on the sd card to test and play with.
Great work mkasick
Sent from my SPH-D700 using Tapatalk
I was never interested in the dual boot feature since that was ROM's only and itwas limited by kernel support.
But now this really interest me, can't wait till we see some developers take advantage of this.
Sent from my SPH-D700 using xda premium
All I have to say is hope you stick with the epic your amazing
Sent from my SPH-D700 using Tapatalk
Yes, this is complementary to Rodderik's dual boot. Kexec allows one to load a different kernel, but it still defaults to booting the ROM stored in flash. Which is great for kernel testing, but not of much use otherwise.
It's easy enough to modify a kernel to load a ROM only from SD, but then we'll start seeing a divide between "bml kernels" and "SD kernels", when really it'd be nice to have init scripts that support both. That's where Rodderik's work comes in.
Probably the best is to have a kernel command line parameter that specifies where the ROM is located, so it can be passed in. Something like "console=ttySAC2,115200 loglevel=4 systemfs=mmcblk0p2 datafs=mmcblk0p3 cachefs=mmcblk0p4". These would default to stl9, stl10, stl11 respectively if unspecified. The kernel command line is available to init through "/proc/cmdline", and it's easy enough to parse in a shell script.
But yes, keeping a working ROM on flash while testing/debugging CyanogenMod was my primary motivation, since I need a working phone "during the day" and can't touch CyanogenMod otherwise.
formula84 said:
All I have to say is hope you stick with the epic your amazing
Click to expand...
Click to collapse
Thanks!
I'm much of a year out on a full upgrade, and I'm not considering a new device sooner as long as my Epic still works.
Edit: An obvoius limitation is modem compatibility. I've avoided the GB leaks thus far, so I'm not sure what's the status with that. But if GB supports the EC05 modem, then you can dual boot EC05 and GB-whatever. Same if EC05 supports newer modems.
Speaking of which, anyone know what GB modem compatibilty is like?
mkasick said:
Yes, this is complementary to Rodderik's dual boot. Kexec allows one to load a different kernel, but it still defaults to booting the ROM stored in flash. Which is great for kernel testing, but not of much use otherwise.
It's easy enough to modify a kernel to load a ROM only from SD, but then we'll start seeing a divide between "bml kernels" and "SD kernels", when really it'd be nice to have init scripts that support both. That's where Rodderik's work comes in.
Probably the best is to have a kernel command line parameter that specifies where the ROM is located, so it can be passed in. Something like "console=ttySAC2,115200 loglevel=4 systemfs=mmcblk0p2 datafs=mmcblk0p3 cachefs=mmcblk0p4". These would default to stl9, stl10, stl11 respectively if unspecified. The kernel command line is available to init through "/proc/cmdline", and it's easy enough to parse in a shell script.
But yes, keeping a working ROM on flash while testing/debugging CyanogenMod was my primary motivation, since I need a working phone "during the day" and can't touch CyanogenMod otherwise.
Thanks!
I'm much of a year out on a full upgrade, and I'm not considering a new device sooner as long as my Epic still works.
Edit: An obvoius limitation is modem compatibility. I've avoided the GB leaks thus far, so I'm not sure what's the status with that. But if GB supports the EC05 modem, then you can dual boot EC05 and GB-whatever. Same if EC05 supports newer modems.
Speaking of which, anyone know what GB modem compatibilty is like?
Click to expand...
Click to collapse
As far as I know, and from experience, modems are a free for all except for bonsai. Ec05 modem works on gb, leaked modems work on ec05.
this is definitely very cool, thanks mkasick!
Sent from my SPH-D700 using XDA Premium App
mkasick you never cease to amaze me...i'll definately play with this, this week if i have the time!
Rodderik said:
mkasick you never cease to amaze me...i'll definately play with this, this week if i have the time!
Click to expand...
Click to collapse
Great!
If you run into something not particularly straight forward, or think there's something I can clarify, please ask. I've been playing around with this long enough that I fear I might've overlooked documenting a detail or two that would be helpful for others.
So to patch any kernel u just point the script to the zImage?
sent from my epic 4g. with the key skips.
ugothakd said:
So to patch any kernel u just point the script to the zImage?
Click to expand...
Click to collapse
The script only implements one patch, it allows any kernel to boot ~30 seconds faster when kexec'd.
But yes, "./patch_decomp_cachebufram.sh zImage" modifies that zImage to boot faster. It requires the xxd hexdump tool that's packaged with vim.
Kexec support itself, along with the slew of other source patches, has to be applied to a kernel source tree, from which a new kernel must be built to take advantage of them.
mkasick said:
The script only implements one patch, it allows any kernel to boot ~30 seconds faster when kexec'd.
But yes, "./patch_decomp_cachebufram.sh zImage" modifies that zImage to boot faster. It requires the xxd hexdump tool that's packaged with vim.
Kexec support itself, along with the slew of other source patches, has to be applied to a kernel source tree, from which a new kernel must be built to take advantage of them.
Click to expand...
Click to collapse
I see...so its a no-go for gb. Or at least quick gingerbread.
sent from my epic 4g. with the key skips.
ugothakd said:
I see...so its a no-go for gb. Or at least quick gingerbread.
Click to expand...
Click to collapse
You should be able to kexec a GB kernel, but you'd need an EC05-ish /system on flash to boot recovery. Unless GB recovery is compatible with Froyo kernels.
If you're going to boot a GB kernel, you'd probably want to repackage the initramfs with an init.rc that loads the rest of the GB ROM off SD. It's actually not a bad way to keep EC05 around for a stable, working phone, and to test GB leaks as they happen. Which, hopefully, shouldn't be much longer.
wow mkasick, you never cease to amaze me bro...
I wish I wasn't working so many damned hours now, with your patches, I really want the dual boot now. Like you, the need for a working phone at all times is what keeps me from flashing more ROMs, including EpicCM and the gb leaks...
I hope Rodderik figures this out pretty quickly, as most of my dev time is spent on the IRC channels, and he's usually around to help and answer questions.
Once I can get my Clean Kernel working with this, I'll be stoked... I have had a tough time dealing with patches thus far, I usually git cherry-pick and/or manually edit, so I need to figure out how to use the patches correctly.
Anyways, gotta go to work now (I'm working 50+ hour weeks now, hence the time constraints), but hopefully I can get the time to get it into my kernel.
Thanks, mkasick!
Sent from my Samsung Epic4G
DRockstar said:
I have had a tough time dealing with patches thus far, I usually git cherry-pick and/or manually edit, so I need to figure out how to use the patches correctly.
Click to expand...
Click to collapse
What environment (OS, etc.) are you using? Is the "patch" utility working for you?
The patches are split up based on functionality. In each patch directory there's a "series" file that lists the order they should be applied. There's a program, quilt that can help manage them but it's not necessary. If you're running a bourne shell (e.g., bash) in the "Kernel" directory of the kernel sources, you should be able to apply the patches with:
Code:
while read i; do patch -p 1 < "/path/to/kexec_patches/kernel-EC05/$i"; done < "/path/to/kexec_patches/kernel-EC05/series"
Whether they'll apply cleanly or not is a different story, but that's the general idea.
And yeah, time ....
Thank you mkasick, that's a great explanation, I think I can handle that, much appreciated!
For the record, I compile by ssh into dev boxes donated for dev use. They all run linux in different distros. I find this most convenient since I can do most everything from the command line using your brilliant connectbot for epic
Sent from my Samsung Epic4G
With those recovery scripts, doesn't Clockwork Mod have to have kexec set up?
ugothakd said:
With those recovery scripts, doesn't Clockwork Mod have to have kexec set up?
Click to expand...
Click to collapse
You mean for boot_zImage_recovery.zip to work?
The CWM kernel doesn't need full kexec support in order to be booted via kexec. But it does need the copy_atags patch in order to respect the "bootmode=3" kernel argument.
Actually, you can take any existing Epic kernel and somewhat-easily fix it to be bootable via kexec. Steps are:
1. Extract EC05 kernel sources. Or use the GB sources, it doesn't matter, it doesn't even have to match the version of the kernel you're fixing.
2. Apply "decomp_cachebufram" and "decomp_copy_atags" patches.
3. Build a kernel. Config options don't matter much since this kernel is going to be thrown away.
4. Find the zImage for the kernel you want to fix. Run:
Code:
skip=`grep -Fabom 1 $'\x1f\x8b\x08' zImage | head -n 1 | cut -d : -f 1`
dd if=zImage bs=1 skip="$skip" | gunzip > Image
cp Image arch/arm/boot/Image
which extracts the decompressed kernel payload from the zImage, and replaces the "Image" that was previously built with the one you've extracted.
5. Run "make" in the kernel source directory again. You might have to append a "CROSS_COMPILE=" path to match the one used in a build script. The output should be:
Code:
CHK include/linux/version.h
make[1]: `include/asm-arm/mach-types.h' is up to date.
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-arm
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
Kernel: arch/arm/boot/Image is ready
GZIP arch/arm/boot/compressed/piggy.gz
AS arch/arm/boot/compressed/piggy.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
Building modules, stage 2.
MODPOST 13 modules
which shows that the build process took the existing, extracted Image, compressed it, and attached a new kexec-compatible decompressor to it.
The resulting "arch/arm/boot/zImage" can be kexec'd, and command line arguments should be respected, e.g., if you want to boot into CWM recovery.
this is a work-in-progress development project for porting ClockworkMod Recovery 5 to Ingenic JZ4770/JZ4760 tablets.
this is not perfect at all. and I'm very busy. progress will be very very slow. I may not be able to answer your question/request. if you have some idea for improvement, please do it freely.
there is no support from any makers/vendors. you must agree all risks by installing non-supported files, it may brick your tablet, and you may lose official support/warranty.
* YOU MUST READ CAREFULLY POST#1, #2, AND #3!
* DO NOT USE IF YOUR TABLET IS NOT LISTED BELOW. IT WILL BRICK YOUR TABLET!
* project page
http://androtab.info/mips/ingenic/clockworkmod/
* supported tablets
ainol NOVO7 Basic and Paladin
Velocity Micro Cruz T100 series (Android 2.2 updated model and Android 2.0 PT701i model)
Velocity Micro Cruz T301
ronzi A3
* changelog
refer git log
* resources
http://developer.mips.com/android/
https://github.com/naobsd/cm_bootable_recovery/compare/ics...ics-mips-naobsd
https://github.com/naobsd/mips_build/compare/mips-ics-mr1...mips-ics-clockworkmod
https://github.com/naobsd/mips_external-busybox/compare/ics...ics-mips
* How to install ClockworkMod Recovery 5 (for ainol NOVO7 Basic/Paladin, Cruz T100 series, Cruz T301)
1. download recovery-signed.zip for your tablet (DO NOT USE FILES FOR OTHER TABLETS!)
2. (if you are using stock recovery)rename it to update.zip, then put it on root of SD card
3. install update.zip from recovery
on stock recovery, update.zip will be installed automatically. on ClockworkMod Recovery, you need to select menu item manually.
* How to install ClockworkMod Recovery 5 (for ronzi A3)
1. download recovery.zip for your tablet (DO NOT USE FILES FOR OTHER TABLETS!), then extract recovery.cpio.img from it
2. make backup of stock recovery
Code:
adb remount
adb shell mv /system/recovery.cpio.img /system/recovery.cpio.img.bak
3. copy recovery.cpio.img into your tablet, then flash it
Code:
adb shell inand_flash_image recovery recovery.cpio.img
* How to boot recovery
push & hold VOL+ while power on
* How to boot recovery (alternative)
Code:
adb reboot recovery
*How to control ClockworkMod Recovery 5
VOL-/HOME: down, VOL+: up, POWER/MENU: select, BACK: back
* Superuser, su, and busybox
it can be installed from ClockworkMod Recovery 5
- Superuser, su, and busybox for JZ4770 ICS
- Superuser, su, and busybox for JZ4760 Froyo
* random notes
- stock recovery
if you installed update.zip from stock recovery, stock recovery image should be renamed as /system/recovery.cpio.img.bak. (unless you didn't remove /system/recovery.cpio.img)
it can be flashed by "inand_flash_image" command. (use "flash_image" command for T100 series except PT701i model)
- mbr, xboot, boot, and recovery areas
backup/restore doesn't work for mbr, xboot, boot, and recovery areas
- time for reboot/poweroff (NOVO7 Basic)
I don't know why but reboot/poweroff take long time (as same as stock rom). you should wait 1 minute. if nothing is happened in 10 minutes, use reset hole
for now I'm preparing to push my changes to github. I'm very busy so it needs some time.
if you made some.zip file to do something for MIPS Android (e.g. superuser.apk with su binary for MIPS), please tell me. I'll add link to post#1.
if you have some idea for next work, please tell me too. (but, as I wrote, I may not be able to answer your request. sorry)
Thanks for your starting thread and project.
I bought a Advanced model but they send us a Basic Novo7.
All we know the incompatibilites using a cpu MIPS, that doesnt allow to run a lot of Android software that for default its compiled for ARM processors.
Im getting a bundle pack of apps running under our device.
Kashamalaga said:
Thanks for your starting thread and project.
I bought a Advanced model but they send us a Basic Novo7.
All we know the incompatibilites using a cpu MIPS, that doesnt allow to run a lot of Android software that for default its compiled for ARM processors.
Im getting a bundle pack of apps running under our device.
Click to expand...
Click to collapse
thank you. I understand your condition.
but here is dev thread for clockworkmod for novo7 basic. if you want to talk about apps which support mips android and/or any general things about novo7b, I recommend you to make new thread for it.
fun_ said:
thank you. I understand your condition.
but here is dev thread for clockworkmod for novo7 basic. if you want to talk about apps which support mips android and/or any general things about novo7b, I recommend you to make new thread for it.
Click to expand...
Click to collapse
I will do as you said
This is great news. If you are wanting to test any work with users on Velocity Cruz t301's which also run an ingenic processor (JZ4760) .
UPDATE: Tried running CWM for the hell of it on the t301 . Stuck at boot screen was able to get back to original recovery however. I'm guessing it might be due to the entry point into the kernel . Since the t301 is ancient Froyo. Would love to take a look at the source
Also here SHOULD be a working SU for MIPs. It work's on the cruz tablets
vanduhl said:
This is great news. If you are wanting to test any work with users on Velocity Cruz t301's which also run an ingenic processor (JZ4760) .
UPDATE: Tried running CWM for the hell of it on the t301 . Stuck at boot screen was able to get back to original recovery however. I'm guessing it might be due to the entry point into the kernel . Since the t301 is ancient Froyo. Would love to take a look at the source
Click to expand...
Click to collapse
I couldn't read what you did exactly. if you flashed my image w/o modification, it must not work. as I wrote, DO NOT USE file for other tablet.
please explain what you did, and please explain detail about your tablet before any random work.
fun_ said:
I couldn't read what you did exactly. if you flashed my image w/o modification, it must not work. as I wrote, DO NOT USE file for other tablet.
please explain what you did, and please explain detail about your tablet before any random work.
Click to expand...
Click to collapse
Attempted using the above stated method(understanding you said DO NOT US file on other tablet) I was curious to see as what kind of error would or may of come up. I'm interested in modifying this for the Velocity Cruz T301 tablet(running a JZ4760 processor) as that community of tablet users has been left under the dust. Now with the novo coming out it will further pile under the dust. I have not yet made any modifications to it, although I would very much like to.
vanduhl said:
Attempted using the above stated method(understanding you said DO NOT US file on other tablet) I was curious to see as what kind of error would or may of come up.
Click to expand...
Click to collapse
kernel must not work because it's for NOVO7B. in general, kernel can't be shared among different products.
key assign, and partition layout may be different too. but currently I have no idea how to fix them because I don't have any detail about your tablet...
http://en.ingenic.cn/product.aspx
it seems JZ4760 is NOT MIPS32R2. then I need to recompile userland binaries.
anyway, technical detail is required to support other tablets.
http://bbs.imp3.net/thread-10520163-1-2.html
it seems source code for xboot, android 2.2 and (part of?)kernel source for NOVO7B is released. I don't try to compile them yet so I may be wrong.
I'll check them later.
Is it possible that someday this recovery will be also ported for ainol novo7 Advanced ?
endrju100 said:
Is it possible that someday this recovery will be also ported for ainol novo7 Advanced ?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1378594
you should use search engine before post a question.
vanduhl said:
This is great news. If you are wanting to test any work with users on Velocity Cruz t301's which also run an ingenic processor (JZ4760) .
UPDATE: Tried running CWM for the hell of it on the t301 . Stuck at boot screen was able to get back to original recovery however. I'm guessing it might be due to the entry point into the kernel . Since the t301 is ancient Froyo. Would love to take a look at the source
Click to expand...
Click to collapse
How did you get back to your stock recovery image on the T301? I think I borked mines on a T105 accidentally with ROM Manager. I accidentally pressed the screen too many times while 'exploring' and the delayed input caused ROM Manager to start flashing a recovery. Now I can't boot into recovery. I just see black nothing.
EDIT:
Disregard - My stock recovery boots. I was performing the boot into recovery procedure incorrectly. Also, because the recovery.cpio.img was in /system I assume it was flashed on each power cycle.
Apologize: I have read the complete topic and now understand that at present it is only for Novo.
Please dont use this thread to talk for another devices that arent be Novo7 Basic.
Asi cant start a new thread yet, here is my thread at spanish forum comunity with a full starter packs of mips app + games and a guide to be root.
htcmania. co m/showthread.php?t=303749
I´ve got successfully get a compiled MIPS version of Titanium backup that works like a charm for our device Novo7 Device! Checkout at the link upside.
Regards. (I will open a new thread when i´ve got 50 messages...)
fun_ said:
it seems source code for xboot, android 2.2 and (part of?)kernel source for NOVO7B is released. I don't try to compile them yet so I may be wrong.
I'll check them later.
Click to expand...
Click to collapse
what other info would you like?
Hi XDA,
so basically i bought a Velocity Cruz T301 recently and followed the known procedures for rooting, flashing ClockworkMod Recovery and custom rom (SJHill Rom v0.3).
before the full brick my device was at ClockworkMod 5 and rooted with SJHill Rom v0.3.
i installed CWM by flashing the zip in stock recovery, then succesfully rooted the device, finally wiped and flashed my custom rom
after major dissapointment in this tablets performance i decided i wanted to get rid of it.
So i downloaded the stock rom, wipe and flashed it onto the tablet...
the tablet turned off when it was finished (i think it was attempting to reboot) and never turned back on again...EVER! :good:
i cant even get to recovery
i tried flashing with adb and fastboot but the device is never even presents itselft to the computer.
i found out that you can boot the device into USB boot mode where you hold the "VOL -" (Volume Down) button and press the reset button and while connected to the computer (windows only) a "JZ4760 USB Boot Device" appears.
i did some googling and also found out that the T301 is based on similar tech to a bunch of tablets and they can all be modified by some software released by Ingenic called USBBootTool.exe
the tool is written in chinese and i cant decypher it all, though i found out how to use it based on its usage for other Ingenic based tablets
1.) you will need to disable driver signature verification (press F8 on boot of windows and toggle the setting, i hate rebooting too but it has to be done)
2.) boot your tablet into USB Boot Mode (hold down Vol - and press Reset button)
3.) install the driver for your device (included in the files below)
4.) with the tablet disconnected you would open the USBBootTool.exe
5.) select your tablet in the options and fill each box with the files needed to flash (files included below)
6.) reconnect the tablet while still in USB Boot Mode and the software will flash your device on detection
everything goes fine for me except when i get to the flashing part in the end.
when USBBootTool detects my tablet, it attempts to flash and gives me a stream of errors and never flashes my device.
i dont know what to do at this point. i have provided direct links to all the software im using and also links to where i got them.
any help would be appreciated, thank you to the XDA community in advance
>------------------- DOWNLOADS ------------------------<
USBBootTool.exe / Tablet Drivers (4725 / 4725B / 4740 / 4750 / 4755 / 4760 / 4770)
http://dl.dropbox.com/u/79196608/burn_tools_3.0.16.rar
obtained from - http://forum.xda-developers.com/showthread.php?t=1720621
Velocity Cruz T301 Update.zip (contains the system.img / data.img / mbr-xboot.bin files)
http://www.cruztablet.com/T301update.zip
obtained from - http://www.cruztablet.com/Article_861.php
SJHill Rom v0.3
http://www.androidfilehost.com/?fid=9390362690511176486
obtained from - http://www.slatedroid.com/topic/27583-rom-t301-sjhill-rom-17-feb-2012-download-link-updated/
ClockworkMod 5
http://files.androtab.info/ingenic/cwm/20120514/T301-recovery-signed.zip
obtained from - http://androtab.info/mips/ingenic/clockworkmod/
I have the same situation. I have gone through every menu in the USB Boot tool and to no avail am I able to recover my T100.
gmick is redoing the software because the coding is set up wrong. Once he gets that figured out there should be a fool proof unbricking method that we can follow. He is posting information over on Slate Droid if you want to take a look.
feyerbrand said:
gmick is redoing the software because the coding is set up wrong. Once he gets that figured out there should be a fool proof unbricking method that we can follow. He is posting information over on Slate Droid if you want to take a look.
Click to expand...
Click to collapse
ok post the link to the thread, and ill add it to the first post as a solution if its found to be a working one
JustSayTech said:
ok post the link to the thread, and ill add it to the first post as a solution if its found to be a working one
Click to expand...
Click to collapse
*Cross Post from SlateDroid* (but I can't post the link because XDA won't allow it)
I found out why the USB boot isn't working. Well, more appropriately I know where it fails but not exactly "why".
The USB Boot tool works like this:
1) Send x00 command (Get CPU Info)
2) Device responds with "JZ4760V1"
3) Host sends two binaries, stage1 and stage2. Stage 1 sets up memory stuff, and Stage 2 sets up USB flashing functions.
4) Host checks that the binaries executed by issuing another x00 command (Which serves as an "Are you still there?" function)
5) If the response is good, the host will flash the images, if the response is bad, it will abort.
Our devices are failing at step 4. The linux usb boot tools (xburst-tools) fail in an identical fashion.
I know that the first stage binary transfers and executes fine because if it didn't the device would be limited to 16k. The second stage is 120K and is transferred successfully. Once the second stage "execute" command is sent, the device crashes.
The second stage is also unique to the CPU type. I've used all of the binaries for JZ4760 I could find on the net and when that failed I cross compiled my own binary from source and it still crashed.
At this point I highly doubt I'll ever be able to fix it, and this completely explains why no one could get any usb recovery tool to work while others using similar devices could. I guess our board is modified just enough for ingenic's stock binaries to fail. Without knowing what's changed (getting Velocity Micro's source) we're SOL.
I can open it up again and solder on the serial header but I'm betting it's going to give me some generic "couldn't execute" message that isn't going to help me. I'll probably do this anyway though because I've come this far so what's the loss.
wow, i learned alot from that post, seems like writing a usbboottool-like application that can send the commands but also log and possibly bypass security checks etc but that def would take sometime. thank you for your insight, seems youve come the closest to cracking the case, actually you found the fault, hopefully your methods can eventually bring about a fix
JZ 4770
gmick said:
*Cross Post from SlateDroid* (but I can't post the link because XDA won't allow it)
I found out why the USB boot isn't working. Well, more appropriately I know where it fails but not exactly "why".
The USB Boot tool works like this:
1) Send x00 command (Get CPU Info)
2) Device responds with "JZ4760V1"
3) Host sends two binaries, stage1 and stage2. Stage 1 sets up memory stuff, and Stage 2 sets up USB flashing functions.
4) Host checks that the binaries executed by issuing another x00 command (Which serves as an "Are you still there?" function)
5) If the response is good, the host will flash the images, if the response is bad, it will abort.
Our devices are failing at step 4. The linux usb boot tools (xburst-tools) fail in an identical fashion.
I know that the first stage binary transfers and executes fine because if it didn't the device would be limited to 16k. The second stage is 120K and is transferred successfully. Once the second stage "execute" command is sent, the device crashes.
The second stage is also unique to the CPU type. I've used all of the binaries for JZ4760 I could find on the net and when that failed I cross compiled my own binary from source and it still crashed.
At this point I highly doubt I'll ever be able to fix it, and this completely explains why no one could get any usb recovery tool to work while others using similar devices could. I guess our board is modified just enough for ingenic's stock binaries to fail. Without knowing what's changed (getting Velocity Micro's source) we're SOL.
I can open it up again and solder on the serial header but I'm betting it's going to give me some generic "couldn't execute" message that isn't going to help me. I'll probably do this anyway though because I've come this far so what's the loss.
Click to expand...
Click to collapse
for my JZ4770 Earlier USB tool was flashing .img without any problem but for now it is saying "load cfg failed". "API downlaod failed' like dialogues and doesnt flash anything. Any idea? Thanks in advance!!
First restart your computer (actually restart it) then redownload the USB boot tool and save it in a completely new directory and use a different USB port
Sent from my Pokeball
Yes, I did
JustSayTech said:
First restart your computer (actually restart it) then redownload the USB boot tool and save it in a completely new directory and use a different USB port
Sent from my Pokeball
Click to expand...
Click to collapse
Yes, I tried with this suggestion. Rather I reinstalled xp and the tried again. But the dialogues are same. The history is like this. Was having ICS on JZ 4770. Formatted with usb tool and put JB updates. It was not sensing touch so reflashed another JB updates. Now the tab boots, it reaches to boot logo for around 12 seconds and restarts in stock recovery. While it is in booting stage it get detected by windows and adb also. In stock recovery mode it get detected by windows and in turn by adb also. If I tried to install updates through SD card it shows it had installed and reboots after completion. But again the same way it goes to boot logo and then back to stock JB recovery. It also boots in ingenic boot device mode and gets detected by USB burn tools. But when try to flash any of the ROM it gives the same dialogues "check cfg failed" "api download failed" "boot. fw failed" and cant flash anything.
Is there any tool which can be flashed or a script which can be used from SD card for completely formatting flash memory so that USB burn tool can flash required ROM?
can you flash the stock rom in recovery?
Managed using USB BOOT TOOL for ingenic JZ 4770 board in English
JustSayTech said:
can you flash the stock rom in recovery?
Click to expand...
Click to collapse
thanks man but I managed to boot the device. I used following USB BOOT TOOL for ingenic 4770 boards. The goodness with this tool, this is completely in English. You will know what you are doing. Even after opening the main window of the tool you can right click and then get another options(yes again in English). My problem with this device was bad blocks at 1024. In the options there is chance to force erase whole the nand partitions which I used and erased all the partitions thereby made all the partions available for flashing and readable by the tool. Then from File option selected stock rom files and flashed them. While flashing selected JZ4770 iNanad.ini file in manual configuration. This tool has really helped me to come out of the issue and will be useful for guys using JZ 4770 board.
http://www.4shared.com/rar/m1BUV5r2/USBBurnTool_20120401_for_relea.html
Got USBBootTool.exe kind of working.
1. Download the following file from Ingenic.
ftp * ingenic * cn/3sw/01linux/tmp/jz4770-20110610.rar
2. Download Applocale from Microsoft.
www * microsoft * com/en-us/download/details.aspx?id=13209
3. Extract the jz4770-20110610.rar and find the folder. (Using 7zip should keep the UTF encoding in Chinese)
20110610\04burn\20110524_4770_Programmer
4. Copy the folder 20110524_4770_Programmer to location you want to use it in.
5. Install Microsoft Applocale (Just in case, I don't think it is required)
Now Start Applocale and create a shortcut to USBbootTool.exe inside 20110524_4770_Programmer
中文(简体) is simplified Chinese option and should let you view the GUI correctly.
6. Now with the Applocale Shortcut created for USBbootTool.exe you can start the application with correct fonts.
Now this is where is breaks down.
TABLET-8 NAND FINAL BSP(S3 TEST) will allow you to read from it and write to it, but the CFG is off.
\tool_cfg\tablet-8-nand-final.ini is the configuration for it.
DO NOT CONNECT THE DEVICE WITH ANY OPTIONS CHECKED OR LOAD ANY FILES.
See Attached Images.
Next to the Read button is some Boot Option menu. I am not fulling aware of what this does.
What I need is a someone to help me fix/correct the ini/cfg files in
\20110524_4770_Programmer\tool_cfg\.ini
\20110524_4770_Programmer\4760\
to correctly match the files of the NAND.
Also if anyone has a copy (dd to img) or (cat to img) of the block devices.
That would help a ton.
# cat /proc/partitions
# cat /proc/mtd
I would also love another T10x Tablet for cheap.
I want to start building things like new bootloader, kernel, system image,
performance libraries to take full use of the Ingenic JZ4760 (www * ingenic * cn/product.aspx?CID=11)
I also bring Christmas gifts
2 APKS. You can place them in /system/app or /data/app.
Google Play will crash now and again, but it will load and work. (Vending.apk)
Secondly I bring the gift of performance increase, just by a slight bit.
edit the line of the heapsize in /system/build.prop dalvik.vm.heapsize=96m
Remember to make sure the permissions are set back to 666 or 644.
Original Vending.Apk before updates came from here: (Incase you are paranoid)
code * google * com/p/ics-nexus-s-4g/source/browse/trunk/system/app/Vending.apk?spec=svn20&r=18
ics-nexus-s-4g * googlecode * com/svn-history/r18/trunk/system/app/Vending.apk
To prevent spam on the XDA forums, ALL new users prevented from posting outside links in their messages. After approximately 10 posts, you will be able to post outside links. Thank you for
Click to expand...
Click to collapse
Stupid. how do you expect real people to help post Tech Docs? That is bad Moderating and Administrating.
Make sure to replace the Asterisk's with spaces to normal dots.
Requesting Block Images.
Does anyone have a copy of it they can send me for a T10x?
block images......
IceGryphon said:
Does anyone have a copy of it they can send me for a T10x?
Click to expand...
Click to collapse
Which block images do you want?
...also is there a way to rip the stock images off the jz4760 in the t301.
Such as:
Can i usethe ingenic uboot tool?
Anybody find the jtag pins?
Is the 4 pin conn next 2 the batt for serial?
.......i guess ill try to take a look this weekend
Ics would be really nice, but probably slower than stock..... especially with the limited ram
I unpacked the stock rom. I also unpacked an ics rom for a jz4770, and repo sync'd the aosp and mips 3.0.8 android kernel.
I'm still trying to figure out specs for the processor though. I know that its mips32 - el- fp- r1, but i cannot figur out the dsp version ... if it has one?
Error in erasing nand
nanachitang420 said:
thanks man but I managed to boot the device. I used following USB BOOT TOOL for ingenic 4770 boards. The goodness with this tool, this is completely in English. You will know what you are doing. Even after opening the main window of the tool you can right click and then get another options(yes again in English). My problem with this device was bad blocks at 1024. In the options there is chance to force erase whole the nand partitions which I used and erased all the partitions thereby made all the partions available for flashing and readable by the tool. Then from File option selected stock rom files and flashed them. While flashing selected JZ4770 iNanad.ini file in manual configuration. This tool has really helped me to come out of the issue and will be useful for guys using JZ 4770 board.
http://www.4shared.com/rar/m1BUV5r2/USBBurnTool_20120401_for_relea.html
Click to expand...
Click to collapse
I used english ingenic tool to erase bad blocks but m nt able erase bad blocks live suit is giving eror id=0x4848
hi all,
i'm going to support multiple android roms loading in my kernel_chooser + root_chooser project.
in few words it will be a powerful bootloader for android.
this is what it will be able to do ( many points are yet working ):
kernel loading thought kexec
boot from external devices
boot from subfolders
custom background
change android /sytem partition
change android /data partition
wipe android /cache partition
what i'm asking to you it's to make your android rom's kernel kexec-ready, applying them a kexec guest patch.
thus to make them ready to load for me.
if not i have to patch your kernel every time you modify it.
kernel_chooser and root_chooser are hosted here: https://github.com/tux-mind/tf201-dev
they are made for the asus transformer prime ( TF201 ), but they can run on any android device with your help.
i will add you to the github collaborators if you want to help.
now we are working on multiple android roms support.
thanks in advance for your time.
-- tux_mind
@tux_mind sounds like an interesting idea. So this works for all device's kernels? Once I apply the patch to my kernel source, what happens after that? I'll make sure to follow your progress, good work
HTCDreamOn said:
@tux_mind sounds like an interesting idea. So this works for all device's kernels? Once I apply the patch to my kernel source, what happens after that? I'll make sure to follow your progress, good work
Click to expand...
Click to collapse
thanks
yes, this should work for all devices, except for a little tuning of the partition with the configuration data ( /data ).
i have to make it to self-detect the /data partition.
let's say for example that you want to use it on your HTC Vision.
i have to build an host kernel by the stock one applying the host kexec patch.
than i have to build an android boot image which contains kernel_chooser as initrd and the above kernel.
this android boot image will be written to your current one though fastboot.
after that kernel_chooser will be able to load any kernel patched with the guest patch.
obviously the loaded kernel must be made for that device
it can also load a custom initrd and use a custom kernel CMDLINE.
so, after i made a HTC Vision kernel_chooser, your rom it's ready to load if you applied the guest patch to you kernel.
i can't explain well how to make you rom "bootable" because we are developing this
but if your kernel is kexec-loadable it will be supported by kernel_chooser.
i will update you in the next days
bye!
Really great idea! As it support other devices I can throw in my kernel which is a kexec one for the Motorola RAZR, because of our locked bootloader. The question is: how different are the methods to use kexec?
M.o.t.o.r.o.l.a.R.a.z.r - JBX-Kernel 0.5a - Tapatalk4
@tux_mind this'll sound really stupid but how do actually patch our kernels for this? Do I have to build kexec from here or something?
dtrail1 said:
how different are the methods to use kexec?
Click to expand...
Click to collapse
kexec it's a syscall, so it's the same on every arm device.
HTCDreamOn said:
@tux_mind this'll sound really stupid but how do actually patch our kernels for this? Do I have to build kexec from here or something?
Click to expand...
Click to collapse
there is a good explaination here:
http://forum.xda-developers.com/showthread.php?t=2104706
look at the "Compatibility patch".
for my tf201 the guest patch is this: http://git.lilstevie.geek.nz/?p=ubu...ch;h=54c2e480682afb0629f3854dfea4154f528421e5
which is almost the same...
i hope that almost all kernels have the same host/guest patch, in order to save us a lot of work.
the patch isn't need for kexec, but for hardboot kexec, thus to physically shutdown and restart the device with your kernel, from 0.
the standard kexec it's a assembly jump to 0 ( jmp 0x0 ) with the new kernel loaded in the .text section.
but the standard method don't reinitialize the devices and many other things that could rest in a undefined state.
btw, i have almost done my work.....i'm fighting the android udev which is overwriting my symlinks..
see you!
i got it!
my initial target was to remove devices created by ueventd and replace them with symlink to loop devices.
but android respawn ueventd and replaces my symlinks...
i tried to start the android ueventd, leave it running, and replace the /sbin/ueventd with a infinite sleep static program
but android dont' start at all..i can't even access via adb.
so, the "final" solution is to edit the /fstab.$hardware, which should be in any andoird boot image ( right ? ).
please feel free to suggest any other way to hack the mount process.
you can find the sources here: https://github.com/tux-mind/tf201-dev/tree/master/android_chooser
the program read the paths from kernel cmdline.
the syntax is that:
Code:
newandroid=blkdev:initrd_path:fstab_path
where
blkdev is the linux name of the blockdevice containing the next args ( e.g. /dev/mmcblk0p8 )
initrd_path is the path on the previous blockdevice of the android initrd ( gzipped or not )
fstab_path is the path on the previous blockdevice of the fstab file
the fstab file have this syntax:
Code:
/android/mountpoint /path/to/image/file
where
/android/mountpoint is the android mountpoint to overwrite ( e.g. /system )
/path/to/image/file is the path to the filesystem image file ( on blkdev ) ( e.g. /boot/unrooted.img )
i don't make any documentation until i will be sure that there is no better way to do this.
thanks in advance for your testing
ah, some other useful info.
because we are in testing the program write a log file with some debug info in the root of your blkdev.
so you will find /android_chooser.log on your blkdev with these info in case of errors.
tux_mind
Please
dtrail1 said:
Really great idea! As it support other devices I can throw in my kernel which is a kexec one for the Motorola RAZR, because of our locked bootloader. The question is: how different are the methods to use kexec?
M.o.t.o.r.o.l.a.R.a.z.r - JBX-Kernel 0.5a - Tapatalk4
Click to expand...
Click to collapse
Dtrail could you explain me kexec and its components required for loading new kernel because my device(electrify 2) is similar to droid razr. Using bmm kexec is boot able because I had checked by flashing droid razr's kernel which gave a boot loop.
I would be pleased and thankful to you if you help me.