I have been following the Android scene here pretty regularly but the os I have always really wanted is a full fledged Linux. I heard about, and wanted a N900 because of Maemo but I'm too poor to buy one . I then heard about the Mer project https://wiki.maemo.org/Mer to port Maemo to other devices and saw it booted on the kaiser http://forum.xda-developers.com/showthread.php?t=565480. On page two of that thread it is stated that someone (Mdrobnak) got it up and running pretty well on his Fuze with a couple tweaks to Xorg.conf, the kernel, and to the splash screen (resized to 640x480). I've been working over the past few days on getting it to start on my fuze but haret keeps giving errors about pc_clk_disable. I resized the splash, changed Xorg.conf to be 640x480 and did the rest of the directions on the Kaiser thread, but no luck. I would love to get a port of this going, as being able to use ~95% of Ubuntu packages working on my phone would be awesome. I wasn't quite sure how to patch the kernel; that would be the zImage, right? Any suggestions?
I'm going to be on #mer and #htc-linux irc on freenode quite a bit until we get this working well if anyone wants to discuss things, not that I can contribute much.
Would it be possible to create a rootfs.img file similar to how XDANDROID does it for people too lazy to partition their card or just plain suck like me?
Sounds interesting! Keep us updated!
Oh god! Ill be in 7th heaven if it's going to be done!
I think you can use the zImage of xdandroid, maybe it'll work
I tried the xdandroid zImage but it didn't work. This is really a call for help. I really don't know what I am doing, lol. I'm not even close to being a dev. Try out the steps on the Kaiser thread but use the stable 0.16 distribution as the testing links don't work. See if you can figure anything out.
Maemo on the Raph ? that would be great! maybe we could run it in dual boot with android and abandon WM for ever !
To get X working, use glemsom's kernel, and add msm_fb.fix_x=1 to cmdline.
For touchscreen, you might want to add msm_ts.raw=1 (but it can also work without it)
phhusson said:
To get X working, use glemsom's kernel, and add msm_fb.fix_x=1 to cmdline.
For touchscreen, you might want to add msm_ts.raw=1 (but it can also work without it)
Click to expand...
Click to collapse
Thanks, phh. Will try it when I get home.
that's the old and ugly msm_fb refresh hack.
I will update here once I have xorg working on kovsky and kaiser.
Man, I actually feel like this is getting places. Got Phhusson from XDANDROID and dcordes from the original Android on Diamond thread. Quite the star power.
@dcordes: What needs to be edited to use VGA; just the first screen resolution dimensions in Xorg.conf?
what image are you using?
I'm using the Smartq5 from here: http://wiki.maemo.org/Mer/Releases/0.16. My main problem is with the kernel though I think; haret hangs after about 15 seconds; I'm gonna create a log of it.
On my Raph300 I can login on the terminal using the Q5 image. I was using the latest zimage from gelmsom. But kernel is screaming some stuff a bout a clock not having an ena bit and something about an rpcrouter being blocked. When I try to start X, I get an error loading libpicacces.so.0
I get that same error, but Haret hangs when I get it. Please share what you did: e.g. editing xorg, exact zImage used, what you used to partition, your default.txt, whether you edited the splash screen image etc. I'd like to get a database of sorts of people's configurations. Good to know though. Did you add Phhusson's tip to default.txt?
"To get X working, use glemsom's kernel, and add msm_fb.fix_x=1 to cmdline.
For touchscreen, you might want to add msm_ts.raw=1 (but it can also work without it)"
Yes i added the msm_fb.fix_x=1 to the cmdline. Unfortunatly it is not the solution for this problem. We have got some trouble with the libraries. Maybe something is missing.
LordKiwi said:
Yes i added the msm_fb.fix_x=1 to the cmdline. Unfortunatly it is not the solution for this problem. We have got some trouble with the libraries. Maybe something is missing.
Click to expand...
Click to collapse
Last time I tried it worked automatically (I mean for X video output.) with msm_fb.fix_x=1
Sorry it works. JesusFreak and I extracted the tar file the wrong way.
I should have type tar -pxvf. I forgot the p which is very important.
Now it stops with a different error.
Code:
(**) FBDEV(0): using shadow framebuffer
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /usr/lib/xorg/modules//libshadow.so
(II) Module shadow: vendor="X.Org Foundation"
compiled for 1.6.0, module version = 1.1.0
ABI class: X.Org ANSI C Emulation, version 0.4
(EE) FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument
(EE) FBDEV(0): mode initialization failed
Fatal server error:
AddScreen/ScreenInit failed for driver 0
Dang it; I just can't get it to work. I'm the thread starter and I can't do it, lol. Here's what I did:
1. Downloaded 0.16 stable smartq5 rootfs.
2. Extracted the tar to my home folder. (Now that I think of it; I did it with archive manager not the command line, so no -p setting or anything. That could be the problem.)
3. Edited the xorg.conf file to change the resolution to 640x480.
4. Changed the splash screen size to 640x480.
5. Formatted my sd card to ext2 for 1.5 gb and fat32 for .5 gb using command line following these directions for ext2: http://wiki.maemo.org/Mer/Documentation/SmartQ_Installation_for_the_Windows_user and gparted for fat32.
6. I then used the directions on the same pagee as before to copy the file, except using cp instead of mv.
7. I copied haret, a zImage, and the startup.txt that I renamed to default.txt and edited to the fat32 partition.
8. I started Haret.
I attached my default.txt.
The formatting is done correct. You should try to use the tar command line wich you can find on the same page. It should solve the problem of loading the library.
•Type sudo tar -pxzvf *.gz and press return. This will now untar the entire 'rootfs' to the card. (Install Mer).
LordKiwi said:
Sorry it works. JesusFreak and I extracted the tar file the wrong way.
I should have type tar -pxvf. I forgot the p which is very important.
Now it stops with a different error.
Code:
(**) FBDEV(0): using shadow framebuffer
(II) Loading sub module "shadow"
(II) LoadModule: "shadow"
(II) Loading /usr/lib/xorg/modules//libshadow.so
(II) Module shadow: vendor="X.Org Foundation"
compiled for 1.6.0, module version = 1.1.0
ABI class: X.Org ANSI C Emulation, version 0.4
(EE) FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument
(EE) FBDEV(0): mode initialization failed
Fatal server error:
AddScreen/ScreenInit failed for driver 0
Click to expand...
Click to collapse
I'm an idiot....... I saved my startup.txt as startup.doc. That's why X didn't start.
0.17 release
Is possible run the 0.17 realease in raphael more fast than in N810?
Related
kaiser ubuntu port based on zubuntu by Omegamoon for Sharp Zaurus was successfully launched on HTC Nike!
Instructions:
1. download kernel
http://84.23.71.227/kerneloftheday/zImageUbuntu
2. download ubuntu basefiles and rootfs
3. place ubuntu.img, haret, initrd.gz and zImageUbuntu to Storage Card/ubuntu/
4. place this default.txt there too
Code:
set RAMADDR 0x10000000
set MTYPE 1724
set KERNEL zImageUbuntu
set initrd initrd.gz
set cmdline "pm.sleep_mode=1 mddi.width=320 mddi.height=480 lcd.density=160 board-htcnike-keypad.keypadlayout=1 board-htcnike-keypad.sticky_timer_time_ms=350 no_console_suspend"
boot
5. change board-htcnike-keypad.keypadlayout=1 to 0 if you have 20key nike.
6. run haret and press "Run", ubuntu & kernel will be loaded to login prompt, login with username root and no password, you will get root shell.
7. write
Code:
export TSLIB_TSDEVICE=/dev/input/event0
ts_calibrate
and calibrate your screen.
8. write startx and see LXDE running on your nike! you've got real linux box in pocket!
Note, rootfs for ubuntu needs 1GB of free space on your sdcard!
For now, you cannot work with screen, we have some difference from kaiser panel's, i.e. ubuntu gui is completely unusable, this thread were started to find out why.
based on this thread from kaiser forum.
Credits: dzo, Omegamoon, domy007, mblaster and guys from Rhodubuntu thread.
I dont get any response when i try to calibrate screen on niki 200
thats strange, it must work.
I will debug on touchscreen problems, but ubuntu running and that is great, now we have only input-devices problems, and this is more better than nothing.
Sounds great, but wouldn't it be better to try something smaller like puppylinux or Feather linux ?
zubuntu is only we have compiled for ARM and working with our hardware that starts X and tested on other htc's devices.
rzk333 said:
zubuntu is only we have compiled for ARM and working with our hardware that starts X and tested on other htc's devices.
Click to expand...
Click to collapse
Ok thanks for the information, did some reading before and was always wondering why they use ubuntu but this answer set things straight.
Greetz,
Great to see a full linux distro around for htc devices. I will fix the '_' tomorrow... Any other missing characters?
How is the speed of ubuntu? Is it very sluggish or usable?
'=' character maybe, for export line.
zImageUbuntu is updated (your link is still valid).
'=' and '-'are on '*'-button, '_' is Alt-
I have included the msm_fb_refresh and the keypad changes into my auto-updated-kernel, so you should be able to use the fresh kernels from my thread with ubuntu if you want recent updates (zImageUbuntu is not automatically updated).
got some progress,
1) msm refresh thread seems to disable sleep mode in android, thread polls framebuffer many times in second and drains battery.
2) linux logo on bootup must be disabled - logo gets over ts_calibrate's first crosshair point.
2) still trying to make touchscreen and tslib friends - i2c bus debug messages logs saying that touchscreen is connected and recieves data correctly.
found some data:
/dev/input/event0 - htcnike-kbd
/dev/input/event1 - htcnike-ts
but still no data from touchscreen...
rzk333 said:
got some progress,
1) msm refresh thread seems to disable sleep mode in android, thread polls framebuffer many times in second and drains battery.
2) linux logo on bootup must be disabled - logo gets over ts_calibrate's first crosshair point.
2) still trying to make touchscreen and tslib friends - i2c bus debug messages logs saying that touchscreen is connected and recieves data correctly.
found some data:
/dev/input/event0 - htcnike-kbd
/dev/input/event1 - htcnike-ts
but still no data from touchscreen...
Click to expand...
Click to collapse
Disabled msm refresh thread from the android kernels again. The kernel you linked in your first post is now automatically updated with anything new in the repository. Bootlogo is disabled, too. Good luck with tslib, let me know if when you need something else to be hacked into the kernel.
mblaster
I've just test the usb ether function in the zImage from the post
showthread.php?p=6675397
and it works just fine.
(Just when I had managed to make adbd works... but ssh is more reliable)
Thanks gTan64.
wow, that is good, now I can dump system state without hours of keyboard typing
I've managed to get internet by usb (cdc only) thanks to gTan64: just apply the patch from is post ("Debian on the vogue"), you can extract it from the download links.
And the TOUCHSCREEN WORK!!!!!!!
But you need to compile tslib from the tslib git (github.com/kergoth/tslib.git), the one in the rootfs from this post doesn't work.
Will make a more complete post later, I think.
Bye.
Ubuntu always shows me a black screen when I try to startup it!
What can I do make it work?
omg, I knew that something is wrong with tslib in this rootfs!
thanks for r&d, if you will make some packages & mans, I'll add them to first post.
Maybe you can upload some pics ?
But you need to compile tslib from the tslib git
Click to expand...
Click to collapse
I tried to compile - but no luck, autoconf fails to make configure...
I also uploaded debian rootfs and posted links in gTan's Debian on Vogue thread.
nothing happened last month?
Hello all,
if you are like me, you love to do things by yourself and see how it works. In this thread I'll show you how to create your Linux environment in order to create and compile your own roms - any version (1.5, 2.3, etc etc). I had soooooo many problems to make it work, so here is THE thread
BE CAREFUL : this thread is ONLY to set up the OS. The Android you will compile will not be compatible with your x10 as it needs to be "edited" for our phones. It basically shows you how to get ready
Note : parts 1 and 2 explain how to set up Ubuntu into a virtual machine in Virtualbox. If you don't virtualize Linux, if your Ubuntu is already installed, etc etc you can directly go to 3. It's just here to explain how to install Ubuntu.
This tutorial works of course for any "hard installation" of Ubuntu (I mean not in a Virtual machine) and in any virtualizing software (Virtualbox, VMWare, etc etc). I've dropped the Virtualbox tutorial because the software is free
1. Requirements
2. Set up Ubuntu 64 bit (Virtualbox)
3. Set up Android Source dependencies
4. Set up Android Source
5. Regular use
1. Requirements
A working computer, capable of virtualization (if you don't want to wipe your Windows or your MacOS X !) and with Internet connection
Few Gb on your hard drive (10Gb minimum ! Recomended : 15-30Gb)
As much RAM as possible (Minimum 1024Mb), and as powerful CPU as possible (Core2Solo, Core2Duo, ...)
A bit a time
2. Set up Ubuntu 64 bit
Download and install the latest Oracle VM Virtualbox for Windows
Download latest 64-bit Ubuntu Linux (as .iso package) - you can store the file wherever you want.
(Optional) Download the VirtualBox v4 extension, this will allow you to support improvements like USB2.0... Install : once VirtualBox will be installed, File>Preferences>Extensions>Add... If you get an error (Error 1), try to put the file in a "very simple" location (like C:\) and reinstall.
Once you've set up Virtualbox, run it. Click on "New", then follow the wizard.
Make sure you set the following :
Operating System : Linux
Version : Ubuntu (64 bit)
RAM : 512Mb (you can adjust more, but avoid use lower than 512Mb - I use 2Gb)
Create a new hard drive : set it variable size or fixed sized, but you'll need at last 15Gb to get all the files. To feel confortable, I use 30Gb (variable)
The computer is created, now run it. It will say there's no OS. Click on Devices > CD/DVD > More CD/DVD... Here is you virtual player. Click on Add, and select the Ubuntu .ISO file you downloaded. Then, choose it in the list, and click Choose. Now, you can restart the virtual machine by clicking Machine > Restart.
The computer should restart from the virtual CD, so install it to your virtual hard drive - regular install, same as if you were installing it on a physical HDD.
Once it's installed, do not forget to kick the .iso file from the virtual player for you not to start always on the CD
3. Set up Android Source dependencies
In Ubuntu, do right-click on the upper bar (where are Applications, Shortcuts...), and click Edit Menus. Then, go to System > Administration and tick Software Sources. We need to do this because Sun is highly restrictive on access to Java setup files...
Close that, then click on System > Administration > Software Sources.
Enable all sources, then on the second tab, tick the two Canonical sources (the most important ones, as these sources allow to install Java !)
Close the window and allow to refresh the sources (if you don't, next steps won't work).
Go and read the official Android Source page. That's what we're going to do.
Run a terminal, and copy/paste this : (this is a corrected setup, it should work like a charm -- please tell if it's not)
Code:
sudo apt-get install git-core gnupg flex bison gperf build-essential zip curl sun-java6-jdk zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev ia32-libs x11proto-core-dev libx11-dev lib32readline5-dev lib32z-dev
After setup complete, make sure Java works, by typing
Code:
java
and
Code:
javac
This should return help on both commands. If one of these doesn't work (ie. "command not found"), your environment is not configured properly.
4. Set up Android Source
Create a dir called "bin" in your user dir.
Code:
cd ~
mkdir bin
echo $PATH
Then, type this :
Code:
curl http://android.git.kernel.org/repo >~/bin/repo
chmod a+x ~/bin/repo
Next step is to create a folder where we'll store Android sources we work on. You can place it and name it as you wish, let's call it "android" and place it on the user folder.
Code:
mkdir android
cd android
Then, run this command :
Code:
repo init -u git://android.git.kernel.org/platform/manifest.git
If it returns "command not found", restart Ubuntu !
Enter username and email, although I'm not sure it's useful for our use -custom roms-.
Now, let's get the files ! Type
Code:
repo sync
and wait... Wait... Wait... Lots of commands, of "Resolving deltas", "Receiving", etc etc. It can be very long (depends of your Internet speed), just wait...
Finally, let's register the public key and finalize setup process. Type
Code:
gpg --import
And the cursor will down a line and nothing will appear. Stuck ? Broken ? Woooops ? Not at all ! Program is waiting for you to type the key, which is sooooooo big. So, copy and paste all this :
Code:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
mQGiBEnnWD4RBACt9/h4v9xnnGDou13y3dvOx6/t43LPPIxeJ8eX9WB+8LLuROSV
lFhpHawsVAcFlmi7f7jdSRF+OvtZL9ShPKdLfwBJMNkU66/TZmPewS4m782ndtw7
8tR1cXb197Ob8kOfQB3A9yk2XZ4ei4ZC3i6wVdqHLRxABdncwu5hOF9KXwCgkxMD
u4PVgChaAJzTYJ1EG+UYBIUEAJmfearb0qRAN7dEoff0FeXsEaUA6U90sEoVks0Z
wNj96SA8BL+a1OoEUUfpMhiHyLuQSftxisJxTh+2QclzDviDyaTrkANjdYY7p2cq
/HMdOY7LJlHaqtXmZxXjjtw5Uc2QG8UY8aziU3IE9nTjSwCXeJnuyvoizl9/I1S5
jU5SA/9WwIps4SC84ielIXiGWEqq6i6/sk4I9q1YemZF2XVVKnmI1F4iCMtNKsR4
MGSa1gA8s4iQbsKNWPgp7M3a51JCVCu6l/8zTpA+uUGapw4tWCp4o0dpIvDPBEa9
b/aF/ygcR8mh5hgUfpF9IpXdknOsbKCvM9lSSfRciETykZc4wrRCVGhlIEFuZHJv
aWQgT3BlbiBTb3VyY2UgUHJvamVjdCA8aW5pdGlhbC1jb250cmlidXRpb25AYW5k
cm9pZC5jb20+iGAEExECACAFAknnWD4CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIX
gAAKCRDorT+BmrEOeNr+AJ42Xy6tEW7r3KzrJxnRX8mij9z8tgCdFfQYiHpYngkI
2t09Ed+9Bm4gmEO5Ag0ESedYRBAIAKVW1JcMBWvV/0Bo9WiByJ9WJ5swMN36/vAl
QN4mWRhfzDOk/Rosdb0csAO/l8Kz0gKQPOfObtyYjvI8JMC3rmi+LIvSUT9806Up
hisyEmmHv6U8gUb/xHLIanXGxwhYzjgeuAXVCsv+EvoPIHbY4L/KvP5x+oCJIDbk
C2b1TvVk9PryzmE4BPIQL/NtgR1oLWm/uWR9zRUFtBnE411aMAN3qnAHBBMZzKMX
LWBGWE0znfRrnczI5p49i2YZJAjyX1P2WzmScK49CV82dzLo71MnrF6fj+Udtb5+
OgTg7Cow+8PRaTkJEW5Y2JIZpnRUq0CYxAmHYX79EMKHDSThf/8AAwUIAJPWsB/M
pK+KMs/s3r6nJrnYLTfdZhtmQXimpoDMJg1zxmL8UfNUKiQZ6esoAWtDgpqt7Y7s
KZ8laHRARonte394hidZzM5nb6hQvpPjt2OlPRsyqVxw4c/KsjADtAuKW9/d8phb
N8bTyOJo856qg4oOEzKG9eeF7oaZTYBy33BTL0408sEBxiMior6b8LrZrAhkqDjA
vUXRwm/fFKgpsOysxC6xi553CxBUCH2omNV6Ka1LNMwzSp9ILz8jEGqmUtkBszwo
G1S8fXgE0Lq3cdDM/GJ4QXP/p6LiwNF99faDMTV3+2SAOGvytOX6KjKVzKOSsfJQ
hN0DlsIw8hqJc0WISQQYEQIACQUCSedYRAIbDAAKCRDorT+BmrEOeCUOAJ9qmR0l
EXzeoxcdoafxqf6gZlJZlACgkWF7wi2YLW3Oa+jv2QSTlrx4KLM=
=Wi5D
-----END PGP PUBLIC KEY BLOCK-----
Once pasted, hit CTRL+D, this will make the program to register the key, and will display the key has processed.
Everything is now done, you have all the sources and you are ready to create your own roms. You can edit files simply by double-click, or use any software you want.
If you want to compile, simply run a terminal, go to your folder (remember it is cd android (MS-DOS-like command), where android is the folder you defined above) then type
Code:
make
. After a long time (depends on how much RAM you assigned to the machine, 512Mbits is slow), you will generate IMG files.
5. Regular use
If you want to get the latest source files (ie you have 2.1 files and want 2.2.1 files), simply run a terminal, go to your working folder and type
Code:
repo sync
. This should do the trick (correct me if I'm wrong)
Compiling sources takes hours to process, and you may want to kill the compile or pause it. You can then abuse of these keyboard shortcuts (common to Ubuntu OS) :
Code:
CTRL+C
will kill the process. Use it carefully, as it instantly kills it with no prompt.
Code:
RIGHT CTRL+P
is a Virtualbox command. Il will pause the whole Ubuntu (and also your process), and makes the screen ugly/gray (it just stuck the screen on Virtualbox v4.x). This is helpful when you run a Virtual machine, as you can pause the OS and make your computer to sleep/hibernate (or save an image - do NOT turn off your computer, as it will turn off the Virtual machine also !). Out of sleep, you can type again RIGHT CTRL+P to make the process to continue.
** Please note it might be risky to flash your phone with the stock rom you compiled (I mean with no modification), as this is not intended to work on X10
** Please note this install is for AOSP and NOT for Android SDK (you can install it with ease).
What's the difference ?
Android Open Source Project (AOSP) allows you to get the source code of the Android Operating System, in order to improve/change it, and create your personalized Android operating system
Android SDK allow you only to create and edit apps for Android Operating System.
Please note that compiling takes hours to process ! (3 hours or more)
** For any question, deeper info : please FIRST read official documentation. Easy to use, you'll get all info ! **
man...did you ever stop?!
THANKS FOR INFO. If you can explain how to make system images for our X10 then we can use the dual boot option to make gingerbread or froyo roms for dual boot using Zhidu chargemon file.
I am not clear on making and android system image for the x10. can we extract a system image from a running rom? that way I could make a system image of black freedom and we can all dualboot it instead of installing it.
rendeiro2005 said:
man...did you ever stop?!
Click to expand...
Click to collapse
Lol I can't stop
@SuperUserMovado : I'd love to know, unfortunately I am like you - I don't know how to do this. I'm gonna get several info there and there and try to do some stuff
Regarding Zd's Dual, please note it is not compatible with his xRecovery, which makes things a bit boring when you want to easily install a custom rom AND benefit of Dual Boot.
Dual boot by the way is an excellent idea, but it has limitations (of course), like no SD card mount and few other things because it run from SD card and not from NAND.
EDIT : here is a good start : http://source.android.com/porting/index.html
I have just started playing with this and have compiled one aosp rom from source. I think it can be extracted from a running rom but I'm not sure how yet. On the other hand it looks like the source is available on the se dev website. I'm having trouble downloading it... not sure yet if its on my end or theirs.
Here's the error if someone could help me out: (Ubuntu 64bit)
Archive: /tmp/X10_X10mini_X10_minipro_X8_2.0.A.0.504.tar.gz-4.zip
[/tmp/X10_X10mini_X10_minipro_X8_2.0.A.0.504.tar.gz-4.zip]
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
zipinfo: cannot find zipfile directory in one of /tmp/X10_X10mini_X10_minipro_X8_2.0.A.0.504.tar.gz-4.zip or
/tmp/X10_X10mini_X10_minipro_X8_2.0.A.0.504.tar.gz-4.zip.zip, and cannot find /tmp/X10_X10mini_X10_minipro_X8_2.0.A.0.504.tar.gz-4.zip.ZIP, period.
Check this site out as well. The whole site is really helpful. I'm in the process of compiling a captivate rom with some slight changes and i hope it works.
Edit: Btw if you get the error repo not found, type this into the command line
code:
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
then close the terminal, reopen another one and it should work
@superusermovado
I'm pretty sure you use unyaffs for the system.img and split_bootimg.ph for the boot.img.
That's how to decompile an update.zip.
From there you recompile as usual. I'm not going to post the instructions because they are all over the net.
Hint: Andy rubins tweet lol
gavriel18 said:
I have just started playing with this and have compiled one aosp rom from source. I think it can be extracted from a running rom but I'm not sure how yet. On the other hand it looks like the source is available on the se dev website. I'm having trouble downloading it... not sure yet if its on my end or theirs.
Here's the error if someone could help me out: (Ubuntu 64bit)
Archive: /tmp/X10_X10mini_X10_minipro_X8_2.0.A.0.504.tar.gz-4.zip
[/tmp/X10_X10mini_X10_minipro_X8_2.0.A.0.504.tar.gz-4.zip]
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
zipinfo: cannot find zipfile directory in one of /tmp/X10_X10mini_X10_minipro_X8_2.0.A.0.504.tar.gz-4.zip or
/tmp/X10_X10mini_X10_minipro_X8_2.0.A.0.504.tar.gz-4.zip.zip, and cannot find /tmp/X10_X10mini_X10_minipro_X8_2.0.A.0.504.tar.gz-4.zip.ZIP, period.
Check this site out as well. The whole site is really helpful. I'm in the process of compiling a captivate rom with some slight changes and i hope it works.
Edit: Btw if you get the error repo not found, type this into the command line
code:
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
then close the terminal, reopen another one and it should work
Click to expand...
Click to collapse
Thanks for info
About this package, what's the content ?? The easiest way is to download from XDA the generic global rom, it's the same -- with no bug
Perceval from Hyrule said:
Thanks for info
About this package, what's the content ?? The easiest way is to download from XDA the generic global rom, it's the same -- with no bug
Click to expand...
Click to collapse
Huh? The generic ROM is compiled. The one we are talking about here is source-code. I thought you should know since you started this topic on how to setup a build environment. Im not intirely sure what the download from from SE is but it looks like the source-code from all the changes and additions SE made to the bare system. So there's the kernel source and some other stuff that I don't know the purpose of.
Sent from my SNES using Mario Paint
LouNGeRR said:
Huh? The generic ROM is compiled. The one we are talking about here is source-code. I thought you should know since you started this topic on how to setup a build environment. Im not intirely sure what the download from from SE is but it looks like the source-code from all the changes and additions SE made to the bare system. So there's the kernel source and some other stuff that I don't know the purpose of.
Sent from my SNES using Mario Paint
Click to expand...
Click to collapse
A compiled rom is not a problem
I was asking what was the content within the rom, and as you said - i supposed too - it is the original + all SE garbage.
Very interesting to get some apps back on AOSP (some like the *Scape, i do like predictive input from SE, gains a lot of time)
To answer then, the SE kit should contain everything of what SE adds : RachaelUI, all their apps (the *Scape), modules (keyboard, apis...), etc etc and all files to link these components to the kernel. And make our phones as fast as a monster truck. Not as fast as AOSP (Formula 1 !!!!!)
Don't forget the most important part, the package contains the SE kernel.
Sent from my SNES using Mario Paint
After using, struggling more like with Ubuntu and VMware, the main issue being I couldn't figure out getting VMware tools running so copy and pasting was hit and miss, I tried the Cygwin method instead which works much better for me on Windows 7 Ultimate x64.
XperiaX10iUser said:
After using, struggling more like with Ubuntu and VMware, the main issue being I couldn't figure out getting VMware tools running so copy and pasting was hit and miss, I tried the Cygwin method instead which works much better for me on Windows 7 Ultimate x64.
Click to expand...
Click to collapse
VMWare is much more difficult to run than VirtualBox. But course you can try and compile Android from Windows
But I definitely can't tell you if the kitchen method will work for XPERIA.
Perceval from Hyrule said:
VMWare is much more difficult to run than VirtualBox. But course you can try and compile Android from Windows
Click to expand...
Click to collapse
I've put VB on too, but thought I'd try the Cygwin method, which as I've said works for me, and is better imo, at least for what I need.
Perceval from Hyrule said:
But I definitely can't tell you if the kitchen method will work for XPERIA.
Click to expand...
Click to collapse
I can, and it does.
XperiaX10iUser said:
I've put VB on too, but thought I'd try the Cygwin method, which as I've said works for me, and is better imo, at least for what I need.
I can, and it does.
Click to expand...
Click to collapse
Thanks for info then
Hey guys, did someone do the same install as me ? (Windows 7 x64 host // Ubuntu 10.10 x64 guest).
I've never been able to make USB to work, kinda weird... Because when you compile Android, you'd like to send it to your phone *warning !*
Perceval from Hyrule said:
Hey guys, did someone do the same install as me ? (Windows 7 x64 host // Ubuntu 10.10 x64 guest).
I've never been able to make USB to work, kinda weird... Because when you compile Android, you'd like to send it to your phone *warning !*
Click to expand...
Click to collapse
That's why I went the Cygwin route, much less hassle imo.
XperiaX10iUser said:
That's why I went the Cygwin route, much less hassle imo.
Click to expand...
Click to collapse
I would say it depends. Linux environment is much cooler to work with source files (no boring "NOOO Windows can't find how to open this weird non-Windows file. What to do ? 1.Delete 2.Crash Windows 3.Phone Ballmer to make a tender offer)
Is compiling long with Cyg ? From AOSP, it takes me up to 3 hours with my (well RAM-ed, well CPU-ed) Virtual Machine.
************ UPDATE *****************
update.zip flashable for DSC and DSC PDroid can be found at
openssl 1.0.1e update for DSC/407
*****************************************
Hello,
you may have heard of the badly choosen default ssl ciphers (1) in gingerbread.
Gingerbread devices use outdated encryption algorithms for ssl communication.
That problem effects also gingerbread based roms like 407 or dsc. You can check this by sending
your default browser (or for example nakedbrowser) to a ssl browser test-server (2)
You will get a result like in attachment 1 ciphers_original: We are using the RC4-SHA without perfect forward secrecy. That is problematic cause of the Lucky 13 attack agains this encryption (3)
With some patch in core.jar in our framework (attachment ciphers_reorder.patch) I got DHE-RSA-AES128-SHA which is considered more secure and also supports perfect forward secrecy. (attachment ciphers_pfs)
You can get my core.jar from http://ge.tt/api/1/files/1MKLbUv/0/blob?download. Install it into /system/framework and rebuild your dalvik-cache.
I can't support TLSv1.1 or TLSv1.2 yet, because it would need to recompile a more recent version of libssl.so.
Users of Opera get even DHE-RSA-AES256-SHA in their connection (attachment ciphers_opera) which is considered state-of-the art cryptography. But even than, other android apps will use the badly choosen systems default. So it is a good idea even for opera
users, to update core.jar.
Can please someone confirm my findings, and install core.jar in a 407 or dsc rom and check your browser on (2)
(1) http://op-co.de/blog/posts/android_ssl_downgrade/
(2) https://cc.dcsec.uni-hannover.de/
(3) http://www.isg.rhul.ac.uk/tls/Lucky13.html
@hunderteins,
Thanks for the post.
I am on currently BB407, PCM ROM. Should I do this too?
How is it, which one to choose? Copy your given "core.jar" and paste to "/system/framework" and rebuild your dalvik-cache... OR flash " ciphers_reorder.patch" ?
Ops, sorry I don't know how to handle file.patch... how is it?
Attached are test run using Firefox and Opera.
I have also run using STOCK browser, BOAT browser, and ONE browser. Result same as you shown in your post's 1st picture.
Dell Streak | InnerSD 8GB | ExternalSD 32GB | Custom ROM
Razak RK said:
I am on currently BB407, PCM ROM. Should I do this too?
Click to expand...
Click to collapse
don't know pcm rom. Can you checksum your /system/framework/core.jar ?
For example
Code:
$ sha1sum /system/framework/core.jar
126bad1df158f1af179d353ecd9e781501a30c73 /system/framework/core.jar
$ md5sum /system/framework/core.jar
1b1c955e837b4413fcbeead0a54cd4b7 /system/framework/core.jar
If you get the same values as above, it's safe to copy my core.jar into
your /system/framework/ and rebuild dalvik-cache (for example with a restart).
If you have other checksum values, you would need to decompile (smali) your core.jar, apply the patch-file and compile (smali) it again and replace classes.dex in your core.jar.
Razak RK said:
Attached are test run using Firefox and Opera.
I have also run using STOCK browser, BOAT browser, and ONE browser. Result same as you shown in your post's 1st picture.
Click to expand...
Click to collapse
Well thank your for the confirmation. Firefox seems also immune. The others use the default android classes.
There is one thing in firefox though. It is able to use TLSv1.2 on the desktop. I wonder if this would work on the mobile version also. Go into about:config and set security.tls.version.max from 1 to 3. Reconnect to the test-server. You should see a nice 'This connection uses TLSv1.2'
Good luck,
hunderteins
Thank you Hunderteins!
How about kernel 3.0?
Are you still working on it?
Regards...
hunderteins said:
don't know pcm rom. Can you checksum your /system/framework/core.jar ?
For example
Code:
$ sha1sum /system/framework/core.jar
126bad1df158f1af179d353ecd9e781501a30c73 /system/framework/core.jar
$ md5sum /system/framework/core.jar
1b1c955e837b4413fcbeead0a54cd4b7 /system/framework/core.jar
If you get the same values as above, it's safe to copy my core.jar into
your /system/framework/ and rebuild dalvik-cache (for example with a restart).
If you have other checksum values, you would need to decompile (smali) your core.jar, apply the patch-file and compile (smali) it again and replace classes.dex in your core.jar.
Well thank your for the confirmation. Firefox seems also immune. The others use the default android classes.
There is one thing in firefox though. It is able to use TLSv1.2 on the desktop. I wonder if this would work on the mobile version also. Go into about:config and set security.tls.version.max from 1 to 3. Reconnect to the test-server. You should see a nice 'This connection uses TLSv1.2'
Good luck,
hunderteins
Click to expand...
Click to collapse
~•~•~•~•~
@hunderteins,
Thank you for your reply.
Here is the checksum I get when I run in Terminal Emulator:-
$ export PATH=/data/local/bin:$PATH
$sha1sum /system/framework/core.jar
1291fcce44f4be036e2209ccb46d3313b65bdfdc /system/framework/core.jar
$md5sum /system/framework/core.jar
19bd48b8eac1bb123a823d039415a344 /system/framework/core.jar
$
So, they are NOT the same.
I don't have knowledge of how to decompile (smali) of core.jar, applying the patch-file, compile (smali) it again and replace classes.dex in my core.jar. Nope... I'm stuck to go further.
As for Firefox mobile on my Streak PCM7, I have check the menu and settings, here is NO option as per you mention.
Reason I'm interested to know is to set my Streak at best.
BTW, I'm currently installing and testing all the Streak Custom ROMs in XDA, trying to find a ROM that would probably best for my daily use = Performance+Save Power+Other Features. I probably end up having to learn to mix some ROMs into my own personal use...if I got the time to do it though...
Dell Streak | InnerSD 8GB | ExternalSD 32GB | Custom ROM
Razak RK said:
I don't have knowledge of how to decompile (smali) of core.jar, applying the patch-file, compile (smali) it again and replace classes.dex in my core.jar. Nope... I'm stuck to go further.
Click to expand...
Click to collapse
basically you need http://code.google.com/p/smali/downloads/list
a good tutorial how the framework is decompiled/updated can be found at
http://forum.xda-developers.com/showthread.php?t=1084850
for how to apply a patch to a source-file consult the manpage of patch
back to topic. I updated core.jar http://ge.tt/api/1/files/7F3UKbv/0/blob?download
Now DHE-RSA-AES256-SHA is included in the list of useable ciphers.
This way in stockbrowser/nakedbrowser the same encrpytion is used as in opera/firefox
look into attached image.
Patch is also included for thoose who find it useful.
Have a nice weekend,
hunderteins
sinan33 said:
How about kernel 3.0?
Are you still working on it?
Click to expand...
Click to collapse
didn't post in that thread, did I?
hunderteins said:
didn't post in that thread, did I?
Click to expand...
Click to collapse
Sorry dude; just eagerness
Confirmed working on Traveller DSC. ROM updates will be coming shortly.
Flashable zip for core.jar patch suitable for DSC and Traveller DSC: MediaFire | Mega
Elliptic curve Diffie–Hellman Key exchange
Hello,
the libssl 1.0.0a on the streak supports elliptic curve Diffie–Hellman key exchange.
With the right server, this speeds up https compared to normal Diffie–Hellman key exchange.
So I had to change the core.jar again to support these cyphers.
With this update I removed the know weak ciphers (export, 56bit etc)
I attached a openssl command for the commandline, to check libssl.so for features. It might
be useful elsewhere.
Have fun,
hunderteins
TLSv1.1 and TLSv1.2 protocol
Hello,
SSLv3/TLSv1.0 are known to be problematic with stream ciphers (the cbc ones) and
as mentioned before, I had to compiled a more recent version of libssl to support
the modern TLS variants.
Attached are the openssl binary and the libssl.so and libcrypto.so of openssl 1.0.1e.
They work on my streak and I get a clean https TLSv1.2 connection to the testserver.
Next step is, to modify core.jar again to get the modern GCM streaming methods
and SHA384 hashes.
Have a nice evening,
hunderteins
GCM streaming, sha384 hashes and server name indication (SNI)
Hello,
as mentioned before, I modified core.jar to match the ciphers from libssl 1.01e. So we get modern ciphers like ECDHE-RSA-AES256-GCM-SHA384 which are considered strong cryptographie. That's even more recent than Android 4.4 KitKat.
But Android Gingerbread has another serious flaw: SNI (server name indication) is not supported with Apache Http Client. Google fixed this *tada* in Honeycomb.
I looked into that problem, but we have to change framework.jar for that, too.
I attached the patches against the backsmalied core.jar and framework.jar. Together with openssl 1.0.1e I get a very beautiful https connection to the testservers (attached screenshots): ECDHE-RSA-AES256-GCM-SHA384 with TLS V1.2 and SNI - in stock android 2.3 browser.
Please confirm my findings. I'll try to make an streakmod compatible update.zip to spread that little security to the masses. If you point me to your core.jar/framework.jar I will consider to integrate your rom into that update.zip.
Have fun,
hunderteins
So if I understand how you put the update.zip together, the update patches the files rather than simply copying a new version of the file over the existing one?
BTW, the PDroid version is working perfectly.
Strephon Alkhalikoi said:
So if I understand how you put the update.zip together, the update patches the files rather than simply copying a new version of the file over the existing one?
BTW, the PDroid version is working perfectly.
Click to expand...
Click to collapse
Thank you for your feedback.
Update.zip deploys openssl 1.0.1e into /system/lib and /system/bin. It replaces classes.dex inside framework.jar and core.jar when the sha1_check is correct. That is mostly like replacing the files itself, because classes.dex is the main ingredient.
An elegant way would be to baksmali/smali on the device itself, but that didn't work because of memory constraint.
have fun,
hunderteins
openssl 1.0.1g for android 2.3
Hello,
you may have heard of the heartbleed bug [1] before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected. So I made an updated package and attached it. Just put the files into your /system/bin and /system/lib and reboot.
Good luck,
hunderteins
[1] http://heartbleed.com/
hunderteins said:
Hello,
you may have heard of the heartbleed bug [1] before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected. So I made an updated package and attached it. Just put the files into your /system/bin and /system/lib and reboot.
Good luck,
hunderteins
[1] http://heartbleed.com/
Click to expand...
Click to collapse
I'll make a flashable zip for this shortly as well as release an update to Traveller DSC.
hunderteins said:
you may have heard of the heartbleed bug before. The 1.0.1e version of openssl I did build for the Dell Streak last autumn is affected.
Click to expand...
Click to collapse
I stand corrected. The 1.0.1e version was build with -DOPENSSL_NO_HEARTBEATS. So it was not affected at all. Tested it with the stock browser and naked browser against pacemaker [1].
Anyway, 1.0.1g is not affected, too.
warning: Stock browser on Android 4.1.1 is affected.
[1] https://github.com/Lekensteyn/pacemaker
Regardless, the upgrade to 1.01g should improve performance slightly, shouldn't it?
Strephon Alkhalikoi said:
Regardless, the upgrade to 1.01g should improve performance slightly, shouldn't it?
Click to expand...
Click to collapse
I don't think so. As of today in 1.0.1-versions of openssl there are only bugfixes. New, improved features are in 1.0.2. [1]
The changelog between 1.0.1e and 1.0.1g shows detailed bugfixes:
Code:
Changes between 1.0.1f and 1.0.1g [7 Apr 2014]
*) A missing bounds check in the handling of the TLS heartbeat extension
can be used to reveal up to 64k of memory to a connected client or
server.
Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <[email protected]> and Bodo Moeller <[email protected]> for
preparing the fix (CVE-2014-0160)
[Adam Langley, Bodo Moeller]
*) Fix for the attack described in the paper "Recovering OpenSSL
ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack"
by Yuval Yarom and Naomi Benger. Details can be obtained from:
http://eprint.iacr.org/2014/140
Thanks to Yuval Yarom and Naomi Benger for discovering this
flaw and to Yuval Yarom for supplying a fix (CVE-2014-0076)
[Yuval Yarom and Naomi Benger]
*) TLS pad extension: draft-agl-tls-padding-03
Workaround for the "TLS hang bug" (see FAQ and PR#2771): if the
TLS client Hello record length value would otherwise be > 255 and
less that 512 pad with a dummy extension containing zeroes so it
is at least 512 bytes long.
[Adam Langley, Steve Henson]
Changes between 1.0.1e and 1.0.1f [6 Jan 2014]
*) Fix for TLS record tampering bug. A carefully crafted invalid
handshake could crash OpenSSL with a NULL pointer exception.
Thanks to Anton Johansson for reporting this issues.
(CVE-2013-4353)
*) Keep original DTLS digest and encryption contexts in retransmission
structures so we can use the previous session parameters if they need
to be resent. (CVE-2013-6450)
[Steve Henson]
*) Add option SSL_OP_SAFARI_ECDHE_ECDSA_BUG (part of SSL_OP_ALL) which
avoids preferring ECDHE-ECDSA ciphers when the client appears to be
Safari on OS X. Safari on OS X 10.8..10.8.3 advertises support for
several ECDHE-ECDSA ciphers, but fails to negotiate them. The bug
is fixed in OS X 10.8.4, but Apple have ruled out both hot fixing
10.8..10.8.3 and forcing users to upgrade to 10.8.4 or newer.
[Rob Stradling, Adam Langley]
It is sad, that on regular android devices, these bugfixes never see the light. Basically you can take these known bugs and rig most of the android 4.x devices.
reg. hunderteins
[1] http://www.openssl.org/news/changelog.html
Regardless, it's not a bad thing to have the latest version.
[Q&A] [TOOL][UTILITY] Carliv Image Kitchen for Android - unpack/repack boot-recovery
Q&A for [TOOL][UTILITY] Carliv Image Kitchen for Android - unpack/repack boot-recovery
Some developers prefer that questions remain separate from their main development thread to help keep things organized. Placing your question within this thread will increase its chances of being answered by a member of the community or by the developer.
Before posting, please use the forum search and read through the discussion thread for [TOOL][UTILITY] Carliv Image Kitchen for Android - unpack/repack boot-recovery. If you can't find an answer, post it here, being sure to give as much information as possible (firmware version, steps to reproduce, logcat if available) so that you can get help.
Thanks for understanding and for helping to keep XDA neat and tidy!
This looks like a really great tool but I'm having troubles with it.
gzip: ../boot.img-ramdisk.gz: not in gzip format
cpio: premature end of archive
Your ramdisk archive is corrupt. Are you trying to unpack a MTK image with regular script?
If so, please use unpack_MTK_img script. ERROR!
>> Exit script
when I use MTK it says
Unpacking the ramdisk....
gzip: ../boot.img-ramdisk.gz: not in gzip format
cpio: premature end of archive
Your ramdisk archive is corrupt. Are you trying to unpack a regular image with MTK script?
If so, please use unpack_img script. ERROR!
>> Exit script
this is for the LG Optimus F3 Boot.img from Team Win 2.8.0.0
is there any way to extract this puppy?
Code:
Printing information for "boot.img"
Android image info utility by [email protected]
Header:
Magic : ANDROID!
Magic offset : 0x00000000
Page_size : 2048 (0x00000800)
Base address : 0x80200000
Kernel address : 0x80208000
Kernel size : 7602936 (0x007402f8)
Kernel offset : 0x00008000
Ramdisk address : 0x88f108f0
Ramdisk size : 2048 (0x00000800)
Ramdisk offset : 0x08d108f0
Second address : 0x81100000
Tags address : 0x80200100
Tags offset : 0x00000100
Cmdline : 'androidboot.hardware=fx3s user_debug=31 vmalloc=308M'
Id : 46c3c0e3d52bc3f86497ddd8f07eae74643c5f0e
Successfully printed all informations for boot.img
HappyRoms said:
This looks like a really great tool but I'm having troubles with it.
gzip: ../boot.img-ramdisk.gz: not in gzip format
cpio: premature end of archive
Your ramdisk archive is corrupt. Are you trying to unpack a MTK image with regular script?
If so, please use unpack_MTK_img script. ERROR!
>> Exit script
when I use MTK it says
Unpacking the ramdisk....
gzip: ../boot.img-ramdisk.gz: not in gzip format
cpio: premature end of archive
Your ramdisk archive is corrupt. Are you trying to unpack a regular image with MTK script?
If so, please use unpack_img script. ERROR!
>> Exit script
this is for the LG Optimus F3 Boot.img from Team Win 2.8.0.0
is there any way to extract this puppy?
Code:
Printing information for "boot.img"
Android image info utility by [email protected]
Header:
Magic : ANDROID!
Magic offset : 0x00000000
Page_size : 2048 (0x00000800)
Base address : 0x80200000
Kernel address : 0x80208000
Kernel size : 7602936 (0x007402f8)
Kernel offset : 0x00008000
Ramdisk address : 0x88f108f0
Ramdisk size : 2048 (0x00000800)
Ramdisk offset : 0x08d108f0
Second address : 0x81100000
Tags address : 0x80200100
Tags offset : 0x00000100
Cmdline : 'androidboot.hardware=fx3s user_debug=31 vmalloc=308M'
Id : 46c3c0e3d52bc3f86497ddd8f07eae74643c5f0e
Successfully printed all informations for boot.img
Click to expand...
Click to collapse
Can you attach that image here, to take a look? It sounds like there is no ramdisk in it. There are some phones that doesn't have ramdisks in boot images.
carliv said:
Can you attach that image here, to take a look? It sounds like there is no ramdisk in it. There are some phones that doesn't have ramdisks in boot images.
Click to expand...
Click to collapse
Sure thing, just remove .zip from the file name, had to do that as it only allows 8Mb img uploads
I'm trying to edit the boot so that I might be able to make the external SD into the data drive, is this even possible or am I wasting my time?
Thanks!
HappyRoms said:
Sure thing, just remove .zip from the file name, had to do that as it only allows 8Mb img uploads
I'm trying to edit the boot so that I might be able to make the external SD into the data drive, is this even possible or am I wasting my time?
Thanks!
Click to expand...
Click to collapse
Ok, I see... Your image is "lokified". In order to use my tool you need to "de-lokify" it first, then after modding you need to "re-lokify" it back. Some infos here and here. It may be many other infos but I didn't have time to do a full search; you have to do it for yourself.
Some LG and Samsung devices have that "Loki" thing and you need to deal with it. Maybe when I'll have a phone like that I'll make an automated process for it, but now I haven't and I can't work "in blind".
I don't know what to say about your last question... I'm not even sure what you're talking about.
carliv said:
Ok, I see... Your image is "lokified". In order to use my tool you need to "de-lokify" it first, then after modding you need to "re-lokify" it back. Some infos here and here. It may be many other infos but I didn't have time to do a full search; you have to do it for yourself.
Some LG and Samsung devices have that "Loki" thing and you need to deal with it. Maybe when I'll have a phone like that I'll make an automated process for it, but now I haven't and I can't work "in blind".
I don't know what to say about your last question... I'm not even sure what you're talking about.
Click to expand...
Click to collapse
Awesome, thanks!
basically, the LG Optimus F3 comes with too little memory built in, there's a program that mounts an external SD's second partition as a data folder, but even still it runs out of internal memory or won't install apps larger than the internal memory because the "System" partition still has little room.
so the goal was to edit the boot so it will boot using an external SD directly as the system drive, it would read it's maximum memory available as whatever the external SD's maximum is.
this would solve the problem, if it works, if not then it'll probably just brick the phone :good:
I just wanted to update and say thanks. This helped out great! I was able to successfully boot /data from my external SD card as desired, however, my card is only a class 2 so it won't be a good idea until I upgrade it to a class 10.
Lg Optimus F3 comes with very little internal storage, which was giving me a headache, so I wanted to make the phone boot using an external SD as the /data partition.
after following your tip, I unloki'd the boot image and used your Carliv Image Kitchen to extract the contents, edited the fstab and edited out the original code: "/dev/block/platform/msm_sdcc.1/by-name/userdata /data" telling it to mount /data on the /dev/block/mmcblk1p2 instead.
after repacking and re-loking and flashing the .img it had some problems, for some reason it was just booting to a black screen, so I used dd from the team win terminal to copy the /dev/block/platform/msm_sdcc.1/by-name/userdata over to the /dev/block/mmcblk1p2, and it worked!
being a class 2, it booted slowly and responded slowly but works none the less.
to be sure there was no problem with partition size, being how I used dd to mirror userdata over to the sdcard, I ran gparted in linux and resized the partition smaller, then larger to full size (just in case)
thanks for your wonderful tool and for pointing me in the right direction.
help sir carliv please
I was trying to install cm12 using carliv touch recovery 3.3 for kit kat on my alcatel pop d3 but it failed now my phone is stuck and wont turn on
what version of cm can that recovery install??????
DONTEGO said:
I was trying to install cm12 using carliv touch recovery 3.3 for kit kat on my alcatel pop d3 but it failed now my phone is stuck and wont turn on
what version of cm can that recovery install??????
Click to expand...
Click to collapse
The answer is already in your question:
I was trying to install cm12 using carliv touch recovery 3.3 for kit kat....
Click to expand...
Click to collapse
As I already posted in recovery's thread, it will work with kitkat kernels. Some people port it to lollipop but I never recommended that.
So to answer clearly cm11 because cm12 means lollipop, or it will work with any other kitkat based ROM if your phone has any kitkat kernel released.
You need to ask the one who released that cm12 for your phone to provide a matching recovery along.
Now you probably need to reflash the phone with SPFlashTools.
ok thanks a whole lot but im having another issue the sd card is now only readable by my phone how do i go about copying a rom to it whenever i plug it into the pc it doesnt come up
DONTEGO said:
ok thanks a whole lot but im having another issue the sd card is now only readable by my phone how do i go about copying a rom to it whenever i plug it into the pc it doesnt come up
Click to expand...
Click to collapse
im trying to install Mystic_OS_v4DL750.zip does it require a gapps package?
Can some one port ne a recovery for xolo era 4g
Sent from my Hacked_Era_4G using Tapatalk
Is it able to unpack stock recovery?
---------- Post added at 03:25 AM ---------- Previous post was at 03:23 AM ----------
Raakib Zargar said:
Can some one port ne a recovery for xolo era 4g
Sent from my Hacked_Era_4G using Tapatalk
Click to expand...
Click to collapse
Which chipset?
Hi there... I woul like to ask if this tool works for Helio x20 cpu's... (Mt6797 - Leagoo T10) because I'm trying to extract the stock recovery but having trouble with the ramdisk... It says "compression used unknown..." I've seen it mentioned in the discussion some times but the explanation was to use the 1. Metod ??? I'm using the windows 1.1 version and I really don't see any other method to use (start bat, r, 1 recovery.img, , 1 unpack image, error....) I'm just installing Ubuntu to see the difference but would be grateful for some advise... Thanks.
Since main Carlive Image Kitchen thread has been closed in 2017 all the util builds have been lost for some unknown reason. Dev claimed he have personal problems and adviced users to help each other.
I've found latest official version 1.3 builds and publish them here for practical and historic reasons. This util mentioned in a various manuals so people will look for it for a long time then. Old Linux modded version by yuweng is also added for completeness.
View attachment CarlivImageKitchen_Windows_v1.3.zip
View attachment CarlivImageKitchen_Windows_x64_v1.3.zip
View attachment CarlivImageKitchen-Linux_v1.3.zip
View attachment CarlivImageKitchen-Linux_x64_v1.3.zip
View attachment CarlivImageKitchen-Linux-DnD-yuweng.zip
Furthermore user FOV5 @ 4pda.ru forums have modded latest 1.3 version a few times so I do publish here his latest modded version 1.5B3 (12-Jan-2018)
Changes history:
- v1.4: Support for some non-standard kernel images (e.g. LibreELEC and similar).
- v1.5B1:
- Removed 'Boot' and 'Recovery' prefixes from file names while unpacking Boot/Recovery images. This is due to ability to easily compare whole Boot and Recovery folders after unpacking.
- Added optional experimental AmLogic core unpacking. This could be helpful to patch storage media layout when device partition build into the core.
- v1.5B2: Fixed 32 bit app crash after core unpacking. A few other small non critical fixes.
- v1.5B3:
- New while core slitting, parameters like Name, Load Address and Entry Point are preserved.
- Fixed: New app will try to pack core only when all the 4 kernel parts are found in the unpacking folder. If core unpacking process some kind failed, one or more kernel.* files will be missing, so repack process will use original core instead of trying to assemble broken one.
View attachment CarlivImageKitchen_Windows_v1.5B3.7z
If you have any questions related to this modded app version look for FOV5 user at 4pda.ru forums and ask him (I don't know does he speak any langs except Russian, online translators available anyway. There is also Russian numeric captcha problem for non-Russian speakers when loggin in to that forums, sorry guys). I do not often use this app and occasionally visit XDA, so I can't support this product in a professional manner. Help each other guys!
I'm not an active developer but I'm also not a *total* noob -- I've successfully compiled usable kernels for Nexus 4, Moto G, HP TouchPad -- but I'm not making much headway on my Z5C kernel.
I want to run an otherwise stock Sony ROM on my phone, but make a couple of minor tweaks to the kernel. With that in view, I downloaded the source tree from Sony's dev site for the kernel that matches the one that shipped with the ROM I am currently running (at the moment, for Reasons, it's a Lollipop one, and I'm not really interested in debating that point anyway), and then I started by building a kernel with ZERO changes applied first. But it will not boot. Instead, with my first attempt at a kernel compiled from scratch, after the Sony Xperia boot logo and before the boot animation would normally kick in, the screen goes black and the notification LED blinks red 4 times, and then it reboots and starts over (bootloop).
I'm not sure what I am supposed to do to diagnose the problem since the screen doesn't display anything and it never gets far along enough in the boot process to where the USB port is initialized. And, yes, the bootloader is unlocked (I can flash a stock kernel to the phone with the DRM fix applied, and that boots and works just fine).
Here is what I have done so far:
Downloaded the kernel sources that match my ROM's kernel at https://developer.sonymobile.com/do...rchives/open-source-archive-for-32-0-a-6-200/
Downloaded the GCC 4.9 for ARM64 cross-compiler / toolchain from https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/
Applied kitakami_defconfig and suzuran_diffconfig, and built the kernel. It compiled cleanly without any errors.
Extracted kernel.elf from my ROM's kernel.sin, and then unpacked the binary image, initramfs, and device tree blob from that.
Re-packaged a new kernel into .img format for Fastboot flash by substituting in my kernel image binary for the official Sony one, but keeping the original ramdisk and DTB.
Flashed image to boot partition with Fastboot == bootloop
Flashed original kernel back == works fine
Decided to try creating a new DTB instead of reusing the one from the original kernel...but dtbTool spits out this:
Code:
Found file: msm8994-v2.0-kitakami_suzuran_generic.dtb ... skip, failed to scan for 'qcom,msm-id = <' tag
Found file: msm8994-v2.1-kitakami_suzuran_generic.dtb ... skip, failed to scan for 'qcom,msm-id = <' tag
Grabbed dtbToolCM from https://github.com/xiaolu/mkbootimg_tools instead, which seems to work.
Substituted in the new DTB image for the original Sony one, repackaged up a new boot.img, flashed that == bootloop
Tested my mkbootimg and the parameters I was using by extracting kernel, ramdisk, and DTB from original kernel.elf, then repackaging them all together into a boot.img and flashing that to the phone with Fastboot == works just fine
Hypothesized that perhaps my kernel didn't like the Sony kernel modules on the system partition because of version magic mismatch, so I changed CONFIG_LOCALVERSION from "-perf" to "-perf-g75e6207" in .config and rebuilt kernel, repackaged, reflashed with Fastboot == bootloop ... ARGH
So at this point, I'm at a loss. I've proven that it's not the way I am packaging up the boot image because if I repack the original Sony kernel binary up with the original ramdisk and DTB and then flash that file to the boot partition, that has no problem booting the phone. Is there some modification that I need to make to the contents of the ramdisk? I'd think I should just be able to use the stock Sony ramdisk unmodified, especially if the kernel itself doesn't differ at all (same sources, same .config) from the one Sony compiled, but...?
Any leads that any experienced Xperia Z-series kernel hackers out there can supply before I end up tearing my hair out would be greatly appreciated.
Thanks so so so much,
-- Nathan
[UPDATE]: Just tried assembling with mkqcdtbootimg instead. No go. Also unpacked the image made by that utility and verified that everything (e.g. offsets, etc.) looked sane. GARGH.
Oh, good grief...I answered my own question.
The version of the compiler has to match EXACTLY with what was used to build the rest of the system. I'm guessing because the compiler version has to match between kernel and kernel modules.
The git repo on googlesource.com that contains the prebuilt arm64 x-chain has been updated since the release of 32.0.A.6.200. Version string for gcc of most recent pull was "4.9.x-google 20150123 (prerelease)", but original kernel binary built by Sony had been compiled by gcc version "4.9.x-google 20140827 (prerelease)".
I finally found a version I could roll back to that contained that version string (commit hash 4b341df712969ca2ac0c3cf6294260d406b9d9be), and it worked.
Hopefully this helps someone else out someday,
-- Nathan
nlra said:
Oh, good grief...I answered my own question.
The version of the compiler has to match EXACTLY with what was used to build the rest of the system. I'm guessing because the compiler version has to match between kernel and kernel modules.
The git repo on googlesource.com that contains the prebuilt arm64 x-chain has been updated since the release of 32.0.A.6.200. Version string for gcc of most recent pull was "4.9.x-google 20150123 (prerelease)", but original kernel binary built by Sony had been compiled by gcc version "4.9.x-google 20140827 (prerelease)".
I finally found a version I could roll back to that contained that version string (commit hash 4b341df712969ca2ac0c3cf6294260d406b9d9be), and it worked.
Hopefully this helps someone else out someday,
-- Nathan
Click to expand...
Click to collapse
I think that cannot be possible. There are lots of kernels out there compiled with toolchains different than the stock one (e.g. Androplus kernel is compiled with UBERTC 4.9)
I am in the same situation as you, but with the Xperia X Compact:
-Untouched copyleft source code
-Untouched ramdisk
-Using AOSP mkbootimg (the new one written in Python: https://android.googlesource.com/platform/system/core/+/nougat-release/mkbootimg/mkbootimg) with arguments specified in README_Xperia (https://github.com/bamsbamx/BMSBMX_kernel_kugo/blob/master/README_Xperia)
And still no boot... I am about to give up on this as I cannot find any other solution...
You can see my build script here for reference: https://github.com/bamsbamx/BMSBMX_kernel_kugo/blob/master/utils/build.sh
bamsbamx said:
I think that cannot be possible.
Click to expand...
Click to collapse
*shrug* I don't know what to tell you. All I know is that I changed one variable at a time, and then when I finally changed the version of the compiler I was using, eureka.
That's not to say that there couldn't have been more than one variable in the equation, and that I happened to knock each pin down one at a time without knowing it. For example, I can tell you that the size of the DTB varied slightly between what dtbToolCM came up with, and what mkqcdbootimg generated, and that the DTB that was generated by mkqcdbootimg was EXACTLY the same size as the one in Sony's official kernel image while dtbToolCM's was not. But changing to mkqcdbootimg alone did not fix my issue.
My theory in the end -- which could be completely wrong -- was that maybe the kernel module version magic includes either part or all of the compiler version string, so until I found the compiler that matched the one that Sony used, the kernel modules that Sony built were unable to load when my kernel was booting. If that wasn't the problem, then maybe there was some other reason the kernel modules couldn't load...maybe a subtle GCC bug that was fixed between the version Sony used and the latest binaries on Google's git server that ended up generating code that is slightly incompatible between binaries produced by the two versions. Or maybe I'm completely cold and it had nothing to do with the kernel modules at all. I guess we will never know unless someone else feels like soldering serial console leads on their Z5's system board, 'cause I sure ain't gonna...
I can tell you that, in the end, I retained all of the following changes, and that with my build environment I no longer have problems producing kernels that will boot a stock Sony ROM:
- I still use what I believe to be the same compiler Sony used
- I still build kernels with CONFIG_LOCALVERSION set to match the exact version string that the stock Sony kernel for my ROM has
- I still continue to use mkqcdbootimg to assemble my DTB + my final image instead of any version of mkbootimg and dtbTool
I haven't tried changing out things other than the GCC version to see if that ends up breaking things again. If I manage to find some spare time to kill in the future, I may do so in order to satisfy my curiosity. If I ever get around to doing that, I'll be sure to update this thread with my results.
FWIW, the Z5 boot image is assembled slightly differently than it appears the X Compact's is for whatever reason. I can tell you, for example, that the Z5's bootloader (at least the stock one...I hear that there is an updated version obtainable through Sony's AOSP program) does not support gzipped kernels. Also, the DTB is assembled and kept separately from the kernel up until the final mkbootimg stage, whereas it appears that the DTB and kernel are concatenated together somehow during the build for the X Compact. The fact that differences like these exist may mean that none of my findings or experiences are necessarily applicable to you and your situation.
I also will note that although you said you are using the Python mkbootimg utility, your build script that you linked to claims otherwise...
Good luck, and if you happen to figure out what the problem ended up being in your case, I'd be very interested to get an update from you!
-- Nathan
nlra said:
*shrug* I don't know what to tell you. All I know is that I changed one variable at a time, and then when I finally changed the version of the compiler I was using, eureka.
That's not to say that there couldn't have been more than one variable in the equation, and that I happened to knock each pin down one at a time without knowing it. For example, I can tell you that the size of the DTB varied slightly between what dtbToolCM came up with, and what mkqcdbootimg generated, and that the DTB that was generated by mkqcdbootimg was EXACTLY the same size as the one in Sony's official kernel image while dtbToolCM's was not. But changing to mkqcdbootimg alone did not fix my issue.
My theory in the end -- which could be completely wrong -- was that maybe the kernel module version magic includes either part or all of the compiler version string, so until I found the compiler that matched the one that Sony used, the kernel modules that Sony built were unable to load when my kernel was booting. If that wasn't the problem, then maybe there was some other reason the kernel modules couldn't load...maybe a subtle GCC bug that was fixed between the version Sony used and the latest binaries on Google's git server that ended up generating code that is slightly incompatible between binaries produced by the two versions. Or maybe I'm completely cold and it had nothing to do with the kernel modules at all. I guess we will never know unless someone else feels like soldering serial console leads on their Z5's system board, 'cause I sure ain't gonna...
I can tell you that, in the end, I retained all of the following changes, and that with my build environment I no longer have problems producing kernels that will boot a stock Sony ROM:
- I still use what I believe to be the same compiler Sony used
- I still build kernels with CONFIG_LOCALVERSION set to match the exact version string that the stock Sony kernel for my ROM has
- I still continue to use mkqcdbootimg to assemble my DTB + my final image instead of any version of mkbootimg and dtbTool
I haven't tried changing out things other than the GCC version to see if that ends up breaking things again. If I manage to find some spare time to kill in the future, I may do so in order to satisfy my curiosity. If I ever get around to doing that, I'll be sure to update this thread with my results.
FWIW, the Z5 boot image is assembled slightly differently than it appears the X Compact's is for whatever reason. I can tell you, for example, that the Z5's bootloader (at least the stock one...I hear that there is an updated version obtainable through Sony's AOSP program) does not support gzipped kernels. Also, the DTB is assembled and kept separately from the kernel up until the final mkbootimg stage, whereas it appears that the DTB and kernel are concatenated together somehow during the build for the X Compact. The fact that differences like these exist may mean that none of my findings or experiences are necessarily applicable to you and your situation.
I also will note that although you said you are using the Python mkbootimg utility, your build script that you linked to claims otherwise...
Good luck, and if you happen to figure out what the problem ended up being in your case, I'd be very interested to get an update from you!
-- Nathan
Click to expand...
Click to collapse
Yeah, sorry about that, I didnt push the new commits to Github yet because of the kernel not booting, the current script I am using is this one:
Code:
#!/bin/bash
RED=1
GREEN=2
BLUE=4
colorPrint() {
tput setaf $2
echo $1
tput sgr0
}
colorPrint "Initializing workspace..." $BLUE
#Device config
device=kugo
#Workspace directories
workdir="$(pwd)"
outputfolder=${workdir}/OUTPUT
outputdir=${outputfolder}/${device}
toolchains=${workdir}/toolchains
ramdisk=${workdir}/ramdisks/${device}/ramdisk
export ARCH=arm64
export CROSS_COMPILE=${toolchains}/aarch64-linux-android-4.9-kernel/bin/aarch64-linux-android-
export KBUILD_DIFFCONFIG=kugo_diffconfig
colorPrint "Cleaning previous builds..." $BLUE
rm -rf $outputdir
mkdir -p $outputdir
colorPrint "Configuring kernel..." $BLUE
make msm-perf_defconfig O=$outputdir
colorPrint "Building kernel..." $BLUE
time make -j8 O=$outputdir 2>&1
if [ ! -f $outputdir/arch/arm64/boot/Image.gz-dtb ]; then
colorPrint "ERROR: kernel image not found. Kernel build failed" $RED
exit 1
fi
if [ ! -e $outputdir/ramdisk.cpio.gz ]; then
colorPrint "ERROR: ramdisk image file not found. Compression failed" $RED
exit 1
fi
colorPrint "Packaging boot image file" $BLUE
${workdir}/utils/mkbootimg \
--kernel $outputdir/arch/arm64/boot/Image.gz-dtb \
--ramdisk $outputdir/ramdisk.cpio.gz \
--base 0x20000000 \
--ramdisk_offset 0x02000000 \
--pagesize 2048 \
--tags_offset 0x01E00000 \
--cmdline "androidboot.hardware=qcom msm_rtb.filter=0x237 ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 zram.backend=z3fold earlyprintk" \
--output $outputdir/boot.img
if [ ! -f $outputdir/boot.img ]; then
colorPrint "ERROR: boot image file not found. boot packaging failed" $RED
exit 1
fi
colorPrint "DONE" $GREEN
colorPrint "boot image file can be found at ${outputdir}/boot.img" $GREEN
This one is for the build 34.3.A.0.217... However, I already had managed to boot copyleft kernel builds in other versions (such as 34.2.A.0.XXX) using the Github script, the UBERTC 4.9 Toolchain and not changing the GCC version, although I had to set # CONFIG_MODULE_SIG_FORCE is not set There must be something strange here
I think there must be something with kernel files permissions, or... maybe this? https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
@bamsbamx as usual, you have dm verity and sony RIC / security disabled, right ?
also hackery is possible to block modules from loading but since it comes at a later stage that most likely is not responsible for the kernel not booting
As alternative you could try https://github.com/sonyxperiadev/mkqcdtbootimg
Usually the instructions don't work with the copyleft kernel source, some fixes or adjustments are normally needed (at least my experience)
zacharias.maladroit said:
@bamsbamx as usual, you have dm verity and sony RIC / security disabled, right ?
also hackery is possible to block modules from loading but since it comes at a later stage that most likely is not responsible for the kernel not booting
As alternative you could try https://github.com/sonyxperiadev/mkqcdtbootimg
Usually the instructions don't work with the copyleft kernel source, some fixes or adjustments are normally needed (at least my experience)
Click to expand...
Click to collapse
Hi,
Nope, I didnt disable RIC neither dm-verity, the only thing I changed was CONFIG_MODULE_SIG_FORCE to 'is not set'. But I guess that wasnt the cause of kernel not booting since my /system partition is untouched. I tried both with mkqcdtbootimg and mkbootimg but still nothing
Hey @nlra, I figured out the problem (finally). The ramdisk I was using had been extracted from a .elf file (obtained via Flashtool through an .ftf file's kernel.sin). Somehow the extraction from the kernel.elf file is broken (resulting in a 7.0MB ramdisk.cpio.gz file)
I managed to pull up the boot.img from the device (via dd if=/dev/block/mmcplk0p33 of=/sdcard/boot.img) and then extract the ramdisk from it, resulting in a 11.4MB file
Then, I was able to boot it BOTH USING mkqcdtbootimg file and mkbootimg python script from AOSP nougat-release branch
Thats it
bamsbamx said:
The ramdisk I was using had been extracted from a .elf file (obtained via Flashtool through an .ftf file's kernel.sin). Somehow the extraction from the kernel.elf file is broken
Click to expand...
Click to collapse
Nice! Glad you figured out what was going on in your case, and thanks for confirming that both mkqcdbootimg and mkbootimg both work for building the X Compact boot image.
-- Nathan