yashsingh1/xdaforums huggingface dataset:
[Galaxy S I9000 Android Development] jerome.d:
The need to run heimdall as root was a very very mild issue for me (I find this strange, but not really problematic).

I suppose also! I do not understand what exactly should a PIT file contain as reference to himself, but anyway I do not intend, on the contrary to Adam, to delve into the understanding/development of PIT files.

So my conclusion is: thanks Benjamin for taking care of us! :)

Now, I'll just wait for the next beta to try my kernel flashing.

PS: btw, thanks for having thanked me. Although I have some experience in some programming/OS issues, it is rare that I have the level to help others on forums (which tend to be overwhelmed with people having much more skills than me!), so I am particularly glad when I can.
[Galaxy S I9000 Android Development] AdamOutler:
I can tell you for a fact that everything up to the very first part of the kernel loads up when you plug in USB to the phone and let it charge when it's off... It's likely a different mode of the same kernel.. However... To my understanding, the kernel is not even required for recovery of the phone. The PBL and SBL are.. I don't get the redundancy. when other areas are lacking so much.

This would be some good information... It could also explain why people get failures when flashing back to stock from some custom build. A SBL rotation could cause a PBL/SBL mismatch...

It would be nice to have a version detection system of sorts... If you do perform that test, PM me.

The IBL is never flashed. It is protected. There's even rumors floating about that the IBL area of memory may be overwritten with a bogus but realistic looking IBL... The same protection scheme Microsoft used on the XBOX... They may be hiding something.

From what I've read in the processor datasheets, the IROM and IBL, while very small, SHOULD have the capability of simply monitoring the processor state for SLEEP, DEEP SLEEP, IDLE or DEEP IDLE, during PBL and SBL. In which case, it would be possible to reset the processor and launch a different boot mode. The PBL itself has the capability built in to boot from UART, USB, MMC or OneNand... There's no reason the IBL should not be able to select a separate PBL which would allow booting from another option.. This is what I'm talking about.

I've revised it quite a bit. After looking at the LibPit, I decided to make it a core part of the program. I haven't decided if I'm going to drop support for my original format or not... I probly will... It would make more sense... but it was DONE!!! damnit... lol.
[Galaxy S I9000 Android Development] Benjamin Dobell:
I just did some quick tests. It appears you're correct that "KERNEL" is the kernel used in recovery mode. I read in a recovery kernel thread that this was not the case. However I just flashed garbage to the "KERNEL" partition and a valid recovery kernel to "RECOVERY" and it didn't work, but the opposite way around did.

Yeah I was fairly certain of this also. But just to clarify I somewhat riskily flashed garbage to both my "KERNEL" and "RECOVERY" partitions. Whilst the phone obviously wouldn't boot past the Galaxy S screen I was still able to access download mode and flash working kernels again.
[Galaxy S I9000 Android Development] AdamOutler:
Samsung could use some help with coding the entire boot sequence. I've put in a few requests for Non-Disclousre Agreements and have not heard anything back. SamsungJohn assures me that he will let me know when they are approved.

It just seems so flakey... Like, they're working on an open source platform... But they close off alot of the booting source. Who would it hurt? I mean, even if someone ripped off their code (which you just proved is total garbage), it's not like it would work on another processor. It's not like they wouldn't sell processors to support that code...

The IROM and PBL run some general purpose IOs on the processor and set up some well-known sequences for booting. They also take care of well documented features of the processor. The worst thing that could happen if they went total open-source is that they could gain the ability to backport user modifications.
[Galaxy S I9000 Android Development] Benjamin Dobell:
I've just pushed an update to the Git repository. Sorry I'm about to head out so I don't have time to build binaries at the moment.

Aside from fixing the PIT issue mentioned above I've added a 'download-pit' command to Heimdall command line and added a "Utilities" tab to Heimdall Frontend where users can then download a PIT file from their device, as well as do a few other things previously only available from command line.

