yashsingh1/xdaforums huggingface dataset:
[Galaxy S I9000 Android Development] Benjamin Dobell:
Hmm, yeah PIT files tend to be distributed separately. I believe Samfirmware has a huge list of them, although you'll want the one that's currently installed on your device. Don't stress if you're not sure which one is correct, when you attempt to flash Heimdall will let you know if the PIT you've specified doesn't match the one on your device (unless of course you're repartitioning, in which case the PIT file on your device will be overwritten).

I planned to add functionality that dumps a device's PIT file straight to file using Heimdall Frontend, however the functionality didn't make it into this release. I'll try get it ready ASAP.

The new interface changes are a bit of a pain now, unfortunately the changes were required to support a wider range of devices. When developers start releasing Heimdall Firmware Packages the process will become much simpler (it will be simpler than both the old interface and Odin).
[Galaxy S I9000 Android Development] Benjamin Dobell:
Heimdall Frontend isn't really meant to provide one-click solutions. I like users looking at exactly which files they're flashing, that way people won't get angry at me because they didn't see what they were flashing ;)

However, I intentionally developed Heimdall and Heimdall Frontend as two separate applications so that anyone can write and distribute scripts (or applications) to perform one click flashes.

A one-click root can be created extremely simply by writing a batch file or shell script with the following single line command:

heimdall flash --kernel zImage

Stick that in a .bat or .sh file in the same directory as a rooted kernel, double click it and you're good to go.

It's probably easier on Windows as you might run into problems on OS X or Linux with permissions. In which case Linux or OS X users could just extract the rooted kernel to their home directory, open a terminal and type:

heimdall flash --kernel zImage

Alternatively Adam Outler is working on a One-Click user interface that uses Heimdall to flash. It's predominantly for Captivates but given that it uses Heimdall it should support all the same devices as Heimdall without any major problems.
[Galaxy S I9000 Android Development] Benjamin Dobell:
It's also available on your system in /usr/share/doc/heimdall/README. Not necessarily my idea of a good way to redistribute READMEs however that's how it's done using debian packages.
[Galaxy S I9000 Android Development] KowalskiXDA:
ERROR: Failed to detect device! For the next time... Thanks!
[Galaxy S I9000 Android Development] Benjamin Dobell:
Linux or OS X? You're in download mode I presume? Also what device are you using?
[Galaxy S I9000 Android Development] AdamOutler:
I'm writing it as broad as possible. It will support all options when I'm finished, however in development, I can only support the options that I have available. It will support the entire "Heimdall Flash" capabilities eventually... Still working on it.... right now as a matter of fact..

The values you see in the top portion comes from a file called DISTRIBTUION.txt contained within the JAR. Currently, it's set to the values of my own phone.

DeviceModel=SGH-I897
DeviceFriendlyName=Captaivate
DeveloperTeam=XDA-Developers
DeveloperMembers=Adam Outler, Robert Dobell
ROMName=I897UCKF1
ROMRevision=
Platform=Android
PlatformVersion=2.3
Manufacturer=Samsung

My original idea was to make it really easy to edit a text file, however I'll be working on supporting the new XML format, supporting the .tar.gz format, as well as additional flashing options.

I'm using the Linux64 binary.

I'm seeing clipping on a few screens.... Here, let me show you.
[Galaxy S I9000 Android Development] KowalskiXDA:
OS X 10.6.8 + Download Mode of course + S2 I9100 (Post # 1140)
[Galaxy S I9000 Android Development] Benjamin Dobell:
Eek, that's a huge font you're using there, I'm not sure there's a whole lot I can do about that other than trying to override your theme options (but that's probably just going to annoy users even more). I intentionally shrunk the Heimdall Frontend interface slightly for the 1.3 update so that it would fit on netbook screens without any problems, I'm not particularly keen to enlarge it again.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Okay, it must be that pesky kext issue. This would be so much easier to work out if I had a SGS2. Although I could say the same thing about the Droid Charge, Galaxy Tab 10.1 and any other problem devices ;)

I'll see what I can do. Although if people do wish to donate towards getting me a SGS2 then that would be great. I've got $266.26 USD saved in my donation account at the moment to put towards a device. Although I haven't taken anything out in almost 5 months so a small portion of that should probably go towards web hosting.
[Galaxy S I9000 Android Development] AdamOutler:
It's the default for Ubuntu. In Ubuntu 11.04, they changed the interface.... focusing on ease of use and readability.. That's going to be all systems I guess... DId you use the default system font or did you specify a particular size?
[Galaxy S I9000 Android Development] AdamOutler:
btw.. I'm not seeing copyright notice in the frontend.

I also reposted that screen shot... For some reason when I made my initial PROPERTIES.txt, I put your name down as Robert... I'm very sorry....

edit: just noticed I spelled Captivate wrong too... hey, who cares?
[Galaxy S I9000 Android Development] Benjamin Dobell:
Ugh, now I know why so many people were complaining ;) I'm still running 10.10.

