Database Develop

[Q] Porting Meego to the Tab, some Android noob questions before I start

Hi chaps,
I've just bought a Galaxy tab with plans to port Meego to the device.
I'm new to all the Android stuff, and tbh the myriad methods for doing this/that/the other and the relative lack of explanation of what's actually being done in these various methods/tools is quite confusing (and worrying).
So, if you'll bear with me, I have a few questions which are probably quite basic.
I've rooted my Tab using SuperOneClick, no problems there, I also understand that there is a leaked flashing tool called (Multi)Odin and an open source flashing tool called Heimdall. I understand adb.
So onto the questions:
Before I start messing about, how should I backup my existing firmware image? I see people talking about taking image dumps using dd, or Odin or Heimdall. What is the preferred method? And how should one then restore the device from these backups?
Alternatively is it possible to simply download the firmware directly from Samsung (I see links to later firmware, but really I'd be happy with what I have currently - P1000XXJK5 and FROYO.XWJJ7)?
I'm assuming that the best installation method would be to replace recovery, then I can add my own kernel and have it boot a rootfs mounted on the external SD card for example. Any thoughts?
I've seen one thread about people compiling their own kernels, with panics and the like which are solved by giving the full path to the initramfs extracted from the existing image. Any clues as to why the built version doesn't work? This is not so important as I can have a look at this when I build the Samsung source.
Is anyone looking at the bootloaders? Is there any information anywhere about them (as changing the bootloader to allow selection of the kernel to be booted would make life easier)?
Thanks for your patience!

Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?

lardman said:
Ok, so to partly answer myself, I see www dot samfirmware dot com has links to downloads of firmware images.
I'd really prefer to generate my own image of what's currently on the device rather than trusting a download site, but I guess it's better than nothing. Does anyone know how these images were generated anyway?
Click to expand...
Click to collapse
Samfirmware get their images direct from Samsung insiders. They are not dumps.
If you want to dump from your device search "rotobackup" here in the dev forum.
Sent from my GT-P1000 using Tapatalk

alias_neo said:
Samfirmware get their images direct from Saunaing insiders. They are not dumps.
Click to expand...
Click to collapse
Ok that's reassuring.
alias_neo said:
If you want to dump from your device search "rotobackup" here in the dev forum.
Click to expand...
Click to collapse
Great, just what I was looking for, many thanks

So some more questions:
Any limit to the size of the kernel? Presumably just the size of the partition (which after extracting the image for backup seems to be a pretty large 15.4MB)?
What do all the .rc files in the raminitfs do? They are as follows: fota.rc, init.goldfish.rc, init.rc, init.smdkc110.rc, lpm.rc, recovery.rc
The init.rc is the normal init.rc file, so that's fine. Presumably the recovery.rc file is run if the bootloader detects that recovery mode is wanted (holding down keys during boot). The init.goldfish.rc? I guess this is to do with the emulator, though why it would be in a release image I don't know.
I assume that init.smdkc110.rc is automatically run somewhere along the line, though I don't see where it's started.
Any thoughts on lpm.rc and fota.rc? Are multiple .rc files run for the normal and recovery boots?
Thanks

lpm.rc is for low power mode that displays battery charging animation
goldfish is for running the rom under qemu.
backup your rom using rotobackup. compile samsung's kernel from sources, mix up default initramfs with meego's init scripts. pack all Meego stuff into loop mounted disk image. then flash zImage to kernel and your disk image to factoryfs using heimdall. I assume you have experience hacking N8xx/N900 and Maemo or Meego?
factoryfs is around 300MB so I think it should fit Meego and it (and kernel) can be easily restored with heimdall.

Thanks for the comprehensive reply
Yes I do have experience hacking Maemo/Meego, though have never really had to fiddle with init scripts before and this is as good a reason as any to learn.
I'd actually like to dual boot, so am modifying recovery.rc to bring up the Meego system on the external SD card.
Am just fiddling about building extra kernel modules now (needs btrfs for my image for example) and modifying the recovery.rc file.

Hmm, well I was all set to go and flash my new zImage and was looking for the heimdall command line, when I saw this at the top of one of the threads in this part of the forum (http://forum.xda-developers.com/showthread.php?t=870690):
Restoring to factory after using this process (you need using stock images):
heimdall flash --kernel stockzImage --recovery stockzImage --factoryfs factoryfs.rfs
Click to expand...
Click to collapse
Which has made me worry a bit that I've missed a recovery partition with its own kernel and wrongly assumed that the same kernel is used for both recovery and normal running, just with a different .rc file to be interpreted by init.
Any thoughts?

Do we trust the partition sizes reported here: http://forum.xda-developers.com/showpost.php?p=9471190&postcount=14
They seem very small for the kernel partition. I used RotoHammer's dd method to grab the contents of the partitions as a backup, so am assuming the sizes shown above are not correct (or represent something else?)
Going back to RECOVERY and ZIMAGE partitions - the ZIMAGE partition contains a recovery.rc, the question is really whether, even if they use the same zImage in both the ZIMAGE and RECOVERY partitions, the version in the RECOVERY partition is actually booted if recovery mode is selected (by holding the up volume key, etc.)? OTOH it may be that the RECOVERY partition is either empty or unused, has anyone tested specifically to see whether recovery.rc is run from the ZIMAGE partition?

Well I think I can answer my own question there, I flashed my modified kernel (modified recovery.rc) only to the KERNEL partition, and it boots normally if I don't touch anything, and just gets stuck on the first Samsung screen if I boot in recovery mode.
So it's doing something, I just can't tell what. Not sure if any kernel messages are getting lost behind that image, or perhaps they aren't even output to the framebuffer at all. I seem to remember seeing something about disabling the splashscreen so I'll go and have a look for that. Anyone got any other suggestions?
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?

I see from the Nexus S port that including adbd in the image seems to be the way to go for early messages, I'll need to generate a new Meego image and have another go later on.

Interesting, I can't see that I've done anything wrong, and my extra init shell script is not started. I am trying to use the "exec" keyword in recovery.rc to start a shell script which will pass control to the Meego rootfs. At the start of my shell script I start adbd (i.e. still within the initramfs), so I should be able to tell if it has started, and it doesn't appear to do so.
Therefore I did some Googling, and I've seen that in some cases the initramfs init does not implement the "exec" keyword (http://forum.samdroid.net/f9/new-init-exec-import-implemented-3280/). This is troublesome for me as it's what I'm trying to use, but at least would explain why I don't seem to leave the init process
I couldn't see the Samsung specific source for init anywhere, has anyone found any? I'm not happy to replace it using the standard Android source as I'm guessing there's code missing which allows the bootloader to tell init how the device was started so that it knows which of the .rc files to run. Has anyone looked into this?
Thanks

Looking at the code in that link it looks pretty straightforward, just a case of parsing the kernel command line (though I might just reverse engineer the existing init first to make sure I'm not missing anything).
Would still be easier to get the actual source code from Samsung, so I've emailed their Open Source group.

lardman said:
P.S. I also note there's a flash of screen corruption as the device starts up with my new kernel, I don't remember seeing that before. Is this a usual occurance?
Click to expand...
Click to collapse
I get it with CM

Does CM use a compressed initramfs? I'm using one of those and wondering if it's something to do with the (admittedly small) extra time required to move to init.
I don't have my Tab with me here, could someone post the output of /proc/cmdline please? You'll need to be root. Thanks.

Well it's booting you'll all be glad to hear.
More details to follow, but from memory the following were required:
Custom kernel to add btrfs support (as the image I'm booting is a btrfs partition on the external SD); kernel patch to allow compile-time cmdline to be added to the end of the bootloader cmdline (to enable console=tty0); replace Android init with init script to perform some basic setup then pivot_root to the Meego partition.
Next steps are to get the Meego system running usefully (which includes getting a terminal as currently I just have a login prompt but no way of inputting anything!) and also seeing whether I can get dual booting working with an Android system standard boot and Meego replacing the recovery boot.
Poor pic, but still: http://people.bath.ac.uk/enpsgp/Tab/PICT0040.JPG

Good stuff. Thanks for keeping us informed.

After you've got the groundwork for this done, how easy would it be to get Ubuntu running?

Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App

brilldoctor said:
Try google http://lmgtfy.com/?q=ubuntu+on+galaxy+tab
Sent from my GT-P1000 using XDA App
Click to expand...
Click to collapse
That's using chroot, which I don't want. I want it running natively.
Sent from my Galaxy Tab

Booting Ubuntu on the O2X

I've spent some (much) time this week with trying to get ubuntu running on the optimus 2x. I have succeeded to boot and get the wifi, X11 and the touch screen sort-of working.
The ramdisk is completely replaced with a busybox executable, some symlinks to it and a shell script that mounts the necessary stuff (/dev/block/mmcblk1p2 as ext3), changes root directory and calls /sbin/init.
USING THE FOLLOWING WILL VOID ANY WARRANTY YOU MIGHT HAVE LEFT AND MIGHT ALSO BRICK YOUR PHONE!
Seriously, don't do this if you don't wish to risk the data on your phone.
I will be providing some demo images for people who don't have a build environment up and running. These images will not work particularly well, don't get your hopes up .
If you want to have a big linux installation (more than 3 GB) you can flash the images to the second partition on your external sd (obviously you have to create this yourself first). You can use the following boot image (which assumes that linux is on /dev/block/mmcblk1p2 with ext3:
https://ha.xxor.net/o2x/boot-20110813.img
I have also targzipped the modifications to the file system that were required to get stuff going here:
https://ha.xxor.net/o2x/o2x-20110813.tar.gz
This should be extracted directly to the root file system.
The kernel source code is up at https://github.com/ergoen/LG-Optimus-2x-linux-kernel
Things that have been done to get this to "work":
1. Boot partition
Apart from grabbing the busybox stuff from some nexus one boot image (I'm sorry whoever fixed it, I don't remember where I got it from ) the boot command line had to be modified a bit, changing stuff from the default usually ends up in a phone that won't boot, but I discovered that it's possible to append new arguments to the default ones. So the following have been appended:
console=tty0 root=/dev/mmcblk1p2 init=/sbin/init
The console=tty0 makes sure that you see stuff on the screen while ubuntu get's running. The last two are not necessary to boot, but ubuntu seem to like (need?) them (or at least the init=/sbin/init), since otherwise you never get to the login prompt on the screen.
2. The Ubuntu installation
To make it possible to communicate with the phone at all adbd was put into the /sbin/ folder and a symlink was created /system/ -> /. Also the "/sbin/adbd recovery &" command was added to rc.local to make it autostart.
2.1. Modules and wifi
We need the /lib/modules/2.6.32.9 directory. Most files inside that were generated using the "depmod" command, the exception is wireless.ko which was taken from android, the firmware and nvram files needed for the wifi chip to work were placed in the /lib/firmware/wl/ folder. To make the wifi module autoload with the proper firmware "wireless" was added to /etc/modules and the file /etc/modprobe.d/wireless.conf was created with the contents describing the location of the firmware and nvram.
To make the wifi autoconnect on boot the /etc/network/interfaces file was modified with the following contents:
auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant.conf
(To make the wifi autoconnect to your wireless you need to run the command "wpa_passphrase networkname networkpassword > /etc/wpa_supplicant.conf using adb or chroot)
2.2. X11
Getting X up by running xinit produces a simple black screen on the phone. At first I thought the problem was that the refresh rate was set to 106 Hz, indeed changing it with xrandr and pushing a new mode got me a visible xterm on Kubuntu 11.04:
https://ha.xxor.net/o2x/xterm.jpg.
On Ubuntu 10.10 it even gave me a nice colored gdm screen:
https://ha.xxor.net/o2x/gdm.jpg
But the image I got there was static and wasn't being updated. Turns out the reason the screen was black earlier with the 106 Hz rate and the reason why the screen is now just showing an image is that the framebuffer device doesn't update the screen like it should..
By modifying the kernel source to redraw the screen every 50 ms (~20 Hz) it's possible to get a scren that works. This is an ugly hack in the tegra-fb driver though, so I'm open for suggestions on how to solve it in a better way!
2.3. Touchscreen
By default the only thing the touchscreen does is force the mouse up in the left corner, I think this is due to some multitouch thing. Some more kernel hacking (basically half-disabling multitouch) makes the touchscreen work.
Pictures:
https://ha.xxor.net/o2x/SAM_0671.jpg
https://ha.xxor.net/o2x/SAM_0672.jpg
Video:
http://vimeo.com/27662093
Thans to RaYmAn and lilstevie on #tegralinux for all their help this far!
3. Misc
(K)Ubuntu 11.04 uses a new version of libc which crashes with the current nvidia kernel (2.6.32.9) on this hardware (http://developer.nvidia.com/tegra/forum/errata-657451-tls-bit-20-cp15-c13-3), so I'm going back to Ubuntu 10.10 until someone ports a newer kernel to the Optimus 2x or this problem can be solved in another way.
edit 1: Ubuntu 10.10 with much more working X11 noted in section 2.2.1.
edit 2: X11 working even more, touchscreen works aswell!
edit 3: Landscape mode works with both X11 and the touchscreen now, getting ready for alpha 1!

Current status:
Working:
- adb (best way of controlling device currently)
- X11 (only framebuffer with hardcoded refresh rate of ~20Hz)
- landscape mode fixed! =D
- touchscreen (probably only single touch)
- wifi (only when running things from console, ubuntus network manager does not recognize it)
Not working:
- Basically everything else
Alpha 1:
EDIT: Seems that multiupload has screwed up and this link was going to some crap, anyway this is not relevant anymore
Username 'ubuntu', password 'ubuntuxda'. Don't use this if you don't know how to restore the boot partition! (Or else you won't be able to boot back into android!)
Experiments:
Tried disabling the CONFIG_TEGRA_ERRATA_657451 switch in the kernel to make newer linux versions boot. This might be a bad idea in the long run, but this far things are working better than with the switch enabled..

I tried Ubuntu via chroot method posted in other thread, but I'm a noob.. Can you please explain what is different about your ubuntu?? Does it boot without Android and doesn't need VNC stuff?

Yes, it boots instead of android when turning on the phone, but it doesn't work completely, so I mostly put it up here so that people could help test and fix/hack things.

You rock! Unfortunately I'm no dev, so can't help but hopefully others will, so we'll get a fully working linux on our phone, and maybe later even meego. Is there btw drivers for the gpu? Because hdmi, with usb host ofc, would be really useful!
Anyway, good job, really!

This looks great ergoen! I'm no dev either but I can't wait until it's available to everyone, I would love to have Ubuntu running on my O2x.
Best of luck!

gpu drivers are closed source, and the ones released by nvidia require a newer kernel (2.6.38), so thats not really possible yet.
Newer kernel will be necessary anyway though, since the crashes I'm getting seems to be due to a bug in tegra which gets worked around in 2.6.36. I'm not skilled enough to perform that port though. I will of course give it a try, but most likely I'll go for some older version of ubuntu and/or perhaps meego instead.

Håller med tidigare poster. Would be awesome with native Ubuntu and Meego on the phone... keep up the good work, can't wait to follow this development.
Sent from my Optimus 2X using XDA Premium App

ergoen said:
... I realized that it tried to run the screen at [email protected], which is hmm, wrong . So setting up a script at /etc/xprofile, which makes sure the refresh rate is 60Hz...
Click to expand...
Click to collapse
What would happen if you changed this to 72Hz instead? I saw that info when I was browsing System Information in some app. Im not a dev At. All. But tell me what you think it's probably a stupid question
Sent from my Optimus 2X using XDA Premium App

I can give it a try later, not that it would make any difference .
edit: 72 Hz also seems to work, cool, that's higher refresh rate than my computer screen...

ergoen said:
I've spent some (much) time this week with trying to get ubuntu running on the optimus 2x. I have succeeded to boot and get the wifi working, also X sort-of works (software fb). I have only slightly modified the kernel (built with CONFIG_SIGNALFD=y so that Meego wont complain in a related attempt to get that os booting). The ramdisk is completely replaced with a busybox executable, some symlinks to it and a shell script that mounts the necessary stuff (/dev/block/mmcblk1p2 as ext3), changes root directory and calls /sbin/init.
USING THE FOLLOWING WILL VOID ANY WARRANTY YOU MIGHT HAVE LEFT AND MIGHT ALSO BRICK YOUR PHONE!
Seriously, don't do this if you don't wish to risk the data on your phone.
I will not provide a complete root file system for two reasons:
1. It's pretty easy to make yourself, grab the omap3 kubuntu mobile image from the kubuntu site, or use rootstock from an ubuntu installation to build one yourself.
2. My upload sucks, and putting several hundred MB onto the interwebz would hurt me.
However, I have placed an image of my boot partition here (assumes you've got ubuntu on the second partition of the external memory card formatted with ext3):
https://ha.xxor.net/o2x/boot.img
I have also targzipeed the modifications to the file system that were required to get stuff going here:
https://ha.xxor.net/o2x/o2x.tar.gz
This should be extracted directly to the root file system you aquired earlier.
Things that have been done to get this to "work":
1. Boot partition
Apart from grabbing the busybox stuff from some nexus one boot image (I'm sorry whoever fixed it, I don't remember where I got it from ) the boot command line had to be modified a bit, changing stuff from the default usually ends up in a phone that won't boot, but I discovered that it's possible to append new arguments to the default ones. So the following have been appended:
console=tty0 root=/dev/mmcblk1p2 init=/sbin/init
The console=tty0 makes sure that you see stuff on the screen while ubuntu get's running. The last two are not necessary to boot, but ubuntu seem to like (need?) them (or at least the init=/sbin/init), since otherwise you never get to the login prompt on the screen.
2. The Ubuntu installation
To make it possible to communicate with the phone at all adbd was put into the /sbin/ folder and a symlink was created /system/ -> /. Also the "/sbin/adbdb recovery &" command was added to rc.local to make it autostart.
2.1. Modules and wifi
We need the /lib/modules/2.6.32.9 directory. Most files inside that were generated using the "depmod" command, the exception is wireless.ko which was taken from android, the firmware and nvram files needed for the wifi chip to work were placed in the /lib/firmware/wl/ folder. To make the wifi module autoload with the proper firmware "wireless" was added to /etc/modules and the file /etc/modprobe.d/wireless.conf was created with the contents describing the location of the firmware and nvram.
To make the wifi autoconnect on boot the /etc/network/interfaces file was modified with the following contents:
auto wlan0
iface wlan0 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant.conf
(To make the wifi autoconnect to your wireless you need to run the command "wpa_passphrase networkname networkpassword > /etc/wpa_supplicant.conf using adb or chroot)
2.2. X11
Getting X up by running xinit produces a simple black screen on the phone. After some troubleshooting and voodoo magic I realized that it tried to run the screen at [email protected], which is hmm, wrong . So setting up a script at /etc/xprofile, which makes sure the refresh rate is 60Hz, and running it after xinit gets you a xterm!!!
https://ha.xxor.net/o2x/xterm.jpg
Telling /etc/X11/xinit/xinitrc to run it makes sure that it gets set up properly by the startx script, unfortunately startx doesn't go through for me on kubuntu because of some weird error caused by a hardware problem in tegra: (http://developer.nvidia.com/tegra/forum/errata-657451-tls-bit-20-cp15-c13-3).
Unfortunately this (probably) means that either we'll have to stay with old versions of libc or get a newer kernel (2.6.36 contains fix). Old libc seems backwards, but porting a new kernel requires a bit more skill than I possess.
2.2.1. Ubuntu 10.10
Grabbed the image ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz from http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ . After first unpacking the tgz, then unpacking the raw disk image to partition images (with 7zip on windows) and then flashing the 1.img file to the second partition on my sdcard I managed to run a much more bug free ubuntu than before.
Ubuntu 10.10 (Maverick) uses an older version of som libraries that don't crash with the old o2x kernel.
This has lead to the following:
https://ha.xxor.net/o2x/gdm.jpg
Obviously touch screen isn't working properly (pressing it puts the pointer into the upper left corner :S) so can't get further than this currently.
3. Misc
avahi-daemon and cups seems to be crashing all the time and restarting, so removing them (apt-get purge if ubuntu/kubuntu) will make the boot much cleaner. Also I get lots of alignment trap kind of errors that shouldn't be there for different kinds of services, (due to tegra bug mentioned earlier).
edit 1: Ubuntu 10.10 with much more working X11 noted in section 2.2.1
Click to expand...
Click to collapse
Its good you got it to work.Saves me some work.I was gonna begin this project my self after the 19th when my exams end.Maybe i could help you.

ergoen said:
I can give it a try later, not that it would make any difference .
edit: 72 Hz also seems to work, cool, that's higher refresh rate than my computer screen...
Click to expand...
Click to collapse
Most computer screens usually support atleast 72hz also, it's just that it only works with d-sub, and sometimes only at a lower resolution.. It's possible to make special drivers to some screens to enable higher refresh rate through dvi also.
Anyway, it's good the screen on the phone refreshes at 72hz instead of 60 for android, but in linux I really don't see the benefit.. Doesn't hurt to have though. Btw, if we would stay on this kernel, can we use the drivers from android then? Shouldn't gpu also work? Or are the drivers limited and don't allow xorg for example? Sorry if it's stupid question, don't have that much knowledge how android works yet.

Update: X11 and touchscreen work on Ubuntu 10.10 Maverick with new kernel (just a few hacks )!
manasgirdhar: sure! Lot's of things to do new kernel is needed for anything newer than ubuntu 10.10, and even here things like sound etc (cpu scaling maybe too) don't work.
kruppin: actually i removed the xorg.conf now, the phone thinks its running at 106 Hz and it works. Unfortunately in practice it goes at more like 20 Hz because of the hack I made to enable the fbdev output in the kernel. Android doesn't use X11, so those drivers wont be of any use. (I will post the kernel modifications to github soon)
edit: kernel source up on https://github.com/ergoen/LG-Optimus-2x-linux-kernel

A List of Things working at 2nd Post would be nice.
So anybody could fast see Updates,...
Edit:
Have you tried some "cleaner" Linux like Debian?

Alpha 1 is up in the second post for anyone who wants to test it (don't ^^).
I have not tried debian no, I thought ubuntu would be the easiest to google errors and bugs for .

You are great! i was hopin' for this since I have mine. You should try to make usb(otg) work to get some devices going i will try to test it soon

That's amazing We have to test USB OTG function. If it works by default, I'll try this right now
It is possible to make a dual-boot: ubuntu and android?

I don't think usb otg works since I am basically using the android version of the kernel, I also won't be able to try since I don't have a cable... (will buy one sooner or later).
Dual boot probably works if you flash the boot.img onto the recovery partition instead of the boot partition (/dev/block/mmcblk0p7 instead of /dev/block/mmcblk0p5). I have not tried this though. That way regular booting would give android and booting while holding volume down would give ubuntu, only problem with this is that cwm will be gone and the only way to fix broken things would be to flash with nvflash.

well it is not a major deal if have cifs avail needs kernel support as well. Benee mentioned (might) some otg support, mayb u could ask.
also, you might give E17 a try, it is butter-fast, and has a touch module for keyboard (letter zooming.!..) LINK
this can be compiled on a lot of hw, and gives good response with fbdev non-accel drivers also.
and most linux apps work on it fine. ofc until we have 2d/3d accel and might try compiz/fusion as well
LINK

Great job ergoen!
I've worked on exactly the same some weeks ago but i never accomplished it. because i stuck creating a working ramdisk. Which toolchain do you use?
MfG

OMAP4430 boot.rom dump

My purpose is to locate the fastboot system, and I thought that I would start from, well, the start. Boot-up on the OMAP4430 tries many places, one is an on-chip 48kb ROM. I initially tried to read /dev/mem, but no matter what address I tried to read it would say Bad Address, so I had to make a kernel module, in which I dumped the boot ROM to a file... and it worked.
The reversion of the ROM on my bionic is 0x03 0x19
(Please read Ch 27(.4.2.1) of OMAP4430_ES2.x_PUBLIC_TRM_vY.zip )
I am more handy with ia32 assembly, not arm...
So where is fastboot? I can see a few other addresses, but if I try to map some of them, the device will reboot.. The TRM spoke of 0x08000000 for a fast boot XIP but a reboot occurs (I think) ... any ideas where to look next?

After a day of digging around, I was able to find that "fastboot"(0x08000000) address at 0x28C18 (0x28000 is the base address of the boot.rom) ... just helping out anyone else interested in looking into this. I somehow don't think that this is what I am looking for though... but atleast I do know that I am making some headway
Edit: Confirm that I am unable to read even one byte from 0x08000000 .. reboots
Edit2: Polling from the Control Register (0x4A0022C4) returned 0x00000AEF ... which means that
1) This is not a GP(General Purpose) OMAP4430
2) SYS_BOOT[5:0] is b101111 which tells us
a) to use Memory, not Peripheral boot devices
b) 1st boot device is MMC2(1)(perm) (eMMC/eSD = GPMC pins)
c) 2nd= USB-ULPI (external transceiver)
... Does the MMC mean it boots from the onboard 16gb? If so, then this might be easier to trace through than I thought...
Has anyone dumped the entire contents of that memory? or just the known partitions?
Edit3: Reading the TRM more (pg 5240) tells me that SDMMC2 only Raw mode is supported, no file system (FAT12/FAT16/FAT32) support because the purpose of this approach is to avoid the boot time penalty of searching for a file system hierarchy when it is not always necessary.
Edit4: ...and Sure enough, dumping the first 512 bytes of /dev/block/mmcblk1 shows the Bootable signature (0x55AA) at the end (0x01FE)
... I thought I read that it would just try to read in RAW mode, which makes it not want to even have such a thing, but I knew it had all those other partitions, so I figured I might have been wrong there...
A proper dump of this soon enough.. atleast I gave you guys the boot.rom from the actual OMAP4430 that would have been otherwise hard to retreive... I only wasted one day on this, not bad and I learned some ARM ASM
Edit5: Maybe I am getting ahead of myself, it is of type 0x83 ... which is Linux, not any of the FAT FS which the boot.rom supports... ?
Edit6: Well, it has the file it's looking for, not sure if it's a FAT system like it's suppose to be though, and it looks like in a 1MB dump that fastboot is in the 2nd or maybe more, partition... I still want to try to dump this "MLO" bootup file... but i have to learn about FAT fs structure, ugh...

The implications of deep hardware hacking like this make me very excited for what could be possible with the Bionic. It contains some absolutely absurd hardware for a mobile device so the sky's the limit at this point. Fantastic work! I could only dream of being able to comprehend the things that guys like you can.
Also I wonder if this thread would end up getting proper attention in the dev section.

projektorboy said:
The implications of deep hardware hacking like this make me very excited for what could be possible with the Bionic. It contains some absolutely absurd hardware for a mobile device so the sky's the limit at this point. Fantastic work! I could only dream of being able to comprehend the things that guys like you can.
Also I wonder if this thread would end up getting proper attention in the dev section.
Click to expand...
Click to collapse
I only wish I could comprehend what he is talking about. I'm glad to see a vested interest is being taken!
Sent from my DROID BIONIC

Thanks so much, Noxz for making the effort to do this!

hey, thanks finally for the responses, a full day after the initial dump and no responses... I think because it's NOT in the dev section... but I can't post a thread there until I have 10 posts... maybe I can get that privilege now, moderators?
The bad part with disassembling is that when it computes an jump in code(in ARM it's called a branch) and doesn't give a specific address, it makes finding that code very hard.. I found the text "MLO", the bootable file, in the boot.rom but nothing of the code I know referenced it yet, unfortunate because that partition is not a standard FAT fs and thus is taking a while to read, but if I did have the disassemble of the ROM code where it looks for that, or even just the file search, then I could easily see what it is reading...
Obviously knowing that fastboot and such is in the second or third partition is quite a step forward, but I need to dump this MLO file so we can read from start to finish...
I'll keep everyone posted

So this partition isn't a correct FAT fs... I don't know if being identified as a Linux partition means anything and I'm just not reading into it right, but I am having some time trying to look into these files, you can easily see the MLO file, a KEYS file, and a PRIMAPP file right at the start, or I should say the file name, but there isn't much information on where they are mapped, etc etc...
Maybe partition2 will be better? It's also identified as a Linux partition
I still have a few days to waste...

Sorry to ask dumb. But what exactly does this benefit me when flashing it?
Sent from my DROID BIONIC using Tapatalk

The current fastboot does not have several commands that is in the original source... but really, I am just interested in the entire boot procedure.. there's a few things I might like to change... The good news is because everything but the boot.rom resides on the eSD, that means we should be able to write to it very easily, so we can change quite a bit

Noxz, I am along with these guys in I would understand more if I was just dropped in the middle of Ghana :\ but I would like you to know that you have given me my 1024th item on my 'to research' list. So once I get bored with what I'm doing now, I am going to try to learn a little bit about ARM and OMAP

Hah, I understand...
I've done a bit of x86 ASM and BIOS disassembly before.. so I figured I might as well peek into this and see what is being hidden and such...
I am seeking help right now... If you know anything about the FAT filesystem... you can start by doing "dd if=/dev/block/mmcblk1p1 of=/mnt/sdcard-ext/partition1"
.. It obviously has that MLO bootup file in it as mentioned in the OMAP4430 TRM but I can't seem to trace what cluster it might be in... I have to assume that it is in fact a FAT fs... but it doesnt seem to follow any of the structures/formats I've been reading... ???

The boot rom you've dumped is the ti omap itself; the only real purpose of that is to bootstrap the bootloader. You are correct in that it's not a GP; none of the Motorola phones are -- this boot rom is what verifies the signature of the bootloader.
http://www.droid-developers.org/wiki/Booting_chain
While not exact, the above diagram will give you an overview of the layout used by Motorola phone. The short version is boot rom -> mbmloader -> mbm -> lbl -> kernel, where mbmloader is the Motorola terminology for the MLO or X-LOADER referenced in the TRM. mbm is the bootloader (motorola boot manager) and controls all actions henceforth, including fastboot (which replaced an older sbf protocol).
The CDT acts as a partition table and lists the layout of the device, including marking where the signatures are located and how often they're checked.
http://blog.opticaldelusion.org/2011/10/bionic-development-notes.html

Sorry for late answer.
Here you can find example of reversing OMAP 3430 bootrom http://hg.droid-developers.org/reverse_engineering/src/b8b881184b5f/asm
As mentioned before droid-developers wiki contain a lot of info about bootrom.
Here you can find info about bootrom itself http://www.droid-developers.org/wiki/Application_Processor_Boot_ROM
Here you can find info about security model in omap http://www.droid-developers.org/wiki/Security http://www.droid-developers.org/wiki/Secure_Services
Here you can find info about my project - emulation of early OMAP booting (including bootrom debugging) http://www.droid-developers.org/wiki/QEMU

[Workshop] Unbrick fully bricked I9070

Hi,
I'm launching this thread to work on an unbrick procedure for fully bricked I9070/P without JTAG or Riffbox (same as Adam Outler, TheBeano, Odia etc... 's project "let's save some bricks")
Reminder : fully bricked = no download/recovery mode, no display, not charging, not going to recovery with a 301k Ohm jig.
I have a fully bricked I9070P and a fully functionnal I8090 (same processor).
Based on the sources and tools for the U8500 that were disclosed in january, I've managed to make my dead phone and my PC talk "a bit" together (under Windows with the VSIW tool, and under linux with recompiling the "flashkit" tools): when plugged in and inserting the battery, the tool sees the terminal, gets its serial number and various data and fails while trying to send and execute a boot file because the terminal closes the USB port.
I've managed to get a certain degree of communication with the "riff" tool (open source) of the Snowball project too (the dev board based on a U9500).
Based on this half successes, I'm pretty sure we are close to a clean solution to revive a fully bricked terminal without soldering JTAG.
Here are the main docs I've read so far :
* most posts from the threads "let's save some bricks" and "fun with resistors"
* the reference documents of the I9070 (Samsung_GT-I9070_Galaxy_S_Advance_Galaxy_S_II_Lite_service_manual.rar)
* the reference manual of the U9500 (http://www.calao-systems.com/reposi...X/DATASHEETS/AP9500_reference_manual_rev1.pdf)
* TSU6111 datasheet from TI (the USB/UART switch the 9070 is using, cf the service manual -> Lite Schematics -> u-USB SW IC part)
* lots of docs from the "flashkit" sources
My setup :
* a fully bricked I9070P
* a fully working I8190P
* an 8GB SDCard
* a Windows/Linux workstation (Ubuntu 12.04LTS + Android compiling environment + disclosed sources)
* terminal emulators
* a Prolific cable (PL2303) (any USB to TTL adapter would do it, you can buy one for 3$ as Arduino accessory, or reuse a Nokia DKU 5 -see hackaday website for a link). Take care with Prolifics : they don't work under Windows 8 with the last driver, you have to use the version before, Google is your friend)
* a set of resistors
* a multimeter
* libusb win32 drivers setup, see sourceforge (use the tool included in the drivers package to generate the right .inf file for the U8500 (or use 04CC and 8500)
Here are my conclusions so far :
* based on the Snowball docs and the U9500 spec, we don't seem to have any need to modify anything (resistors) on the mainboard to change boot sequence. The dev board does not have any switch for that and my dead I9070 and working I8190 exibit the same behaviour at bootup : the appear as a "U8500 USB ROM" for a seconds and disconnect when going on farther in the boot sequence.
Moreover, the fact that I managed to have my dead phone talk with the flashtool confort me in the fact that we are almost done.
* I have *not* managed to get any output on my terminal with my Prolific cable plugged in with a 630kOhm resistor on the pins 4 and 5. My resistor setup might be good because it make my working I8190 boot when I plug it in.
But I'm not sure of my RX/TX setup, I have crossed the RX/TX of the phone and the ones of the Prolific but I might have been wrong identifying the pins of my modified USB plug (D+ and D-).
But I'm sure the RX and TX wires of my Prolific are the right ones : when I connect them together (nullmodem configuration), the characters typed on my terminal are displayed.
So the main issue is : how can we have the dead phone keep the USB port open and not close it after 2 seconds?
My assumption is that it is always probing different boot methods (UART, USB, MMC etc) and then attempts to boot normaly from eMMC.
I don't know which part of the bootchain sequence I've garbaged on my I9070: IBL, PBL, SBL, PARAM? Managing to get any debug output on my console would greatly help me.
Has any of you tried to achieve something similar? If yes, could you post your setup and results?
Let's save some bricks another time!

any progress
flentus said:
Hi,
I'm launching this thread to work on an unbrick procedure for fully bricked I9070/P without JTAG or Riffbox (same as Adam Outler, TheBeano, Odia etc... 's project "let's save some bricks")
Reminder : fully bricked = no download/recovery mode, no display, not charging, not going to recovery with a 301k Ohm jig.
I have a fully bricked I9070P and a fully functionnal I8090 (same processor).
Based on the sources and tools for the U8500 that were disclosed in january, I've managed to make my dead phone and my PC talk "a bit" together (under Windows with the VSIW tool, and under linux with recompiling the "flashkit" tools): when plugged in and inserting the battery, the tool sees the terminal, gets its serial number and various data and fails while trying to send and execute a boot file because the terminal closes the USB port.
I've managed to get a certain degree of communication with the "riff" tool (open source) of the Snowball project too (the dev board based on a U9500).
Based on this half successes, I'm pretty sure we are close to a clean solution to revive a fully bricked terminal without soldering JTAG.
Here are the main docs I've read so far :
* most posts from the threads "let's save some bricks" and "fun with resistors"
* the reference documents of the I9070 (Samsung_GT-I9070_Galaxy_S_Advance_Galaxy_S_II_Lite_service_manual.rar)
* the reference manual of the U9500 (http://www.calao-systems.com/reposi...X/DATASHEETS/AP9500_reference_manual_rev1.pdf)
* TSU6111 datasheet from TI (the USB/UART switch the 9070 is using, cf the service manual -> Lite Schematics -> u-USB SW IC part)
* lots of docs from the "flashkit" sources
My setup :
* a fully bricked I9070P
* a fully working I8190P
* an 8GB SDCard
* a Windows/Linux workstation (Ubuntu 12.04LTS + Android compiling environment + disclosed sources)
* terminal emulators
* a Prolific cable (PL2303) (any USB to TTL adapter would do it, you can buy one for 3$ as Arduino accessory, or reuse a Nokia DKU 5 -see hackaday website for a link). Take care with Prolifics : they don't work under Windows 8 with the last driver, you have to use the version before, Google is your friend)
* a set of resistors
* a multimeter
* libusb win32 drivers setup, see sourceforge (use the tool included in the drivers package to generate the right .inf file for the U8500 (or use 04CC and 8500)
Here are my conclusions so far :
* based on the Snowball docs and the U9500 spec, we don't seem to have any need to modify anything (resistors) on the mainboard to change boot sequence. The dev board does not have any switch for that and my dead I9070 and working I8190 exibit the same behaviour at bootup : the appear as a "U8500 USB ROM" for a seconds and disconnect when going on farther in the boot sequence.
Moreover, the fact that I managed to have my dead phone talk with the flashtool confort me in the fact that we are almost done.
* I have *not* managed to get any output on my terminal with my Prolific cable plugged in with a 630kOhm resistor on the pins 4 and 5. My resistor setup might be good because it make my working I8190 boot when I plug it in.
But I'm not sure of my RX/TX setup, I have crossed the RX/TX of the phone and the ones of the Prolific but I might have been wrong identifying the pins of my modified USB plug (D+ and D-).
But I'm sure the RX and TX wires of my Prolific are the right ones : when I connect them together (nullmodem configuration), the characters typed on my terminal are displayed.
So the main issue is : how can we have the dead phone keep the USB port open and not close it after 2 seconds?
My assumption is that it is always probing different boot methods (UART, USB, MMC etc) and then attempts to boot normaly from eMMC.
I don't know which part of the bootchain sequence I've garbaged on my I9070: IBL, PBL, SBL, PARAM? Managing to get any debug output on my console would greatly help me.
Has any of you tried to achieve something similar? If yes, could you post your setup and results?
Let's save some bricks another time!
Click to expand...
Click to collapse
dude did you find any solution??same problem here

up up this thread.... i'm also experiencing with my s3 mini i8190 continuously disconnecting libusb-win32 driver... my phone is at deadboot and unable to resurrect with RIFFBOX...

neilPD_07 said:
up up this thread.... i'm also experiencing with my s3 mini i8190 continuously disconnecting libusb-win32 driver... my phone is at deadboot and unable to resurrect with RIFFBOX...
Click to expand...
Click to collapse
Mebay u have dead mini USB port in SIII mini ?
Sent from my GT-I9070 using Tapatalk

Hi guys,
I had a little time playing with this, but I have good news :
I modified the default profile used for the flashtool backend to "ADL boot" : my "dead" phone now stays connected to the USB and is reported as "started" by the flashtool CLI ("flash-tool get_connected_equipments") however, when I try some "active" flash-tool CLI commands, the backend crashes.
As I was running it either in windows 8.1 64 bits or Linux in a VM, their might have some bad interactions with the OS on the one hand and the USB port forwarding on the other hand (there was issues with the LCD and LCM drivers in Windows, I grabbed the 64 bits ones from VSIW...).
-> I have to test on a 32 bit Windows.
Good to read to understand further (extracted from flash-tool-backend.html file) :
Note : ME stands for mobile equipment, "boot indication" can take the following values : ADL, ALT, Normal, Production, Programming : set into the config files pointed by the .mesp file)
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool. The PC tool then answers with a boot indication. If normal, "ADL" or "production" is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC). If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend. When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
I think I'd have to assemble the correct bootloader to enable "profile-STE_DBX500_flashloader.prfl" profile to work (we are missing corresponding loader.ldr loader). It would enable the use of the "LoaderCommunication"
I think I have all the pieces and the docs (we even have the certificates to sign it !): just need time and a better GFAF (Girlfriend acceptance factor).
The guys who managed to unbrick some Qualcomm based devices might be of a huge help, they would be much more efficient than I can be... I any of you have time to drive them around here, do not hesitate!
Enjoy!

flentus said:
Hi guys,
I had a little time playing with this, but I have good news :
I modified the default profile used for the flashtool backend to "ADL boot" : my "dead" phone now stays connected to the USB and is reported as "started" by the flashtool CLI ("flash-tool get_connected_equipments") however, when I try some "active" flash-tool CLI commands, the backend crashes.
As I was running it either in windows 8.1 64 bits or Linux in a VM, their might have some bad interactions with the OS on the one hand and the USB port forwarding on the other hand (there was issues with the LCD and LCM drivers in Windows, I grabbed the 64 bits ones from VSIW...).
-> I have to test on a 32 bit Windows.
Good to read to understand further (extracted from flash-tool-backend.html file) :
Note : ME stands for mobile equipment, "boot indication" can take the following values : ADL, ALT, Normal, Production, Programming : set into the config files pointed by the .mesp file)
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool. The PC tool then answers with a boot indication. If normal, "ADL" or "production" is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC). If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend. When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
I think I'd have to assemble the correct bootloader to enable "profile-STE_DBX500_flashloader.prfl" profile to work (we are missing corresponding loader.ldr loader). It would enable the use of the "LoaderCommunication"
I think I have all the pieces and the docs (we even have the certificates to sign it !): just need time and a better GFAF (Girlfriend acceptance factor).
The guys who managed to unbrick some Qualcomm based devices might be of a huge help, they would be much more efficient than I can be... I any of you have time to drive them around here, do not hesitate!
Enjoy!
Click to expand...
Click to collapse
Any good updates & tested solution sir? I'm still waiting for a big solution for this kind of problem... TIA

Hi !
well, I'm almost done with the bootloaders: I have a loader.ldr compiled + 2 bin.
I've reset my dev. env. to an Ubuntu 10.04 according to a .doc I found in the sources (search for "*.doc", you will find "getting_Started_with_Android_and_Linux.doc"): I now have far less compilation errors, but I'm still struggling to get the full compilation process just right. For eg. I had to remove the "alsactrl" component due to dependency issues I've not been able to solve.
As already stated, I'm far from being a dev. expert so it takes me a lot of time to acheive the right compilation.
I would highly need the help of s/b who is fluent with Android compilation/dev env.: first it would be necessary to establish how to merge correctly the disclosed sources with Google's sources + the open sources from Samsung (kernel + system) (we have duplicates here as the kernel is also available in the disclosed sources, but both are different releases).
As already stated, given the few spare tile I have and without the help of the right people this will take me ~4 months+ to have this unbrick done (if I face no deadlock).
So, if you want this faster: get the right guys on the forum (from the "dev" branches) and drag them here so we can go forward much faste!

Hi!
So, I think I'm getting close: I now have the boot files build procedure working (+kernel and sytem, but I don't need those).
When I try to boot my phone with those boot files using the "flasher -tXXXX -X0,normal.bin" command, it seems that they are rejected as the phone connects and disconnects (boot loop on the iRom startup, I believe).
So, now I really need to have some kind of debug console setup to understand what's going on (cause of rejection, like signature problem etc...):
I've been working blindly up to now hopping that the software would work "off the shelves"... it never does
I'll have to try to understand how the "trigger UART" parameter of flashkit backend works and what is it intended to (I'll have to read the code for that as I've never seen any explanation about it anywhere in the docs). I don't figure out how this could work as on the backend GUI it lists the host PC's serial ports...
Another option would be to have my FTDI debug setup working. Maybe it's not "another option" but is required if the "trigger UART" is just enabling UART debug on the phone and requires a debug cable to read these debug data. My problem in that case would be how to have USB *and* UART on the same port... unless all this is designed for dev targets that have 2 USB ports as the Calao's u8500 targets. In that case, i'd have to find something smarter
As usual, if someone with knownledge on all this is willing to help: wave your hand, I'd happy to share my researches and go forward much faster. But I really feel I'm alone on this (even if I know that there will be tons of leechers when/if I manage to have this work
That's life on XDA!

Nice nice
flentus said:
Hi!
So, I think I'm getting close: I now have the boot files build procedure working (+kernel and sytem, but I don't need those).
When I try to boot my phone with those boot files using the "flasher -tXXXX -X0,normal.bin" command, it seems that they are rejected as the phone connects and disconnects (boot loop on the iRom startup, I believe).
So, now I really need to have some kind of debug console setup to understand what's going on (cause of rejection, like signature problem etc...):
I've been working blindly up to now hopping that the software would work "off the shelves"... it never does
I'll have to try to understand how the "trigger UART" parameter of flashkit backend works and what is it intended to (I'll have to read the code for that as I've never seen any explanation about it anywhere in the docs). I don't figure out how this could work as on the backend GUI it lists the host PC's serial ports...
Another option would be to have my FTDI debug setup working. Maybe it's not "another option" but is required if the "trigger UART" is just enabling UART debug on the phone and requires a debug cable to read these debug data. My problem in that case would be how to have USB *and* UART on the same port... unless all this is designed for dev targets that have 2 USB ports as the Calao's u8500 targets. In that case, i'd have to find something smarter
As usual, if someone with knownledge on all this is willing to help: wave your hand, I'd happy to share my researches and go forward much faster. But I really feel I'm alone on this (even if I know that there will be tons of leechers when/if I manage to have this work
That's life on XDA!
Click to expand...
Click to collapse
U R great man..UP UP UP :good::good::good:

use UART debug on USB
This will help me, I'll test it on my working S3 mini (same proc and very similar HW)... when I have time...
-> this will validate my UART debug setup : http://forum.xda-developers.com/showthread.php?t=2100809

ok, UART debug up and partially running on my SIII mini: debug messages displayed on terminal but keystrokes do not reach the phone, this is secondary for me at the moment, I may have a bad contact somewhere.
Tested on my dead I9070: no display, so the Xloader on my eMMC is garbaged (or Xloader UART debug is disabled, but this is less likely).
As expected, I now have to figure out how to have flashloader boot files upload *and* debug working together to understand what's wrong with my compiled boot files. I think the "trigger UART" thing is a good track, but I'm really puzzled by how to have the USB *and* the UART setup at the same time.
I fear to fry something by having phone D+/D- connected to USB port of the PC and connected at the same time to my Prolific TxD/RxD + 5V VCC connected to PC USB... sounds like a bad thing.
Another track would be USB debug I see in some parts of the code, but I don't know how to read the debug from there, more code to inspect...

got it~
---------- Post added at 02:03 PM ---------- Previous post was at 01:22 PM ----------
I also have a fully bricked I9070( not I9070P).I`m waiting for your good news.Thanks first.

I received this PM, I believe it can be useful for others experimenting with it
flentus said:
Ola Paul,
I contact you on an advise from Cocafe.
I launched a while ago the thread "[Workshop] Unbrick fully bricked I9070" (http://forum.xda-developers.com/showthread.php?t=2701363)
I'm looking for help to acheive the task as I don't have very much time to spend on it due to huge work I have this year.
Would you be ok to participate if you have a little spare time and interest in it?
I think I'm very close to the solution, and this would help a lot of 9070 owners (and maybe SIII mini and Sony too).
As explained in my thread, I have difficulties getting the disclosed sources to build correctly up to the end when integrated with Google SDK. As a result the "finalizing" scripts (that gather the binaries and tidy the "out" directory) don't execute: I end up with a large mess and STE tools don't work out of the box. I have to gather the pieces one by one to have them run which is very time consuming and error prone.
I can say that the recovery process won't need any kind of soldering, wiring or whatever: just a regular USB cable and the right sofware.
The disclosed sources contain everything we need: PBL/SBL sources, signing tool+certificates, the software to talk to the iROM + various documentation.
The problem is just a question of assembling the pieces...
My idea is to assemble an Xloader (PBL) + Uboot (SBL) + recovery and boot from that to execute recovery.
The "flashkit" tool enables this process, I quote the docs: "If 'programming' boot indication is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend.".
Tell me if you wish to help me, or if you know someone who has competencies and would wish to!
I speek average spanish if you prefer to exchange in this language.
Regards
Click to expand...
Click to collapse
I am sorry for pointing this out, STE tools wont work ever on i9070, the reason being that we do not have a STE bootloader, heck, most of the low level stuff do not resemble the ST-Ericsson Montblanc development board. You can't even change the bootloader arguments, you can only add to them (the way I first enabled SELinux), the Samsung Bootloader version that we have may be not as restrictive as others, but Sonys bootloader resembles more to STE's than ours.
The only way you may found how to restore it is accessing the JTAG mode (something that is determined only if JTAG is connected and recognized) and depends solely on the emergency bootloader (if that exists, because I am not sure how the device powers on without PBL), the "seconds" of power you get on the USB is the device looking for JTAG.
The "disclosed" sources are for ST-Ericsson devices
Something you should do, is analyze the structures of /dev/block/mmcblk0p10, which contains our partition table (GUID Partition Table - GPT).
Simple way of doing it, you have to do dd if=/dev/block/mmcblk0p10 of=/sdcard/janice.pit on terminal emulator, this is ROM agnostic, because the structures are the same on both stock and any custom ROM. Of course, that is from a working device, I'll do that and drop it here later since I am working on something else right now, and thanks diegoch for discovering this.
Anyway, as diego pointed to me, our partition table is like this.
PIT, CSPSA, EFS, MODEM fs, SBL, SBL2, PARAM, IPL modem, MODEM, Kernel, Kernel2, system, data, cache, preload, fota, sdcard
This is the correct order I believe, since basically, when you use ODIN and use a PIT file, the partition table gets rewritten according to whatever is on that .pit file. So PIT is basically the GPT partition table; obviously SBL is the Samsung bootloader, and SBL2 I believe it's either stage 2.5 or a backup of the first.
So, no clue by going the STE way, something familiar here.
So, I may say something good at the end, see if the i9100 guys ever did it, and go from there, since our device is largely based around i9100 (Galaxy S II)

Hi Paul,
thanks for your contribution.
A few replies/questions :
* you state that Montblanc dev board and I9070 are completly different: isn't the aim of dev dev board to be close to ME while adding extra connectors to ease debug and interfacing for prototyping? Calao dev board looks very close to I9070: I have compared the schematics and component list: they look very very much alike. For me, NovaThor U8500 plateform consists of a DB8500 SoC, a Mali 400, a built-in modem + chips for USB, audio and SIM operations.
So, to me, I may be wrong, at least the processor (u8500), PLL, eMMC, SDRAM, UART + several low level controlers should be the same. As we are trying to work at such level (just trying to get the basic system to boot to just enable eMMC write), don't we have a chance to manage to have those work (maybe with adressing adaptation, those might be tough)?
* I can't agree with you that "the "seconds" of power you get on the USB is the device looking for JTAG.": on boot time, even without trashed PBL, the ME connects to USB properly with vendor/ID=04cc/8500, and sends its ASIC ID (displayed on PC screen). As stated earlier in the thread, I manage to send some commands and receive response from the ME in this state using STE tools (flashkit_cli, sending commands threw flashkit_backend).
It's definetly not any JTAG stuffs. JTAG on the I9070 is accessible on the mainboard via dedicated pads, you can locate using the light schematics provided in the "Service manual" package.
This early boot behaviour is documented in the "flash-tool-backend.html" document (available in s-4.1_vendor_st-ericsson.tar in ./s-4.1_vendor_st-ericsson/vendor/st-ericsson/tools/platform/flash_kit/flash_tool_backend/com.stericsson.sdk.backend.build/doc):
Boot process description
When the peripheral boot sequence starts, the ME sends an asic id to the connected PC tool.
The PC tool then answers with a boot indication.
- If normal, ADL or production is sent as boot indication; this means that the x-loader will start the binary software stored at the corresponding location in the boot image (based on the location stated by the TOC).
- If programming is used as boot indication, the PC will send a completely new set of boot code to the ME. This is used when a loader is downloaded during service mode startup via the Flash Tool Backend.
- When the normal boot indication is sent, Flash Tool backend sends no more data and the ME is booted with the binary software stored in the place where the normal software is stored according to the TOC.
The ADL boot scenario works like this:
1. Flash Tool Backend receives asic id
2. Boot indication ADL is sent
3. Flash tool backend starts LCD and LCM and waits for a loader startup message.
The loader is stored at the ADL location of the boot image (this is supported by the assemble tool).
* If I understand well, as we don't have the sources for the bootloader, your proposal is to grab one from a working device.
That sounds a really good idea!
Here is the complete partition table/PIT of the I9070 (recovered by someone with a Riff box from a GB archive, if I remember well):
(copy/paste it in a traditional editor and add padding to recover the table).
Partition number Filename in archive Name in PIT starting offset HEX Size in bytes HEX
MBR, GPT 0 20000
STE_boot.bin TOC ISSW XLOADER 20000 60000
mmcblk0p10 GT-I9070P_EUR_XX_8G.pit PIT 80000 100000
mmcblk0p6 cspsa.img CSPSA FS 180000 180000
EMPTY 300000 100000
mmcblk0p7 EFS.img EFS 400000 A00000
mmcblk0p2 modemfs.img MODEM FS E00000 100000
mem_init.bin STE MEM INIT 1E00000 80000
power_management.bin PWR MGT 1E80000 80000
mmcblk0p14 normal.bin SBL 1F00000 200000
mmcblk0p16 normal2.bin SBL_2 2100000 200000
mmcblk0p1 param.lfs PARAM 2300000 1000000
mmcblk0p12 ipl.bin IPL MODEM 3300000 200000
mmcblk0p13 modem.bin MODEM 3500000 1000000
mmcblk0p15 kernel.bin KERNEL 4500000 1000000
mmcblk0p17 kernel2.bin KERNEL2 5500000 1000000
mmcblk0p3 system.img SYSTEM 6500000 26400000
mmcblk0p5 userdata.img DATAFS 2C900000 80000000
mmcblk0p4 cache.img CACHEFS AC900000 13200000
mmcblk0p9 hidden.img HIDDEN BFB00000 14000000
mmcblk0p11 ssgtest.img FOTA D3B00000 3200000
mmcblk0p8 ums.rfs UMS D6D00000 FAA00000
--> PBL corresponds to "TOC ISSW XLOADER" (STE_boot.bin in the flash archive) and SLB to normal.bin. So basically we have our boot files. We can extract them from the GB flash archive or from a ROM dump (I have dd'ed every partitions from 2 different I9070P + a full recovery dump from a 9070 provided by Riff box support files I found once I don't remember where).
So, if I have time one of theses days, I'll try to build a flash archive based on these files and try to boot from STE tools on it using "programming" as boot indication.
* Using the knowledge of the I9100 (Galaxy S II): I'm afraid this is a very different hardware, I9100 uses an Exynos 4210, so I hardly see what we could use from there... Could you give us some more advise on that idea?
Regards

Hi!
I had no time working on this for a while: extremely busy at work.
Maybe this weekend...
@cocafe: I've read you know how to extract the initramfs from the kernel, modify, repack, and reflash it. I'll need to do that to modify the "on boot" section of the init.rc to launch the recovery from standard boot. Could you drop me here the command lines to do that? Thanks in advance!

This looks by far the most advanced research into bringing back a hard bricked i9070.
@flentus Did you manage to upload a new bootloader?

Hi,
had to time at all to play with this for a loooong time.
I have grabed a few new phones so me 9070 is now burried deep into a drawer but I really wish to finish this one day because I feel I'm very close to something.
If anybody would like to take over this, feel free, I can provide support for the stuff I have understood (and remember of...)
Regards

[Q] Installing Linux Mint 17 on tf701t?

Hello, recently purchased a asus tf701t laptop/tablet hyrbid and the device itself is perfect. Powerful cpu, good storage and an insane 2k resolution for a 10' inch screen which I don't think has been done before.
However I absolutely hate android (no offense to android developers) and decided to try installing Linux Mint 17 which can be installed on any regular laptop easily. Essentially, I want to get rid of both android bootloader and the OS itself and replace that with Grub bootloader and Linux Mint 17 OS. But android is fighting me every step of the way trying to prevent me from doing just that I unlocked the bootloader so my warrenty is void now.
But beyond that I can't install linux iso because the android bootloader isn't registering the usb stick (with linux iso on it) so I can't launch the linux live iso at all. I tried using cdrom iso using disk to launch through usb and still doesn't come up in the bootloader options. I know its possible to use linux on these devices because I've seen people have done it before on the internet.
I am now at this point starting to consider android itself as malware as the very definition of the word, ....lets start with the fact that they locked the bootloader, prompting me to give ip address just to enable me to unlock the bootloader (malicious and very dodgy). No root access therefore, third party programs are required to enable root which further my belief that android os is more malware than it is a legitimate operating system. Lastly, either possibly no usb driver for bootloader or usb port is locked out by design at bootloader (either way, might explain why I can't use usb linux iso).
What I can't understand is, why google can lock down a device tighter than fort knox on a Asus brand device. This is like buying a brand new car and not being able to open your own car even though you purchased it. What google has done is borderline illegal and I'm abit astonished how they can get away with it...
Sorry for the rant guys I'm abit fustrated atm. Can anyone please help me? I really love linux mint and if its possible to format android and install linux mint on this device I would be eternally grateful

Update: I attempted to flash the device with the command: fastboot -i 0x0B05 flash recovery recovery.img which works...but when I reboot and push power and down volume into bootloader...and try to get into recovery...the screen looks like its about to load into it but then resumes boot of android.
I'm really puzzled by this. So cannot flash a custom recovery for some strange reason

Its not so simple I dont think. You might want to watch whats happening on this thread for now.
http://forum.xda-developers.com/transformer-tf701/general/native-linux-asus-tf701t-t2973119
I would think you would have to completely replace the bootloader with something like uboot maybe if you wanted to wipe the tablet. But I dont think anyone knows. Then you could end up with some permanent brick. There would be no recovery or fastboot option if you were somehow able to get some kind of boot loader on this thing. I have no idea.
Edit: Also there is no arm based Linux Mint afiak.

YayYouFixedIt said:
Its not so simple I dont think. You might want to watch whats happening on this thread for now.
I would think you would have to completely replace the bootloader with something like uboot maybe if you wanted to wipe the tablet. But I dont think anyone knows. Then you could end up with some permanent brick. There would be no recovery or fastboot option if you were somehow able to get some kind of boot loader on this thing. I have no idea.
Edit: Also there is no arm based Linux Mint afiak.
Click to expand...
Click to collapse
Thanks I appreciate the reply. I understand this won't be easy but I'm stubborn that way
Can you give me some advice on where I can start learning how to place a native linux os on the device? Would grub bootloader work with tf701t?

have you considered returning your tf701 and replacing it with the tf700 infinity? you can replace the OS with ubuntu.. theres much more support for that model than the tf701

tf701mega said:
have you considered returning your tf701 and replacing it with the tf700 infinity? you can replace the OS with ubuntu.. theres much more support for that model than the tf701
Click to expand...
Click to collapse
Out of curiosity, have you used the tf700t? it is good for development, but it could run pretty slow at times. It might of been because of the tegra 3 processor, because the tf300t also had this performance issue. I was barely able to type up documents on a CM Rom because the tablet would lag when typing out and would then force close and corrupt my document.
atleast for me, that was the reason why I went with this one rather than the tf700t. This is just my 2 cents about getting the tf700t. I would suggest trying it out before getting it.
Sent from my K00C using Tapatalk 2

Just how stubborn are you?
How much work do you want to put into this? There are two options, the easy route that you probably will consider imperfect, and the much more complicated route that I'm not certain will work. I'll do my best to explain both.
The method I use is to install a linux distro (in my case, ubuntu) inside a chroot. There are several apps on the android market to help you set this up. The one I used sets up an Xvnc server, so you can view your linux desktop by using an android VNC viewer -- but it's just connecting locally, not going over the network.
This works nicely out of the box, but it's slow, partly because it's using the VNC protocol and partly because there's no 2d hardware acceleration. I tinkered with my setup and installed XSDL, a native android X server with hardware acceleration. I had to modify the linux startup script to skip starting Xvnc and instead connect to XSDL (which is on :0.0 like a normal X server).
This works great and is fairly fast. For me, this is a good compromise between a full-fledged linux laptop and the convenience of android apps written specifically for a multitouch screen. I generally do most of my stuff in Android, but I can drop into my Ubuntu desktop whenever I need more power.
The really big downside is that it's hard to prevent Android's low-memory killer from sacrificing XSDL when I haven't used it for awhile. I've mucked about with various solutions involving oom_score_adj and such, and that helps, but android still ends up killing my X server sometimes.
So, that's the easy method. For the more complicated method, I'm just theorizing, and this stuff may not work. You're going to need to either already have somewhat deep linux knowledge or be willing to learn Here goes.
In this post, I described how I managed to boot my tf701t after the internal memory card died a horrible death. The important bit here is that I learned how to boot any initrd/kernel combination using fastboot, and how to roll that combination into a boot.img so that the tablet always boots it. This is what you'll need to do both for the installation and for future boots into your Linux install.
First off, choose your Linux distro. I don't think you'll be able to use Mint, since, as someone pointed out above, there's no ARM build of Mint. However, there is an ARM build of Debian and Mint has the "debian edition", so maybe there is an ARM version. It may be, though, that the Mint folks only built their special stuff (Cinnamon/mate/whatever) for x86 platforms. I'd recommend Ubuntu as a compromise since I know it runs on the tf701t.
For the initial installation, put the contents of the install ISO onto an SD card -- just copying your bootable USB drive over should work. Now for the tricky bit: you'll need to pull the kernel and initrd ("ramdisk", "initial ramdisk" -- usually initrd-<something>.gz) off of the usb drive and into a working directory on a Linux laptop or desktop (let's call it the "host"). You might get away with just fastbooting this kernel/ramdisk directly. Install the fastboot package for your distro (Ubuntu has one, anyway). Connect up your tablet, put it in fastboot mode (I think that's done by booting with volume up and down held) and do 'fastboot boot <your kernel> <your ramdisk>'.
This will boot the kernel and load up the initrd, which is a tiny little linux filesystem stored in memory. The kernel runs a program called init inside the ramdisk and init takes over and boots into the actual installer. The question in my mind is how it goes about finding the ISO contents. If it searches by filesystem UUID, and there's a good chance that it does, then it will find your the ISO contents on the SD card just fine and the installer will start up.
If not, well, things will get a lot more complicated. Normally what one would do in a case like this would be to pass kernel command-line arguments (you do this in the SYSLINUX bootloader for distros like Ubuntu) telling it where to find the installation media. We can't do that because fastboot doesn't let you pass command-line arguments. Instead, you'd need to extract the initrd on the Host machine, modify the init script in some way to tell it where to find the installation media (probably /dev/block/mmcblk1p1), and then repackage it. I went into somewhat shallow detail on how to do the extract/repackage parts of this, but this is where either prior linux knowledge or a willingness to do some research comes in. Hints: gunzip the initrd, then use the cpio tool to extract it.
Okay, so let's say that you get the installer booting. The next big question is whether it's going to work at all. In theory the graphics chip inside the tf701t is supported by linux, but in practice, maybe it's only supported by a kernel module that Samsung built. Maybe you'd need to substitute the stock kernel. The next question is whether X has a module that will work with the graphics chip. But maybe even if it doesn't you can use a text-mode installer. That would at least let you get a system installed that you could then hack on to try to get X running.
So, let's say you do get linux installed (probably onto the internal SD card, /dev/block/mmcblk0). Now you want to boot it. You'll need to look into the installed system and steal its kernel and ramdisk, and get them onto the Host machine. Or maybe you could just extract them from the debian packages, since I'm not sure how you'd get things off of that internal SD at this stage. As a hint, these may well NOT be the same kernel/initrd as in the installer.
Once you've got the kernel/ramdisk, you can try to boot into them with fastboot. If that works (big if), then you'll want to be able to boot them without fastboot. That's where the 'fastboot flash:raw' command comes in. It takes a kernel/ramdisk, builds an android boot.img out of them, and flashes it to the device. From then on, the device will boot that kernel and ramdisk by default.
So, in theory this could work. The biggest potential stumbling block is whether X is going to natively support the graphics chip. If it doesn't, you may be stuck using the basic framebuffer driver, or maybe that won't even work at all. ...or you could just settle for the chroot method and be done with it
Good luck. I'm very interested to hear whether this works. I'm probably not going to try it myself since I like Android enough that I want to keep it around. I also can't walk you through this in finer detail because of external limits on my time, but I'd be happy to answer theoretical questions and specific technical questions, so long as you're willing to do the legwork of reading manpages and such I hope this works out for you!
Oh, one thing just occurred to me: skip the part in the installer about installing grub. It's not going to work on this device and may cause problems. You'll take care of the bootloader part yourself with the fastboot flash:raw command.

Oh, I see there's already some decent progress in this thread. Also it looks like I totally missed the -c option in fastboot that lets you pass kernel command-line arguments... that'll definitely be a time-saver. Given what I see over in that thread, it looks like we may actually get a reasonable native linux on our TF701t. Not sure how far the OP has gotten on things like mouse/keyboard input, though.
I have to say, I'm pretty excited! It'd be super cool to be able to dual-boot native linux and android on this tablet. Best of both worlds.

lexelby said:
How much work do you want to put into this? There are two options, the easy route that you probably will consider imperfect, and the much more complicated route that I'm not certain will work. I'll do my best to explain both.
The method I use is to install a linux distro (in my case, ubuntu) inside a chroot. There are several apps on the android market to help you set this up. The one I used sets up an Xvnc server, so you can view your linux desktop by using an android VNC viewer -- but it's just connecting locally, not going over the network.
This works nicely out of the box, but it's slow, partly because it's using the VNC protocol and partly because there's no 2d hardware acceleration. I tinkered with my setup and installed XSDL, a native android X server with hardware acceleration. I had to modify the linux startup script to skip starting Xvnc and instead connect to XSDL (which is on :0.0 like a normal X server).
This works great and is fairly fast. For me, this is a good compromise between a full-fledged linux laptop and the convenience of android apps written specifically for a multitouch screen. I generally do most of my stuff in Android, but I can drop into my Ubuntu desktop whenever I need more power.
The really big downside is that it's hard to prevent Android's low-memory killer from sacrificing XSDL when I haven't used it for awhile. I've mucked about with various solutions involving oom_score_adj and such, and that helps, but android still ends up killing my X server sometimes.
So, that's the easy method. For the more complicated method, I'm just theorizing, and this stuff may not work. You're going to need to either already have somewhat deep linux knowledge or be willing to learn Here goes.
In this post, I described how I managed to boot my tf701t after the internal memory card died a horrible death. The important bit here is that I learned how to boot any initrd/kernel combination using fastboot, and how to roll that combination into a boot.img so that the tablet always boots it. This is what you'll need to do both for the installation and for future boots into your Linux install.
First off, choose your Linux distro. I don't think you'll be able to use Mint, since, as someone pointed out above, there's no ARM build of Mint. However, there is an ARM build of Debian and Mint has the "debian edition", so maybe there is an ARM version. It may be, though, that the Mint folks only built their special stuff (Cinnamon/mate/whatever) for x86 platforms. I'd recommend Ubuntu as a compromise since I know it runs on the tf701t.
For the initial installation, put the contents of the install ISO onto an SD card -- just copying your bootable USB drive over should work. Now for the tricky bit: you'll need to pull the kernel and initrd ("ramdisk", "initial ramdisk" -- usually initrd-<something>.gz) off of the usb drive and into a working directory on a Linux laptop or desktop (let's call it the "host"). You might get away with just fastbooting this kernel/ramdisk directly. Install the fastboot package for your distro (Ubuntu has one, anyway). Connect up your tablet, put it in fastboot mode (I think that's done by booting with volume up and down held) and do 'fastboot boot <your kernel> <your ramdisk>'.
This will boot the kernel and load up the initrd, which is a tiny little linux filesystem stored in memory. The kernel runs a program called init inside the ramdisk and init takes over and boots into the actual installer. The question in my mind is how it goes about finding the ISO contents. If it searches by filesystem UUID, and there's a good chance that it does, then it will find your the ISO contents on the SD card just fine and the installer will start up.
If not, well, things will get a lot more complicated. Normally what one would do in a case like this would be to pass kernel command-line arguments (you do this in the SYSLINUX bootloader for distros like Ubuntu) telling it where to find the installation media. We can't do that because fastboot doesn't let you pass command-line arguments. Instead, you'd need to extract the initrd on the Host machine, modify the init script in some way to tell it where to find the installation media (probably /dev/block/mmcblk1p1), and then repackage it. I went into somewhat shallow detail on how to do the extract/repackage parts of this, but this is where either prior linux knowledge or a willingness to do some research comes in. Hints: gunzip the initrd, then use the cpio tool to extract it.
Okay, so let's say that you get the installer booting. The next big question is whether it's going to work at all. In theory the graphics chip inside the tf701t is supported by linux, but in practice, maybe it's only supported by a kernel module that Samsung built. Maybe you'd need to substitute the stock kernel. The next question is whether X has a module that will work with the graphics chip. But maybe even if it doesn't you can use a text-mode installer. That would at least let you get a system installed that you could then hack on to try to get X running.
So, let's say you do get linux installed (probably onto the internal SD card, /dev/block/mmcblk0). Now you want to boot it. You'll need to look into the installed system and steal its kernel and ramdisk, and get them onto the Host machine. Or maybe you could just extract them from the debian packages, since I'm not sure how you'd get things off of that internal SD at this stage. As a hint, these may well NOT be the same kernel/initrd as in the installer.
Once you've got the kernel/ramdisk, you can try to boot into them with fastboot. If that works (big if), then you'll want to be able to boot them without fastboot. That's where the 'fastboot flash:raw' command comes in. It takes a kernel/ramdisk, builds an android boot.img out of them, and flashes it to the device. From then on, the device will boot that kernel and ramdisk by default.
So, in theory this could work. The biggest potential stumbling block is whether X is going to natively support the graphics chip. If it doesn't, you may be stuck using the basic framebuffer driver, or maybe that won't even work at all. ...or you could just settle for the chroot method and be done with it
Good luck. I'm very interested to hear whether this works. I'm probably not going to try it myself since I like Android enough that I want to keep it around. I also can't walk you through this in finer detail because of external limits on my time, but I'd be happy to answer theoretical questions and specific technical questions, so long as you're willing to do the legwork of reading manpages and such I hope this works out for you!
Oh, one thing just occurred to me: skip the part in the installer about installing grub. It's not going to work on this device and may cause problems. You'll take care of the bootloader part yourself with the fastboot flash:raw command.
Click to expand...
Click to collapse
Very stubborn
Sorry I didn't respond sooner as I was away with family for Christmas.
Thank you for the guide, it was extremely helpful. I am still working on getting the device ready so I'll update as I progress.
Thanks again