I've also added a few tooltips to Heimdall Frontend that should help users out. I still need to fix the "same filename in packages" bug reported by AdamOutler, but once I've done that this will be the release candidate for 1.3.0.
[Galaxy S I9000 Android Development] Benjamin Dobell:
A lot of the bootloader code comes from other vendors, chip manufacturers etc. Samsung have a license with these vendors that prohibits redistribution of the source. If you want Samsung to open-source the bootloaders you'll have to get approval from all the different vendors.

Samsung accidentally released the bootloader source-code to their Acclaim R880 a while back. Interestingly enough when browsing it I found a lot of GPL'd code as well as proprietary code, obviously conflicting licenses. In fact they had even marked some of the GPL violations themselves with "***** GPL violation *****" in the source code. Samsung assured me that the code I was viewing was not used to compile the official bootloaders distributed with the phone and that the bootloaders distributed contained no GPL'd code, interpret that however you like ;)

EDIT: Oh I also removed the libusb-1.0 source code from my repo. Library files are there for windows as there's no such thing as pkg-config on Windows. I'm also no longer statically linking libusb-1.0 to the Windows binary. This is in order to ensure I'm not violating the LGPL by releasing the binary as MIT. Mind you releasing it has LGPL isn't a big deal as it's only the binary, my source would still be MIT.
[Galaxy S I9000 Android Development] AdamOutler:
member Conexxion2005 stated to me that he played around with the PARAM.lfs file... absolutely screwed it up.. Apparently that's where the full screen graphics are contained for the PBL/SBL sequences, like download mode, the startup logo, and the softbrick logo. Apparently the worst thing you can do is simulate a hard brick by modifying it... I'm more prone to take your word as you have a better understanding of the partitions.. what do you think?

I just committed the final bit of pit support. It's been fully Javadoc'd appropriately as well. If you wanted to pull a revision for that library you were talking about, SVN R57 would be the one. http://code.google.com/p/heimdall-one-click/source/detail?r=57

Now I'm back to the GUI.
[Galaxy S I9000 Android Development] cronosmachine:
Pulling from my phone directly to make own firmware odin using either Heimdall/odin

Hi, I tried to create this thread.

http://xdaforums.com/showthread.php?p=15695721

The idea is how to make it own firmware after make custom ROM.

I'm still not sure for boot.bin and Sbl.bin if pulling from my phone will cause any problem or not.

Should I use from stock firmware to use your program while flashing?

Can I say Primary boot loader is boot.bin and while secondary boot loader is Sbl.bin?

It seem your program Heimdall will suitable to build package.

But I still having difficulties how to use your program to create a package firmware like stock firmware.
[Galaxy S I9000 Android Development] AdamOutler:
Benjamin Dobell, is it possible to have a mandated master reset, or a cache clear added in, or are those undisclosed parameters in the protocol?
[Galaxy S I9000 Android Development] jerome.d:
I tried to build the new sources, but couldn't manage to do it: ./configure in heimdall does not find my libusb-1.0 library. I tried everything to set the PKG_CONFIG_PATH variable but I failed (that's strange because my libusb is installed in /usr/lib, I assume this is a standard prefix for pkg-config...).

So I guess I'll wait for Benjamin to buid the sources for us.
[Galaxy S I9000 Android Development] schack:
:-) :-) Actiually I already did that before asking my question, and I didn't find anything useful, except from instructions on how to build Heimdall from sources.

Best regards

Henrik Schack
[Galaxy S I9000 Android Development] AdamOutler:
Benjamin Dobell, I cloned your repo. It looks like the backend will be ready to launch soon huh? I'm eager for the new "Official" backend. Anyways. I could not get the backend to build. It had a make error 2 on the 2nd file or something.

The frontend built. I noticed that you took care of alot of the problems already on linux. Just a few more left..

Awesome idea with the download pit. That's great!

I just made my own custom firmware... I took the stock Captivate i897 kernel and I used the Ursa Minor kernel from Andromeda3 as a recovery. The device acted normally in all modes. No changes notable.... I swapped them and it booted to ursa minor with ursa minor recovery... I wonder what recovery actually does.