I do have some vague control over the font size with Qt, however it's pretty arbitrary. In OS X it has been a real problem, OS X likes to make things so tiny you can't read them. So if I was to decrease the font size then OS X users would be left squinting. I can obviously change it at runtime (OS specific) if need be, I'll do a bit of research about Qt and Unity and see if there's some decent advice floating about out there.

Haha, you're really stressing out about that copyright. It doesn't need to popup on screen, slap you and steal your first born ;) Heimdall Frontend's copyright is accessible from Help -> About Heimdall Frontend.

Or do you mean once you click Help -> About Heimdall Frontend the copyright isn't displayed? With those sort of font sizes I wouldn't be surprised if it's clipping, but you should at least be able to make out the copyright.

Haha, yeah I saw that mistake ages ago when you e-mailed me. I'm not too fussed, as long as in the final release you don't credit me or Glass Echidna incorrectly then that's fine.

:P
[Galaxy S I9000 Android Development] AdamOutler:
I do stress about copyrights. They're the only thing that keeps open source developer's work from being attributed to the next guy who uses them. If I wanted to, I could take your compiled app and call it my own. Noone would know the difference. I mean, we work for free or donations... I want my work to be my work.

In my app, I have an "About" window with a copyright header, project logo and a bit of detail about the project... it's also got a "legal" button where you can view the entire license and which parts of my code are attributed to that license.... Heimdall & Heimdall One-Click, mit license, Elevate.exe-unknown license... gave credit to the dude who made it. Timed window boxes....

/*
* Gio Gilligan, Mar 14, 2007
* http://www.jguru.com/faq/view.jsp?EID=266182
* Unlicensed
*/

Even my unzip class comes with attribution..... 'Licensed under the "I Found This On Stack Overflow License"'.

My work in FileOperations, FlashPreparation, HeimdallOneClickAboutBox, App, View, InstallHeimdall, Legal, Log, Shell, ShellWorker, Statics, and WindowsProblem classes are all 100% attributable to me.

If you look in the source, you'll find the folder called HeimdallOneClick/Resources/HeimdallPackage/ and there is a single text file which contains:

