yashsingh1/xdaforums huggingface dataset:
[Galaxy S I9000 Android Development] AdamOutler:
How can I un-ARM the pit file? What type of encoding is it using?
[Galaxy S I9000 Android Development] Benjamin Dobell:
It's just big endian, Java makes it a bit more convoluted than necessary but it's still fairly straight forward. Just reverse the byte order when unpacking. In saying that the file format itself isn't documented, it's not too difficult to work out though.

I'd be happy to either write a libpit Java wrapper for you, or a Java native libpit depending on how difficult working with a JNI is. Let me know if you've worked it out, if not I'll sort it out for you.
[Galaxy S I9000 Android Development] AdamOutler:
I don't know anything about big/little endian. I could try, but im betting that you would do it exponentially better then I could hope to do.
[Galaxy S I9000 Android Development] AdamOutler:
just noticed this..

The reason I say rm `which heimdall` is because One-Click UnBrick will automatically reinstall the DEB and restore it if heimdall is not found. it cause no problems. I know it's not the 'proper' way to do it, but it's a very easy way to do a reinstallation of 1.2, and it works for all platforms, os-x, deb32, deb64 and Windows... automatically.

The idea is that a user should only have to flash the bootloaders if they are required on their device.... Those random Odin protocol errors could leave the device hard-bricked and fully inoperative... but that can only occur when flashing a bootloader.

A ROM developer should never replace the bootloader. That is the improper way of distributing a rom for the phone. If the bootloaders require changing, it was because of lazyness on the ROM developer's part (MIUI, CyanogenMod). The proper way to do it would not be to change the bootloader to emulate another phone. The proper way is to build the kernel to the bootloader. It's more difficult, but it's far less risky then replacing the bootloader.

Don't get me wrong, I've flashed bootloaders in the past (CyanogenMod)... I ended up with my first phone hard bricked by Odin-3 one-click while flashign back to stock. This is what started my mission on trying to find a solution to the bricking problem.... And it lead me to building a safer flashing method.

So, by examining the evidence, I've come to the conclusion that the bootloader should not be flashed unless the kernel does not work with that bootloader. By using this method, it will reduce the risk of flashing. If the kernel boots, and buttons work properly, then no bootloaders are required... If the kernel does not boot and/or something does not work properly, well, then it was tried the safe way and you can go back and try the hard way. Also, the ROM developer can specify if flashing bootloaders is required... which should never happen... but the bootloaders should be available to bring a phone back to the way it was intended to be.
[Galaxy S I9000 Android Development] AdamOutler:
I was examining ways to do a conversion on the PIT file.. http://commons.apache.org/io/api-release/org/apache/commons/io/input/SwappedDataInputStream.html

It looks like it would be possible to use this.. Establish a File>FileInputStream>DataInputStream>SwappedDataInputStream>DataOutputStream>FileOutputStream
[Galaxy S I9000 Android Development] jerome.d:
Since the discussion seems to be around the current subject of interest to me, I take the opportunity to place a little question: I would like to flash the CF-root kernel for my firmware (KE7 on SGS2). But Chainfire only gave the kernel in its .zip file, since all the other files are the same as for the stock kernel.

My idea was to to create a heimdall package with only the kernel. I first have to find a proper .pit file for my firmware (I do not know yet where they are, the stock oden firmwares given in a thread here only contain the "phone" parts, without the pit file; I was thinking about using the pit file from KG1, available in the file distributed somewhere else here, but I am afraid they are the same as for KE7). But once I have found this file, I would use it to create a Heimdall firmware with only the kernel file, and flash this.

From what you said I understand that this is safe to do so. Heimdall will properly flash only the kernel, leaving all other partitions as they are.

PS: another option I thought about, if I do not find the pit file for KE7: I take the pit file for KG1, the kernel file from CF, and all other files (boot, sbl, params...) from KE7, and use all these to create a "complete" heimdall firmware that I then flash. I believe this would work (even mixing the pit file from one version with the files from another version), but I was not inclined, for my first flash, to flash everything (flashing only the kernel, as said, is less risky).
[Galaxy S I9000 Android Development] AdamOutler:
Benjamin Dobell,

I found a weakness while beta testing.

Say, a ROM developer names his FactoryFS image.bin...

Then his kernel guy names his Kernel image.bin...

There are two files contained in the tar archive named image. This is perfectly acceptable in TAR format, but not on a filesystem. The compressor should look at that. I attached an example here with two bootloaders.

Sorry about the multiple formats, XDA mandates zip, so it's firmware.tar.gz.zip... lol.