I'm going to check it out with UART.
[Galaxy S I9000 Android Development] jerome.d:
That's strange, I had exactly the opposite problem: I managed to build the backend (albeit after much sweating: I took some time to understand that I lacked many qt dev packages, ergo my issue with pkg-config), but I was not able to properly build the frontend.

There was several warnings in this build, and it ended with:

Source/Packaging.cpp:471: error: ‘gzFile’ was not declared in this scope
Source/Packaging.cpp:471: error: expected ‘;’ before ‘packageFile’
Source/Packaging.cpp:478: error: ‘packageFile’ was not declared in this scope
Source/Packaging.cpp:478: error: ‘gzclose’ was not declared in this scope
Source/Packaging.cpp:493: error: ‘packageFile’ was not declared in this scope
Source/Packaging.cpp:493: error: ‘gzread’ was not declared in this scope
Source/Packaging.cpp:500: error: ‘gzclose’ was not declared in this scope
Source/Packaging.cpp:512: error: ‘gzclose’ was not declared in this scope
Source/Packaging.cpp:522: error: ‘packageFile’ was not declared in this scope
Source/Packaging.cpp:522: error: ‘gzclose’ was not declared in this scope
Source/Packaging.cpp: In static member function ‘static bool HeimdallFrontend::Packaging::BuildPackage(const QString&, const HeimdallFrontend::FirmwareInfo&)’:
Source/Packaging.cpp:573: error: ‘gzFile’ was not declared in this scope
Source/Packaging.cpp:573: error: expected ‘;’ before ‘packageFile’
Source/Packaging.cpp:592: error: ‘packageFile’ was not declared in this scope
Source/Packaging.cpp:592: error: ‘gzclose’ was not declared in this scope
Source/Packaging.cpp:598: error: ‘packageFile’ was not declared in this scope
Source/Packaging.cpp:598: error: ‘gzwrite’ was not declared in this scope
Source/Packaging.cpp:603: error: ‘gzclose’ was not declared in this scope
Source/Packaging.cpp:614: error: ‘packageFile’ was not declared in this scope
Source/Packaging.cpp:614: error: ‘gzclose’ was not declared in this scope
Source/Packaging.cpp:625: error: ‘packageFile’ was not declared in this scope
Source/Packaging.cpp:625: error: ‘gzclose’ was not declared in this scope
make: *** [release/Packaging.o] Error 1
[Galaxy S I9000 Android Development] jerome.d:
I have just noticed that all the files that I had put on the internal stockage of my phone (not my external sd card) have been wiped out. The only unusual operation I made on my phone was trying to flash the kernel using Heimdall (I did not try any other flash). When I did this, after one of the error (I do not remember if it was the libusb error - when I was not root - or the "-pit" error), my phone was stuck in "download" mode (it did not reboot by himself), so I switched if off by a long press on the "power" button.

Is it possible that one of the operation made by heimdall wiped my phone internal storage (even if it did not flash anything)? Should I have left the "download mode" by another method than powering off via the button?

PS: none of the lost files were critical, I have them on my PC. It's just that I would like to understand what happened...

PPS: also, when I plug my phone to my PC, the internal storage is now detected as "/media/6E4F-0A0D" rather than something like "/media/AA..." (its name changed).
[Galaxy S I9000 Android Development] TA123:
Happened to me once with the previous version of heimdall. But the 1.3 beta worked just fine.
[Galaxy S I9000 Android Development] jerome.d:
Unfortunately, if this happened with heimdall, this was on the 1.3 beta (on Linux), since it is the only one I tested.
[Galaxy S I9000 Android Development] jerome.d:
OK, I managed to solve my build issues (I lacked one more package zlib-dev...).

I successfully build the backend and the frontend. I do not have time yet to test the flashing of the device, but I'll try this afternoon (probably using the "download pit file" utility: is there an easy way, once this pit file from my phone is downloaded, to compare it with the pit file coming from samfirmware, i.e. to see if the partitions are the same?).

PS: for those of us under Ubuntu 10.04, here is a quick guide of the operations I had to perform in order to run heimdall 1.3, and to compile from the sources:

