yashsingh1/xdaforums huggingface dataset:
[Galaxy S I9000 Android Development] tkienzle:
Thank you sir for your every speedy reply... :D
[Galaxy S I9000 Android Development] tkienzle:
Ok i think i git it now :D going to try and setup a fork to you now...
[Galaxy S I9000 Android Development] hlaube:
Hi Ben,

still having problems on my Mac (running 10.5.8, Intel Chip)

MacBook:~ herbert$ heimdall --help

dyld: unknown required load command 0x80000022

Trace/BPT trap

I used meenwhile the 1.2-version on Win XP (32Bit, bootcamp on my Mac) without problems.

I followed your instructions, you provided by mail:

I expected (or rather was hoping for) the linker error to be resolved with the updated universal libusb-1.0 library, which seems to be installed correctly on your system.

There is no /usr/local/lib/libusb-1.0.0.dylib still on your system? Also what version of OS X are your running?

Although it shouldn't be necessary. Perhaps try copying /usr/lib/libusb-1.0.0.dylib to /usr/local/lib/libusb-1.0.0.dylib. Make sure the permissions are correct (chmod 755 /usr/local/lib/libusb-1.0.0.dylib). If that still doesn't work all I can think of is trying to compile from source.

As stated: It was still /usr/local/lib/libusb-1.0.0.dylib their, which I deleted, I re-installed the binary loader heimdall-1.2.0-mac.dmg, which had no Readme-file in it.

The error is still there. I also tried copying /usr/lib/libusb-1.0.0.dylib to /usr/local/lib/libusb-1.0.0.dylib and did set perissions. Did not changed the problem.

Would like to try the compilation from source.
[Galaxy S I9000 Android Development] Benjamin Dobell:
I definitely want to get those binaries working at some stage so less experienced users don't have to worry about compiling from source. However at the moment I'm at a bit of a loss as to what is going wrong.

Cool it looks like you've got a Github fork up and running. If you go to your downloads section you should be able to upload RPM packages. Once you're done post the direct link(s) in this thread and I'll put it up on the first page of the thread.
[Galaxy S I9000 Android Development] tkienzle:
My shockwave crashed when i was uploading them don't think it worked how do i delete them and try again?
[Galaxy S I9000 Android Development] Benjamin Dobell:
It's a bit buggy at the moment. When my upload finish I receive an error claiming the upload failed, however the uploads are fine. It's probably easiest to download the files yourself after uploading just to verify they're not corrupt.

If they are corrupt then you can delete them by first clicking the "Manage downloads" button. This should then cause several "Delete" buttons to appear next to each file presently available for download.
[Galaxy S I9000 Android Development] Dr Hotdog:
I'm having some problems with flashing 'hidden' or 'movinand' files to my Galaxy Tab (I'm trying to flash the GB_Stock_Safe_v2 ROM from Team Overcome, which includes both types of files). I'm using the latest version of the command line tool, compiled from the source fetched from the github repository today. If I include either a hidden or movinand file in the flash command I get errors like the following:

Uploading HIDDEN
100%
Failed to confirm end of file transfer sequence!
HIDDEN upload failed!
Ending session...
Rebooting device...

Any ideas? Flashing without the hidden and movinand files just results in a Tab that won't boot :-(
[Galaxy S I9000 Android Development] Benjamin Dobell:
Would you mind uploading the verbose output somewhere and posting a link so I can get a few more details? I don't own a Galaxy Tab (yet) so I can't debug/test for them unfortunately.

Heaps of Galaxy Tab owners used Heimdall 1.1.1 without problems and it wasn't capable of flashing hidden or movinand. I don't know if they were selecting repartition though, perhaps selecting repartition causes problems.

By the way, which Galaxy Tab? Original Galaxy Tab (7 inch), Galaxy Tab 10.1 or Galaxy Tab 10.1v?
[Galaxy S I9000 Android Development] Dr Hotdog:
Will do.