/* This package contains:
* Heimdall Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/

The license is the only thing that protects an open-source developer. In 30 years when my Java app is running on someone's refridgerator, I don't want Samsung taking credit for it.

Licensing allows me to program with pride and say "I did this" in sound concious without having to feel bad about it. It's right there in black and white. Anyone can read it... Noone can change it. It allows me to ensure that the proper credit is given to the proper person.
[Galaxy S I9000 Android Development] Benjamin Dobell:
I understand what you're saying and I agree, I don't want someone stealing my work either. I simply meant that I'm not too fussed, just as long as you include the copyright somewhere that's reasonably accessible then it's fine.

Although I'm glad you mentioned this because you just reminded me I need to add copyright notices for libusb-1.0, zlib and Qt! I'm used to distributing things in source form where these notices are included in header files and "COPYRIGHT" files. I completely forget when I'm working with binaries!
[Galaxy S I9000 Android Development] TA123:
Is it easier than to do it from command line? I've got modem.bin so it should be something like

heimdall flash --modem modem.bin

But in the CSC package I've got two binaries: cache.bin and hidden.bin (from the memory). Should I flash the both of them?
[Galaxy S I9000 Android Development] Benjamin Dobell:
This is why I generally think one-click solutions aren't practical, and sometimes a bad idea. Do you want to flash cache.bin and hidden.bin? I have no idea what files you're flashing, where they came from, or what you're hoping to achieve. The answer is simply flash the files you want to flash.

If you're trying to perform a full firmware flash then you should flash all the files the developer has distributed (unless documentation says otherwise). It's for this very reason I'm hoping Heimdall's firmware package format will be adopted by developers.
[Galaxy S I9000 Android Development] AdamOutler:
Yeah.. It's not always practical to have a one-click solution for everything. Sometimes it's very desirable though. Like.... Reducing problems with a custom ROM, or flashing a firmware from SamFirmwares.com. You wouldn't want to use a one-click to update a modem or the FactoryFS. I do plan on testing and releasing Andromeda4 as a one-click package only to ensure stability of the ROM. Another major point is that there are no one-click back-to-stock solutions for Linux or OS X.

Someone tested One-Click UnBrick with Lion a few minutes ago. I'm still using the 1.2 binaries in One-Click UnBrick. As long as you used the same methods in 1.3, everything should be fine for the backend for Lion. http://xdaforums.com/showpost.php?p=15579790&postcount=138

Also, hackaday.com just covered One-Click UnBrick... a few minutes ago. http://hackaday.com/2011/07/12/one-click-unbrick-for-samsung-phones/
[Galaxy S I9000 Android Development] Benjamin Dobell:
You might want to go easy on the advertising of One-Click Unbrick, the "heimdall close-pc-screen" command won't repair a bricked phone. It simply unsets a flag on the phone that will allow the phone to "attempt" to boot. If a flash failed resulting in a corrupt file then running "heimdall close-pc-screen" could potentially damage the phone.

EDIT: The best way to fix a soft-bricked device is just to flash a full set of firmware files.
[Galaxy S I9000 Android Development] AdamOutler:
I am not advertising. It advertised itself. I told Mike(the author on hackaday and a programmer buddy) that this project is not really done. Also, Close-PC-Screen depends on the SBL being operable. With the SBL operable, download mode will be accessible. I verified this with UART. It should be completely safe. What leads you to believe otherwise?
[Galaxy S I9000 Android Development] Benjamin Dobell:
Sorry I didn't mean you shouldn't advertise the software at all. Rather I meant "Unbrick" probably isn't an accurate term to describe the software as it won't repair a bricked device or even a device with a partially failed flash.

The command itself is safe. However forcing a device to boot using corrupted files may not be. It's unlikely the hardware would become damaged from forcing the device to boot, however there's definitely potential to lead to further corruption of the software and/or user content.

As such the "heimdall close-pc-screen" command should probably only be used if you get stuck in download mode because a device stops in a situation where no files have been written. If some files were written then a safer bet would just be to try flash again.
[Galaxy S I9000 Android Development] AdamOutler:
From my understanding, the "flash not complete" bit is set at the beginning of flashing. Any number of things can trigger the bit not to be unset. Once the flash is completed sucessfully, the flag is unset.

The order of boot is IROM>PBL>SBL. At this point SBL is where the flag is checked and the phone is bricked. SBL also contains download mode. Hard bricks stop at PBL. Soft bricks stop at SBL. If the SBL is on the phone, then you have download mode.

Why would you say hardware damage can occur? The IROM, PBL and SBL initialize the hardware. The Kernel allows interface with the hardware. The Kernel is the only thing that's not initialized. If damage were to occur, it would occur before the Kernel was loaded.

I've been doing research on this. There's no hazardous voltages allowed onto the processor. There is only firmware and that firmware is designed to be modifiable for any configuration. The higher voltages are isolated from the processor and applied to the devices which can handle them.

After using unbrick.. If it wont boot your phone, then hold download mode combination while booting. The IBL/PBL reads the button combination and automatically routes the SBL into download mode. You can't have softbrick status without a proper SBL. A mismatch would cause a hardbrick.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Correct.

I'm not saying damage will occur, just that it is a possibility based on the information I have at hand (which isn't a whole lot). If the hardware ensures this won't happen then that's great :) I'm just being cautious.

"close-pc-screen" won't really un(soft-)brick a device because damaged files won't be repaired. For instance if the system (or factoryfs) partition is corrupt the device will still fail to boot after running "close-pc-screen". Users may be confused by this result. Also attempting to boot with corrupt files may force the device into a boot loop, which may cause further problems.

Again these are all only possibilities. However, it's this logic that lead me to name the command "close-pc-screen" and not "unbrick". Trying to explain to users when they should and shouldn't use this functionality is fairly difficult so I just prefer to tell users to reflash their device as that will work regardless of the device's present state.
[Galaxy S I9000 Android Development] GuestK00150:
OS X working ;)

Hey Benjamin and all OS X users,

o.k. one day late, but here is my os x report ;) And the result first: A few problems on the way (all documented below), but I got it to work ;) perhaps this helps other os x users (just change my username tom in the commands and/or the script to your needs) and helps you to solve the problems...

System Information

Mac OS X 10.6.8, 64-bit mode (needs to be started in 32-bit mode later)

Installation steps, problems and solutions

1	download and install macports

2	install pkgconfig via macports

sudo port install pkgconfig

3	removing old files

sudo rm -rf /Users/tom/Desktop/heimdall/
sudo rm -rf /System/Library/Extensions/heimdall.kext
sudo rm -rf /usr/bin/heimdall
sudo rm -rf /usr/local/bin/heimdall

4	clone git repo

git clone [url]https://github.com/Benjamin-Dobell/Heimdall.git[/url] /Users/tom/Desktop/heimdall/

5	installing libusb

cd /Users/tom/Desktop/heimdall/libusb-1.0/
sudo ./configure
sudo make
sudo make install

6	installing libpit

cd /Users/tom/Desktop/heimdall/libpit/
sudo ./configure
sudo make
sudo make install

7	installing heimdall

cd /Users/tom/Desktop/heimdall/heimdall/
sudo ./configure
sudo make
sudo make install

this ends in the following error:

solution: install libusb via macports

sudo port install libusb

repeat heimdall install steps

8	install kext

cd /Users/tom/Desktop/heimdall/OSX
sudo sh install-kext.sh

this ends in the following error:

solution: performing all the script steps line by line by hand (copy - paste)

sudo chmod 755 /usr/local/bin/heimdall
sudo cp -r heimdall.kext /System/Library/Extensions
sudo chmod -R 755 /System/Library/Extensions/heimdall.kext
sudo chown -R root:wheel /System/Library/Extensions/heimdall.kext
sudo kextload /System/Library/Extensions/heimdall.kext

last step ends in the following error:

It seems that the kext has to be edited for 64-bit use - please do this so it can work with lion - THANKS.

solution: download sixtyfour switcher from macupdate.com, reboot to 32-bit mode and redo command:

sudo kextload /System/Library/Extensions/heimdall.kext

9 boot phone to download mode, plugin usb cable and detect device

heimdall detect

10 you did it - YAY ;) flash your stuff according to the documentation

Have fun flashing!

@ Benjamin: If you need a tester to solve the issues - just let me know! It can take a day or two but you will get a feedback for sure! Thanks for your hard work - Hope you keep it up!

11	Building the frontend has still the problem asking for SDK 10.4. Pleas update to 10.6 / 10.7.

12	Rebooting back to 64-bit mode breaks the kext again, so flashing only works in 32-bit mode for me now!
[Galaxy S I9000 Android Development] KowalskiXDA:
I try it! Thanks Tom, Adam & Benjamin!

Result: Failed to detect compatible device.

I wait the Heimdall update by Benjamin... :)
[Galaxy S I9000 Android Development] TA123:
OK, found the PIT file. Now I got an error (both command line and frontend):

Initialising connection...
Detecting device...
libusb couldn't open USB device /dev/bus/usb/001/003: Permission denied.
libusb requires write access to USB device nodes.
ERROR: Failed to access device. libusb error: -3
[Galaxy S I9000 Android Development] AdamOutler:
you need to install git. You can get it online or try sudo port git. It is supposed to be git clone http....
[Galaxy S I9000 Android Development] GuestK00150:
The answer is in my post (number 7). Maybe you have been too tired ;) Install libusb via macports:

sudo port install libusb
[Galaxy S I9000 Android Development] GuestK00150:
right, I forgot about that cause I always have it installed ;) thanks
[Galaxy S I9000 Android Development] AdamOutler:
I was talking to kawalski ...

You were editing that post faster then I could keep up. I had a subscription notification on this thread at step 2. I responded to it on step 4 or 5. Now I came back and it's at step 8 or 9... slow down partner.. You're compiling software that's been compiled before. Take your time to understand things... It can be slow and tedious. It just takes patience.
[Galaxy S I9000 Android Development] Benjamin Dobell:
xda_devtom, thanks for the detailed info. I'll try iron out some of those kinks for the next update.
[Galaxy S I9000 Android Development] GuestK00150:
don`t get your point, my post was quite long and when reading over it after it was finished I just wanted to make some things clearer. But thanks anyway ;)

I like your communication here, a lot of things can be sorted out with your activity and help!
[Galaxy S I9000 Android Development] GuestK00150:
superb! thanks again for your good and hard work. Would love to see the 64-bit kext problem solved first, because it is most important thing to get it to work on lion. So if you need a tester for 64-bit kext let me know ;)
[Galaxy S I9000 Android Development] AdamOutler:
What does it mean when Heimdall pauses for several seconds? Everything just stops and there are no updates? What's going on at that point? Communication error?
[Galaxy S I9000 Android Development] Benjamin Dobell:
Depends when the pause happens. If it's when sending a file it's because Heimdall finished a "file transfer sequence" and Heimdall is waiting on the device. I presume the delay is caused by the device copying the file sequence from RAM onto permanent storage. You can verify this by checking if the progress bar on the device jumps to a new value. That's because the device's progress bar only updates at the end of a file transfer sequence.
[Galaxy S I9000 Android Development] AdamOutler:
I'm going to put a 2 second timer on the % sign, qualified by only numbers and a percent sign and turned off by alpha characters, to be reset every time a character is received. The timer will trigger a message like "Buffered, copying files internally." with a '.' added every timer tick. A user got impatient and thought his device froze while using Heimdall Frontend 1.2.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Could you try change line 43 of /System/Library/Extensions/heimdall.kext/Contents/Info.plist from:

to

i.e. Replace "kernel" with "kpi".

I'm hoping if you do that, reboot the system (just in case) and connect your device in download mode then it will be detected.
[Galaxy S I9000 Android Development] techmik67:
Yes, and I then chose HEIMDAL driver..... and got the above error.
[Galaxy S I9000 Android Development] Benjamin Dobell:
I was away for a few days but I'm back now and I thought I should let everyone know I've got Heimdall working in a stable state that I'm extremely happy with.

I have just flashed my phone 10-15 times in a row. Heimdall is also significantly faster than Odin now as I have found the 15 ms delay between communication to be totally unnecessary except when waiting on the phone after a sequence of file transfers (which is safely accounted for).

I'm now in the process of cleaning up the source a bit and getting ready to release a source included beta for Windows, OS X and Linux. This release will carry the beta tag as there is still some functionality I would like to include for a final release (repartitioning etc.) The source code also makes mention to dumping the ROM/RAM but at present there is no way to do so, this will also be included in the first non-beta release.

Anyway if you've been hanging out for a Linux/OS X or source included release then check back here in an hour or so.
[Galaxy S I9000 Android Development] pietro_spina:
Great news!

I won't be in a situation to test for a few weeks but I'll certainly spread the word in the meantime.

Cheers,

P
[Galaxy S I9000 Android Development] xdaalmar:
I have announced Heimdall in a forum in Spain, and I have to tell you that we, linux users, are looking forward the beta release very much.
[Galaxy S I9000 Android Development] andrewluecke:
Sounds good. If it's open source, there might even be a chance that Samsung adopts it
[Galaxy S I9000 Android Development] FadeFx:
Congrats Benjamin...

But be sure you will most likely never know...
[Galaxy S I9000 Android Development] snaff:
Thanks Benjamin, this software will be much appreciated.
[Galaxy S I9000 Android Development] xvarthx:
I have a Galaxy S, H3g - 3 Branded (Italy)

Mine Product ID: 6877 rev 4.00 , but "Italy" it's not on your list for this product id.