1) update libusb-1.0 to version 1.0.8, by taking the .deb package from http://packages.debian.org/

2) add the backport repository from kubuntu (sudo add-apt-repository ppa:kubuntu-ppa/backports) and update the qt library to version 4.7

[If you just want to execute the binaries, you can stop here; to build from the sources, continue...]

3) add the following packages, by using synaptic: g++, zlib1g-dev, libqt4-dev (version 4.7), qt4-qmake, libusb-dev, build-essential [not sure this last one is mandatory, though].
[Galaxy S I9000 Android Development] jerome.d:
A few bug reports (heimdall 1.3, built on ubuntu 10.04 / phone: SGS2) on the pit printing/downloading: when I plug my phone in download mode, it is detected fine, and I can print the pit file. However, at the end of this print, I see:

Ending session...

ERROR: Failed to receive session end confirmation!
Re-attaching kernel driver...

(note: this is the same if I run "heimdall print-pit" in command line).

From this point, if I try to re-print the pit file or to download it, I get

Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...
ERROR: Setting up interface failed!

and the only way I can get a connection with the phone is to power it off and re-boot it in the download mode.

If I try, without printing the pit, to download it directly, I get

Downloading device's PIT file...
PIT file download sucessful

Ending session...
ERROR: Failed to receive session end confirmation!
Re-attaching kernel driver...

The pit seems to be correctly downloaded, but the session ending is still problematic.

Where is the bug?

PS: the downloaded pit is twice as large as the pit file coming from samfirmware (4Ko vs 2Ko). However, since they are not human-readable, I cannot tell more.

PPS: btw, I have strange "?" icons besides many buttons in the frontend (detect/print/save as in the utilities tab, for example). Is this normal? Some userguides to come?
[Galaxy S I9000 Android Development] jerome.d:
Oh, another thing I have just noticed: once again, after the preceding trials with heimdall (and the "ending session" erros), when I power down my phone from the download mode and reboot in the "usual" mode, all my internal storage has been wiped out to the factory settings (I did not lose my personnal data on my external sd card, but all the files I put in the internal storage).

Not very fun if each use of heimdall means a wipe of the internal memory. I hope this "ending session" issue can be easily fixed (I assume the memory wipe is a consequence of this issue)...

PS: btw, this issue was already present in the beta1 version (the preceding version of heimdall 1.3), and this is probably what caused my wipe yesterday too.
[Galaxy S I9000 Android Development] Benjamin Dobell:
The reason I suggested you read the README is because it includes precisely what you requested, step-by-step instructions. There are literally numbered step-by-step instructions included in the README that explain how to flash using Heimdall Frontend as well as how to flash from command line, as well as instructions for a few other common tasks.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Well the whole protocol itself is undisclosed, I reverse engineered the protocol myself. However based on what I've reverse engineered I have not come across a way to force the cache to clear. Depending on your secondary bootloader and what type of flash you've performed then devices sometimes boot into recovery mode and perform a few actions after a flash, often copying across installed applications etc. However I haven't found a way to control this process using the Loke flashing protocol. It's probably possible using adb though.
[Galaxy S I9000 Android Development] Benjamin Dobell:
That's definitely not good. When you perform a flash with Heimdall do you receive the ending session error? Based on the information I've obtained this error is only displayed when performing a non-flashing action. So if you're able to intentionally put some file on the internal SD card and determine if they're only wiped when that error appears, or whether they're wiped all the time (after a flash as well) then that would be great.

Because it only happens when you don't flash (I think) then I'm guessing it has something to do with the SGS2 expecting files to be flashed once a session has been initialised. The original series of Galaxy S devices (GT-I9000, captivate, vibrant etc.) don't exhibit this problem. Unfortunately without access to a SGS2 I'm really not sure how I'm going to be resolve this.
[Galaxy S I9000 Android Development] jerome.d:
To be franck, following this error (which is completely reproductible), I did not try a flash. I was a little bit afraid of what such an error could produce after a flashing action.

But I'll try and let you know (albeit perhaps only tomorrow morning, I'm not sure I'll have time this evening).
[Galaxy S I9000 Android Development] jerome.d:
Well, it seems to have properly worked.

