Hi guys! what about the development of unbrickable mod for galaxy s2? is there any methods to unbrick it? I already tried the jig but it doesn't work, i think the problem is the bootloader (broken) thank you in advance for your reply.
Lets save some bricks...
- Thread starter js22
- Start date
- Status
You will receive no help in this thread about the RIFF box. The whole point of this thread was to avoid JTAG. Wrong thread, read it. Search your device forums or find a kinda, sorta, similar thread and post it there.
Wrong thread. You can find help here: http://xdaforums.com/showthread.php?t=1372365 and here: http://xdaforums.com/showthread.php?t=1313588
I'm beginning to think this thread should be locked. it's a development discussion thread for the Hummingbird processor and we keep getting noob questions which are off-topic.
hello
I'm looking for any information about the iROM bootloader of s5pv210 (similar to s5pc110). Currently I have a a PDA based on s5pv210. Initially, it started from built-in NAND memory (with old u-boot on it). However, I found all six OM signals and now I can switch the boot mode. My first task - to make the processor start from SD-card. However, I have not yet succeeded in doing so. I figured out the format of card and where should BL1 lie. Now I have two questions:
1) how to determine whether the secure boot mode used and whether or not my binary to be signed? As i understand, some CPU have zeroed eFUSE, so it can run unsigned binary. I have some signed binaries (from similar devices and demo-boards) that should only start unsigned binary. But i have no success with them.
2) What is the format of 16-byte header. As long as I understood the first 4 bytes is the size of the image, then 4 bytes of unknown purpose, then the 4-byte checksum (the byte sum of all binary), then another 4 bytes of unknown function. Maybe someone has more information?
Thank you and apologize for my english.
P.S. may be someone have tried to disassemble iROM binary to determine its logic?
I'm looking for any information about the iROM bootloader of s5pv210 (similar to s5pc110). Currently I have a a PDA based on s5pv210. Initially, it started from built-in NAND memory (with old u-boot on it). However, I found all six OM signals and now I can switch the boot mode. My first task - to make the processor start from SD-card. However, I have not yet succeeded in doing so. I figured out the format of card and where should BL1 lie. Now I have two questions:
1) how to determine whether the secure boot mode used and whether or not my binary to be signed? As i understand, some CPU have zeroed eFUSE, so it can run unsigned binary. I have some signed binaries (from similar devices and demo-boards) that should only start unsigned binary. But i have no success with them.
2) What is the format of 16-byte header. As long as I understood the first 4 bytes is the size of the image, then 4 bytes of unknown purpose, then the 4-byte checksum (the byte sum of all binary), then another 4 bytes of unknown function. Maybe someone has more information?
Thank you and apologize for my english.
P.S. may be someone have tried to disassemble iROM binary to determine its logic?
Last edited:
jerdog
Admin Emeritus - Purveyor of word nuggets
- Status
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
19I've been reading up on SGS hardware and bootloaders, and I feel like there's a very good chance that there's a way (within reach? ??) to to fix a totally bricked phone.
NOTE: I'm no expert on this stuff. If I'm missing something totally stupid, please forgive me. Anyways, here goes...
The user manual for the s5pc110 chip describes the booting process; it has 3 levels. On hw reset the cpu begins executing code that lives in ROM. The ROM code loads the primary bootloader from a source selected by external pin inputs. The PBL pretty much just loads the SBL, which does the major setup and loads the kernel.
The important thing, which I haven't seen anyone discuss, is that the initial ROM code includes the ability (poorly documented, of course) to load the PBL from UART or USB.
Repeat : non-eraseable code in our phones which is executed on hw reset can load a bootloader over serial or USB into memory and then execute it.
From other threads, we know that Samsung is able to restore a bricked phone without opening it up. Why should they have all the fun?
The first step is asserting the proper pins. This is done by connecting the proper resistance betw pins 4 & 5. The 'jig' thread describes using 301k to get into download mode, but this is happening in the SBL. Many other R values are desribed in the 'fun with resistors' thread and in the fsaXXXX-i2c.c kernel source. One of them does a reboot and connects a (3.3V) UART to the D+/D- pins.
One thing that is described in the docs is that the ROM code tries UART first and then fails over to USB. Since UART is so much simpler, I'd say that's where to begin.
We already learned in that thread that connecting at 115200 baud and banging on RETURN brings up a "SBL>" prompt with lots of cool commands available. But as TheBeano pointed out, that's not much use if the SBL is toast.
What I'm wondering is whether there's a way to interrupt the normal boot while its still running ROM code. There's no reason the ROM would set up the UART at the same baud rate as the SBL and kernel. Maybe just a lower baud and banging on RETURN is enough.
For anybody with the time and the hardware, that should be easy enough to try. TheBeano?
There's probably some handshake/protocol issues to figure out to get a bootloader loaded and executing, but we do have a known good one (the PBL) to play with.
If that can be made to work, it would be a huge step towards a working solution. There is code floating around (I saw it on the teamhacksung git) that ports u-boot bootloader to our phones. AFAIK, nobody around here has tried it. But if we are able to test bootloaders w/o flasing, then maybe we (someone with a clue about bootloaders,that is) can open the door to safe, open-source booting.
So that's it. Is this crazy-talk, or do you guys n gals think it just ... might ... work?5I am actually very surprised that no one has replied to this, it is actually a very good idea and also very possible
I will add a little insight without giving too much away
Its also possible to start the phone via JTAG and pass the control over to USB or UART, even to enter DLM and flash the phone without repairing the current IBL/PBL/SBL within the phone which are damaged, e.g. the loaders are running in RAM this is done via CMM or JNAND ...
I have the full unstripped source code for the PBL and SBL and may consider releasing them if some input starts in this thread, its all too easy just to give them out without the scene thinking on its feet
Oh BTW: My dog spoke to another dog who's owner works for Samsung and he told him that the 2.3.3 release, will be released when its f**king ready and not 1 day before.4WE HAVE HELLO WORLD
Rebellos! You are the man!
Ok, steps to reproduce:
1. Perform UnBrickable mod from the first post in this thread. http://xdaforums.com/showthread.php?t=1206216
2. With the phone off, Insert battery into phone. Press power on button for 1 second. Observe message on internal UART:
Code:Insert an OTG cable into the connector! ������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������ Uart negotiation Error
3. Insert the OTG Cable (standard USB cable plugged into USB port on phone-- OTG port) and obvserve message on internal UART port:
Code:������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������ Uart negotiation Error
4. on a Linux system run the "dltool" and use this firmware http://xdaforums.com/attachment.php?attachmentid=698077&d=1314105521 from Rebellos
Code:adam@Adam-Desktop:~/Desktop/dltool$ sudo ./smdk-usbdl -f ./s5pc110_test/s5pc110_testcode.bin -a D0020000 SMDK42XX,S3C64XX USB Download Tool Version 0.20 (c) 2004,2005,2006 Ben Dooks <ben-linux@fluff.org> S3C64XX Detected! => found device: bus 001, dev 050 => loaded 16384 bytes from ./s5pc110_test/s5pc110_testcode.bin => Downloading 16394 bytes to 0xd0020000 => Data checksum af84 => usb_bulk_write() returned 16394 adam@Adam-Desktop:~/Desktop/dltool$
5. Observe Internal UART message:
which repeats every 20 seconds.Code:Hey you! Out there on the road, Always doing what you are told, Can you help me?
GREAT WORK!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!3TheBeano what service manual will help you? full one?
http://www.filesonic.com/file/305248751/Samsung_GT-i9000_Galaxy_S_service_manual.rar full one.
http://megaupload.com/?d=C0JHS7A8 - service training manual 01/20112^^ Thanks.... So what do we have when the primary bootloader is destroyed?
Here is a general purpose video describing what we have so far.
New posts
-
-
[Hisense a9] Root - Reward Offered (Snapdragon 662)- Latest: idonotbelonghere