NOTE ON THIS ATTACHMENT: DO NOT USE ON ANY MACHINE!!!!

Edit:firmware removed as it is useless except to ruin a device.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Nice pick-up. I'll just auto-rename any file clashes (append an integer I guess).

I noticed one other bug with the Frontend a couple of days ago as well, if you click Cancel when selecting the name for a package then the Frontend still builds a package with a blank name, straight-forward to fix.

Also, I just woke up then so I'll get to work on that Java libpit right now.
[Galaxy S I9000 Android Development] AdamOutler:
Great!

I was thinking about ROM development... During the development cycle of Andromeda3, for nightly builds, I'd synchronize the local copy of the SVN repository, make a CWM Flashable zip, then automatically upload to the Team Komin File Server at midnight with this code.

#! /bin/sh
Repo="/home/adam/TeamKomin"
svn update "$Repo"
test -e "$Repo/tmp" && rm -Rf "$Repo/tmp"
mkdir "$Repo/tmp"
cp -rf "$Repo/SVN/trunk/data/" "$Repo/tmp/"
cp -rf "$Repo/SVN/trunk/META-INF/" "$Repo/tmp/"
cp -rf "$Repo/SVN/trunk/system/" "$Repo/tmp/"
cp -rf "$Repo/SVN/trunk/updates/" "$Repo/tmp/"
find "$Repo/tmp/" -name ".svn" -type d -exec rm -rf {} \;
test -e "$Repo"/Distributions/AndromedaNightly.zip && rm "$Repo"/Distributions/AndromedaNightly.zip
cd "$Repo/tmp/"
date=`date +%y%m%d`
zip -r "$Repo"/Distributions/Andromeda-Nightly-"$date".zip ./*
rm -rf "$Repo/tmp"
cd "$Repo"/Distributions/
DISPLAY=:0
export DISPLAY
x=`expect -c 'set timeout 3600' -c 'spawn sftp USERNAME@SERVER REMVOED;
sleep 10;
expect "s password:"; send "****PASSWORD REMOVED\n";
expect "Connected to";
expect "sftp>"; send "cd Andromeda/nightly\n";
expect "sftp>"; send "put @@@ServerStructureRemoved@@@@Andromeda-Nightly-'"$date"'.zip\n";
expect "sftp>"; send "cd ..\n";
expect "sftp>"; send "rm ./AndromedaNightly.zip\n";
expect "sftp>"; send "symlink nightly/Andromeda-Nightly-'"$date"'.zip ./AndromedaNightly.zip\n";
expect "sftp>"; send "ls\n";
expect "sftp>"; send "quit\n"'`

if [ $? != 0 ]; then
echo "`date` $x" >> ~/Desktop/error.log
zenity --info --text="Nightly Build Failed
$x" 200 200
else
zenity --info --text="Nightly Build Sucessful
$x" 200 200
fi'

I was thinking it would be really neat if Heimdall-Frontend would take some parameters, force them into the fields, then generate a Tar.gz... It would make auto-building possible.... for arrays they could be broken down like --developers "me,some guy, some other guy"...

Just a thought... I'm not incapable of creating a tar.gz file with a set of XMLs, but it would be nice to have all of the error checking of Heimdall.

Speaking of errors... As soon as I finish this XML Parser, I will be moving on to error processing of Heimdall. Do you have a documented list, or a piece of source code I can read for the errors? I would like to make sure I process every error that Heimdall can generate.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Hmm, theoretically I could do that but passing command line parameters to a GUI based application might be a bit messy, especially on OS X. I could move the XML and tar.gz functionality into a library and then make a second binary specifically for automating builds, it would still have a dependency on Qt though.

I'll look into doing this later, I won't have time to include it in the 1.3.0 release.

Are you referring to return values or literally textual output? Because Heimdall itself only returns a 0 or -1, 0 to indicate success and -1 to indicate a failure.

In order to find the cause of the error you can just take a look at stderr, you should pretty much be able to display the errors output from Heimdall straight to users (I trim the leading "ERROR: " in Heimdall Frontend).

I've finished writing the Java libpit. I'm just going to write a quick test application to make sure it works and throw it up on Github.
[Galaxy S I9000 Android Development] starche_old:
First of all, I'm really sorry not to mention my OS - it's ubuntu 10.04 x64.

I'd like to understand what's wrong and I like challenges :-) But I'll try rite now

I tried 1.3 and 1.1.1 from here:

http://www.glassechidna.com.au/products/heimdall/

all of them require 1.0.8 or newer, but I've got 1.0.6 only. I'm stuck trying to compile libusb and heimdall installation is the next step. That's weird that I can not compile smth from sources.

I've got pkg-config as well as lubusb-dev version 0.1.12 already, libpit is not there though. Should I install it also?

There's only 2 weird messages appearing while compiling libusb:

-while "make":

make[2]: Entering directory `/home/roman/libusb-1.0.8/doc'
make[2]: Nothing to be done for `all'.

AFAIK, but that's not big deal at all

- another 1 - while "sudo make install":

make[2]: Entering directory `/home/roman/libusb-1.0.8'
make[2]: Nothing to be done for `install-exec-am'.

For this 1 I'm not sure if that's the reason or not.
[Galaxy S I9000 Android Development] Benjamin Dobell:
libpit (Java) is now available on Github.
[Galaxy S I9000 Android Development] AdamOutler:
Sweet.... I just committed the Java TGZ support.

This goes in:

HeimdallAutomate HeimdallAutomate =new HeimdallAutomate();
try {
HeimdallAutomate.unpackHeimdallResource(Statics.ROMPackageTGZ);
} catch (IOException ex) {
Logger.getLogger(HeimdallOneClickView.class.getName()).log(Level.SEVERE, null, ex);
}
System.out.println("PlatformName: "+HeimdallAutomate.getPlatformName());
System.out.println("PlatformVersion: "+HeimdallAutomate.getPlatformVersion());
System.out.println("FirmwareName: "+HeimdallAutomate.getFirmwareName());
System.out.println("FirmwareVersion: "+HeimdallAutomate.getFirmwareVersion());
System.out.println("Developers: "+HeimdallAutomate.getDevelopers());
System.out.println("Website: "+HeimdallAutomate.getWebsite());
System.out.println("DonateLink: "+HeimdallAutomate.getDonateLink());
System.out.println("PartitionNumbers: "+HeimdallAutomate.getPartitionsToFlash());
System.out.println("FileNames: "+HeimdallAutomate.getFilesToFlash());
System.out.println("FullyQualifiedFileNames: "+HeimdallAutomate.getFullyQualifiedFilenames());
System.out.println("PITFileName: "+HeimdallAutomate.getPitFileName());
System.out.println("RebootRequested: "+ HeimdallAutomate.rebootIsRequested());
System.out.println("RepartionRequested: "+HeimdallAutomate.repartitionIsRequested());
System.out.println("Devices: "+ HeimdallAutomate.getDevices());
System.out.println("FlashCommand: "+(HeimdallAutomate.getCommand(true)));

this comes out:

PlatformName: PlatformNameq
PlatformVersion: PlatformVersion
FirmwareName: Some Funky FirmwareName
FirmwareVersion: FirmwareVersion
Developers: [Adam, woot, Benjamin]
Website: http://www.homepage.com
DonateLink: http://www.donate.com
FlashCommand: [--pit, /tmp/adamHeimdallOneClick/part.pit, --11, /tmp/adamHeimdallOneClick/modem.bin, --6, /tmp/adamHeimdallOneClick/zImage]
PartitionNumbers: [11, 6]
FileNames: [modem.bin, zImage]
FullyQualifiedFileNames: [/tmp/adamHeimdallOneClick/modem.bin, /tmp/adamHeimdallOneClick/zImage, /tmp/adamHeimdallOneClick/part.pit, /tmp/adamHeimdallOneClick/firmware.xml]
PITFileName: /tmp/adamHeimdallOneClick/part.pit
RebootRequested: true
RepartionRequested: false
Devices: [Craptivate, Smugmug 33wq0, Captivate, Samsung SGH-i897]

Source for TGZ is here: http://code.google.com/p/heimdall-o.../src/heimdalloneclick/HeimdallTGZSupport.java

and here: http://code.google.com/p/heimdall-o...ck/src/heimdalloneclick/HeimdallAutomate.java

btw... I followed the How To Write Unmaintainable Code guide to the tee. Particularly this part:
[Galaxy S I9000 Android Development] jerome.d:
My experience (see previous page) might be of use here.

I am under ubuntu 10.04 (albeit x32, but I do not think this changes things). I also only had the 1.6 version of libusb-1.0. To upgrade to the 1.8 version, I simply dowloaded the package from the debian packages, see http://packages.debian.org/squeeze/libusb-1.0-0 . It required no other dependency and thus I could install it directly (e.g. through gdebi-gtk or plain sudo apt-get install).

Then, however, when I try to run heimdall-frontend, I had some issues with the Qt version. Ubuntu 10.04 has the 4.6.2 version, but there is a bug in it which provokes a crash in Heimdall-frontend when you try to load a pit file. You therefore have to upgrade to QT 4.7.

This can easily be done using a backport repository from kubuntu (yes, even if you run ubuntu and not kubuntu): simply run "sudo add-apt-repository ppa:kubuntu-ppa/backports", it will add the repository to your deb sources, and you can then launch synaptic (for exemple) and select the 4.7 version of the Qt libraries (alternatively, you can simply choose to update all your packages wkith this new repository - I think it only update the Qt libraries and a package to connect ipods and iphones).

With these two simple operations (install libusb from the .deb package taken on the debian website, update qt via the kubuntu-ppa), I was able to run heimdall 1.3 (both command-line and the corresponding frontend).

Hope this will work for you too.
[Galaxy S I9000 Android Development] unbas:
Hey guys!

First of all apologize for my English is very bad and I use the translator, I hope you understand.

Using Ubuntu 10.04 and am a newcomer on Android. I wonder how I can use my SGS2 Heimdall to flash ROM's with the officers. I've been looking but can not find any manual front-end.

Heimdall I have installed version 1.3 (Beta)

Anybody can help me?
[Galaxy S I9000 Android Development] Benjamin Dobell:
A README is included in all packages. The debian package extracts the documentation /usr/share/doc/heimdall/README.
[Galaxy S I9000 Android Development] unbas:
Sorry. I dont read the README :( sorry
[Galaxy S I9000 Android Development] GuestK00150:
tested and confirmed working on OS X 10.6.8, 64-bit!

good work! THANKS :)
[Galaxy S I9000 Android Development] AdamOutler:
I don't really understand that libpit library. I've been trying to understand it, but it's so general purpose and there's no javadoc... I can't wrap my head around the library.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Look at the pitprint example, it shows you how to use it.

EDIT: All you really care about is PitEntry.getPartitionName() and PitData.unpack() for unpacking a file stream.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Slight correction in regards to this. Heimdall returns 0 on success or a safe abort, meaning no communication with the device took place. -1 is returned if something went wrong whilst communicating.

There was also a -2 return value that I forgot about when the device couldn't be detected or claimed, but I've just removed it in favour of a 0 return value.

So basically a return value of 0 means no communication took place OR the whole process finished successfully, so as far as the device is concerned nothing went wrong. -1 means something went wrong whilst communicating with the device.
[Galaxy S I9000 Android Development] starche_old:
I wish I'm able to say "thanks" twice :-) thanks a lot, man :-)

2 of 2 advices really help me to run heidall :-)

Now I need to read the topic trying to understand why I can not flash kernel separately from the whole firmware. When I'm loading the kernel (for example, talonDEV) heimdall says "firmware.xml is missing from the package". I understand that the kernel itself is not the full firmware, but what should I do if I wanna flash kernel only?
[Galaxy S I9000 Android Development] jerome.d:
Glad I could be of use.

I intended myself to flash a kernel (and only a kernel) today (I was going for the CF-root version of my current kernel).

If I understand well, you have to use the advanced method: you cannot simply put the kernel file in the first tab off the frontend, you have to go to the "flash" tab, indicate a pit file (see samfirmware or take the EXT4 put file from any stock firmware) and them indicate that you flash a kernel.

Basically, this comes down to creating your own heimdall package (you can in fact also do that, once you haven filled the flash tab, by going to the third tab).

I let you know how it worked for me (I'll do that in a few hours).
[Galaxy S I9000 Android Development] starche_old:
that's pity... pretty often I'm flashing new kernels, but not the whole "stuff"...

Hopefully I'm be able to flash new kernel w/o odin
[Galaxy S I9000 Android Development] AdamOutler:
when you built the software did you SUDO make, or just make? if you sudo made it, then you made it with superuser permissions and you'll need superuser permissions to read it.

} else {

You can adjust the device permissions with

sudo chmod +rw /dev/ttyACM*

where * = the ACM that represents your phone.

off hand, I'd say it looks like it's saving you from flashing the wrong firmware. Benjamin Dobell does a great job with this project in the respect to maintaining your phone in it's proper working manner... If the pit reports a larger or smaller block size then the file, then the file was not designed for your phone. In this manner there is no overwrites or underruns which can cause random problems later.

Why don't you post up the command(s) you used? where you got your software... This would make it easier to see what the problem is.

Have you tried flashing a stock kernel from SamFirmwares.com?

The most important line in that log above is this..

ERROR: Partition corresponding to -pit argument could not be located

this says that the pit is either not for the phone, or the kernel is not for the phone.
[Galaxy S I9000 Android Development] jerome.d:
I used the frontend, so there is not real "commands" in it (except while launching via "sudo heimdall-frontend").

My actions inside the frontend:

I took the .pit file from the KG1 firmware (for my phone, the SGS2), which is exactly the same as the .pit file from samfirwmare (I checked via "diff -s", not only by looking at the name of the file), i.e. u1_02_20110310_emmc_EXT4.pit

I loaded this .pit file in the "flash" tab of the frontend,

I clicked "add" and then chose "kernel". There, I put the CF-root kernel from my current firmware (KE7), i.e. the zImage coming from CF-Root-SGS2_XW_XEU_KE7-v4.0-CWM4.tar, which Chainfire posted in the development forum for the SGS2 (my phone),

I clicked on "start", and then the status window reported the error I wrote above.

I understood that the problem seemed to be in the pit file, but since this is the one from samfirmware for KE7 (my firmware) and the same as in the (leaked) KG1, I assume it is correct. Besides, samfirmware seems to indicate that there one and only one pit file for all the stock firmwares (my KE7 is a stock firmware), so I really do not understand were is the problem and how I can correct it.
[Galaxy S I9000 Android Development] Benjamin Dobell:
The recovery kernel is used in recovery mode. This allows you to have a different kernel for regular boot and recovery mode, meaning that additional functionality present in your recovery kernel doesn't need to bloat the general use kernel. It's also useful in case the regular boot kernel was to become corrupt then the recovery kernel would be fine.

SBL2 is used as a backup, this is how a custom jig works. So even if you corrupt your secondary bootloader the custom jig forces the device to use the working secondary bootloader.

Now I'm not entirely sure about this. But I read somewhere that the secondary bootloader might actually just rotate these bootloaders and even though I specify I want to flash "SBL" it may flash "SBL2" instead. Then it would rotate them. Whilst that's certainly possible I'm not really sure that is happening, especially since I'm capable of specifying both "SBL" and "SBL2" in one flash. Admittedly I could pretty easily test this theory by dd'ing secondary bootloaders before and after a few flashes and seeing what happens, I just haven't bothered.

Because the primary bootloader is so low level there's not really much point in storing a backup. The reason for this is that if the primary bootloader is not working then there's not really any way to detect it.

Although, the primary bootloader actually consists of an initial bootloader (IBL) and a primitive bootloader (PBL). It's my understanding that a copy of a working IBL is always stored on the phone, in fact the IBL may actually be discarded when you flash, once again I'd have to look into this to clarify. Anyway the IBL is what contains the functionality to specify an alternate PBL i.e. an SDCARD. The chipset has in-built functionality for this and can be done by toggling pins, it's just rather difficult without JTAG, not to say it's even easy then.

Yeah that will work.

I've only had a chance to glance at it. I'll have a deeper look when I next get a chance i.e. after I respond to the other posts and release a new beta (read on).
[Galaxy S I9000 Android Development] schack:
How do I make Heimdall work on Mac ?

Could someone write a step-by-step instruction ?

All I get is

iMac:~ henj$ heimdall detect

Failed to detect compatible device
[Galaxy S I9000 Android Development] Benjamin Dobell:
Thanks for helping out other users, great work. I've even thanked your post now ;)

Correct, I'll elaborate further in the next few posts.
[Galaxy S I9000 Android Development] Benjamin Dobell:
I've seen a few reports of that lately, I'm not quite certain what is happening. It may depend on how you install but generally speaking the udev rules should mean you don't need super user permissions.

I guess you could say that is a bug. It's not a syntactical bug or anything, I actually intentionally included that functionality. However I was unaware that some PIT files don't store a reference to themselves, which seems a bit odd to me. However another user reported this to me via PM and we have confirmed that some changes I've made fix the problem. As such the next beta release will fix this. I'll try get it out ASAP!

Depending on your PIT you may be able to do so fine now, for instance my device uses the "512" PIT and it works fine. If your PIT doesn't contain a reference to itself then you'll need to wait for this next beta.

After all I guess this is what betas are for ;)
[Galaxy S I9000 Android Development] Benjamin Dobell:
In this case it's actually a bug, of sorts, see above for details. However in the event that the PIT file specified doesn't match the PIT file on your device (and repartition wasn't specified) then you will see the following:
[Galaxy S I9000 Android Development] Benjamin Dobell:
Read the README.