I was one of them, on this very Tab I used Heimdall 1.1.1 to successfully flash the Overcome JMK_Stock_Safe ROM, including repartitioning. In fact I've just done it again since I couldn't get the GB_Stock_Safe_v2 to work. The JMK_Stock_Safe ROM (a 2.2.1 ROM) doesn't have a hidden part though whereas the GB_Stock_Safe_v2 (a 2.3.3 ROM) does, and seems to need it.

It's a GSM 7" (GT-P1000).
[Galaxy S I9000 Android Development] Dr Hotdog:
OK, I tried to flash the GB_Stock_Safe ROM again with hidden file included and with the verbose output option. It again failed to complete the hidden file upload. I've attached the output.

Unfortunately this time my Tab has ended up bricked, after Heimdall finished the screen went off and now it is completely unresponsive :(
[Galaxy S I9000 Android Development] Benjamin Dobell:
Hmm, now that definitely shouldn't happen! The hidden partition isn't used during the boot process so it wasn't the problem. However the primary bootloader you flashed at the same time is. That primary bootloader you flashed is definitely meant for your tab? Presumably it is.

If the primary bootloader is compatible with your device then the problem has to be some sort of incompatibility between the secondary bootloader (or param.lfs) on your device and primary bootloader you just flashed.

Are you able to compare the checksums of the Sbl.bin and param.lfs between the two sets of firmwares you're using? i.e. The one you were going to flash and the one presently on your device.

I don't know how easy it is with the Galaxy Tab, but if possible try remove and replace the battery. If that doesn't work then you'll need to try use a custom jig. Mind you I'm still not certain if that will work, hopefully the backup-secondary bootloader on your device is compatible with the primary bootloader you just flashed.

EDIT: In previous versions the primary bootloader and secondary bootloader were always flashed after other firmware files. The problem is I can't enforce that directly now as there's no easy way for me to identify which files are in fact the bootloaders. Well if you specify them using the --primary-bootloader and --secondary-bootloader syntax then I can tell, but not if you use --<partition identifier> syntax.
[Galaxy S I9000 Android Development] Dr Hotdog:
According to the checksums the boot.bin, Sbl.bin and param.lfs are all different between the two firmwares (Overcome's JMK-stock-safe and GB_Stock_Safe_v2), so some sort of fatal incompatibility between the primary bootloader from GB_Stock_Safe_v2 and secondary bootloader or params from JMK-stock-safe would explain it. Not too surprising I suppose, one is Froyo and the other Gingerbread.

What I should have done was first flash everything apart from the hidden and movinand parts before trying the hidden part again. That way when the flash failed my phone should have been left in a state where I could at least get back into download mode so I could go back to JMK-stock-safe like I already had done. Hindsight is a wonderful thing...

Unfortunately the battery on the Galaxy Tab is not removable, at least not without some level of surgery on the device. Some people have been able to revive bricked Tabs by simply waiting a day or two for the battery to run flat, then recharging it and booting to download mode after that. At this point it's looking like a visit to a Samsung Service Centre is in my near future :(
[Galaxy S I9000 Android Development] hlaube:
Is there a way I can be of support?

And would you mind putting the source of 1.2 into your repository, so I can compile it?
[Galaxy S I9000 Android Development] Benjamin Dobell:
As of yet I'm not sure how you'll be able to help, I need to get a better idea of what is going wrong.

However the 1.2.0 source is already available from Github:

https://github.com/Benjamin-Dobell/Heimdall

The link on the product page just takes you a particular commit, the one with the v.1.1.1 tag which is probably why you couldn't find it.

Ugh, sorry about that. I'll try make sure files involved in booting up are flashed last in the next update so this doesn't happen. Alternatively I could just let the flash continue if one file fails, however I don't think that's necessarily a good idea either.

If you can get your hands on a custom jig then it's definitely worth giving that a try before taking it to a Samsung Service Centre.
[Galaxy S I9000 Android Development] hlaube:
May it be possible that we have a bad mix of libusb and its naming?

I found:

/usr/lib/libusb-1.0.0.dylib

/usr/local/bin/libusb-config

/usr/local/include/libusb-1.0

/usr/local/include/libusb-1.0/libusb.h

/usr/local/lib/libusb-1.0.a

/usr/local/lib/libusb-1.0.la

/usr/local/lib/libusb.a

/usr/local/lib/libusb.la

/usr/local/lib/libusbpp-0.1.4.dylib

/usr/local/lib/libusbpp.a

/usr/local/lib/libusbpp.dylib

/usr/local/lib/libusbpp.la

/usr/local/lib/pkgconfig/libusb-1.0.pc

/usr/local/lib/pkgconfig/libusb.pc

What I am concerned of is libusb with level 1.0 an level 1.0.0

In all honest, I have no clue, but it is something that looks strange.

The crash-report does not tell a lot:

Process: heimdall [251]

Path: /usr/bin/heimdall

Identifier: heimdall

Version: ??? (???)

Code Type: X86 (Native)

Parent Process: bash [238]

Date/Time: 2011-06-05 11:21:57.562 +0200

OS Version: Mac OS X 10.5.8 (9L31a)

Report Version: 6

Anonymous UUID: F7C5B2D7-800C-4B8A-8EC0-1227517A3ABE

Exception Type: EXC_BREAKPOINT (SIGTRAP)

Exception Codes: 0x0000000000000002, 0x0000000000000000

Crashed Thread: 0

Dyld Error Message:

unknown required load command 0x80000022

Because of the download of the source, I may be to stupid, but I will keep trying to download the source of 1.2.0
[Galaxy S I9000 Android Development] hlaube:
Learned how to use git, downloaded source and I might have found something wrong.

libusb installs ok:

bash-3.2$ sudo make install

Making install in libusb

test -z "/usr/local/lib" || .././install-sh -c -d "/usr/local/lib"

/bin/sh ../libtool --mode=install /usr/bin/install -c libusb-1.0.la '/usr/local/lib'

libtool: install: /usr/bin/install -c .libs/libusb-1.0.0.dylib /usr/local/lib/libusb-1.0.0.dylib

libtool: install: (cd /usr/local/lib && { ln -s -f libusb-1.0.0.dylib libusb-1.0.dylib || { rm -f libusb-1.0.dylib && ln -s libusb-1.0.0.dylib libusb-1.0.dylib; }; })

libtool: install: /usr/bin/install -c .libs/libusb-1.0.lai /usr/local/lib/libusb-1.0.la

libtool: install: /usr/bin/install -c .libs/libusb-1.0.a /usr/local/lib/libusb-1.0.a

libtool: install: chmod 644 /usr/local/lib/libusb-1.0.a

libtool: install: ranlib /usr/local/lib/libusb-1.0.a

----------------------------------------------------------------------

Libraries have been installed in:

/usr/local/lib

If you ever happen to want to link against installed libraries

in a given directory, LIBDIR, you must either use libtool, and

specify the full pathname of the library, or use the `-LLIBDIR'

flag during linking and do at least one of the following:

- add LIBDIR to the `DYLD_LIBRARY_PATH' environment variable

during execution

See any operating system documentation about shared libraries for

more information, such as the ld(1) and ld.so(8) manual pages.

----------------------------------------------------------------------

test -z "/usr/local/include/libusb-1.0" || .././install-sh -c -d "/usr/local/include/libusb-1.0"

/usr/bin/install -c -m 644 libusb.h '/usr/local/include/libusb-1.0'

Making install in doc

make[2]: Nothing to be done for `install-exec-am'.

make[2]: Nothing to be done for `install-data-am'.

make[2]: Nothing to be done for `install-exec-am'.

test -z "/usr/local/lib/pkgconfig" || ./install-sh -c -d "/usr/local/lib/pkgconfig"

/usr/bin/install -c -m 644 libusb-1.0.pc '/usr/local/lib/pkgconfig'

and then heimdall can't configure:

MacBook:heimdall herbert$ ./configure

checking for pkg-config... /opt/local/bin/pkg-config

checking pkg-config is at least version 0.9.0... yes

checking for DEPS... no

configure: error: Package requirements (libusb-1.0 >= 1.0.8) were not met:

No package 'libusb-1.0' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you

installed software in a non-standard prefix.

Alternatively, you may set the environment variables DEPS_CFLAGS

and DEPS_LIBS to avoid the need to call pkg-config.

See the pkg-config man page for more details.

To me, your configure-file looks for a libusb 1.0.8, which was not installed on the step before.
[Galaxy S I9000 Android Development] Dr Hotdog:
I had to work around the same problem when building heimdall from source, hlaube. The problem seems to be that the install script for libusb puts its pkgconfig file in a location (/usr/local/lib/pkgconfig/) that the heimdall configure script doesn't check when it looks for libusb.

My solution was to manually add /usr/local/lib/pkgconfig to the PKG_CONFIG_PATH environment variable after install libusb and before configuring heimdall.
[Galaxy S I9000 Android Development] hlaube:
Thanks, will test it when MotoGP is over :)

Well, could not wait.... it worked. Thanks!!!!
[Galaxy S I9000 Android Development] hlaube:
Problems on Mac 10.5.8, commandline, with booloader

Ok, got it running, flashed phone from commandline on my Mac.

Did first some flashes without bootloader, to be sure. After that I flashed last successfull Rom again.

I first flashed without booloader, which went again fine and then with bootloader. The process on the commandline came to a positiv end, the last line stated, as expected to reboot now, but since this point my phone is black. In the protocol on the screen it heimdall stated positiv, that ibl+pbl got flashed sucessfull. :mad:

I have used tis rom numerous times with Heimdall 1.1.1 and also with Odin, I have flashed it with and without bootloader already. It is a stock GB JVB-Rom.

I just ordered the pieces I need to build a jig -- :(
[Galaxy S I9000 Android Development] Benjamin Dobell:
What device are you flashing?

Also did you just flash a boot.bin by itself? If so that's what just happened to Dr Hotdog, although he(?) didn't do that intentionally.

Whenever you flash a primary bootloader it needs to go on the device with a compatible secondary bootloader (Sbl.bin) and compatible param.lfs. Mind you in the past I've flashed boot.bin or Sbl.bin by itself numerous times (I guess I've just always flashed compatible versions). I've only seen a couple of instances of this happen so I'm kinda worried it just happened twice in a row! Or at least I think that's what happened.
[Galaxy S I9000 Android Development] hlaube:
Ben, I flash an GT-I9000.

I flashed this package complete, it is GT_I9000_XXJVO_XXJVO_OXAJVO. I use this stock package, when I do a clean install for new roms. It is a complete package, I used for sure 20-30 times already, mostly I used your 1.1.1-version with the frontend. And mostly I flashed with these bootloaders.

I never flashed only a booloader, the only thing, I ever flashed for itself, are kernels. Everytime, I flash with bootloader, I have the correct dbdata, cache, factoryfs, boot and sbl-files out of one package together, also everytime a modem.

Here the content:
[Galaxy S I9000 Android Development] Benjamin Dobell:
I assume you flashed param.lfs (--param) as well?

I'm confused as to what has gone wrong. If Heimdall reported the flash went through fine then all the files that were specified definitely made it across the USB connection without problems.

Out of curiosity did you repartition at any stage? I'm trying to think of what functionality changed between 1.1.1 and 1.2.0 but there's nothing really that would effect a GT-I9000 besides where partition IDs are retrieved from.

If you go into terminal in OS X it will remember your previous commands. Would you be able to press up a few times until you get the exact set of flash commands you used (even from the previous flashes that were successful). If possible I'll try repeat the exact procedure with my Macbook and the two GT-I9000's I test with. I'll see if I can encounter anything unusual.
[Galaxy S I9000 Android Development] hlaube:
Damned, I found the mistake, I selected a wrong file for the secondary bootloader. I just typed s and "tab", and seleted the pit-file. :mad:

heimdall flash --repartition --pit s1_odin_20100512.pit --dbdata dbdata.rfs --modem modem.bin --cache cache.rfs --factoryfs factoryfs.rfs --param param.lfs --kernel zImage --primary-boot boot.bin --secondary-boot s1_odin_20100512.pit

I just hope, with the jig I can get it running again.
[Galaxy S I9000 Android Development] Benjamin Dobell:
Don't worry, that's actually great news! The custom jig will sort that out in no time. The custom jig causes the phone to boot with the backup secondary bootloader, thank you Samsung!

You had me really confused/worried there for a bit!
[Galaxy S I9000 Android Development] hlaube:
Glad to here that. I do not wanted to worry you, as stated earlier, I am convinced with of your software, thats why I promote it at other places.

Btw. have you seen in earlier posts, that there is a small bug in your source for the mac?

Regards,

Herbert
[Galaxy S I9000 Android Development] Benjamin Dobell:
Do you mean the libusb pkgconfig thing? Because I'm not sure that's actually a bug, it's just how libusb (which I don't maintain) has been setup to work with pkgconfig. Although I did forget to mention anything about it in the README so I probably should add something.
[Galaxy S I9000 Android Development] hlaube:
Yes, that thing with libusb and pkgconfig. Evtl. your script can set /usr/local/lib/pkgconfig to the PKG_CONFIG_PATH environment variable, so heimdall configures well.
[Galaxy S I9000 Android Development] Kinslayer81:
Works great with the Galaxy S II I9100

Just to confirm, successfully flashed Galaxy S II I9100 with Heimdall 1.2.0 today, a few times... works great! That's from Linux.

Such a pleasure to not have to fire up W7 in VirtualBox, I think all the last times I've done this was just for Odin. Thank you, thank you, thank you :)
[Galaxy S I9000 Android Development] AyuCon:
I tried to flash I9100 with Heimdall 1.2 on linux, but only got the "Failed to detect compatible device" error.

Any ideas?

edit: Nvm, I'm a noob. Forgot download mode :-)
[Galaxy S I9000 Android Development] Kinslayer81:
Dude! You seriously just brightened up my day now :)

Enjoy your new ROM :)
[Galaxy S I9000 Android Development] AkkerDK:
Ok, guess I'm a noob

'Cause I must have been doing something wrong.

Tried to flash a new ROM to my SGS II with Heimdall 1.2.0 (although it states to be v1.0.2b), bought with and without frontend 1.1.1 but neither time it succeded ... when the phone reboots as planned, it just stays where it starts, with "Samsung Galaxy S II GT-I9100" and the yellow triangle on the display, and nothing else happens at all :o(

The ROM is Lite'ning ROM v1.1 ... I downloaded the file "Litening_Rom_v1-1.rar, unpacked and got "Litening_Rom_v1-1.tar.md5 ... That to I unpacked and got a drawer "Litening_Rom_v1-1.tar.md5_FILES which contained 2 files; "factoryfs.img" and "zImage".

Starting up Heimdall Frontend (sudo heimdall-frontend) I put ../factory.img in FactoryFS and ../zImage in Kernel (zImage) ... nothing more.

I then connected my phone, USB-debugging checked and in download mode, with USB-cabel to my PC and started flashing ... it seems to flash as it should, and when finished my phone rebooted ... but only to where I described earlier.

I could shotdown my phone, and I started my phone in download mode again.

After connecting the phone with USB-cabel to my PC, I this time tried to flash with Heimdall command line ... The result was the following;

-------------------------------------------------------------------------------------

jan@Pythagoras ~ $ sudo heimdall flash --factoryfs /home/jan/Skrivebord/Litening_Rom_v1-1.tar.md5_FILES/factoryfs.img

Heimdall v1.0.2b, 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/

Claiming interface... Failed. Attempting to detach driver...

Claiming interface again... Success

Setting up interface... Success

Beginning session...

Handshaking with Loke... Success

Downloading device's PIT file...

PIT file download sucessful

Uploading FACTORYFS

100%

FACTORYFS upload successful

Ending session...

Rebooting device...

Re-attaching kernel driver...

-------------------------------------------------------------------------------------

My phone again rebooted, I detached it from the PC, but again my phone never came any further that earlier descried :o(

What have I done wrong?

EDIT!

Looks like I have been able to make my phone function again, using Odin to flash the .tar.md5 file
[Galaxy S I9000 Android Development] event2000:
I used a Galaxy S zimage for my Galaxy Player 4.0 Wlan (YP-G1), following some posts that it should work.

But it didnt, and i couldnt backup my player beforehand.

Is there some way to get a boot.img from samsung? Or maybe one from the YP-GB1 Player which is being sold in Korea and Russia, or do you have some other ideas?

Right now theres a heavy piece of white paper laying besides me which makes me feel pretty sad everytime i have a look at it and remember how nicely it worked before (w/o android market though, the reason i started fiddeling around with it)

Ye i was stupid, i know that...
[Galaxy S I9000 Android Development] Kinslayer81:
I had the same experience with the Lite'ning ROM, I never tried with Odin though. However, I saw plenty of accounts of similar issues even with people flashing with odin.

I eventually flashed the AngeloM's ROM, and had the same problem, as did other people. I eventually resolved it by something along the lines of wiping, flashing XWKE2, checking it worked, wiping, flashing AngeloM's ROM. From other reports and my own experience, it seems to be important to have a stock image as a base, and then wipe BEFORE flashing a custom ROM, even though some people get by without a wipe at all.

All in all, it sounds like these are more ROM issues than Heimdall issues. Ultimately, Heimdall seems to be flashing the phone great. For starters, after a wipe, all the stock ROMs work perfectly. So I think that's the problem, and therefore, we might be better off discussing these problems on relevant ROM threads.

Having said that... you said it worked after flashing in Odin... did you wipe before this? (Or did you wipe after flashing in Heimdall... which could still be considered a wipe before flashing the custom ROM)
[Galaxy S I9000 Android Development] Benjamin Dobell:
These sorts of boot up issues can usually be fixed by first booting into recovery and clearing the cache, or alternatively by flashing a new cache file.
[Galaxy S I9000 Android Development] AkkerDK:
Yes, It worked with Odin, and no, I didn't do any wipe neither before nor after anything flashing.

My big problem with using Odin is, that I only got linux on my own PC ... To use Odin, I have to (mis)use one of my kids PC, which do have windows on them :( And man, just the boot time :eek: ... I would have been done with flashing in linux, before the windows PC even has been through boot, login and all :D
[Galaxy S I9000 Android Development] AkkerDK:
Hey, I didn't think of that, I could/should have tried that first ... it still would have been faster than booting up a windows PC :D

Another thing ... I haven't been able to find any ReadMe file with instructions on how to use Heimdall ... The way I did it, as described in my first post, is that the correct way? Unpacking the .tar.md5 file and placing the files within where it is relevant in Heimdall?
[Galaxy S I9000 Android Development] ankbhdk:
I tried it too on my I9100, and although I only tried the print-pit and dump command, it ended up trashing my internal sdcard, so suddenly I got a lot more space on the phone ;o)

I think it was the print-pit command, because first time it dumped the expected info, and afterwards the phone stopped responding to requests - although still seemed in download mode. After a reboot The internal sdcard was wiped.