yashsingh1/xdaforums huggingface dataset:
[Galaxy S I9000 Android Development] Benjamin Dobell:
Sorry about the delay guys. The release has been held back by some OS X specific issues. As far as I can tell the issue is that OS X itself is complaining about the Galaxy S' lack of compliance with the USB specification, so it's refusing to communicate with the device.
[Galaxy S I9000 Android Development] Lakitu:
Your efforts are much appreciated. I look forward to giving this a try once I get my new phone.
[Galaxy S I9000 Android Development] mike.sw:
Hey Benjamin Dobell,

GJ very good news and good job!

I'm going to receive my device later today, but for now I'm going to stop the whole relashing adventure. I missed my device so much, just want to hug it lol.

I did however left you small donation as a thank you for this great project.
[Galaxy S I9000 Android Development] oswade:
I know where you were hahaha ;) Seems like that Trials 360 game isn't on ps3.. damns :(

Good luck developing your software, SGS ftw!
[Galaxy S I9000 Android Development] xdaalmar:
What about linux?
[Galaxy S I9000 Android Development] Akrilee:
@Benjamin Dobell:

Hi, 2 months or so ago I also wanted to start to build an alternative odin flasher. Unfortunately I lacked a bit the time and knowledge (I only dumped a USB flashing session with wireshark - Windows XP in VirtualBox and Wireshark in Linux host system). I would like to work, if possible on this "little" project of yours/team. Drop me a PM if you read this with some details (how you started this, usb dump reverse engineered/odin reverse enigneered etc. etc.). Would be nice to get this baby fully compatible with odin - maybe even more stable than odin.
[Galaxy S I9000 Android Development] Benjamin Dobell:
I have just uploaded a very rushed beta release that includes the full source-code, GNU build files and Windows binaries only. I will add another update with proper instructions soon, please refer to the first post in this thread for more details.

EDIT: Although I couldn't get my Macbook running OS X 10.6 to connect to a Galaxy S I'd like other people to give it a shot, especially if you're running a more recent version of OS X.
[Galaxy S I9000 Android Development] dirk1978:
lol. Looks like I'll just have to wait until I catch you up:

darrenm@darrenm-desktop:~/Apps/Heimdall Beta 1/Heimdall Beta 1$ ./configure
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for DEPS... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... configure: error: newly created file is older than distributed files!
Check your system clock

Actually solved that, but it won't compile. Fails right away:

darrenm@darrenm-desktop:~/Apps/heimdall/heimdall$ make
make all-am
make[1]: Entering directory `/home/darrenm/Apps/heimdall/heimdall'
depbase=`echo source/BridgeManager.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -g -O2 -MT source/BridgeManager.o -MD -MP -MF $depbase.Tpo -c -o source/BridgeManager.o source/BridgeManager.cpp &&\
mv -f $depbase.Tpo $depbase.Po
source/BridgeManager.cpp: In constructor ‘Heimdall::BridgeManager::BridgeManager(bool, int)’:
source/BridgeManager.cpp:208: error: ‘detachedDriver’ was not declared in this scope
source/BridgeManager.cpp: In destructor ‘Heimdall::BridgeManager::~BridgeManager()’:
source/BridgeManager.cpp:220: error: ‘detachedDriver’ was not declared in this scope
source/BridgeManager.cpp: In member function ‘bool Heimdall::BridgeManager::Initialise()’:
source/BridgeManager.cpp:377: error: ‘detachedDriver’ was not declared in this scope
source/BridgeManager.cpp:381: error: ‘r’ was not declared in this scope
make[1]: *** [source/BridgeManager.o] Error 1
make[1]: Leaving directory `/home/darrenm/Apps/heimdall/heimdall'
make: *** [all] Error 2
[Galaxy S I9000 Android Development] techmik67:
I Tried all options possible.... anything but HAVE DISK gets "the best driver for this device is already installed" and when choosing have disk and pointing to the correct directory, i can at least SEE and CHOOSE the heimdall driver, but when i click ok to do it, i still get the same error with the beta.... "There is no driver selected for the device information set or element". I have a windows vista 32bit and windows7 64 bit, and get the same error on both systems....
[Galaxy S I9000 Android Development] mopodo:
same problems on Debian/squeeze

these errors are just some typos in the code

detachDriver can easily be added around line 68 (bool detachedDriver;)

r should be result (at line 381)
[Galaxy S I9000 Android Development] dirk1978:
Cheers. Compiled and installed:

darrenm@darrenm-desktop:~/Apps/heimdall/heimdall$ make
make all-am
make[1]: Entering directory `/home/darrenm/Apps/heimdall/heimdall'
depbase=`echo source/BridgeManager.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -g -O2 -MT source/BridgeManager.o -MD -MP -MF $depbase.Tpo -c -o source/BridgeManager.o source/BridgeManager.cpp &&\
mv -f $depbase.Tpo $depbase.Po
depbase=`echo source/main.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
g++ -DHAVE_CONFIG_H -I. -g -O2 -MT source/main.o -MD -MP -MF $depbase.Tpo -c -o source/main.o source/main.cpp &&\
mv -f $depbase.Tpo $depbase.Po
In file included from source/main.cpp:44:
source/SendFilePartPacket.h: In constructor ‘Heimdall::SendFilePartPacket::SendFilePartPacket(FILE*, int)’:
source/SendFilePartPacket.h:54: warning: ignoring return value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result
source/SendFilePartPacket.h: In constructor ‘Heimdall::SendFilePartPacket::SendFilePartPacket(FILE*, int)’:
source/SendFilePartPacket.h:54: warning: ignoring return value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result
source/SendFilePartPacket.h: In constructor ‘Heimdall::SendFilePartPacket::SendFilePartPacket(FILE*, int)’:
source/SendFilePartPacket.h:54: warning: ignoring return value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result
source/main.cpp: In function ‘bool attemptFlash(Heimdall::BridgeManager*, FILE*, FILE*, FILE*, FILE*, FILE*, FILE*, FILE*, FILE*, FILE*)’:
source/main.cpp:714: warning: ignoring return value of ‘size_t fread(void*, size_t, size_t, FILE*)’, declared with attribute warn_unused_result
/bin/bash ./libtool --tag=CXX --mode=link g++ -g -O2 -o heimdall source/BridgeManager.o source/main.o -lusb-1.0
libtool: link: g++ -g -O2 -o heimdall source/BridgeManager.o source/main.o /usr/lib/libusb-1.0.so -lrt -pthread
make[1]: Leaving directory `/home/darrenm/Apps/heimdall/heimdall'
darrenm@darrenm-desktop:~/Apps/heimdall/heimdall$ sudo make install
make[1]: Entering directory `/home/darrenm/Apps/heimdall/heimdall'
test -z "/usr/local/bin" || /bin/mkdir -p "/usr/local/bin"
/bin/bash ./libtool --mode=install /usr/bin/install -c heimdall '/usr/local/bin'
libtool: install: /usr/bin/install -c heimdall /usr/local/bin/heimdall
make[1]: Nothing to be done for `install-data-am'.
make[1]: Leaving directory `/home/darrenm/Apps/heimdall/heimdall'
darrenm@darrenm-desktop:~/Apps/heimdall/heimdall$ heimdall
Usage: -pit <file> -factoryfs <file> -cache <file> -dbdata <file> -boot <file>
-sbl <file> -param <file> -kernel <file> -modem <file> [-delay <milliseconds>]

Just a bit scared to do anything with the phone when I'm not 100% sure I've compiled everything in correctly.
[Galaxy S I9000 Android Development] mopodo:
you are my hero!

flashed JPK almost successful to my device!!

Copying to device was successful (rebooted device and reattached kernel driver...)

BUT in the recovery menu following error occured

UPDATE:

I wiped data and cache in the recovery menu and booted my phone.

Everything works!
[Galaxy S I9000 Android Development] GuestK00150:
this changes the error message from (before doing above)

to a new error message