Heimdall v1.3 (beta), Copyright (c) 2010-2011, Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...

Beginning session...
Handshaking with Loke...

Downloading device's PIT file...
PIT file download sucessful

Uploading KERNEL
0%
1%
3%
4%
6%
7%
9%
10%
12%
14%
15%
17%
18%
20%
21%
23%
25%
26%
28%
29%
31%
32%
34%
35%
37%
39%
40%
42%
43%
45%
46%
48%
50%
51%
53%
54%
56%
57%
59%
60%
62%
64%
65%
67%
68%
70%
71%
73%
75%
76%
78%
79%
81%
82%
84%
85%
87%
89%
90%
92%
93%
95%
96%
98%
100%

KERNEL upload successful
Ending session...
Rebooting device...
Re-attaching kernel driver...

The internal storage was not wiped by the kernel flash.

I have flashed the CF-Root kernel, now I have to play a little bit with it but it seems to be ok.

Anyway, it is a shame that some (basic!) operations lead to a memory wipe. If I can be of help, Benjamin...
[Galaxy S I9000 Android Development] GuestK00150:
oh no, please don`t do that! Same internal formating for me! all my data are gone :( hope you can fix this soon, THANKS
[Galaxy S I9000 Android Development] jerome.d:
Just for info, I have successfully flashed the XXKG2 firmware (using Intratech's files), and then flashed the KG1 CF-Root kernel (waiting that Chainfires creates his rooted KG2 kernel).

Both operations with heimdall, both went very well.

Except that it is a little bit frightnening to have to select each file individually, when flashing a complete ROM: I checked twice (or even more) to see if I was not forgetting one file, or if I was not putting one file in the wrong pit (e.g. boot.img in factoryfs.img, etc.). This is, for me, one of the weaknesses of heimdall when one flashes a ROM from Odin's packages.
[Galaxy S I9000 Android Development] AdamOutler:
Benjamin Dobell,

I have to say that this was a concern for me as well. I'd like to recommend a solution. Name verification based on PIT and other known standards. Basically, have a verification button. I'm picturing something like

Entry= getEntry().toLowerCase;
if (Entry.Title == "PBL") {
getNameAndVerifyAgainstKnownNames("PBL",Entry) \
} else if (Entry.Title == "SBL") {
getNameAndVerifyAgainstKnownNames("SBL",Entry) \
} else.......

where getNameAndVerifyAgainstKnownNames would match known PBL or SBL names against a list all in lower case.. boot.bin pbl.bin, sbl.bin.... and so on.. 2/3 of the letters should match one or more of the known names as a fuzzy logic check....

Just something to consider, as a "pre check" before generating a package.
[Galaxy S I9000 Android Development] schack:
Ok, but where can I find instructions on making things work when they dont ?

Best regards

Henrik Schack
[Galaxy S I9000 Android Development] Benjamin Dobell:
The solutions is for experienced developers to produce Heimdall Firmware Packages for inexperienced users to flash. That way inexperienced users don't have to be concerned about partition or file names at all. I don't want to constrain users to name files in a way that may not make sense to them.

From the very first release it's been a major design goal of Heimdall to support file names other than those specified within a PIT file. Generally speaking different files should have different file names so as to uniquely identify them. "zImage" and "Sbl.bin" are potentially very bad names, especially when you've got a lot of them. An example of a good name is something like "zImage_CF-Root_JVK_v2_7". Perhaps even better names would be those that include the appropriate partition, "Kernel_CF-ROOT_JVK_v2_7" or "IBL+PBL 2.2.bin" etc.

The confusion with file names at the moment is brought about because users expect files to be named the way Odin wants them to be named. If files are named better upon distribution then that will likely help users deal with any potential confusion.

Of course video tutorials flashing particular files would also be a huge help.

EDIT: I'll add "extension" warnings to the Frontend based on PIT entries. If a PIT entry specifies a file name (not always the case) and a user specifies a file using a different file extension then a warning will be given, however the user will be free to continue if they're certain of what they're doing.