EDIT: This error massages do not appear when trying to load the kext, but when checking what`s wrong with the following command

sudo kextutil -pi /System/Library/Extensions/heimdall.kext
[Galaxy S I9000 Android Development] TA123:
Success! Used the command line version and successfully flashed the modem and CSC. Regarding the error, just if anyone gets it, just do:

sudo chmod 666 /dev/bus/usb/001/003

Replace the path with the one you get in the error.

Thanks a lot, Benjamin! Now I had no reason to boot into Win7 anymore.
[Galaxy S I9000 Android Development] AdamOutler:
Hey, any thoughts on an MD5 checksum to verify everything went well?

http://www.twmacinta.com/myjava/fast_md5.php#tutorial

This would allow an optional extra level of security to ensure nothing happened between hash>tar.gz>internet>download>uncompress>hash verification.

<file>
<id>0</id>
<filename>boot.bin</filename>
<MD5checksum>d66fb9c71dd5bca76c6d47bb9fea4455 </MD5checksum>
</file>

looks like it's pretty easy to implement.
[Galaxy S I9000 Android Development] Benjamin Dobell:
There's no need for this as the gzip format includes 32-bit cyclic redundancy check. In saying that I'm not sure if Zlib is automatically checking it for me so I'll have to look into it further. However I am checking the TAR header checksums, it's unlikely they would pass if something went wrong when decompressing the stream as one stuff up would probably break the whole stream.

EDIT: The documentation of Zlib's gzip functions are a bit weak, but as far as I can tell I'm supposed to check the CRC myself.
[Galaxy S I9000 Android Development] AdamOutler:
I don't have that option in java.

Im having a heck of a time with untar/gz.... been at it for 10 hours and still can't get a legible file to write.. its really difficult. Any chance you know of a shortcut? I can post my code if you think you might be able to see something im missing.

Im trying my hardest to establish a foundation for that java library you were talking about.... rather then use my existing code, im writing it with no other class references. This new tar.gz format is really tough though. Its kicking my ass

edit: maybe add tar.gz support into heimdall itself?

2nd edit:

Some of the things I've tried:

Commons-FS libraries - cannot use an input stream from a JAR file, so file must be first copied to filesystem, then copied out of the tar.gz, increasing time.

Commons-Compress library - slow, but it is possible to get individual file libraries using the java utils... however it was too slow for me to consider

java.util.zip.GZIPOutputStream to tar - writes illegible files.. tar ends up at 18 megs and invalid after about 1 minute.

And a few others...

I'm watching my processor during the process and it's not peaking out at any time... around 17% usage. Hard disk is not really utilized either. I don't know where the hangup is.

I think it might be better to go through native C++ heimdall because the Java VM appears to handle decompression VERY slowly..... nearly 1 full minute to ungz a file. Alot of my ass kicking was to get around that, I tried other methods but that seems to be the main problem I guess. I stop trying after I see how long it's taking.

I am going to keep trying... I have not yet tried a buffered reader sucessfully. I can support the new XML, but it is beginning to look like TGZ is too something for Java...
[Galaxy S I9000 Android Development] AdamOutler:
whoooo buddy...

8 seconds for decompression and maxed out all 4 multi-threaded cores on my computer with this code..

if (isResource){
BufferedGZ =new BufferedInputStream ( new GZIPInputStream(getClass().getResourceAsStream(GZFileName)));
} else {
BufferedGZ = new BufferedInputStream ( new GZIPInputStream(new FileInputStream(GZFileName)));
}
BufferedOutputStream out = new BufferedOutputStream (new FileOutputStream(new File(Folder+"Temp.tar")));

try {
int avail=0;
byte bytedata[];
while (( avail=BufferedGZ.available()) != 0){
BufferedGZ.read(bytedata=new byte[avail], 0, avail);
out.write(bytedata);
}
} finally {
out.close();
}

That's more like it. I'm going to work on the tarstream now.
[Galaxy S I9000 Android Development] Benjamin Dobell:
The 64-bit kext issue has been fixed for OS X!

Anyone whose device was not detected and is running 10.6.4+ (or manually boots a 64-bit kernel) should download Heimdall Suite 1.3 (beta 2) from the first post in this thread. Beta 2 is an OS X only release as the only thing that changed was the kext.
[Galaxy S I9000 Android Development] AdamOutler:
I got this thing runnning very efficiently now. Untar and UnGZ 277.5 megs to the disk in 5 seconds.

boot.bin Writingjava.io.BufferedOutputStream@164dbd5
Sbl.bin Writingjava.io.BufferedOutputStream@9cb0f4
cache.rfs Writingjava.io.BufferedOutputStream@125844f
dbdata.rfs Writingjava.io.BufferedOutputStream@11978b
modem.bin Writingjava.io.BufferedOutputStream@f42ad0
factoryfs.rfs Writingjava.io.BufferedOutputStream@1171b26
zImage Writingjava.io.BufferedOutputStream@88e2dd
param.lfs Writingjava.io.BufferedOutputStream@e64686
part.pit Writingjava.io.BufferedOutputStream@203c31
firmware.xml Writingjava.io.BufferedOutputStream@105bd58
BUILD SUCCESSFUL (total time: 5 seconds)

I'm really impressed. disregard my last comments. This is fully dooable in java..

If it were possible to multithread, then it could be much quicker, the only problem is that the TAR is a sequential file. If it were GZ only, then it might be possible to multithread this. The problem is that the TAR is designed to be read as a Tape ARchive and therefore is a sequential read by default.... It takes just as long to read and enumerate all the entries in the entire file as it does to read and write the entire file. :(.

Tar is sucks for a ROM file. ROMs don't have RWX permissions that need to be saved.. If it were simply a GZ or a Zip, then I'm betting I could multithread processors to extract in around 2-3 seconds.

TGZ is good to go... XML up next.

http://code.google.com/p/heimdall-o.../src/heimdalloneclick/HeimdallTGZSupport.java
[Galaxy S I9000 Android Development] jerome.d:
Firmwares packages?

Hello.

I am quite new to Heimdall (in fact, I only discovered it a week ago, and I haven't yet installed it - although I am very interested since I only have linux computers). I have a question which is probably basic, but I did not find the answer in the readme file available on github... this files explains how to build a proper firwmare file, that can then be flashed through Heimdall, but can I also take one of the (many) files prepared for Odin and directly use them in Heimdall?

In other words, do all the .tar files of firmwares for Odin we see here can safely and directly be used with Heimdall, or do I have to make some kind of operation before?

Sorry if this has already been answered in this thread, but I do not have the courage to read 130+ pages to find it (and I tried the "search" function, but did not find the answer).

Also, secondary question: I own a SGS2, which should be flashable via Heimdall 1.2.0. Should I use this version, or rather the (beta) 1.3 available in the first post of the thread?

Thanks in advance for your answers.
[Galaxy S I9000 Android Development] Benjamin Dobell:
In order to flash (or package) firmware that comes in Odin format you must first extract the contents of the tar archives and use the files inside the tar directly.

The 1.2.0 release was command line only so I'd recommend using the 1.3 beta. The beta is.stable and includes a few.minor fixes since 1.2.0.
[Galaxy S I9000 Android Development] starche_old:
Guys, I need help.

I'm stuck with libusb. I've got it from sourceforge, compiled it it - NP at all (using this post - http://xdaforums.com/showpost.php?p=8470642&postcount=132). But still I cannot install heimdall due to libusb. One thing worries me when I'm making the file:

The only thing I found in the topic is that's necessary to run

but that's what's I'm doing. And also - there's no heimdall in /usr/local/bin. there's libraries in /usr/local/lib

SO, what's I'm doing wrong?
[Galaxy S I9000 Android Development] AdamOutler:
The One-Click UnBrick is the quickest way to get your system back to Heimdall 1.2. If you're running Linux, just type 'sudo rm `which heimdall`' then run the jar. If you're running Windows, use the "Resolution Center" to reinstall drivers.

Benjamin Dobell, I'm making great progress here using that new XML... That thing is really smart. I was able to automate it to the point where it's simply

heimdallTGZSupport.unTarGZResource(myResource);
String Command=HeimdallAutomate.getCommand;

Command then contains the entire --0 /path/to/file.bin --22 /path/to/file.bin.... Awesome work on that XML. It makes things very easy. I'm still working on the rest of the information...

I would like to know about the --<partition numbers>. I want to make sure the user does not flash bootloaders unless they're needed. This is a core administrative control on my program. Have you seen a bootloader on anything other then 500 (--0) or 501(--1)?
[Galaxy S I9000 Android Development] Benjamin Dobell:
I assume you're trying to build on a RPM based linux distribution? If you're debian based then you can use the packages in the first post.

I'd expect that if something was going wrong then you'd receive an error. However in order to build Heimdall you should make sure that you've got pkg-config installed as it is responsible for finding libusb-1.0. If the libusb-1.0 you've downloaded isn't working then the one in the Heimdall git repository should work. If you're working 1.3 release then you'll also need to make sure you build (no need to install though) libpit prior to building heimdall. The README contains detailed instructions.

If you still can't get libusb-1.0 to work then you can probably download developer packages using yum (once again assuming RPMs here).
[Galaxy S I9000 Android Development] Benjamin Dobell:
Well that's a little bit subjective ;) I'd probably say installing the heimdall-1.2.0.deb is quicker :p Haha, I don't mind though.

Also:

rm `which heimdall`

is not the correct way users should delete software installed from a package, it breaks the package management system. Users should use apt-get or something like Ubuntu's Software Manager (or whatever it's called).

Glad you've got the TAR and gzip functionality working nicely. In regards to the bootloader thing, I don't really recommend leaving them out. If a developer chooses to include them in a package they probably did so for a reason. For instance Froyo vs. Gingerbread bootloaders. Of course Heimdall Frontend does allow you to remove them manually from the flash if you really want. I wouldn't bother personally, I always flash my bootloaders when I perform a full flash and have never had a problem.

If you really do want to remove them then I don't recommend making any hard-coded assumptions about what partition ID will be used. I've regularly seen bootloaders on partitions 0 (primary) and 3 (secondary), with 4 being a backup secondary bootloader. If you really are worried about boot files you'll also want to consider param.lfs as well. But there's no guarantee these will be the partition IDs.

Heimdall itself tries to detect boot files in order to ensure they're all flashed together after everything else has been flashed. The way I do this is by looking in the PIT file for partitions named "IBL+PBL", "BOOT", "SBL", "SBL1", "SBL2", "PARAM" or "NORMALBOOT". That's obviously still hard-coded in some sense, but I'm using the names instead of the partition IDs.
[Galaxy S I9000 Android Development] jerome.d:
OK, thanks for the answer, but I am still lost.

I have installed and tried heimdall 1.3 (with frontend). I tried to follow the instructions from the readme file on github, but when I select, in the "flash" tab, the .pit file from the KG1 package made for Odin, the frontend crashes with the message

heimdall-frontend: symbol lookup error: heimdall-frontend: undefined symbol: _ZN9QListData11detach_growEPii

Did I do something wrong?

Also, even if I manage to charge this .pit file, all the process seems quite risky for me: how can I know how to partition my phone? I have read everywhere that the .pit file should NOT be used when flashing, except if one wants to erase all data (which is not my case).

Besides, how can I know which files from the Odin package are "primary boot loader", "secondary boot loader", etc ? Shall I trust that the names will guide me (e.g. "boot.bin" is the primary boot loader whereas sbl.bin is the secondary boot loader)?

Sorry for appearing not too courageous, but I would not want to brick my phone by making bad choices.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Well the software should never crash, so that's definitely not your fault. I just did a bit of googling and it looks like that might be a bug in Qt, I'm certainly not trying to use that symbol directly.

What OS are you running? Also what version of Qt is installed on your system? If it's not the latest version then it may be worth upgrading.

Your device will only be repartitioned (wiped) if you select the repartition check-box.

In prior versions of Heimdall Frontend (1.1.1) it was not possible to use a PIT without repartitioning even though Heimdall itself has no such restriction. In this case selecting the PIT file is required so that Heimdall Frontend knows which files are flashable, it also provides an additional level of safety over Odin as Heimdall will safely abort the flash if the PIT file you selected doesn't match the one on your device.

There's no harm in being cautious, just try read and use the search functionality wisely.

In this case yes the primary bootloader is boot.bin and the secondary bootloader is Sbl.bin. Depending on your device the name inside the PIT file for your primary bootloader will likely be "IBL+PBL" which means initial bootloader & primitive bootloader (i.e primary bootloader).
[Galaxy S I9000 Android Development] jerome.d:
I am on Ubuntu 10.04 LTS. I had to update libusb-1.0 since the native package for this distro is 1.0.6 and heimdall 1.3 requires 1.0.8. As for Qt, if I understand well what synaptic tolds me, I think I am on 4.6.2. I am however not very enclined toward "updating" this Qt version since it is the one coming with the LTS version (and, I am assuming, is something quite "at the core" of my gnome version); upgrading the sole libusb-1.0 package was ok for me, but the whole Qt library is another scale... (I prefer, if I can, to stick with my distribution's packages, for stability issues).
[Galaxy S I9000 Android Development] Benjamin Dobell:
I doubt updating Qt would cause problems. Nonetheless if you're reluctant to do so you can always use Heimdall from command line. Just type:

heimdall help

for details.
[Galaxy S I9000 Android Development] GuestK00150:
great! will try on the weekend ;)

THANKS
[Galaxy S I9000 Android Development] jerome.d:
OK, thank you. I looked into upgrading Qt but it is really painful (lots of dependencies are required, so I have to look for a proper debian/ubuntu repository to add to my lists, etc.: not something that can be done in 5 minutes...). As for the command line, I am not afraid of them per se, but for something like flashing my phone (with all the - bad - consequences it can have),

I prefered to test a little bit step by step, by first trying to build a Heimdall firmware and see how it is loaded. Anyway, if I remember correctly there is not need to use the frontend to build the firmware (I'll just to delve a little bit into the appendices and write the xml files myself). I'll do that and see if I can then upload it in the first tab of the frontend.
[Galaxy S I9000 Android Development] jerome.d:
I managed to find a repository (kubuntu backport for lucid lynx) which has qt4.7. After installation of the new version of qt, Heimdall seems to work fine. I was able, I think, to create a firmware package.

However, I'll have to dig a little bit in the posts here to ensure that I put the proper Odin files to the proper place in Heimdall. I'll have to understand/search for my "device product code" (unless it is plainly "GT-I9100", i.e. the commercial name for SGS2).

Thanks anyway to you, Benjamin.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Great! I'm glad you got it working.

Yeah, "GT-I9100" would be the correct product code for the SGS2. GSMArena is generally a good place to search for product codes when you're not sure.