[Heimdall] Repartitioning Problem. C++ Developers required. Offering UnBrickable Mod. - Captivate Android Development

I'm here to recruit help from XDA-Developers for open-source development. I can offer UnBrickable Mod to any Developer who thinks they can help with this C++ issue. This will allow you to play with Loki (the device's side of Odin/Heimdall) and not worry about it.
The only thing keeping the Linux and Mac platforms from being better then Windows at developing ROMs and other firmware is Heimdall's ability to repartition. Once this barrier is broken down, we will have an entire open source chain for developing and Linux will be the premeire platform for developing on Samsung devices. There will be no reason to use Closed Source Windows, Odin, or Samsung Drivers... This is the last barrier.
I am offering debug logs which show the UART output during the flashing of Heimdall and Odin.
here are Heimdall logs/uart logs: http://pastebin.com/srhG7yJA
here are Odin Uart Logs: http://pastebin.com/AiKspmxR UART coming soon.
Here are both Heimdall and Odin USB logs via Wireshark.
http://www.mediafire.com/file/2wccdcuf87q2i3l/odinheimdallUSBLog.zip
Benjamin Dobell has set up code for Heimdall here: https://github.com/Benjamin-Dobell/Heimdall/
This is not a bounty thread. It is an open source development/improvement thread. I have spoken to Benjamin Dobell, the creator of Heimdall, and he is too busy with a new job and working loads of overtime hours. He has approved of this action. Fixing this issue with Heimdall will allow the entire Samsung community to utilize Heimdall as a total replacement for Odin on all platforms.
What's my role/interest in this? I want Linux to be as good or better then Windows.. I'm an Open Source guy. I'm also not good at C++ programming language. I understand the headers, but not the CPP files. I can provide debugging and beta testing though. I've created the cross-platform Heimdall One-Click . I brought UnBrickable Mod to the Captivate and the only thing left in the entire open-source chain of software from complete destruction of data on the device to completely stock is getting Heimdall to repartition.
Once this final hurdle in Heimdall is completed, we've got a full open-source stack of cross-platform, community-based software by XDA-Developers for XDA-Developers and users. Open-Source software will be able to provide more then closed source software, and once again XDA-Developers will prove that we can do things better then the Manufacturers.

There is an issue tracking system here: https://github.com/Benjamin-Dobell/Heimdall/issues
I believe the underlying cause of all 3 of the existing issues in the Heimdall Repostiory lies with Heimdall's ability to repartition.
issue 21: "Failed to confirm end of file transfer sequence!" signifies that the information sent overran the partition area and therefore it never responded that the end was confirmed.
Issue 19: "Could not find end of file or end of file transfer, something similar." Likely the same as issue 21.
Issue 14: "Expected file part index" again, dealing with partition tables. "ERROR: Expected file part index: 0 Received: 1"
I believe all three of these issues could be worked into a single "Heimdall Repartitioning" issue for the reasons stated above.

I got some experience in C++ and Java...
once I get home ill take a look at the heimdall source, and give it a shot.

Smasher816 said:
I got some experience in C++ and Java...
once I get home ill take a look at the heimdall source, and give it a shot.
Click to expand...
Click to collapse
Hey great.. I have a special test setup with UART output.
First I totally thrashed my partition table by uploading the Bada OS SBL.. This SBL rewites partition tables. Then I used the HIBL to unbrick my phone and load a proper SBL. This is the UART during booting up to "Download Mode".
Code:
-------------------------------------------------------------
Hummingbird Interceptor Boot Loader (HIBL) v1.0
Copyright (C) Rebellos 2011
-------------------------------------------------------------
Calling IBL Stage2 ...OK
Testing DRAM1 ...OK
iRAM reinit ...OK
cleaning OTG context ...OK
Chain of Trust has been successfully compromised.
Begin unsecure download now...
0x00000000BL3 EP: 0x40244000
Download complete, hold download mode key combination.
Starting BL3 in...
Set cpu clk. from 400MHz to 800MHz.
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Modified by Rebell
Build On: Jun 8 2011 21:44:47
-----------------------------------------------------------
Re_partition: magic code(0xffffffff)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x50
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 7
partitions loading success
board partition information update.. source: 0x0
.Done.
read 1 units.
==== PARTITION INFORMATION ====
ID : *unknown id* (0x9)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : *unknown id* (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 7
===============================
ID : *unknown id* (0x1)
ATTR : RW SLC (0x1001)
FIRST_UNIT : 8
NO_UNITS : 796
===============================
ID : *unknown id* (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 804
NO_UNITS : 716
===============================
ID : *unknown id* (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1520
NO_UNITS : 372
===============================
ID : *unknown id* (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1892
NO_UNITS : 56
===============================
ID : *unknown id* (0x18)
ATTR : RW SLC (0x1001)
FIRST_UNIT : 1948
NO_UNITS : 56
===============================
FlashDevOpen 232: Error(nErr=0x80000002)
j4fs_open 136: Error(nErr=0x40000000)
loke_init: j4fs_open failed..
init_fuel_gauge: vcell = 4051mV, soc = 82
check_quick_start_condition_with_charger- Voltage: 4051.25000, Linearized[55/70/85], Capacity: 85
init_fuel_gauge: vcell = 4051mV, soc = 82, rcomp = d01f
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xffffffff,0x80040001)
nps status file does not exist..
nps status is incorrect!! set default status.(completed)
nps status=0x504d4f43
PMIC_IRQ1 = 0x3c
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x0
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0x40
PMIC_STATUS2 = 0x2c
get_debug_level current debug level is 0x0.
get_debug_level current debug level is 0x0.
get_debug_level current debug level is 0x0.
aries_process_platform: Debug Level Invalid
keypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xffffffff,0x80040001)
nps status file does not exist..
nps status is incorrect!! set default status.(completed)
nps status=0x504d4f43
==> Welcome to ARIES!
==> Entering usb download mode..
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
Error : Current Mode is Host
EP2: 0, 2, 0; len=7
EP2: 0, 2, 0; len=7
sug: IN EP asserted
I gave the command in Heimdall to repartition and flash the boot.bin to partition 1.
Code:
heimdall flash --repartition --pit ./part.pit --1 ./boot.bin
At this point it should have downloaded the partition, saved it, and then heimdall should request the partition back and use that as its guide.
The boot.bin is only 1 block long so this log is short.
Code:
- Odin is connected!
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xffffffff,0x80040001)
j4fs_write_file_bootloader 192: Error(nErr=0x40000000)
process_packet: request id(100), data id(0)
process_rqt_init: platform number(0x0), revision(0x0)
process_packet: request id(100), data id(1)
process_packet: request id(100), data id(2)
process_packet: request id(103), data id(0)
process_rqt_close: xmit completed!
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xffffffff,0x80040001)
j4fs_write_file_bootloader 192: Error(nErr=0x40000000)
process_packet: request id(103), data id(1)
process_rqt_close: target reset!
ARIES MAGIC_ADDR=0x0 / INFORM5=0x12345678
and this is the log from Heimdall
Code:
Initialising connection...
Detecting device...
Claiming interface...
Attempt failed. Detaching driver...
Claiming interface again...
Setting up interface...
Beginning session...
Handshaking with Loke...
Ending session...
Rebooting device...
Re-attaching kernel driver...
At this point the device "resets" and attempts to boot from the bootloader.
If you need any testing let me know. I can compile source, I can get UART logs. I can repartition the heck out of this device as it is UnBrickable and my test phone.

I believe the device uses the SBL> prompt when it is in download mode.. You can see from this UART log that the device attempted to "saveenv" but it could not. http://code.google.com/p/badadroid/...ompare_logs/SBL_mode_help.txt?spec=svn61&r=57
It also returned the same "FlashDevRead 63 error)
The final action the device needs to do is "savepart" if the partition tables were saved after the pit were uploaded then it would be good to go. There are several other commands as well.. "addpart" and "removepart".. If it comes to using this, let me know. I've worked with Benjamin Dobell's libpit before and I can help out greatly with repartitioning as I've worked extensively in the SBL prompt.
I'm not sure how the Download Mode works exactly, but if it uses the SBL prompt, then I can write pseudocode of how it should work.

This probably isn't going to help much, but it may be a start.
I figured the best way to solve this would be to find the differences between a successful Odin flash and an unsuccessful Heimdall flash. So I delved right in to the wireshark dumps. It seems likely that Heimdall is missing a step.
I do not understand the protocol (yet), but I can see the raw data in the stream. In the Heimdall process, there is some protocol traffic, then the entire PIT file is sent, then some more protocol traffic, then the kernel data is sent. But in the Odin process, there is some protocol traffic, then the entire PIT file is sent, then some more protocol traffic, then the PIT file is sent again in 512 byte chunks, then some protocol traffic (more than usual), and then the kernel data is sent.
At the moment, I can't be sure if this is functionally equivalent or not. I'll need to do quite a bit of deciphering on the protocol to get up to speed on what's really going on. Unfortunately, this is the sort of thing that's easiest if one can watch the action in real time, but as I only have my one phone that I need for work, that's not really an option for me at this time.
Hopefully, I'll return with more info after I've absorbed the communication layer details to see what the non-data chatter actually is.

Could that extra protocol data possibly be Odin commanding delete partitions and add partitions? I'm hypothesizing... nothing more. I see some similarities to the UART logs during SBL> prompt and Odin, so I'm thinking that maybe the SBL prompt is used, or at least some of the methods... In this thread you can see all of the SBL commands http://forum.xda-developers.com/showthread.php?t=1209288
Sure it's from an Infuse, but they're all based on i9000 which is like the mother of our entire generation of devices. The SBLs are interchangeable with different entry points for each "version".

AdamOutler said:
Could that extra protocol data possibly be Odin commanding delete partitions and add partitions? I'm hypothesizing... nothing more. I see some similarities to the UART logs during SBL> prompt and Odin, so I'm thinking that maybe the SBL prompt is used, or at least some of the methods... In this thread you can see all of the SBL commands http://forum.xda-developers.com/showthread.php?t=1209288
Sure it's from an Infuse, but they're all based on i9000 which is like the mother of our entire generation of devices. The SBLs are interchangeable with different entry points for each "version".
Click to expand...
Click to collapse
I have a feeling that it is using the SBL prompt somehow after the flash because everything else seems pretty much identical (besides the timing). If anyone needs to understand the protocol then I recommend just looking at Heimdall's source code, in particular the packet header files store all the constants that are sent and received over USB.

Found the problem - the End Transfer packet is missing. There is also some additional strangeness, though.
Heimdall:
Packet 1: 65 00 00 00 (Init pit transfer)
Packet 2: 65 00 00 00 02 00 00 00 D0 06 00 00 (Want to send 1744 bytes)
Packet 3: [full contents of pit]
Packet 4: 66 00 00 00 (Init file transfer - probably starting the kernel send)​
Odin:
Packet 1: 65 00 00 00 (Init pit transfer)
Packet 2: 65 00 00 00 02 00 00 00 D0 06 00 00 (Want to send 1744 bytes)
Packet 3: [full contents of pit]
Packet 4: 65 00 00 00 03 00 00 00 D0 06 00 00 (Finished sending 1744 bytes)​
The odd part is what odin does next, after the "finished sending":
Packet 5: 65 00 00 00 01 00 00 00 (Dump pit file)
Packet 6: 65 00 00 00 02 00 00 00 00 00 00 00 (Sending chunk 0)
Packet 7: [first 512 bytes of pit]
Packet 8: 65 00 00 00 02 00 00 00 01 00 00 00 (Sending chunk 1)
Packet 9: [next 512 bytes of pit]
Packet 10: 65 00 00 00 02 00 00 00 02 00 00 00 (Sending chunk 2)
Packet 11: [next 512 bytes of pit]
Packet 12: 65 00 00 00 02 00 00 00 03 00 00 00 (Sending chunk 3)
Packet 13: [next 512 bytes of pit]
- repeat for 8 chunks - data past the end of the actual pit file is sent as zeroes -
Packet 22: 65 00 00 00 03 00 00 00 (Done)
Packet 23: 66 00 00 00 (Init file transfer - probably kernel)​
I couldn't begin to tell you why any of this exists at all, but my strong suspicion is that duplicating the Odin behavior will make Heimdall work properly.

So, Adam, the first thing I would try would be to simply add the "finished sending" packet. Try recompiling with this replacement for BridgeManager.cpp and this additional file EndPitFilePacket.h in the project.

psych0phobia said:
So, Adam, the first thing I would try would be to simply add the "finished sending" packet. Try recompiling with this replacement for BridgeManager.cpp and this additional file EndPitFilePacket.h in the project.
Click to expand...
Click to collapse
That did it! Problem solved!
1.I uploaded the Bada bootloaders to my device in order to totally destroy my partition tables.
2.I tried to flash with heimdall 1.3 and it did not work to restore
3.I compiled and installed the new 1.3modified version
4.I flashed with heimdall 1.3modified and it worked
to be sure I repeated the Bada bootloaders once again. The only thing wrong with my device now is that it has no /efs/ partition... which is understandable because bada turned the OneNAND into it's *****.
Great job psych0phobia If you need anything from me just let me know. I mean anything ...
Let me know when you can spare your device so I can modify it. Please push this change upstream.

Here's the UART log
Code:
[���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
Uart negotiation Error
-------------------------------------------------------------
Hummingbird Interceptor Boot Loader (HIBL) v1.0
Copyright (C) Rebellos 2011
-------------------------------------------------------------
Calling IBL Stage2 ...OK
Testing DRAM1 ...OK
iRAM reinit ...OK
cleaning OTG context ...OK
Chain of Trust has been successfully compromised.
Begin unsecure download now...
0x00000000BL3 EP: 0x40244000
Download complete, hold download mode key combination.
Starting BL3 in...
Set cpu clk. from 400MHz to 800MHz.
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Modified by Rebell
Build On: Jun 8 2011 21:44:47
-----------------------------------------------------------
Re_partition: magic code(0x0)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x50
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
partitions loading success
board partition information update.. source: 0x0
.Done.
read 1 units.
==== PARTITION INFORMATION ====
ID : IBL+PBL (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : PIT (0x1)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 1
===============================
ID : EFS (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 2
NO_UNITS : 40
===============================
ID : SBL (0x3)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 42
NO_UNITS : 5
===============================
ID : SBL2 (0x4)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 47
NO_UNITS : 5
===============================
ID : PARAM (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 52
NO_UNITS : 20
===============================
ID : KERNEL (0x6)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 72
NO_UNITS : 30
===============================
ID : RECOVERY (0x7)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 102
NO_UNITS : 30
===============================
ID : FACTORYFS (0x16)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 132
NO_UNITS : 1146
===============================
ID : DBDATAFS (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1278
NO_UNITS : 536
===============================
ID : CACHE (0x18)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1814
NO_UNITS : 140
===============================
ID : MODEM (0xb)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1954
NO_UNITS : 50
===============================
loke_init: j4fs_open success..
load_lfs_parameters valid magic code and version.
reading nps status file is successfully!.
nps status=0x504d4f43
load_debug_level reading debug level from file successfully(0x574f4c44).
init_fuel_gauge: vcell = 4192mV, soc = 90
check_quick_start_condition_with_charger- Voltage: 4192.50000, Linearized[77/92/100], Capacity: 94
init_fuel_gauge: vcell = 4192mV, soc = 90, rcomp = d01f
reading nps status file is successfully!.
nps status=0x504d4f43
PMIC_IRQ1 = 0x28
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x0
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0x40
PMIC_STATUS2 = 0x2c
get_debug_level current debug level is 0x574f4c44.
aries_process_platform: Debug Level Low
keypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
reading nps status file is successfully!.
nps status=0x504d4f43
==> Welcome to ARIES!
==> Entering usb download mode..
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
Error : Current Mode is Host
EP2: 0, 2, 0; len=7
EP2: 0, 2, 0; len=7
sug: IN EP asserted
- Odin is connected!
set_nps_update_start: set nps start flag successfully.
process_packet: request id(100), data id(0)
process_rqt_init: platform number(0x0), revision(0x0)
process_packet: request id(100), data id(1)
process_packet: request id(100), data id(2)
process_packet: request id(101), data id(0)
process_packet: request id(101), data id(2)
process_packet: request id(101), data id(3)
[FNW: ] STL read to partition ID: 20
Done.
read 25 units.
partition_backup: efs. meta data=3(units), real size=6553600
.....Done.
read 5 units.
partition_backup: sbl. buf=0x46e00000, size=1310720(bytes)
.....Done.
read 5 units.
partition_backup: sbl2. buf=0x46f40000, size=1310720(bytes)
fsr_bml_format_device start
set_dynamic_partition: pit magic code=0x12349876
bbm format success
bbm_erase_all: step 1. Start unit=1, End unit=2.
.
bbm_erase_all: step 1. Start unit=52, End unit=2004.
..............................................................................................................................................................................................................................................
bbm eraseall success.
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
partitions loading success
Erasing: 1 to 2
.
bbm erase part success
.Done.
Written 1 units.
current percent: 0 (1/1110)
board partition information update.. source: 0x403ee838
Erasing: 2 to 42
........................................
bbm erase part success
[FNW: ] STL formatted (partition ID: 20)
[FNW:INF] nVol : 0, partition_id : 20, stSTLInfo.nTotalLogScts : 12800, buf :0x46400000
TotalLogSct : 12800, size : 6553600
Done.
Written 25 units.
current percent: 2 (26/1110)
Erasing: 42 to 47
.....
bbm erase part success
.....Done.
Written 5 units.
current percent: 2 (31/1110)
Erasing: 47 to 52
.....
bbm erase part success
.....Done.
Written 5 units.
current percent: 3 (36/1110)
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(5445016), id(6), final(1)
Save Image (KERNEL) to flash ......
Erasing: 72 to 102
..............................
bbm erase part success
.....................Done.
Written 21 units.
current percent: 5 (57/1110)
current write_count=1
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(12582912), efs_clear(0), boot_update(0), final(1)
xmit_complete_phone: cp partition found!(11)
Save Image (MODEM) to flash ......
Erasing: 1954 to 2004
..................................................
bbm erase part success
................................................Done.
Written 48 units.
current percent: 9 (105/1110)
current write_count=1
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(104857600), id(22), final(0)
Save Image (FACTORYFS) to flash ......
Erasing: 132 to 1278
..............................................................................................................................................................................................................................................
bbm erase part success
[FNW: ] STL formatted (partition ID: 22)
[FNW:INF] nVol : 0, partition_id : 22, stSTLInfo.nTotalLogScts : 569344, buf :0x46400000
TotalLogSct : 204800, size : 104857600
Done.
Written 394 units.
current percent: 45 (505/1110)
current write_count=1
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(104857600), id(22), final(0)
Save Image (FACTORYFS) to flash ......
[FNW:INF] nVol : 0, partition_id : 22, stSTLInfo.nTotalLogScts : 569344, buf :0x46400000
TotalLogSct : 204800, size : 104857600
Done.
Written 394 units.
current percent: 81 (905/1110)
current write_count=2
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(58163200), id(22), final(1)
Save Image (FACTORYFS) to flash ......
[FNW:INF] nVol : 0, partition_id : 22, stSTLInfo.nTotalLogScts : 569344, buf :0x46400000
TotalLogSct : 113600, size : 58163200
Done.
Written 219 units.
current percent: 101 (1127/1110)
current write_count=3
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(1376256), id(23), final(1)
Save Image (DBDATAFS) to flash ......
Erasing: 1278 to 1814
..............................................................................................................................................................................................................................................
bbm erase part success
[FNW: ] STL formatted (partition ID: 23)
[FNW:INF] nVol : 0, partition_id : 23, stSTLInfo.nTotalLogScts : 263168, buf :0x46400000
TotalLogSct : 2688, size : 1376256
Done.
Written 6 units.
current percent: 102 (1133/1110)
current write_count=1
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(1245184), id(24), final(1)
Save Image (CACHE) to flash ......
Erasing: 1814 to 1954
............................................................................................................................................
bbm erase part success
[FNW: ] STL formatted (partition ID: 24)
[FNW:INF] nVol : 0, partition_id : 24, stSTLInfo.nTotalLogScts : 64000, buf :0x46400000
TotalLogSct : 2432, size : 1245184
Done.
Written 5 units.
current percent: 102 (1138/1110)
current write_count=1
save param.blk, size: 5268
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xfffff,0x80040001)
j4fs_write_file_bootloader 192: Error(nErr=0x40000000)
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(262144), id(0), final(1)
Save Image (IBL+PBL) to flash ......
binary version: EVT1.
boot.bin is the one-binary.
relocate & fusing continue..
completed.
Erasing: 0 to 1
.
bbm erase part success
.Done.
Written 1 units.
current percent: 102 (1139/1110)
current write_count=1
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(1310720), id(3), final(1)
Save Image (SBL) to flash ......
=== SBL signature information ===
File Size : 677052
=================================
read part info
id = 0x3
attr = 0x1002
first unin = 0x2a
number units = 0x5
pages per unit = 0x40
n1st page = 0xa80, page offset = 0x13f, len = 0x48
read part info
id = 0x4
attr = 0x1002
first unin = 0x2f
number units = 0x5
pages per unit = 0x40
n1st page = 0xbc0, page offset = 0x13f, len = 0x48
Found bootable SBL ID: 4
save SBL partition id: 3
Erasing: 42 to 47
.....
bbm erase part success
.....Done.
Written 5 units.
current percent: 103 (1144/1110)
current write_count=1
save sbl id: 3 / erase sbl id: 4
.
process_packet: request id(102), data id(0)
process_packet: request id(102), data id(2)
process_packet: request id(102), data id(3)
process_rqt_xmit: size(872448), id(21), final(1)
Save Image (PARAM) to flash ......
FlashDevClose 262: Error(nErr=0x80040001)
Erasing: 52 to 72
....................
bbm erase part success
[FNW: ] STL formatted (partition ID: 21)
[FNW:INF] nVol : 0, partition_id : 21, stSTLInfo.nTotalLogScts : 2560, buf :0x46400000
TotalLogSct : 1704, size : 872448
Done.
Written 4 units.
current percent: 103 (1148/1110)
current write_count=1
set_nps_update_start: set nps start flag successfully.
process_packet: request id(103), data id(0)
process_rqt_close: xmit completed!
set_nps_update_completed: set nps completed flag successfully.
process_packet: request id(103), data id(1)
process_rqt_close: target reset!
ARIES MAGIC_ADDR=0x0 / INFORM5=0x12345678
1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------
+n1stVPN 2688
+nPgsPerBlk 64
PBL found bootable SBL: Partition(3).
Set cpu clk. from 400MHz to 800MHz.
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
Board Name: ARIES REV 03
Build On: Jun 8 2011 21:44:47
-----------------------------------------------------------
Re_partition: magic code(0x0)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x50
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
......... everything after this is standard data... just included this far to show it booted.
Everything worked..
Would you like WireShark to verify things?
As far as logging, the only thing I could see is this:
Code:
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0xfffff,0x80040001)
j4fs_write_file_bootloader 192: Error(nErr=0x40000000)
which means it tried to read some garbage from the OneNAND and failed.

AdamOutler said:
That did it! Problem solved!
1.I uploaded the Bada bootloaders to my device in order to totally destroy my partition tables.
2.I tried to flash with heimdall 1.3 and it did not work to restore
3.I compiled and installed the new 1.3modified version
4.I flashed with heimdall 1.3modified and it worked
to be sure I repeated the Bada bootloaders once again. The only thing wrong with my device now is that it has no /efs/ partition... which is understandable because bada turned the OneNAND into it's *****.
Great job psych0phobia If you need anything from me just let me know. I mean anything ...
Let me know when you can spare your device so I can modify it. Please push this change upstream.
Click to expand...
Click to collapse
Yay for a properly working Heimdall! Once this fix gets officially implemented I'll update my Heimdall =D
How much do you charge to make the Captivate Unbrickable? X3

I have a darn huge iq... Classified as genius level... Yet, try as I might, cannot make head or tail of Adams post...
Sent from my cell phone. DUH.

psycho2097 said:
I have a darn huge iq... Classified as genius level... Yet, try as I might, cannot make head or tail of Adams post...
Sent from my cell phone. DUH.
Click to expand...
Click to collapse
Don't give me credit... this is the real genius here...
psych0phobia said:
So, Adam, the first thing I would try would be to simply add the "finished sending" packet. Try recompiling with this replacement for BridgeManager.cpp and this additional file EndPitFilePacket.h in the project.
Click to expand...
Click to collapse
Basically, heimdall could not repartition the OneNAND. I identifed the problem, provided detailed debug level information and asked for help. psych0phobia looked at the Odin/Loki protocol, learned it, found the differences between Odin and Heimdall based on the output of both programs and then wrote the fix. Make sure you thank him. Thank Benjamin Dobell as well, he wrote Heimdall in the first place.
now... if you want to compile it under Linux... open a terminal and copy-pasta.
Code:
sudo apt-get install build-essential curl git
mkdir heimdall
cd heimdall
git clone https://github.com/Benjamin-Dobell/Heimdall.git
cd Heimdall/heimdall
curl http://android.merseine.us/BridgeManager.cpp> ./BridgeManger.cpp
curl http://android.merseine.us/EndPitFilePacket.h >./EndPitFilePacket.h
cd ..
cd ..
cd libpit
./configure
make
cd ..
cd heimdall
./configure
make
sudo make install
This will give Heimdall the ability to fully recover a bad partition table.
NOTE: This should only be used until a version greater then Heimdall 1.3.0 is released.

Yea, kinda got that part.... So my understanding would be now we can successfully flash nexus s. Firmware without screwing everything up... Right? In layman-geek's terms, not super-duper-mega-geek terms....
Sent from my cell phone. DUH.

psycho2097 said:
Yea, kinda got that part.... So my understanding would be now we can successfully flash nexus s. Firmware without screwing everything up... Right? In layman-geek's terms, not super-duper-mega-geek terms....
Sent from my cell phone. DUH.
Click to expand...
Click to collapse
I wont say anything about nexus s just yet... We have a 100% open-source, DIY, and free method of restoring a device to stock. Linux, UnBrickable Mod and heimdall.

In other words....
In yo face jtag

whiteguypl said:
In other words....
In yo face jtag
Click to expand...
Click to collapse
Hell yeah! 3 cheers 4 the unbrickable mod!
Sent from my cell phone. DUH.

Just thought I should let you guys know that I've pushed the source for the 1.3.1 updates to Github and it includes a fix, thanks psych0phobia! 1.3.1 also includes substantially improved no-reboot functionality that allows Heimdall to detect and use an existing session (i.e. previous operation with the --no-reboot parameter). Basically this means that you can do things like dump your PIT and then flash your phone without rebooting in between.
I should note that I kind of forgot to update the make files So it won't actually build on Linux/OS X until I do that when I get home (at work now). Windows users can give it whirl though.

Related

UART Output / Bootloader Hacking / Kernel Debuging

Hey guys, I set up my Arduino Mega to communicate via UART with my Infuse4g.
The UART output comes out of the USB port at 115200kbps on the D+ and D- lines when you connect a 619kOhm resistor to USB Pins 4 and 5. It can be used for kernel debugging or general hacking around.
Here's some pics of my setup.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This emulates the "Test Board" from the KIT-S5PC110 which is used to develop the Aeries platform
You can make it do all kinds of crazy stuff....
Typical boot with battery just inserted.
Code:
1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------
+n1stVPN 2688
+nPgsPerBlk 64
PBL found bootable SBL: Partition(3).
MAX8893_REG_ONOFF return val 1
MAX8893_REG_DISCHARGE return val ff
MAX8893_REG_LSTIME return val 8
MAX8893_REG_DVSRAMP return val 9
MAX8893_REG_BUCK return val 4
MAX8893_REG_LDO1 return val e
MAX8893_REG_LDO1 new val e
MAX8893_REG_LDO2 return val 10
MAX8893_REG_LDO2 new val 10
MAX8893_REG_ONOFF return val 1
MAX8893_REG_ONOFF new val 21
MAX8893_REG_ONOFF return val 21
MAX8893_REG_ONOFF new val 31
Set cpu clk. from 400MHz to 800MHz.
OM=0x9, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
Board Name: ARIES REV 03
Build On: May 19 2011 22:17:14
-----------------------------------------------------------
Re_partition: magic code(0x0)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x50
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
partitions loading success
board partition information update.. source: 0x0
Now Read Images - ID : 1
.Done.
read 1 units.
==== PARTITION INFORMATION ====
ID : IBL+PBL (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : PIT (0x1)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 1
===============================
ID : EFS (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 2
NO_UNITS : 40
===============================
ID : SBL (0x3)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 42
NO_UNITS : 5
===============================
ID : SBL2 (0x4)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 47
NO_UNITS : 5
===============================
ID : PARAM (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 52
NO_UNITS : 20
===============================
ID : KERNEL (0x6)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 72
NO_UNITS : 30
===============================
ID : RECOVERY (0x7)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 102
NO_UNITS : 30
===============================
ID : FACTORYFS (0x16)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 132
NO_UNITS : 1146
===============================
ID : DBDATAFS (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1278
NO_UNITS : 536
===============================
ID : CACHE (0x18)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1814
NO_UNITS : 130
===============================
ID : MODEM (0xb)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1944
NO_UNITS : 60
===============================
loke_init: j4fs_open success..
load_lfs_parameters valid magic code and version.
reading nps status file is successfully!.
nps status=0x504d4f43
load_debug_level reading debug level from file successfully(0x574f4c44).
init_fuel_gauge: vcell = 3797mV, soc = 57
check_quick_start_condition- Voltage: 3797.50000, Linearized[45/60/75], Capacity: 59
init_fuel_gauge: vcell = 3797mV, soc = 57, rcomp = d01f
reading nps status file is successfully!.
nps status=0x504d4f43
PMIC_IRQ1 = 0x20
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x0
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0x40
PMIC_STATUS2 = 0x0
get_debug_level current debug level is 0x574f4c44.
aries_process_platform: Debug Level Low
keypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
check_download: micorusb_status1 = 400, key_value = 0
aries_process_platform: final s1 booting mode = 0
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
lcd_power_on_ld9040
s6e63m0_c110_spi_read_byte-------------------------: 86
DA lcd ID1 = 86
s6e63m0_c110_spi_read_byte-------------------------: 48
DB lcd ID2 = 48
s6e63m0_c110_spi_read_byte-------------------------: 44
DC lcd ID3 = 44
LCD_ID == 3
Autoboot (0 seconds) in progress, press any key to stop
get_debug_level current debug level is 0x574f4c44.
get_debug_level current debug level is 0x574f4c44.
boot_kernel: Debug Level Low
FOTA Check Bit
Read BML page=, NumPgs=
FOTA Check Bit (0xffffffff)
Load Partion idx = (6)
..............................done
Kernel read success from kernel partition no.6, idx.6.
setting param.serialnr=hex value hex value
setting param.board_rev=0x30
setting param.cmdline=console=ttySAC2,115200 loglevel=4
Starting kernel at 0x32000000...
0xF8
AST_POWERON
BOOTING COMPLETED
held enter while booting UART
Code:
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------
+n1stVPN 2688
+nPgsPerBlk 64
PBL found bootable SBL: Partition(3).
MAX8893_REG_ONOFF return val 1
MAX8893_REG_DISCHARGE return val ff
MAX8893_REG_LSTIME return val 8
MAX8893_REG_DVSRAMP return val 9
MAX8893_REG_BUCK return val 2
MAX8893_REG_LDO1 return val 2
MAX8893_REG_LDO1 new val e
MAX8893_REG_LDO2 return val e
MAX8893_REG_LDO2 new val 10
MAX8893_REG_ONOFF return val 1
MAX8893_REG_ONOFF new val 21
MAX8893_REG_ONOFF return val 21
MAX8893_REG_ONOFF new val 31
Set cpu clk. from 400MHz to 800MHz.
OM=0x9, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
Board Name: ARIES REV 03
Build On: May 19 2011 22:17:14
-----------------------------------------------------------
Re_partition: magic code(0x0)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x50
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
partitions loading success
board partition information update.. source: 0x0
Now Read Images - ID : 1
.Done.
read 1 units.
==== PARTITION INFORMATION ====
ID : IBL+PBL (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : PIT (0x1)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 1
===============================
ID : EFS (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 2
NO_UNITS : 40
===============================
ID : SBL (0x3)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 42
NO_UNITS : 5
===============================
ID : SBL2 (0x4)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 47
NO_UNITS : 5
===============================
ID : PARAM (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 52
NO_UNITS : 20
===============================
ID : KERNEL (0x6)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 72
NO_UNITS : 30
===============================
ID : RECOVERY (0x7)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 102
NO_UNITS : 30
===============================
ID : FACTORYFS (0x16)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 132
NO_UNITS : 1146
===============================
ID : DBDATAFS (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1278
NO_UNITS : 536
===============================
ID : CACHE (0x18)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1814
NO_UNITS : 130
===============================
ID : MODEM (0xb)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1944
NO_UNITS : 60
===============================
loke_init: j4fs_open success..
load_lfs_parameters valid magic code and version.
reading nps status file is successfully!.
nps status=0x504d4f43
load_debug_level reading debug level from file successfully(0x574f4c44).
init_fuel_gauge: vcell = 3777mV, soc = 48
check_quick_start_condition- Voltage: 3777.50000, Linearized[41/56/71], Capacity: 49
init_fuel_gauge: vcell = 3777mV, soc = 48, rcomp = d01f
reading nps status file is successfully!.
nps status=0x504d4f43
PMIC_IRQ1 = 0x30
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x0
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0x40
PMIC_STATUS2 = 0x0
get_debug_level current debug level is 0x574f4c44.
aries_process_platform: Debug Level Low
keypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
check_download: micorusb_status1 = 400, key_value = 0
aries_process_platform: final s1 booting mode = 0
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
lcd_power_on_ld9040
s6e63m0_c110_spi_read_byte-------------------------: 86
DA lcd ID1 = 86
s6e63m0_c110_spi_read_byte-------------------------: 48
DB lcd ID2 = 48
s6e63m0_c110_spi_read_byte-------------------------: 44
DC lcd ID3 = 44
LCD_ID == 3
Autoboot (0 seconds) in progress, press any key to stop Autoboot aborted..
SBL>
SBL>
SBL>
SBL>
SBL>
SBL>
SBL>
SBL>
SBL>
SBL>
SBL>
SBL Prompt
Code:
SBL> printenv
PARAM Rev 1.3
SERIAL_SPEED : 7
LOAD_RAMDISK : 0
BOOT_DELAY : 0
LCD_LEVEL : 97
SWITCH_SEL : 65
PHONE_DEBUG_ON : 0
LCD_DIM_LEVEL : 0
LCD_DIM_TIME : 6
MELODY_MODE : 1
REBOOT_MODE : 0
NATION_SEL : 0
LANGUAGE_SEL : 0
SET_DEFAULT_PARAM : 0
PARAM_INT_13 : 0
PARAM_INT_14 : 0
VERSION : I9000XXIL
CMDLINE : console=ttySAC2,115200 loglevel=4
DELTA_LOCATION : /mnt/rsv
PARAM_STR_3 :
PARAM_STR_4 :
SBL> setenv SWITCH_SEL 6543
argv[0] : setenv
argv[1] : SWITCH_SEL
argv[2] : 6543
value : 6543
SBL> reboot
command_loop: parse command error! (reboot)
SBL> reset
Rebooting...
SB1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------
+n1stVPN 2688
+nPgsPerBlk 64
PBL found bootable SBL: Partition(3).
MAX8893_REG_ONOFF return val 31
MAX8893_REG_DISCHARGE return val ff
MAX8893_REG_LSTIME return val 8
MAX8893_REG_DVSRAMP return val 9
MAX8893_REG_BUCK return val 2
MAX8893_REG_LDO1 return val e
MAX8893_REG_LDO1 new val e
MAX8893_REG_LDO2 return val 10
MAX8893_REG_LDO2 new val 10
MAX8893_REG_ONOFF return val 31
MAX8893_REG_ONOFF new val 31
MAX8893_REG_ONOFF return val 31
MAX8893_REG_ONOFF new val 31
Set cpu clk. from 400MHz to 800MHz.
OM=0x9, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
Board Name: ARIES REV 03
Build On: May 19 2011 22:17:14
-----------------------------------------------------------
Re_partition: magic code(0x0)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x50
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
partitions loading success
board partition information update.. source: 0x0
Now Read Images - ID : 1
.Done.
read 1 units.
==== PARTITION INFORMATION ====
ID : IBL+PBL (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : PIT (0x1)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 1
===============================
ID : EFS (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 2
NO_UNITS : 40
===============================
ID : SBL (0x3)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 42
NO_UNITS : 5
===============================
ID : SBL2 (0x4)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 47
NO_UNITS : 5
===============================
ID : PARAM (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 52
NO_UNITS : 20
===============================
ID : KERNEL (0x6)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 72
NO_UNITS : 30
===============================
ID : RECOVERY (0x7)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 102
NO_UNITS : 30
===============================
ID : FACTORYFS (0x16)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 132
NO_UNITS : 1146
===============================
ID : DBDATAFS (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1278
NO_UNITS : 536
===============================
ID : CACHE (0x18)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1814
NO_UNITS : 130
===============================
ID : MODEM (0xb)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1944
NO_UNITS : 60
===============================
loke_init: j4fs_open success..
load_lfs_parameters valid magic code and version.
reading nps status file is successfully!.
nps status=0x504d4f43
load_debug_level reading debug level from file successfully(0x574f4c44).
init_fuel_gauge: vcell = 3768mV, soc = 48
check_quick_start_condition- Voltage: 3768.75000, Linearized[40/55/70], Capacity: 49
init_fuel_gauge: vcell = 3768mV, soc = 48, rcomp = d01f
reading nps status file is successfully!.
nps status=0x504d4f43
PMIC_IRQ1 = 0x0
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x0
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0x40
PMIC_STATUS2 = 0x0
get_debug_level current debug level is 0x574f4c44.
aries_process_platform: Debug Level Low
keypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
check_download: micorusb_status1 = 400, key_value = 0
aries_process_platform: final s1 booting mode = 0
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
lcd_power_on_ld9040
s6e63m0_c110_spi_read_byte-------------------------: 86
DA lcd ID1 = 86
s6e63m0_c110_spi_read_byte-------------------------: 48
DB lcd ID2 = 48
s6e63m0_c110_spi_read_byte-------------------------: 44
DC lcd ID3 = 44
LCD_ID == 3
Autoboot (0 seconds) in progress, press any key to stop
get_debug_level current debug level is 0x574f4c44.
get_debug_level current debug level is 0x574f4c44.
boot_kernel: Debug Level Low
FOTA Check Bit
Read BML page=, NumPgs=
FOTA Check Bit (0xffffffff)
Load Partion idx = (6)
..............................done
Kernel read success from kernel partition no.6, idx.6.
setting param.serialnr=serial number.....
setting param.board_rev=0x30
setting param.cmdline=console=ttySAC2,115200 loglevel=4
Starting kernel at 0x32000000...
0xF8
AST_POWERON
BOOTING COMPLETED
All commands available at SBL Prompt.
Code:
SBL> help
Following commands are supported:
* setenv
* saveenv
* printenv
* help
* reset
* boot
* kernel
* format
* open
* close
* erasepart
* eraseall
* loadkernel
* showpart
* addpart
* delpart
* savepart
* nkernel
* nramdisk
* nandread
* nandwrite
* usb
* mmctest
* keyread
* readadc
* usb_read
* usb_write
* fuelgauge
* pmic_read
* pmic_write
To get commands help, Type "help <command>"
SBL> help setenv
* Help : setenv
* Usage : setenv [name] [value] . .
Modify current environment info on ram
SBL> help saveenv
* Help : saveenv
* Usage : saveenv
Save cuurent environment info to flash
SBL> help printenv
* Help : printenv
* Usage : printenv
Print current environment info on ram
SBL> help reset
* Help : reset
* Usage : reboot
Reboot system
SBL> help boot
* Help : boot
* Usage : boot [kernel options]
Boot Linux with optional kernel options
SBL> help kernel
* Help : kernel
* Usage : kernel hex_adr
Change the Linux kernel base
SBL> help format
* Help : format
* Usage : format
format device
SBL> help open
* Help : open
* Usage : open
open device
SBL> help close
* Help : close
* Usage : close
close device
SBL> help erasepart
* Help : erasepart
* Usage : erasepart partition_id
erase part of units
- ex) erase 0x9(temp partition)
SBL> help eraseall
* Help : eraseall
* Usage : eraseall
erase all units
SBL> help loadkernel
* Help : loadkernel
* Usage : loadkernel
load kernel image
- loadkernel 0x80A00000 from kernel partition
SBL> help showpart
* Help : showpart
* Usage : showpart
show partition information
SBL> help addpart
* Help : addpart
* Usage : addpart <id> <attr> <unit>
add partition information
- ex) addpart 0x(id) 0x1(attr) 0x10(units)
SBL> help delpart
* Help : delpart
* Usage : delpart
delete last partition information
SBL> help savepart
* Help : savepart
* Usage : savepart
save partition information
SBL> help nkernel
* Help : nkernel
* Usage : nkernel command
* Usage : nkernel
read kernel from flash to DDR
SBL> help nramdisk
* Help : nramdisk
* Usage : nramdisk command
* Usage : nramdisk
read ramdisk from flash to DDR
SBL> help nandread
* Help : nandread
* Usage : * Usage : nandread <PARTID> <SIZE>
read partition from flash to SDRAM(0x80000000)
SBL> help nandwrite
* Help : nandwrite
* Usage : * Usage: nandwrite <PARTID> <SIZE>
write partition from SDRAM(0x80000000) to flash
SBL> help usb
* Help : usb
* Usage : usb download command
SBL> help mmctest
* Help : mmctest
* Usage : *Usage : mmctest
SBL> help keyread
* Help : keyread
* Usage : *Usage : keyread
SBL> help readadc
* Help : readadc
* Usage : *Usage : readadc <channel>
SBL> help usb_read
* Help : usb_read
* Usage : usb_read reg
Read the usb ic register
SBL> help usb_write
* Help : usb_write
* Usage : usb_write reg, val
Read the usb ic register
SBL> help fuelgauge
* Help : fuelgauge
* Usage : *usage : fuelgauge
SBL> help pmic_read
* Help : pmic_read
* Usage : pmic_read reg
Read the pmic register
SBL> help pmic_write
* Help : pmic_write
* Usage : pmic_write reg, val
Read the pmic register
SBL> printenv
PARAM Rev 1.3
SERIAL_SPEED : 7
LOAD_RAMDISK : 0
BOOT_DELAY : 0
LCD_LEVEL : 97
SWITCH_SEL : 65
PHONE_DEBUG_ON : 0
LCD_DIM_LEVEL : 0
LCD_DIM_TIME : 6
MELODY_MODE : 1
REBOOT_MODE : 0
NATION_SEL : 0
LANGUAGE_SEL : 0
SET_DEFAULT_PARAM : 0
PARAM_INT_13 : 0
PARAM_INT_14 : 0
VERSION : I9000XXIL
CMDLINE : console=ttySAC2,115200 loglevel=4
DELTA_LOCATION : /mnt/rsv
PARAM_STR_3 :
PARAM_STR_4 :
SBL> showpart
board partition information update.. source: 0x0
Now Read Images - ID : 1
.Done.
read 1 units.
==== PARTITION INFORMATION ====
ID : IBL+PBL (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : PIT (0x1)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 1
===============================
ID : EFS (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 2
NO_UNITS : 40
===============================
ID : SBL (0x3)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 42
NO_UNITS : 5
===============================
ID : SBL2 (0x4)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 47
NO_UNITS : 5
===============================
ID : PARAM (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 52
NO_UNITS : 20
===============================
ID : KERNEL (0x6)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 72
NO_UNITS : 30
===============================
ID : RECOVERY (0x7)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 102
NO_UNITS : 30
===============================
ID : FACTORYFS (0x16)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 132
NO_UNITS : 1146
===============================
ID : DBDATAFS (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1278
NO_UNITS : 536
===============================
ID : CACHE (0x18)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1814
NO_UNITS : 130
===============================
ID : MODEM (0xb)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1944
NO_UNITS : 60
===============================
SBL> mmctest
Enable Movinand
[set_mmc_ocr] Sector Mode
[hsmmc_init] MMC card is detected
Product Name : MAG4FA
<display_card_info:935> ext_csd
<display_card_info:937>card_size: 15264
Total Card Size: 15265 MByte
SBL> keyread
keyread: row(0) col(0) read key value = 0x1
keyread: row(1) col(0) read key value = 0x2
SBL> pmic_read
---------read pmic register : multiple
(0x0 : 0x0), (0x1 : 0x0), (0x2 : 0x0), (0x3 : 0x0),
(0x4 : 0x0), (0x5 : 0xf0), (0x6 : 0x0), (0x7 : 0x0),
(0x8 : 0x40), (0x9 : 0x0), (0xa : 0xff), (0xb : 0xff),
(0xc : 0xa), (0xd : 0x80), (0xe : 0xff), (0xf : 0xff),
(0x10 : 0x3f), (0x11 : 0xef), (0x12 : 0x78), (0x13 : 0x10),
(0x14 : 0xbb), (0x15 : 0x12), (0x16 : 0x12), (0x17 : 0x12),
(0x18 : 0x12), (0x19 : 0xe), (0x1a : 0xe), (0x1b : 0x2),
(0x1c : 0x4), (0x1d : 0x86), (0x1e : 0x11), (0x1f : 0xc),
(0x20 : 0x2), (0x21 : 0x2), (0x22 : 0x30), (0x23 : 0xac),
(0x24 : 0x4), (0x25 : 0x14), (0x26 : 0x6), (0x27 : 0x10),
(0x28 : 0x2), (0x29 : 0xe), (0x2a : 0x31), (0x2b : 0x17),
This is what happens when you go into download mode... this occurs near the end of the SBL.
Code:
SBL> usb
reading nps status file is successfully!.
nps status=0x504d4f43
==> Welcome to ARIES!
==> Entering usb download mode..
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
lcd_power_on_ld9040
s6e63m0_c110_spi_read_byte-------------------------: 86
DA lcd ID1 = 86
s6e63m0_c110_spi_read_byte-------------------------: 48
DB lcd ID2 = 48
s6e63m0_c110_spi_read_byte-------------------------: 44
DC lcd ID3 = 44
LCD_ID == 3
Really man...have you already taken this thing apart?
Sent from my SGH-I897 using XDA Premium App
and here's the kernel debugging.... in case the kernel locks up during boot and Android will not function correctly, it provides a shell. Authorize ahead of time so that you can use Super User.
The settings in SBL prompt are
Code:
setenv SWITCH_SEL 6543
setenv PHONE_DEBUG_ON 1
saveenv
This can be very useful for kernel devlopers
Code:
Starting kernel at 0x32000000...
Uncompressing Linux...................................................................................................................................................................................
[ 0.000000] copy: bad source 0
[ 0.000000] mout_audss: bad source 0
[ 0.090142] KERNEL:kernel_sec_get_debug_level_from_boot=0x574f4c44
[ 0.094877] KERNEL:magic_number=0x0 DEBUG LEVEL low!!
[ 0.099895] (kernel_sec_set_upload_cause) : upload_cause set 0
[ 5.833835] init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'
sh: can't access tty; job control turned off
$ [ 11.433364] init: no such service 'bootanim'
[ 24.851663] init: sys_prop: permission denied uid:1000 name:wifi.interface
[ 35.227503] init: no such service 'bootanim'
[ 38.484304] init: sys_prop: permission denied uid:1000 name:dpm.allowcamera
su
sh: can't access tty; job control turned off
# dmesg|tail
<4>[ 47.443068] [email protected]
<4>[ 51.363390] mook - wm8994 TTY Off
<4>[ 51.666438] eth0: SIOCSIWSCAN : ISCAN
<4>[ 51.667822] +++: Set Broadcast ISCAN
<4>[ 53.013468] [email protected]
<4>[ 54.447852] Send Event ISCAN complete
<4>[ 54.448053] eth0 wl_iw_iscan_get_scan buflen_from_user 8192:
<4>[ 54.448067] eth0: SIOCGIWSCAN GET broadcast results
<4>[ 54.448111] wl_iw_iscan_get_scan return to WE 803 bytes APs=3
<4>[ 84.445803] wl_iw_set_ss_cache_timer_flag called
#
Looks like samsung has an autorun to reflash the recovery partition at /system/etc/install-recovery.sh
bulletproof1013 said:
Really man...have you already taken this thing apart?
Sent from my SGH-I897 using XDA Premium App
Click to expand...
Click to collapse
No, and I don't plan on it unless I have a problem that requires me to take it apart. Apparently this phone does not have bricking problems with people porting bootloaders from other devices.
I can see this being very handy indeed. Running kernels blind, having to get to at least ADB is a real pain. At least we now know this method works for the Infuse.
No bricking problems? Really?
Sent from my SGH-I897 using XDA Premium App
AdamOutler said:
No, and I don't plan on it unless I have a problem that requires me to take it apart. Apparently this phone does not have bricking problems with people porting bootloaders from other devices.
Click to expand...
Click to collapse
No bricking problems b/c we can't flash bootloaders haha. Well actually there is a way, but the only person to try said way bricked.
That's because the bootloaders are lock. well not motorola lock. I've read some where in the Galaxy tab 10.1 forum that Samsung had to lock the bootloaders because of copyright issues with media hub. if thats true Roger infuse don't offer media hub and the bootloaders for that phone are not lock. we got an update for the tab 10.1 that lock the bootloaders and the tab offer media hub could be true since Samsung are not known for locking them. I could be wrong.
Sent from my SAMSUNG-SGH-I997 using XDA Premium App
gtg465x said:
No bricking problems b/c we can't flash bootloaders haha. Well actually there is a way, but the only person to try said way bricked.
Click to expand...
Click to collapse
*raises hand* hehe
But I'm wondering if accessing the phone via UART would work with a device that's hardbricked as bad as that was? Too late to test now, it's already in the mail. ... unless I were to try flashing bootloaders like we did before? hehe
Aou said:
*raises hand* hehe
But I'm wondering if accessing the phone via UART would work with a device that's hardbricked as bad as that was? Too late to test now, it's already in the mail. ... unless I were to try flashing bootloaders like we did before? hehe
Click to expand...
Click to collapse
I have JTAG capabilities if you want to test.
You can get into download mode as long as you have SBL.
I've worked on and developed a way to turn Captivate into KIT-S5PC110 (the aeries development platform)... http://forum.xda-developers.com/showthread.php?t=1206216 It may be possible on this device.... I'm still working on my captivate.
AdamOutler said:
I have JTAG capabilities if you want to test.
You can get into download mode as long as you have SBL.
I've worked on and developed a way to turn Captivate into KIT-S5PC110 (the aeries development platform)... http://forum.xda-developers.com/showthread.php?t=1206216 It may be possible on this device.... I'm still working on my captivate.
Click to expand...
Click to collapse
Thanks, but the dead phone is gone and in the mail. I'd rather not void a warranty on this device by using JTAG. That device would not even go to download mode when using a JIG. Even the battery charging screen was gone. It was a hard brick.
AdamOutler said:
I have JTAG capabilities if you want to test.
You can get into download mode as long as you have SBL.
I've worked on and developed a way to turn Captivate into KIT-S5PC110 (the aeries development platform)... http://forum.xda-developers.com/showthread.php?t=1206216 It may be possible on this device.... I'm still working on my captivate.
Click to expand...
Click to collapse
Since you have JTAG capabilities there should be no risk of bricking. Maybe you can experiment with bootloader flashing on this phone. I can link you to gb bootloaders and custom bmlwriter flashing program if you're interested.
gtg465x said:
Since you have JTAG capabilities there should be no risk of bricking. Maybe you can experiment with bootloader flashing on this phone. I can link you to gb bootloaders and custom bmlwriter flashing program if you're interested.
Click to expand...
Click to collapse
Did you ever get a copy of BML5 from a Rogers device?
Aou said:
Did you ever get a copy of BML5 from a Rogers device?
Click to expand...
Click to collapse
Yes, but there's a bit of a problem with that. The dump of bml5 was blank. We aren't entirely sure what's going on with our bootloaders, thus the need for someone with a JTAG to test crazy ass shiz.
edit: Although it's not a pressing issue now that we have a kernel workaround for no GB bootloaders.
gtg465x said:
Since you have JTAG capabilities there should be no risk of bricking. Maybe you can experiment with bootloader flashing on this phone. I can link you to gb bootloaders and custom bmlwriter flashing program if you're interested.
Click to expand...
Click to collapse
I just gave you 1001 thanks! lol.
Just because you have a JTAG writer does not mean it's easy to JTAG a device. I would test with bootloaders if something required it, however it's not a good idea to go flashing random bootloaders ever... Only if required.
The proper way is to rework the kernel like you did.
Well, thanks to your original post, I was able to get something from the UART on my Infuse. Unfortunately, it's all garbage. Are you using a standard RS-232 connection, or TTL 5v connection? If using TTL 5v, would it be possible to use a TTL 3.3v? This is what I'm getting in putty:
½^ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZÚ¯¿¿¿Y=%#1¿_¿{!!'!=7/¿¯y*¿Y=%#1¿u'59¿y!£§¿g7£¿¥ë奥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥¥ëåëåj¤t4õ5ý¿¿¿¿¿¿¿ëåj¤Ê_5')¿¿¿¿¿ëåµ--!#¯*£ëåßg
(repeats). I get a whole new set of garbage when I put int he battery. It all looks like your video on youtube with the captivate, but it's just all garbage. I tracked down another forum post where you were getting garbage also, but then never posted the resolution.
Any help would be awesome. Thanks!
gtg465x said:
Since you have JTAG capabilities there should be no risk of bricking. Maybe you can experiment with bootloader flashing on this phone. I can link you to gb bootloaders and custom bmlwriter flashing program if you're interested.
Click to expand...
Click to collapse
I don't think he's got JTAG capabilities on the phone yet, and probably won't until he REALLY needs them.
Getting JTAG capability requires soldering a connector to the board permanently or semi-permanently, or soldering individual wires to the board only for the flash process. No one has been able to figure out any compression-spring/pogo-pin contact approach, the connector pad pitch is just too damn small.
Otherwise I'd probably have JTAG capability too. If not for the connector issue I'd be experimenting with a Bus Blaster v2.
Entropy512 said:
I don't think he's got JTAG capabilities on the phone yet, and probably won't until he REALLY needs them.
Getting JTAG capability requires soldering a connector to the board permanently or semi-permanently, or soldering individual wires to the board only for the flash process. No one has been able to figure out any compression-spring/pogo-pin contact approach, the connector pad pitch is just too damn small.
Otherwise I'd probably have JTAG capability too. If not for the connector issue I'd be experimenting with a Bus Blaster v2.
Click to expand...
Click to collapse
I can put the connector on.. assuming its 12 pin plus 4 mounting pads? I have them in stock. Its not a problem for me to solder them. I can do it.
Does anyone have some tech porn of this board, or disassembly instructions?

[GUIDE] USB Uart on Galaxy S devices [2012/09/25]

== General Info ==
Hello, and welcome to my usb uart guide - aka, how to totally f' your phone up, if you don't think first!
Really though, read everything before attempting anything!
USB Uart is not new news. There are many great people whom have come before me to make what I am documenting here possible. But I am putting this here because I keep getting PM'd about getting help with USB Uart, and figured it would be good to start a thread that documents what you need and how to get going.
So up front, I need to list some credits.
I gained a lot of knowledge from these people:
TheBeano - Fun with resistors (home/car dock mode + more)
UberPenguin - Galaxy S UART JIG & Debugging Connector
AdamOutler - UART Output / Bootloader Hacking / Kernel Debuging
E:V:A - The Samsung Anyway Jig
I'm sure there is more... let me know if you think you need to be in this list. I'll be happy to update it!
== WARNING ==
I am not responsible for anything you do to your device! If you follow my guide and it results from anything like your phone not working or ending the world, I cannot be held accountable for what you do!
This guide will show you how to use the usb uart on most galaxy s phones (with the FSA9480 USB port accessory detector and switch)
It helps to have Unbrickable Mod. There are some commands you can run from the SBL that will wipe your bootloaders!
You must be VERY CAREFUL!
== Requirements ==
First off, you will need some hardware to connect to your computer. It helps. Below is a list of things I use and they are common and cheap. The links to the items below are what I have. Its what works for me.
mini-usb cable - http://www.sparkfun.com/products/598
bus pirate or arduino (I only cover bus pirate here... for now.) - http://www.seeedstudio.com/depot/bus-pirate-v3-assembled-p-609.html?cPath=174
In my guide i use the bus pirate probe kit - http://www.seeedstudio.com/depot/bus-pirate-probe-kit-p-526.html?cPath=178_180
I used a tape printer to label the test clips.
breadboard (optional, if you rather just solder the resistor to the micro-usb break-out board. more later...) - http://www.sparkfun.com/products/112
USB MicroB Plug Breakout Board - http://www.sparkfun.com/products/10031
some jumper wire - http://www.sparkfun.com/products/124
150k, 523k, 619k resistor (ymmv. AdamOutler and others told me to try 523k or 619k, but I was able to get all the output I need with 150k)
guts - priceless
Also, I use minicom on Linux and Mac OS X (use homebrew to install minicom), but you should be able to use any serial console program you like (i.e. kermit, cu, etc...)
I highly suggest getting to know your bus pirate, but this guide assumes you have read manuals and updated firmware. Any of the other uart modes should also work this way, but I currently don't cover that here... yet.
== Getting Started ==
When we connect to the usb port on the bus pirate(bp), you can find the version info by typing i at the high impedance mode (HiZ>) prompt. Change to this mode when your modifying connections or cable argments.
Code:
HiZ>i
Bus Pirate v3b
Firmware v6.0 r1625 Bootloader v4.4
DEVID:0x0447 REVID:0x3043 (24FJ64GA002 B5)
http://dangerousprototypes.com
Disconnect the bp and lets connect everything from the micro usb port connecting to your phone backwards to the bp. I use a breadboard for things that I might work on later or things I'll re-arrange a lot. You may also decide to solder the resistor directly to the GND/ID pins, but you will need a little lead on the GND. Connect MOSI to D+ and MISO to D-.
Another warning!
You can also fry the ftdi on the bus pirate, if you mess with the connections while the bus pirate is in any mode besides HiZ (Hi Impedance) or unplugged. Usually, I'm in uart bridge mode, so you can't go back to HiZ. You just have to unplug the usb cable.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Solder some jumper wire to the micro usb breakout board. I use about an inch.
I usually start at a1 on the breadboard with vcc and a4 and a5 for ID and GND (respectively). In these images, I'm at the opposite end of the board to make it easier to have the phone next to and above my mouse so it is easy for me to work with the phone.
Put the resistor on b4 and b5 - which is where I connect GND on the bp.
Now that you have the bp connected to the circut, lets move forward and plug in the micro usb cable into the bp and then into your computer.
To change into UART mode on the buspirate, type 'm' at the HiZ> prompt:
Code:
HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
x. exit(without change)
(1)>3
Set serial port speed: (bps)
1. 300
2. 1200
3. 2400
4. 4800
5. 9600
6. 19200
7. 38400
8. 57600
9. 115200
10. BRG raw value
(1)>9
Data bits and parity:
1. 8, NONE *default
2. 8, EVEN
3. 8, ODD
4. 9, NONE
(1)>1
Stop bits:
1. 1 *default
2. 2
(1)>1
Receive polarity:
1. Idle 1 *default
2. Idle 0
(1)>1
Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)
(1)>2
Ready
UART>(3)
UART bridge
Reset to exit
Are you sure? y
After you get into UART Bridge mode, you will have to unplug the usb port from your computer to reset the bus pirate.
This is where experimenting with different resistors on the GND/ID pins make a difference. Using 619k resistance, I just plug the phone in and it boots up. During boot up, I can see the PBL output like the output you will see in the rest of this document. Using 150k resistance, the phone doesn't automatically turn on.
Also, you may have different usability of the console depending on if you set the output type to Open drain or Normal drain.
With Open drain, I am able to see the uart output, but I am not able to break into the SBL prompt like I am with Normal drain.
Interestingly, with 619k on my SGH-T959V, I don't see all of the kernel console output. I still haven't figured out exactly why yet. With 150k resistance, I don't see the PBL output, but I can still break into the SBL prompt (with normal drain) and get full kernel console output.
When you get to this point, the mode light should now be green. When you plug your phone into the micro usb adapter (again 619k in these examples), you should see everything from the pbl in to the kernel starting:
Code:
1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------
+n1stVPN 2688
+nPgsPerBlk 64
+n1stVPN 3008
+nPgsPerBlk 64
PBL found bootable SBL: Partition(4).
Set cpu clk. from 400MHz to 800MHz.
OM=0x29, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
Board Name: ARIES REV 03
Build On: Oct 28 2011 15:45:50
-----------------------------------------------------------
Re_partition: magic code(0x0)
[PAM: ] ++FSR_PAM_Init
[PAM: ] OneNAND physical base address : 0xb0000000
[PAM: ] OneNAND virtual base address : 0xb0000000
[PAM: ] OneNAND nMID=0xec : nDID=0x60
[PAM: ] --FSR_PAM_Init
fsr_bml_load_partition: pi->nNumOfPartEntry = 12
partitions loading success
board partition information update.. source: 0x0
.Done.
read 1 units.
==== PARTITION INFORMATION ====
ID : IBL+PBL (0x0)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 0
NO_UNITS : 1
===============================
ID : PIT (0x1)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 1
NO_UNITS : 1
===============================
ID : EFS (0x14)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 2
NO_UNITS : 40
===============================
ID : SBL (0x3)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 42
NO_UNITS : 5
===============================
ID : SBL2 (0x4)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 47
NO_UNITS : 5
===============================
ID : PARAM (0x15)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 52
NO_UNITS : 20
===============================
ID : KERNEL (0x6)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 72
NO_UNITS : 30
===============================
ID : RECOVERY (0x7)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 102
NO_UNITS : 30
===============================
ID : FACTORYFS (0x16)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 132
NO_UNITS : 1540
===============================
ID : DATAFS (0x17)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 1672
NO_UNITS : 2120
===============================
ID : CACHE (0x18)
ATTR : RW STL SLC (0x1101)
FIRST_UNIT : 3792
NO_UNITS : 160
===============================
ID : MODEM (0xb)
ATTR : RO SLC (0x1002)
FIRST_UNIT : 3952
NO_UNITS : 60
===============================
loke_init: j4fs_open success..
load_lfs_parameters valid magic code and version.
reading nps status file is successfully!.
nps status=0x504d4f43
load_debug_level reading debug level from file successfully(0x574f4c44).
init_fuel_gauge: vcell = 4013mV, soc = 86
check_quick_start_condition- Voltage: 4013.75000, Linearized[74/89/100], Capacity: 89
init_fuel_gauge: vcell = 4013mV, soc = 86, rcomp = d000
reading nps status file is successfully!.
nps status=0x504d4f43
PMIC_IRQ1 = 0x20
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x0
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0x40
PMIC_STATUS2 = 0x0
get_debug_level current debug level is 0x574f4c44.
aries_process_platform: Debug Level Low
keypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
check_download: micorusb_status1 = 400, key_value = 0
aries_process_platform: final s1 booting mode = 0
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
Autoboot (0 seconds) in progress, press any key to stop
get_debug_level current debug level is 0x574f4c44.
get_debug_level current debug level is 0x574f4c44.
boot_kernel: Debug Level Low
FOTA Check Bit
Read BML page=, NumPgs=
FOTA Check Bit (0xffffffff)
Load Partion idx = (6)
..............................done
Kernel read success from kernel partition no.6, idx.6.
setting param.serialnr=0x3733b898 0x1ffc00ec
setting param.board_rev=0x30
setting param.cmdline=console=ttySAC2,115200 loglevel=4
Starting kernel at 0x32000000...
== The SBL (Secondary BootLoader) ==
The most interesting line out of all of that was:
Code:
Autoboot (0 seconds) in progress, press any key to stop
If you happen to hold down the Enter/Return key while booting the phone you will get into the "SBL>" prompt.
The Secondary BootLoader is essentially like u-boot.
Code:
...
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
Autoboot (0 seconds) in progress, press any key to stop Autoboot aborted..
SBL>
If we type help, we will get some commands you can run. Some of these commands are affected by what is set in the environment.
Code:
SBL> help
Following commands are supported:
* setenv
* saveenv
* printenv
* help
* reset
* boot
* kernel
* format
* open
* close
* erasepart
* eraseall
* loadkernel
* showpart
* addpart
* delpart
* savepart
* nkernel
* nramdisk
* nandread
* nandwrite
* usb
* mmctest
* keyread
* readadc
* usb_read
* usb_write
* fuelgauge
* pmic_read
* pmic_write
To get commands help, Type "help <command>"
SBL>
You can get some minimal help for each command:
Code:
SBL> help loadkernel
* Help : loadkernel
* Usage : loadkernel
load kernel image
- loadkernel 0x80A00000 from kernel partition
Another set of intersting commands here are the ones that manipulate the environment:
setenv
saveenv
printenv
Code:
SBL> help setenv
* Help : setenv
* Usage : setenv [name] [value] . .
Modify current environment info on ram
SBL> help saveenv
* Help : saveenv
* Usage : saveenv
Save cuurent environment info to flash
SBL> help printenv
* Help : printenv
* Usage : printenv
Print current environment info on ram
printenv is probably the safest of them to run, so lets try this first.
Code:
SBL> printenv
PARAM Rev 1.3
SERIAL_SPEED : 7
LOAD_RAMDISK : 0
BOOT_DELAY : 0
LCD_LEVEL : 97
SWITCH_SEL : 1
PHONE_DEBUG_ON : 0
LCD_DIM_LEVEL : 0
LCD_DIM_TIME : 6
MELODY_MODE : 1
REBOOT_MODE : 0
NATION_SEL : 0
LANGUAGE_SEL : 0
SET_DEFAULT_PARAM : 0
CUST_KERNEL_DL_COUNT : 0
KERNEL_BINARY_TYPE : 0
VERSION : I9000XXIL
CMDLINE : console=ttySAC2,115200 loglevel=4
DELTA_LOCATION : /mnt/rsv
PARAM_STR_3 :
PARAM_STR_4 :
I'm not fully sure what all of these options are, but the ones I know about are SWITCH_SEL and PHONE_DEBUG_ON.
I usually turn SWITCH_SEL to 765431. If I turn 2 on, I don't get anything. It would be worthy to test each number in SWITCH_SEL to figure out what number changes what. That maybe specific to the device I have.
Setting at least 6543 in SWITCH_SEL will give you kernel log output:
Code:
setenv SWITCH_SEL 6543
saveenv
I also set PHONE_DEBUG_ON to 1:
Code:
setenv PHONE_DEBUG_ON 1
saveenv
When I set this, I get some extended battery statistics like:
Code:
[BAT] CHR(0) CAS(0) CHS(3) DCR(0) ACP(2) BAT(81,0,0) TE(31) HE(1) VO(3926) ED(1000) RC(0) CC(0) VF(591) LO(0)
You must remember that after running setenv, you must then run saveenv at least once at the end to save the environment. I believe this environment info is saved to either an offset on the sbl partition or on the param.lfs. It would be useful to find this out, because u-boot has a userspace utility (that you can use from within linux userspace) to modify the u-boot environment. It may be handy to use a tool like that to modify the CMDLINE option during rom flashing time.
Also, instead of powering your phone off then on again to put the new settings in place, just run reset from the sbl prompt to reboot the phone with the new settings.
Anyways, This is what I have so far. I will be adding more to this as time goes on.
Enjoy!
-Bryan
Very nice and clear guide!
Also check out my Anyway thread on more details about JIG resistances etc. Soon I hope there will be more added to that about building your own Samsung Test Jig...
Setenv switch sel 1234567
Phone debug on 1
This gives you some kernel debugging.
bhundven said:
I usually turn SWITCH_SEL to 765431. If I turn 2 on, I don't get anything. It would be worthy to test each number in SWITCH_SEL to figure out what number changes what.
Click to expand...
Click to collapse
AdamOutler said:
Setenv switch sel 1234567
Phone debug on 1
This gives you some kernel debugging.
Click to expand...
Click to collapse
Yup. I've got that in there.
It's interesting to note that not all bootloaders are created equal. My results are on SGH-T959V.
Any chance that it will work witch Galaxy Ace too?
dragonnn said:
Any chance that it will work witch Galaxy Ace too?
Click to expand...
Click to collapse
I'm not sure. The GT-i9001 and the SGH-i717 (at&t galaxy note) also both have the FSA9480 chip, but use Qualcomm chips. I can only get some bootloader output from the SGH-i717:
Code:
Android Bootloader - UART_DM Initialized!!!
[VIBETONZ] ENABLE
[VIBETONZ] DISABLE
HW_REV = 12
mipi_init : status = 1
HW_REV = 12
start init_charger
smb328a_init_charger : is_reboot_mode = 0, vcell = 3975
check valid dcin (0x33) = 0x0
no dcin, skip init_charger
fuelguage : soc = 80%, vcell = 3975mV
fuelguage : rcomp(0xd01f) ==?? 0xd0d0
HW_REV = 12
VReset : 0x8c
Hibernation mode : 0x0
8340 = ( 397500 - 334350 ) * 13207 / 100000
HW_REV = 12
reboot_mode = 0xb6cef249
do key check
enter normal booting mode
AST_POWERON
usable ddi data.
HW_REV = 12
HW_REV = 12
E.V.A. said that it might be some debugging setting in the kernel that might have disabled the kernel log output.
It would be helpful to get some MSM developers here to help us out with that!
bhundven said:
I'm not sure. The GT-i9001 and the SGH-i717 (at&t galaxy note) also both have the FSA9480 chip, but use Qualcomm chips. I can only get some bootloader output from the SGH-i717:
Click to expand...
Click to collapse
I looked in the kernel source and it have ./drivers/i2c/chips/fsa9280.c and the driver is included in the build kernel:good:. As far I understand we can using this method recovery the phone from hard brick? That will be really nice, my friend bricked his Ace, maybe he can use this method.
dragonnn said:
I looked in the kernel source and it have ./drivers/i2c/chips/fsa9280.c and the driver is included in the build kernel:good:. As far I understand we can using this method recovery the phone from hard brick? That will be really nice, my friend bricked his Ace, maybe he can use this method.
Click to expand...
Click to collapse
Currently, I only know this method to work on SGS( not sgs2 or sgs3 ) phones with the FSA9480.
bhundven said:
Yup. I've got that in there.
It's interesting to note that not all bootloaders are created equal. My results are on SGH-T959V.
Click to expand...
Click to collapse
The switches are messages from levels 1-7. Turn on more to get more messages.
AdamOutler said:
The switches are messages from levels 1-7. Turn on more to get more messages.
Click to expand...
Click to collapse
That makes sense, but what doesn't is if I set SWITCH_SEL to 1234567 or any combination with 2, I get no output. As long as I don't have 2 in there, it works fine. Must just be this device.
Memory Architecture
Of course each device will have a different Memory Map. Each carrier designs their varient based on what they want and need to function. The MM is sectioned off in the ROM. Any user or modifiable area is stored in RAM so remember we are working in an area that is not supposed to touched (ROM).
Bootloaders are tricky beasts, have never developed a flashing algorithm so I don't know. Usually BLs are not updated after release ( atleast in my field) only sw/fw is.
Either way, excellent ideas, but there is always a way in!
Fly-n-High said:
Of course each device will have a different Memory Map. Each carrier designs their varient based on what they want and need to function. The MM is sectioned off in the ROM. Any user or modifiable area is stored in RAM so remember we are working in an area that is not supposed to touched (ROM).
Bootloaders are tricky beasts, have never developed a flashing algorithm so I don't know. Usually BLs are not updated after release ( atleast in my field) only sw/fw is.
Either way, excellent ideas, but there is always a way in!
Click to expand...
Click to collapse
huh?
Good post
Nice...!!
Thanks you~
can't get SBL or PBL logs on uart in galaxy-y (GT-S5360)
Hello sir,
Thanks for your great tutorial .
I Tried to get uart on galaxy-y (GT-S5360) . I got a working uart but can't see any PBL or SBL logs during the boot. The only log I see during the booting is
Code:
AST_POWERON..
BOOTING COMPLETED
After booting, uart works fine and i can use a shell via serial using command
(on phone)
Code:
busybox sh</dev/ttyS0 >/dev/ttyS0
and on PC
Code:
microcom -s 115200 -p /dev/ttyS0
ttyS0 settings of the phone is
Code:
speed 115200 baud; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
And that of PC is
Code:
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl echoke
cat /proc/cmdline of phone is
Code:
console=ttyS0,115200n8 mem=362M kmemleak=off root=/dev/ram0 rw androidboot.console=ttyS0 mtdparts=bcm_umi-nand:[email protected](bcm_boot)ro,[email protected](loke)ro,[email protected](loke_bk)ro,[email protected](systemdata)ro,[email protected](modem)ro,[email protected](param_lfs)rw,[email protected](boot)ro,[email protected](boot_backup)ro,[email protected](system)rw,[email protected](cache)rw,[email protected](userdata)rw,[email protected](efs)rw,[email protected](sysparm_dep)ro,[email protected](umts_cal)ro,[email protected](cal)r BOOT_MODE=0 loglevel=0 BOOT_FOTA=0 DEBUG_LEVEL=LOW
Circuit diagram is attached below
any one please help
harish2704 said:
I Tried to get uart on galaxy-y (GT-S5360) . I got a working uart but can't see any PBL or SBL logs during the boot. The only log I see during the booting is
Code:
AST_POWERON..
BOOTING COMPLETED
Click to expand...
Click to collapse
I get something similar on a Samsung Rugby Smart (SGH-I847). I think they have tweaked the UART stuff on the newer devices that post date the Galaxy S devices. They might share the UART chip, but it seems as if they changed the loader implementation which is causing the newer devices to not see the PBL and SBL information during boot.
harish2704 said:
Circuit diagram is attached below
Click to expand...
Click to collapse
Have you tried a 150k or 619k resistor instead of the 523k? I was able to get output with both a 150k and 619k, but the output was very similar to what you have posted. Likely a long shot, but worth a try.
harish2704 said:
cat /proc/cmdline of phone is
Code:
console=ttyS0,115200n8 mem=362M kmemleak=off root=/dev/ram0 rw androidboot.console=ttyS0 mtdparts=bcm_umi-nand:[email protected](bcm_boot)ro,[email protected](loke)ro,[email protected](loke_bk)ro,[email protected](systemdata)ro,[email protected](modem)ro,[email protected](param_lfs)rw,[email protected](boot)ro,[email protected](boot_backup)ro,[email protected](system)rw,[email protected](cache)rw,[email protected](userdata)rw,[email protected](efs)rw,[email protected](sysparm_dep)ro,[email protected](umts_cal)ro,[email protected](cal)r BOOT_MODE=0 loglevel=0 BOOT_FOTA=0 DEBUG_LEVEL=LOW
Click to expand...
Click to collapse
Do you have any control over this? It might be the case that ttyS0 isn't setup during early-boot and you need to use a different tty to get it to output over the FSA chip.
Have you tried a 150k or 619k resistor instead of the 523k?
Click to expand...
Click to collapse
yes I tried I didn't feel any difference b/w 619k & 523k when tried. And with 150k, I couldn't get uart active ()
Do you have any control over this? It might be the case that ttyS0 isn't setup during early-boot and you need to use a different tty to get it to output over the FSA chip
Click to expand...
Click to collapse
.
What you mean by control? You mean, can i change this parameters? yes its possible by reflashing (update.zip methode)
Or
you mean do i have control on ttyS0 device? yes I could change that by
Code:
busybox stty -F /dev/ttyS0 ..........
command
Sorry for my language
harish2704 said:
What you mean by control? You mean, can i change this parameters? yes its possible by reflashing (update.zip methode)
Click to expand...
Click to collapse
This is the method I was referring to. If you tweak the parameters you might be able to get the kernel log over serial.
Sent from my SAMSUNG-SGH-I547 using Tapatalk 2
Can you please describe about the tweaks i have to do...
in my knowledge, kernel param
Code:
console=ttyS0,115200n8
is enough for that....
So please specify the tweaks...
harish2704 said:
Can you please describe about the tweaks i have to do...
in my knowledge, kernel param
Code:
console=ttyS0,115200n8
is enough for that....
So please specify the tweaks...
Click to expand...
Click to collapse
If you can interact with ttyS0 post-boot I'd expect it to work. Is there maybe anther serial device such as ttyHS0 or similar that you can interact with? If so, that might be something to try.
You need to change that ttyS0 to ttySAC2 in the boot parameters. Use the abootimg tool on Ubuntu. Apt-get install abootimg.

Flash Counter not resetting itself!?

Hi, I had recently flashed the jellybean leak Ota for my tab(it's p3100), I had then flashed cwm. Now I tried resetting my flash counter but after rebooting it still stuck at 1 count. What should I do?
Sent from my GT-P3100 using XDA Premium HD app
Help anyone?
Sent from my GT-P3100 using XDA Premium HD app
Maybe flash back to ics. And reset the counter
Sent from my GT-I9100 using Tapatalk 2
Aditya16 said:
Hi, I had recently flashed the jellybean leak Ota for my tab(it's p3100), I had then flashed cwm. Now I tried resetting my flash counter but after rebooting it still stuck at 1 count. What should I do?
Sent from my GT-P3100 using XDA Premium HD app
Click to expand...
Click to collapse
have you tried "Triangule Away" ?
you can installed it from google play
but you need to root your device first
sapiterbang said:
have you tried "Triangle Away" ?
you can installed it from google play
but you need to root your device first
Click to expand...
Click to collapse
I resetted it with that only. Is it some bug in jb?
Sent from my GT-P3100 using XDA Premium HD app
Alvin Lai said:
Maybe flash back to ics. And reset the counter
Sent from my GT-I9100 using Tapatalk 2
Click to expand...
Click to collapse
Will try that.
Sent from my GT-P3100 using XDA Premium HD app
May be try installing supersu ( not superuser) from google play and give permissions to triangle away
Install latest version 1.95 of triangle away
Sent from Galaxy S2 or Galaxy Tab2
I confirm Triangle Away and SuperSU combination still work in JB.
So after rebooting and going to the download mode, even for me it is zero, but after exiting and booting back it goes back to 1 count.
Sent from my GT-P3100 using XDA Premium HD app
Aditya16 said:
So after rebooting and going to the download mode, even for me it is zero, but after exiting and booting back it goes back to 1 count.
Sent from my GT-P3100 using XDA Premium HD app
Click to expand...
Click to collapse
Post your issue in Triangle Away thread. Maybe someone can help you...
---------- Post added at 05:06 PM ---------- Previous post was at 05:06 PM ----------
Aditya16 said:
So after rebooting and going to the download mode, even for me it is zero, but after exiting and booting back it goes back to 1 count.
Sent from my GT-P3100 using XDA Premium HD app
Click to expand...
Click to collapse
Post your issue in Triangle Away thread. Maybe someone could help you
Waw... Back from recovery I got +1. This is not because JB but Sbl.bin updated (download mode in potrait position now). The second boot loader checkbit RECOVERY partition:
Code:
Secondary Bootloader v3.1 version.
Copyright (C) 2011 System S/W Group. Samsung Electronics Co., Ltd.
Board: GT-P3100 REV 04-REAL / Sep 17 2012 13:37:57
booting code=0x0
===== PARTITION INFORMATION =====
ID : X-loader (0x1)
DEVICE : MMC
FIRST UNIT : 0
NO. UNITS : 0
=================================
ID : EFS (0x4)
DEVICE : MMC
FIRST UNIT : 8192
NO. UNITS : 40960
=================================
ID : SBL1 (0x2)
DEVICE : MMC
FIRST UNIT : 49152
NO. UNITS : 4096
=================================
ID : SBL2 (0x3)
DEVICE : MMC
FIRST UNIT : 53248
NO. UNITS : 4096
=================================
ID : PARAM (0x5)
DEVICE : MMC
FIRST UNIT : 57344
NO. UNITS : 16384
=================================
ID : KERNEL (0x6)
DEVICE : MMC
FIRST UNIT : 73728
NO. UNITS : 16384
=================================
ID : RECOVERY (0x7)
DEVICE : MMC
FIRST UNIT : 90112
NO. UNITS : 16384
=================================
ID : CACHE (0x8)
DEVICE : MMC
FIRST UNIT : 106496
NO. UNITS : 1433600
=================================
ID : MODEM (0x9)
DEVICE : MMC
FIRST UNIT : 1540096
NO. UNITS : 40960
=================================
ID : FACTORYFS (0xa)
DEVICE : MMC
FIRST UNIT : 1581056
NO. UNITS : 2867200
=================================
ID : DATAFS (0xb)
DEVICE : MMC
FIRST UNIT : 4448256
NO. UNITS : 25280478
=================================
ID : HIDDEN (0xd)
DEVICE : MMC
FIRST UNIT : 29728734
NO. UNITS : 1048576
=================================
ID : GANG (0x0)
DEVICE : MMC
FIRST UNIT : 0
NO. UNITS : 0
=================================
loke_init: j4fs_open..success
<start_checksum:310>CHECKSUM_HEADER_SECTOR :42
<start_checksum:313>offset:42, size:1024
Not Need Movinand Checksum
load_lfs_parameters valid magic code and version.
switch_sel_str='1'
switch_sel_int='1'
load_debug_level: read debug level successfully(0x574f4c44)...LOW
init_ddi_data: usable ddi data.
Set charging current TA
omap_max17042_read_temp: FG Temp raw_data : 0x2723
read_temp_adc:adc_data : 772
read_temp_adc:adc_data : 763
read_temp_adc:adc_data : 765
read_temp_adc:adc_data : 759
read_temp_adc:adc_data : 758
check_battery_type: fg temp : 39136, adc_temp : 420
check_battery_type: Set BATTERY_TYPE_SDI
omap_max17042_set_model_data : Already fuel gauge initialized !!
max17042_compensate_soc: vcell(3840), rep_soc(43)
calculate_table_soc: charging status : 2, vcell(3840), table_soc(52)
[SBL] VFOCV MSB : 0xc0, LSB : 0x7
[SBL_CHARGER] SOC : 43, VCELL : 3840, VFSOC : 42, VFOCV : 3840
save param.blk, size: 5268
save param.blk successfully.
save switch_sel(1)...ok
reading nps status file is successfully!.
nps status=0x504d4f43
g_nRebootReason = 0x1
set_lcd_panel_id: panel_adc=142
*** ltn070nl01_power_on ***
lcd_pannel_id=2
Autoboot (1 seconds) in progress, press any key to stop .
boot_kernel: debug level low!
checkbit: find RECOVERY
checkbit (f55f0aa0)
Kernel @ 81808000 (0x3f715c bytes)
Ramdisk @ 82800000 (0x880aa bytes)
Starting kernel at 0x81808000...
Now I need Sbl.bin backup from ICS!
ketut.kumajaya said:
Waw... Back from recovery I got +1. This is not because JB but Sbl.bin updated (download mode in potrait position now). The second boot loader checkbit RECOVERY partition:
Code:
Secondary Bootloader v3.1 version.
Copyright (C) 2011 System S/W Group. Samsung Electronics Co., Ltd.
Board: GT-P3100 REV 04-REAL / Sep 17 2012 13:37:57
booting code=0x0
===== PARTITION INFORMATION =====
ID : X-loader (0x1)
DEVICE : MMC
FIRST UNIT : 0
NO. UNITS : 0
=================================
ID : EFS (0x4)
DEVICE : MMC
FIRST UNIT : 8192
NO. UNITS : 40960
=================================
ID : SBL1 (0x2)
DEVICE : MMC
FIRST UNIT : 49152
NO. UNITS : 4096
=================================
ID : SBL2 (0x3)
DEVICE : MMC
FIRST UNIT : 53248
NO. UNITS : 4096
=================================
ID : PARAM (0x5)
DEVICE : MMC
FIRST UNIT : 57344
NO. UNITS : 16384
=================================
ID : KERNEL (0x6)
DEVICE : MMC
FIRST UNIT : 73728
NO. UNITS : 16384
=================================
ID : RECOVERY (0x7)
DEVICE : MMC
FIRST UNIT : 90112
NO. UNITS : 16384
=================================
ID : CACHE (0x8)
DEVICE : MMC
FIRST UNIT : 106496
NO. UNITS : 1433600
=================================
ID : MODEM (0x9)
DEVICE : MMC
FIRST UNIT : 1540096
NO. UNITS : 40960
=================================
ID : FACTORYFS (0xa)
DEVICE : MMC
FIRST UNIT : 1581056
NO. UNITS : 2867200
=================================
ID : DATAFS (0xb)
DEVICE : MMC
FIRST UNIT : 4448256
NO. UNITS : 25280478
=================================
ID : HIDDEN (0xd)
DEVICE : MMC
FIRST UNIT : 29728734
NO. UNITS : 1048576
=================================
ID : GANG (0x0)
DEVICE : MMC
FIRST UNIT : 0
NO. UNITS : 0
=================================
loke_init: j4fs_open..success
<start_checksum:310>CHECKSUM_HEADER_SECTOR :42
<start_checksum:313>offset:42, size:1024
Not Need Movinand Checksum
load_lfs_parameters valid magic code and version.
switch_sel_str='1'
switch_sel_int='1'
load_debug_level: read debug level successfully(0x574f4c44)...LOW
init_ddi_data: usable ddi data.
Set charging current TA
omap_max17042_read_temp: FG Temp raw_data : 0x2723
read_temp_adc:adc_data : 772
read_temp_adc:adc_data : 763
read_temp_adc:adc_data : 765
read_temp_adc:adc_data : 759
read_temp_adc:adc_data : 758
check_battery_type: fg temp : 39136, adc_temp : 420
check_battery_type: Set BATTERY_TYPE_SDI
omap_max17042_set_model_data : Already fuel gauge initialized !!
max17042_compensate_soc: vcell(3840), rep_soc(43)
calculate_table_soc: charging status : 2, vcell(3840), table_soc(52)
[SBL] VFOCV MSB : 0xc0, LSB : 0x7
[SBL_CHARGER] SOC : 43, VCELL : 3840, VFSOC : 42, VFOCV : 3840
save param.blk, size: 5268
save param.blk successfully.
save switch_sel(1)...ok
reading nps status file is successfully!.
nps status=0x504d4f43
g_nRebootReason = 0x1
set_lcd_panel_id: panel_adc=142
*** ltn070nl01_power_on ***
lcd_pannel_id=2
Autoboot (1 seconds) in progress, press any key to stop .
boot_kernel: debug level low!
checkbit: find RECOVERY
checkbit (f55f0aa0)
Kernel @ 81808000 (0x3f715c bytes)
Ramdisk @ 82800000 (0x880aa bytes)
Starting kernel at 0x81808000...
Now I need Sbl.bin backup from ICS!
Click to expand...
Click to collapse
How will i get this sbl.bin file from?
Aditya16 said:
How will i get this sbl.bin file from?
Click to expand...
Click to collapse
From /dev/block/mmcblk0p2 and /dev/block/mmcblk0p3. Be careful, this is a critical part of boot process.
I really do not not know how to do it advice please?
Sent from my GT-P3100 using XDA Premium HD app
News update guy's. Chainfire pm'ed me saying that he will look into the matter. Now all we can do is cross our finger and wait.
Oh and also this download mode does not show +1 when I replaced CWM with stock recovery. I wonder why?
Sent from my GT-P3100 using XDA Premium HD app
UPDATE:
No warning when boot to stock JB XXCLI5 recovery:
Code:
g_nRebootReason = 0x2
set_lcd_panel_id: panel_adc=143
*** ltn070nl01_power_on ***
lcd_pannel_id=2
Autoboot (1 seconds) in progress, press any key to stop .
boot_kernel: debug level low!
checkbit: find RECOVERY
checkbit (f55f0aa0)
Kernel @ 81808000 (0x3f715c bytes)
Ramdisk @ 82800000 (0x135b4d bytes)
save param.blk, size: 5268
save param.blk successfully.
save switch_sel(1)...ok
Starting kernel at 0x81808000...
More investigation needed, when boot to unofficial recovery:
Code:
g_nRebootReason = 0x2
set_lcd_panel_id: panel_adc=143
*** ltn070nl01_power_on ***
lcd_pannel_id=2
Autoboot (1 seconds) in progress, press any key to stop .
boot_kernel: debug level low!
checkbit: find RECOVERY
checkbit (f55f0aa0)
Kernel @ 81808000 (0x39a7b0 bytes)
Ramdisk @ 82800000 (0x1e4fc6 bytes)
[WARNING] Current kernel is NOT official binary!!!
save param.blk, size: 5268
save param.blk successfully.
save switch_sel(1)...ok
Starting kernel at 0x81808000...
Normal boot to stock JB XXCLI5 kernel:
Code:
g_nRebootReason = 0x1
set_lcd_panel_id: panel_adc=142
*** ltn070nl01_power_on ***
lcd_pannel_id=2
Autoboot (1 seconds) in progress, press any key to stop .
boot_kernel: debug level low!
checkbit: find RECOVERY
checkbit (f55f0aa0)
Kernel @ 81808000 (0x3f715c bytes)
Ramdisk @ 82800000 (0x880aa bytes)
Starting kernel at 0x81808000...
Parsed above value from /proc/last_kmsg. From last_kmsg value (second boot loader message?), I can confirm my boot logo hack is safe. Sbl successfuly mount param.lfs:
Code:
loke_init: j4fs_open..success
<start_checksum:310>CHECKSUM_HEADER_SECTOR :42
<start_checksum:313>offset:42, size:1024
Not Need Movinand Checksum
load_lfs_parameters valid magic code and version.

[REF] GT-I9305 hardware hacking

Dear Hardware Hackers, Geeks and Modders,
it always takes some time for me to switch over to a "new" device
Recently i bought a GT-I9305 for cheap, to be more exactely bought two; a broken and a working one.
Anyway, as always i need to disassemble my toys, see what's inside and investigate how things work out on the hardware base.
To follow my descriptions and findings in this thread it is recommended to grab the service manual, e.g. at cpkb.org.
As usual there are already many technical threads covering some of the hardware issues.
It's time to put some light on the unknown details here.
Starting a few weeks ago there'd been some time for reverse engineering, study documents, read posts and draw some conclusions.
I hope you'll enjoy my discoveries and give some feedback.
It might take some time though to write down everything even more detailed and get it little bit structured to post it here.
SD-card mode or complete brick recovery by re-write internal bootloader:
The sboot bootloader is capable to start from external SD-card as well and detects the media it has been started from.
To re-write the bootloader in the internal eMMC, we need an external boot media and block the internal boot process at power up.
The SD-card needs a special structure with the sboot binary right in place.
There's already a detailed thread about this procedure (see the reference links below).
Anyway, as you might have read elsewhere, replacing KNOX bootloader with an older one will not work.
The first time a KNOX bootloader is installed on the device,
some hardware protected blocks on the eMMC become active to meet the requirements of the KNOX function.
This process could not be reverted by simply overwrite the sboot section.
We need other tools for this. This might be covered later.
Prevent booting from internal eMMC by blocking MMC_CMD:
GT-I9300:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R313
GT-I9305:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R634
Please refer to the service manual for the correct position of the components.
Bootloader recovery will need some proof of concept, to be 100% certain that it works in the same way, as it does on GT-I9300.
SD-card booting by changing the CPU boot mode (permanently):
The boot code is set at power up by reading the logic level at special IO pins (XOM6:0).
These logic levels are set by a bunch of resistors and could be tweaked.
The boot modes for Exynos 4412 known so far:
Code:
XOM[5:1] : 1st device : 2nd device
5b'00010 : SDMMC_CH2 : USB
5b'00011 : eMMC43_CH0 : USB
5b'00100 : eMMC44_CH4 : USB
5b'10011 : eMMC43_CH0 : SDMMC_CH2
5b'10100 : eMMC44_CH4 : SDMMC_CH2
GT-I9305 (default, might need some approval by reading the registers):
Code:
XOM[5:1]
5b'10100 : eMMC44_CH4 : SDMMC_CH2
XOM0 : R612 10K PU
XOM1 : R614 100K PD
XOM2 : R615 100K PD
XOM3 : R609 10K PU
XOM4 : R616 100K PD
XOM5 : R610 10K PU
XOM6 : R617 100K PD
GT-I9305 (SD-card boot mode, needs testing!!!):
Code:
XOM[5:1]
5b'00010 : SDMMC_CH2 : USB
XOM0 : R612 10K PU (no change here)
XOM1 : R614 100K PD (no change here)
XOM2 : R615 10K PU (changed from PD to PU)
XOM3 : R609 100K PD (changed from PU to PD)
XOM4 : R616 100K PD (no change here)
XOM5 : R610 100K PD (changed from PU to PD)
XOM6 : R617 100K PD (no change here)
This relationship had been partly reverse engineered and concluded from other designs.
May need some approval though.
Same here, external booting from SD-card will need some proof of concept, to be 100% certain that it works without flaws.
There's a uncertainty concerning standard sboot, to allow a complete boot into system level (e.g. recovery) using a non default boot mode.
Maybe the code is bound to the device (internal eMMC only) in some way, or external SD-card is not fully supported as boot media.
Anyway, it is straight forward to build up a SD-card for testing.
The kernel boot parameter and parts of recovery image will need some tweaks to use the right device to boot from.
Direct access to Exynos 4412 debug UART:
The debug UART is permanently accessible on connector HDC401 (no need to block the USB port for this feature).
AP_TXD : HCD401, pin 11 (LVTTL 1.8V)
AP_RXD : HCD401, pin 17 (LVTTL 1.8V)
Please refer to the service manual for the position of connector HCD401.
These signals are fully tested and working.
The best would be to get the counter part of Panasonic AXE620124AW1 for a direct connection,
but this parts seems tobe hard to find.
As an alternative you'll need some very fine soldering iron and some tiny wires.
This way you could solder the wires directly to the pins of the connector.
You'll need some 1.8V level converter (+ USB UART) as already to be found in many projects.
Set up your terminal to 8N1 at 115200Bit/s and there you go.
E.g. enter S-Boot command line by hitting enter at boot up:
Code:
PMIC rev = PASS2(4)
cardtype: 0x00000007
SB_MMC_HS_52MHZ_1_8V_3V_IO
mmc->card_caps: 0x00000311
mmc->host_caps: 0x00000311
mmc_initialize: mmc->capacity = 30777344
Samsung S-Boot 4.0-1153417 for GT-I9305 (May 29 2013 - 17:22:39)
EXYNOS4412(EVT 1.1) / 2047MB / 15028MB / Rev 2 / I9305XXBME3
initialize_ddi_data: usable! (0:0x0)
PARAM ENV VERSION: v1.0..
init_fuelgauge: fuelgauge power ok
get_battery_detect: battery is missed
init_fuelgauge: battery is not detected, vcell(3858), soc(59)
init_fuelgauge: POR status
fuelgauge_por: POR start: vcell(3858), vfocv(3871), soc(59)
fuelgauge_por: update SDI M0 parameter
fuelgauge_por: RCOMP(0x0063), TEMPCO(0x0930)
fuelgauge_por: POR finish: vcell(3856), vfocv(3901), soc(55)
get_table_soc: vcell(3855) is caculated to t-soc(62.486)
init_fuelgauge: start: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_fuelgauge: finish: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL2:0x3b
init_microusb_ic: MUIC: CONTROL2:0x3b
PMIC_ID = 0x02
PMIC_IRQSRC = 0x00
PMIC_STATUS1 = 0x10
PMIC_STATUS2 = 0x00
PMIC_PWRON = 0x02
PMIC_IRQ1 = 0x0c
PMIC_IRQ2 = 0x00
s5p_check_keypad: 0x0
s5p_check_reboot_mode: INFORM3 = 0 ... skip
s5p_check_upload: MAGIC(0xc0c0c0c0), RST_STAT(0x10000)
microusb_get_attached_device: STATUS1:0x38, 2:0x00
s5p_check_download: 0
microusb_get_attached_device: STATUS1:0x38, 2:0x00
check_pm_status: chargable jig, LPM boot
AST_CHARGING..
cmu_div:1, div:7, src_clk:800000000, pixel_clk:57153600
s6e8ax0_read_id :: retry: 1
s6e8ax0_read_id :: 0xd1
<start_checksum:373>CHECKSUM_HEADER_SECTOR :4096
<start_checksum:375>offset:50, size:6296
<start_checksum:379>CHECKSUM_HEADER_INFO : NeedChecksum:0 PartNo:20
Not Need Movinand Checksum
Movinand Checksum Confirmation Pass
autoboot aborted..
S-BOOT #
S-BOOT # help
Following commands are supported:
* chipinfo
* help
* log
* reset
* boot
* load_kernel
* printenv
* setenv
* saveenv
* findenv
* checksum_need
* usb
* upload
* keyread
* readadc
* usb_read
* usb_write
* sdcard
* mmcdtest
* fuelgauge
To get commands help, Type "help <command>"
S-BOOT #
That's it by now!
Consider this as a starter, i'll try to add, correct or change some things from time to time and i hope it's human readable
Please give me some feedback or tell me your thoughts
I will add pics as soon as possible and further details if there's some interest.
I will also give some credits soon, because some of these findings are based on information from the curious around here
Credits:
AdamOutler
E:V:A
References:
GT-I9300 hard-brick-fix
http://forum.xda-developers.com/galaxy-s3/general/galaxy-s-iii-gt-i9300-hard-brick-fix-t1916796
Totally Revolutionary SDCard Bootloader For Galaxy S III
http://forum.xda-developers.com/galaxy-s3/general/totally-revolutionary-sdcard-bootloader-t2061437
Port SDCard Recovery to Other Exynos4412 Devices
http://forum.xda-developers.com/showthread.php?p=34732948
Knox reset
http://forum.xda-developers.com/showthread.php?t=2504258
eMMC sudden death research
http://forum.xda-developers.com/showthread.php?t=2096045
NOTE:
I am not responsible for any damaged devices.
The technical information may need some verification by experiments!
It would be nice to add a remark and refer to this post, if you use the pics and information from this thread :highfive:
Cheers,
scholbert
technical info, datasheets... stuff
eMMC function, structure and usage
1. Basic info
The onboard eMMC is the mass storage of our device.
There's much more under the hood, than you might expect and notice during normal usage within the OS.
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
If you upgraded to JB/KK bootloder another part is setup up and configured:
RPMB (KNOX counter, etc.)
I found no information about the size, but it's a multiple of 128K and may be set up between 128-512K.
Once activated the information stored in this area is controlled by internal security mechanism of eMMC.
Only trusted code is granted access and even worse, from a users sight it acts like OTP memory.
To get some info about the eMMC built in your device the sysfs entries are a good place to start.
We could grep the type of device form here, e.g. the eMMC in my GT-I9305 gives this output:
Code:
# cd /sys/class/block/mmcblk0/device
# cat name
MAG4FB
# cat manfid
0x000015
# cut -b 19,20 cid
f7 // this is the firmware revision in hex
# cat date
09/2012
See the datasheet attached (this is the exact part)
2. EFI partition and GPT
The first block of USER area of starts with traditional MBR.
Next block starts with the header for the EFI partition which is the base container for all other parts.
Code:
[SIZE="2"]45 46 49 20 50 41 52 54 Signature "EFI PART"
00 00 01 00 GPT version 1.0
00 02 00 00 header size 512 Bytes
5B DF 6D 84 CRC32 of header
00 00 00 00 reserved
01 00 00 00 00 00 00 00 Current LBA (location of this header copy)
FF 9F D5 01 00 00 00 00 Backup LBA (location of the other header copy)
22 00 00 00 00 00 00 00 First usable LBA for partitions (primary partition table last LBA + 1)
DE 9F D5 01 00 00 00 00 Last usable LBA (secondary partition table first LBA - 1)
41 4E 44 52 4F 49 44 20 4D 4D 43 20 44 49 53 4B ANDROID MMC DISK
02 00 00 00 00 00 00 00 Starting LBA of array of partition entries (always 2 in primary copy)
80 00 00 00 Number of partition entries in array
80 00 00 00 Size of a single partition entry (usually 128)
28 53 B2 A4 CRC32 of partition array
00 00 00 00[/SIZE]
The rest of this block is the GPT.
Reference:
http://en.wikipedia.org/wiki/GUID_Partition_Table
Other useful reading:
http://forum.xda-developers.com/showpost.php?p=31254495
3. PIT
This is another essential part of the USER area of eMMC and defines all partitions used by the OS.
Here's the definition of the internal structure:
Code:
[SIZE="2"]typedef int __s32;
typedef unsigned int __u32;
#define PARTITION_MAGIC 0x12349876
typedef struct _partition_header {
__u32 dwMagic; /* MAGIC CODE */
__s32 nCount; /* PARTITION (OneNAND + MOVINAND) */
/* PIT Option. */
__s32 dummy[5];
} __attribute__((packed)) partition_header;
typedef struct _partition_info {
__s32 nBinType; /* BINARY_TYPE_ (AP or CP?) */
__s32 nDevType; /* PARTITION_DEV_TYPE_ */
__s32 nID; /* PARTITION ID */
__s32 nAttribute; /* PARTITION_ATTR_ */
__s32 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
__u32 dwBlkSize; /* BLOCK SIZE / OFFSET IN BLOCKS */
__u32 dwBlkLen; /* BLOCK LENGTH */
__u32 dwOffset; /* FILE OFFSET (obsolete) */
__u32 dwFileSize; /* FILE SIZE (obsolete) */
char szName[32]; /* PARTITION NAME */
char szFileName[32]; /* FILE NAME */
char szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
} __attribute__((packed)) partition_info;[/SIZE]
Example:
Code:
[SIZE="2"]BOOTLOADER:
00 00 00 00 nBinType; /* BINARY_TYPE_ (AP or CP?) */
02 00 00 00 nDevType; /* PARTITION_DEV_TYPE_ */
50 00 00 00 nID; /* PARTITION ID */
02 00 00 00 nAttribute; /* PARTITION_ATTR_ */
01 00 00 00 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
00 00 00 00 dwBlkSize; /* BLOCK SIZE / BLOCK OFFSET */
C6 06 00 00 dwBlkLen; /* BLOCK LENGTH */
00 00 00 00 dwOffset; /* FILE OFFSET (in TAR) */
00 00 00 00 dwFileSize; /* FILE SIZE */
szName[32]; /* PARTITION NAME */
42 4F 4F 54 4C 4F 41 44 45 52 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szFileName[32]; /* FILE NAME */
73 62 6F 6F 74 2E 62 69 6E 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[/SIZE]
4. Complete partition table (GT-I9305)
Code:
[SIZE="2"]Block Size = 0x200
BOOT AREA:
Partition Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
BOOTLOADER sboot.bin 0x00000000 0x06C6 0x000D8C00 0x50 0x50
TZSW tz.img 0x000D8C00 0x0138 0x00027000 0x51 0x51
DDI-DATA (DATA) - 0x000FFC00 0x0001 0x00000200
USER AREA:
Partition Name Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
eMMC MBR (MBR) - 0x00000000 0x0001 0x00000200
EFI PART (GPT) - 0x00000200 0x0001 0x00000200
PIT m3.pit 0x00004400 0x0010 0x00002000 0x46 0x46
MD5HDR md5.img 0x00006400 0x0800 0x00100000 0x47 0x47
BOTA0 - 0x00400000 0x2000 0x00400000 0p1 0x01
BOTA1 - 0x00800000 0x2000 0x00400000 0p2 0x02
EFS efs.img 0x00C00000 0xA000 0x01400000 0p3 0x03
m9kefs1 m9kefs1.bin 0x02000000 0x2000 0x00400000 0p4 0x04
m9kefs2 m9kefs2.bin 0x02400000 0x2000 0x00400000 0p5 0x05
m9kefs3 m9kefs3.bin 0x02800000 0x2000 0x00400000 0p6 0x06
PARAM param.bin 0x02C00000 0x4000 0x00800000 0p7 0x07
BOOT boot.img 0x03400000 0x4000 0x00800000 0p8 0x08
RECOVERY recovery.img 0x03C00000 0x4000 0x00800000 0p9 0x09
RADIO modem.bin 0x04400000 0x2c000 0x05800000 0p10 0x0A
TOMBTONES tombstones.img 0x09C00000 0x80000 0x10000000 0p11 0x0B
CACHE cache.img 0x19C00000 0x200000 0x40000000 0p12 0x0C
SYSTEM system.img 0x59C00000 0x300000 0x60000000 0p13 0x0D
HIDDEN hidden.img 0xB9C00000 0x118000 0x23000000 0p14 0x0E
OTA - 0xDCC00000 0x4000 0x00800000 0p15 0x0F
USERDATA userdata.img 0xDD400000 0x0000 0p16 0x10
[/SIZE]
5. DDI-DATA
In the hidden boot0 partition the values like the flash count are stored.
Triangle away is able to modify this data.
It's stored at 0x000FFC00 on the boot0 partition of emmc.
Code:
struct ddi_data {
int magic; // must be 0x12340012
int custom_flash_count;
int odin_count;
int binary_type; // 0 = samsung official, 1 = custom, 2 = "Unknown"
char model_name[16];
int rom_type; // this is the first 4 bytes of the decrypted 16 bytes
in the param partition. 0xFF000000 = samsung, 0xEE000000 = custom }
For details please refer to this post:
http://forum.xda-developers.com/showthread.php?p=28953690#post28953690
Further useful reading:
http://wiki.cyanogenmod.org/w/EMMC_Bugs
Thesis:
Remove KNOX bit by eMMC low level format command:
With KNOX activation at booloader level, there's an area which stores the KNOX bit information called RPMB.
During research of the eMMC sudden death, some firmware files for the eMMC controller had been reverse engineered and some of the custom commands had been discovered.
Read this and follow ups:
http://forum.xda-developers.com/showpost.php?p=49548099&postcount=121
By changing the boot mode and boot up completely from SD-card into special recovery, it might be possible to send this command with a tool called mmc-utils:
https://github.com/BenGardiner/mmc-utils
Because this will wipe out everything, it would be a great adventure and you'll need a proper backup of all significant parts from the internal eMMC. Otherwise device specific parameters will be lost forever.
See this remark as a reference as well:
http://forum.xda-developers.com/showpost.php?p=51297844&postcount=135
I'll spent some time to think about a useful SD-card layout... :laugh:
TBC
scholbert
All this looks knowledgeable
How are you at ROM/Kernel building?
Hi f0xy!
f0xy said:
All this looks knowledgeable
Click to expand...
Click to collapse
Thanks for this feedback!
I know these experiments are only for the fearless with good eyes.
For the average user there's no need to hack boot mode or stuff, unless there's some evil bricked device
I guess folks need pix
f0xy said:
How are you at ROM/Kernel building?
Click to expand...
Click to collapse
Depends...
On a hobbyist level i build many kernels, tweaked drivers and kernel code for personal use over the years.
Little less if we speak about building ROMs.
I might help out on some issues, but don't count on me for bigger projects.
Time is always lacking and often i'm too lazy to clean up the code for git
Cheers,
scholbert
Hi,
just added the complete partition table for GT-I9305 and some other stuff in the second post...
I try to sum up facts floating around as well and put it in the context of GT-I9305, so some info here is no breaking news
Anyway, enjoy the tech ride!
Regards,
scholbert
@mad_ady I seen your post in boeffla, some info here may be of help? Or maybe the @op can provide some help for you?
Regards
Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?
Hi mad_ady!
mad_ady said:
Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?
Click to expand...
Click to collapse
Yeah i guess other devices with onboard eMMC use GPT tables as well.
Though it is not completely clear at which level these are accessed.
I assume that the bootloader or even kernel is able to read this table during start up and is also aware of the sizes and boundaries.
The PIT table plays another role in this game.
AFAIK this is the reference for Odin/Heimdall and should match GPT boundaries.
Some experts are needed to confirm this or i'll have to dig a little deeper myself
Regards,
scholbert
Hi there,
i made a comparison between the cmdline passed to the kernel by "old" and "new" bootloaders.
Just started some investigation to fix "offline charging" with KK stock running on devices which still got the old bootloader.
Here's the default cmdline "old" vs. "new":
Code:
[SIZE="2"]JB 4.1.2 (I9305XXBME3) KK 4.4.4 (I9305XXUFNJ1)
console=ram console=ram
loglevel=4 loglevel=4
androidboot.baseband=mdm androidboot.baseband=mdm
sec_debug.level=0 sec_debug.level=0
sec_watchdog.sec_pet=5 sec_watchdog.sec_pet=5
androidboot.debug_level=0x4f4c androidboot.debug_level=0x4f4c
[email protected] [email protected]
- [email protected]
- [email protected]
s3cfb.bootloaderfb=0x5ec00000 s3cfb.bootloaderfb=0x5ec00000
lcdtype=96 lcdtype=96
consoleblank=0 consoleblank=0
lpcharge=0 -
lpj=3981312 lpj=3981312
vmalloc=144m vmalloc=176m
oops=panic oops=panic
pmic_info=67 pmic_info=67
cordon=<32-Byte hash value> cordon=<32-Byte hash value>
- connie=GT-I9305_OPEN_EUR_<32-Byte hash value>
androidboot.emmc_checksum=3 androidboot.emmc_checksum=3
- androidboot.boot_salescode=
- androidboot.odin_download=1
androidboot.bootloader=I9305XXBME3 androidboot.bootloader=I9305XXUFNJ1
- androidboot.selinux=enforcing
- androidboot.warranty_bit=1
- androidboot.sec_atd.tty=/dev/ttySAC2
androidboot.serialno=<16-Byte serial> androidboot.serialno=<16-Byte serial>
snd_soc_core.pmdown_time=1000 snd_soc_core.pmdown_time=1000[/SIZE]
As you might see there's the keyword lpcharge, which is not present on the "new" bootloaders.
On the new bootloaders there's the additional parameter android.bootmode=charger, if you start up with a charger plugged in.
On KK stock some proprietary binaries identify this keyword to activate offline charging.
Some kernel drivers (battery) react to this string as well and there's a patch already.
There'd been some attempts to fix this in initial ramdisk by hi-jacking cmdline present in /proc/cmdline and replace lpcharge=1 with android.bootmode=charger .
My first idea was, to make use of a similar function at kernel level and append android.bootmode=charger to the "old" bootloader cmdline, if lpcharge is set to 1 (similar to a conditional CONFIG_CMDLINE_EXTEND function).
The kernel itself will put this in /proc/cmdline afterwards and user space tools will be satisfied.
Some years ago i tweaked some kernel code for Archos tablets, which made use of custom ATAG keys to hand over some device specific parameters. Maybe i'll get something out of it
For my personal reference:
http://forum.xda-developers.com/galaxy-tab-3/general/kitkat-t31x-t2892792/post55863790#post55863790
TBC
Cheers,
scholbert
Hello.
Thanx for your Thread. For some summary about I9300 and I9305.
:good:
Please I need some input for my low brain...
I'm playing with I9300 and Tizen RD-PQ stuff...
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Thanx for every input.
Best Regards
The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n
Hi!
adfree said:
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
Click to expand...
Click to collapse
See mad_ady's comment:
mad_ady said:
The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n
Click to expand...
Click to collapse
From kernel level it is only possible to dump user area (unless you use a specific kernel with mmcblk0boot0 and mmcblk0boot1 enabled).
Read again this quote form my second post:
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
Click to expand...
Click to collapse
adfree said:
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
Click to expand...
Click to collapse
Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
adfree said:
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Click to expand...
Click to collapse
Nope... it's at the very start of eMMC in a seperate area, normally hidden from user (see my comments above).
See datasheet attached, maybe this helps to understand how eMMC works.
EDIT:
Found the exact part which is soldered on my GT-I9305 mainboard.
See second post for reference as well:
http://forum.xda-developers.com/showpost.php?p=56747098&postcount=2
I'll leave this older datasheet her as well... this is at least a similar part.
Good luck and best regards,
scholbert
Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
Click to expand...
Click to collapse
I have problems to check my progress... because broken/damaged Display...
I see only black...
In Android I can use ADB stuff to see something...
Writing 32 MB RD-PQ dump not kill I9300... (no idea if this could kill IMEI, EFS or other Security stuff)
But I can't see where it hangs or if something is on Display...
Writing only s-boot-mmc.bin (200 KB sboot) from RD-PQ...
I have no idea yet, how to check if really written or ignored by I9300 sboot...
Code:
getprop ro.bootloader
Gives no anwser...
And this feature looks like Kernel related stuff...
Example why I am unsure if 200 KB sboot is accepted...
In I9300 you can find easily string ODIN in sboot...
But in RD-PQ is no ODIN text string... then why my I9300 works without problems with Odin...
I need some time to buy cheap working Display...
So I can see "visual effects" on Display...
1 goal would be this:
SDCARD MODE
COPY BINARY FROm SDCARD..
COPY BINARY TO EMMC..
SDCARD DOWNLOAD COMPLETED.
Click to expand...
Click to collapse
In Tizen world it seems mandatory to restore uboot... it contain the THOR string for THOR Downloader...
https://lists.tizen.org/pipermail/general/2013-November/002707.html
For me it is not clear enough... if RD-PQ sboot loads uboot...
sboot AND uboot is executed...
OR it is or feature...
Only uboot could be enough to executed...
About dump mmcblk0...
Code:
dd if=/dev/block/mmcblk0 skip=0 count=10000000 of=/sdcard/dump_v1.bin
dd if=/dev/block/mmcblk0 skip=10000000 count=10000000 of=/sdcard/dump_v2.bin
dd if=/dev/block/mmcblk0 skip=20000000 of=/sdcard/dump_v3.bin
This seems to work... but last 1 is again 11 GB + big...
It starts after with beginning...
I need proper count value... need some time and calculator...
I hope next week I have working Display for my testdevice...
Best Regards
eMMC hacking.... SD card boot... remove KNOX bootloader... finally?
Hi again,
i'd like to refer to a software package which seems to have leaked from a service center or similar some time ago.
Please refer to this thread, which explains how to revive hard bricked S3 devices and other Exynos devices:
http://forum.xda-developers.com/galaxy-s3/general/samsung-s3-i9300-note2-n7100-i9500-s4-t2647558
I found this package at several other places in the web as well, and it might be useful for some smart experiments :angel:
Here's what i got from it...
S3 repair contains a test suite for low level tests and tasks to setup up S3 from scratch.
You'll have to prepare a MicroSD card with a low-level tool (similar to dd command in linux).
The write script gives an idea about the offsets used on the SD card (multiples of 512 bytes), so i translated those to hex values:
emmc_auto.sbl.bin:1:499OFF: 0x00000200 LEN: 0x0003e600
E4412_S.TN.bl1.bin:9500:16OFF: 0x004a3800 LEN: 0x00002000
S5E4412_asb.bin:20000:40000OFF: 0x009c4000 LEN: 0x01388000
asb.ramfs:80000:97000OFF: 0x02710000 LEN: 0x02f5d000
From what i got by investigating the hex data of these binaries, the functions should be:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- S5E4412_asb.bin -> a standalone tool and testsuite compiled as a ready to run binary (no elf format here!)
- asb.ramfs -> a proprietary RMFS formatted ramdisk which carries some test files (e.g. test pattern, test videos, etc.)
A quite interesting piece of code is the S5E4412_asb.bin file.
So grepping some strings in this binary file gave this section, which is responsible for
vendor boot size change with CMD62 (refer to the eMMC datasheet as well) and seems to restore the bootloaders:
Code:
0x093DB6 0x2B APP STEP] Step 1. BL Download Address Set
0x093DE6 0x2D APP STEP] Step 2. DRAM Download Address Set
0x0943CA 0x0A NA,\NA0\NA
0x0943D6 0x0A NA$\NA(\NA
0x0943FE 0x2D APP STEP] CMD 0xEFAC62EC : RESPONSE 0x%08x %
0x094432 0x2B APP STEP] CMD 0xCBAEA7 : RESPONSE 0x%08x %
0x094462 0x32 APP STEP] Boot Partition Size : RESPONSE 0x%08x %
0x09449A 0x32 APP STEP] RPMB Partition Size : RESPONSE 0x%08x %
0x09472A 0x24 APP STEP] CMD 6 : RESPONSE 0x%08x %
0x094756 0x2B APP STEP] BL1 & BL2 loading Address : 0x%x
0x094786 0x2C APP STEP] Dram Image loading Address : 0x%x
0x0947B6 0x34 APP STEP] BL1 & BL2 compare address for Read : 0x%x
0x0947EE 0x35 APP STEP] Dram Image compare address for Read : 0x%x
As user Oranav pointed out in the eMMC sudden death research thread, there might be commands
which should initiate low level formatting of the eMMC chip:
CMD62 (ARG: 0xEFAC62EC)
CMD62 (ARG: 0xFAC0021)
This might probably delete all the chip metadata (incl. wear leveling state and bad block info)
and if these commands are correct, it will also reset KNOX counters and stuff.
In other words this is a full factory wipe of eMMC cells.
These are some snippets in S5E4412_ASB.bin located at:
0x8A41C0:
Code:
A5 A2 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
71 1F 04 00
AB C2 9E FF
5A 7B B6 F0
83 68 AE 0F
CD 12 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
1D 28 04 00
...and again at:
0x8C43F0
Code:
2D A2 04 00
CD A4 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
AB C2 9E FF
5A 7B B6 F0
9F 1B 04 00
83 68 AE 0F
47 0F 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
This could be some approval for the usage of these commands at least, because these sections are pure ARM assembly and seem to be associated with eMMC low level setup.
I'll have to find out some offsets for this machine code to try a disassembly.
Maybe this will lighten things up even more.
EDIT:
BTW, found one of the main return addresses which is at 0x40008000 (physical address at the beginning of DRAM). Let's see if this is correct.
EDIT2:
Bingo... just had a look in my boot logs i once grepped during UART session:
Starting kernel at 0x40008000...
Conclusion:
The ASB test suite (S5E4412_asb.bin) is booted/started at the same offset as the linux kernel does.
Let's see what this may give us
Another thing to mention is, that included in S5E4412_asb.bin there's a M0 test bootloader (GT-I9300).
Have a look at offset 0x08d8fe8 inside the binary
So in the end i wonder, if someone has ever used this "Service" card together with a real UART connection to the board.
Apart from the automated test and setup process, my guess is, that there should be some command line or some kind of a test menu which may give alternative choices to proceed certain tasks.
P.S.: Maybe it's hard to understand what i like to point out here... but imagine we use the following:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- recovery.img -> kernel + recovery to start completely from SD card (eMMC not touched here!!!)
P.P.S: Let's see if the SD card boot files look for a signature here.....
Stay tuned!
scholbert
... further experiments
Hi,
i made further progress with my attempts to boot my GT-I9305 completely from external MicroSD.
As proposed in my last post i prepared a card with the following commands:
Code:
echo "Exynos4412 FWBL1+BL2"
dd if=./emmc_auto.sbl.bin of=/dev/sda bs=512 seek=1
echo "Exynos4412 TZSW"
dd if=./E4412_S.TN.bl1.bin of=/dev/sda bs=512 seek=9500
Next is to prepare the board.
You'll need Anyway JIG or a dedicated UART connection as described in my first post.
To block access to internal eMMC the resistor R634 on the GT-I9305 mainboard got shorted.
Insert the MicroSD with the proprietary boot files into the socket.
Connect to a terminal and attach supply voltage of 3.8-4.0V to the battery connector.
Press the power button and hold it.
Here's the output so far:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422650 usec
<OK>
Inp32(uAddr) : 0x0
LINUX Bootingøq!ñ¥¡Õ
At this point there are no further outputs, as there's nothing to be executed.
Like known from the sboot, hitting enter on your terminal from the very beginning gives a commandline interface.
Unfortunately, it seems that the watchdog is not stopped at this point and maybe the PMIC is not fully initialized.
This leads to repeated resets.
Anyway if you're fast enough, you may get this command list from the proprietary bootloader:
Code:
BL>help
CMD LIST
LOG
WAIT
USB
GET
JUMP
RUN
RUN2
INIT
INIT2
DMC
CLK
DVFS
ASV
DVFSQA
EMA
PMIC
SD
EMMC
ZIP
ABB
RESET
DUMP
MEMCPY
MEMCMP
MEMSET
OUTP32
INP32
SETBITS
GETBITS
COPYRUN
MEMCPY_RUN
PATTERN
BOOT
CTA
ASB
COM
HELP
H
TEST
TN
<OK>
BL>
Some of these commands play an important role for starting up the ASB test suite if present.
These command are included in BL2 and they seem to be interpreted by ASB:
Code:
TN M0|PMIC
INIT2 3|init2|TEST
EMMC
0x10020800 1|TEST RUN
I started to mod these, but as far as i did not start the ASB image yet there's nothing to observe.
By looking at other logs from brick recoveries, i found a relationship between the first output of ASB and these commands.
My idea is that by changing these we could influence the behaviour of the ASB code for educational purpose.
As described above, without parts of ASB the PMIC seems not to be fully initialized,
because i found out that you need to hold the power button to keep the board alive.
This is little strange, as i am pretty sure that this was not the case in the begining, but maybe i'm wrong.
Anyway as far as i observed it, the board starts normally from internal eMMC after my experiments had finished.
At least nothing indicates that something got damaged...
Just to check out what happens i put a raw recovery image at position 20000 (0x9c4000) on the card.
This is the beginning of kernel code.
Afterwards i started a new terminal session and i saw that the first command of kernel code got printed,
but unfortunately after the bootcode jumps to this code there's no further output.
Something is still missing.
Could be something obvious (e.g. missing TAGS at 0x40000100) or could be not.
Maybe it would be a good idea to compile a version of u-boot and try again.
Let's see
scholbert
....grrrr
Hi again!
First of all, nice to see that at least two guys follow my binary surgery.
Second, i must admit that the platform is not that responsive as i first thought.
Due to all this signing stuff, it is easy to break something and CPU simply stops executing code.
So for now there's nothing, than further logging outputs from the console.
1. I removed some of the start up commands from BL2, which leaves TN M0|PMIC & INIT2 3|init2|TEST for ASB code.
This is what i got then:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[CHIPID] E4412 EVT1.1
LOTID WNO X Y IDS HPM ASV_GRP FUSE SHIFT
[LOG]N571A 18 201 195 22 22 8 -1 100000 80
There's no auto booting anymore at this point.
2. I put anything back, apart from the RUN command.
During this test i used a modified ASB binary with sboot from I9305XXALI4 put in the right place.
Unfortunately the output stops after "FW Booting"
The device kept being powered though. Which is a good thing from my guess.
Here's the log:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422818 usec
<OK>
Inp32(uAddr) : 0xea00007e
FW Booting
Right now it's a bit to early for further conclusions, but maybe the signing stuff got broken at some point in both cases.
It could also be that some of the signatures is especially for GT-I9300, or in other words the CPU on GT-I9305 uses a different key set.
That's it by now, but i won't give up yet
Cheers,
scholbert
Wow, that's one of the most insightful threads about 4412 I've seen for a while.
Replying here on OP's PM for further reference:
* At LenovoK860 uboot sources:
These seem to contain private keys for some batch of 4412 - that's the first time I see private signing keys of any Exynos to leak. Previous leaks were just wild security-dropping bootloader stages signed with private keys, but no keys included.
These keys can either match batch customized for Lenovo or match all 4412 (Exynos4 public key hash fuses, in theory, meant to be factory/OEM customizable) - I'd say the latter since neither GS3 or any common device built on S5PC2xx I've seen was expected to have any grade of real security, so probably neither Lenovo or Samsung cared to customize any of Exynoses used around.
There is a way to check it by comparing dumps from 0x10100000 area between GS3 and LenovoK860 CPUs (I'm uncertain, as I'm really rusty). Probably there's also other way by comparing Lenovo stage1 public keys with GS3 0x1010_0000 dumps, considering how pubkey is validated against these bits (no idea, don't remember).
* At My and Adam's tries:
We were quite succesfull in running UBoot on I9300 and GalaxyCam GC100.
What we couldn't achieve was kernel booting - Exynos4 kernels require TZSW to be fully operating and communicating with it. I couldn't get it to load up properly.
There's quite of history of our tries under https://github.com/Rebell/exynos4_uboot/commits/master
Another option is, of course, disabling TZSW support in kernel and not booting it at all - it doesn't seem to work out-of-the-box either, and would make impossible to boot any non-modded kernels.
AFAIR (and boy, was it while ago), referenced sources were building and fusing to the SD card flawelessly and supporting both fastboot and UART terminal with most (all?) of the commands working (yes, it can do raw R/W to eMMC and whatnot in SVC mode without TrustZone supervisor interfering, because it's not loaded at all yet). Just kernel wouldn't boot. I'd say you should give it a try (if you didn't already).
The crucial part we used there was FWBL1 (there https://github.com/Rebell/exynos4_uboot/tree/master/sd_fuse) - first, already signed, stage of bootloader hat's doing nothing but loading another stage of bootloader without any security (kudos to Odroid).
We couldn't find any equivalent of signed FWBL1 for Exynos4210 (GS2 CPU) that would allow us booting eMMC hardbricked GS2 devices.
* At ASB:
First time I hear of it. Never seen this stuff before.
... just an update
Hi,
it's been a while now that i found some time to fiddle around with one of my i9305 mainboards.
In the meantime there'd been some nice conversation via PM with Rebellos as well.
u-boot on Galaxy S3
Find the sources here:
https://github.com/Rebell/exynos4_uboot
So i finally gave it a try, jumped on his work and compiled a version of u-boot for Galaxy S3 devices.
As a prerequisite you'll have to block eMMC and to make it short...
It just works!!!
Attached you'll find a log from external sdcard boot.
Maybe i'll do some tweaks in the near future, e.g. remove the annoying "pmic_s5m8767_init" messages,
as there is no such device on our S3.
s-boot for Tizen on Galaxy S3
On the Tizen Wiki (https://wiki.tizen.org/wiki/Flash_Tizen_2.2.1_Image_to_Reference_Device)
there's a link to a tar with image files (Tizen_RD-PQ_System_20131107_1.tar), which contains a s-boot file.
Unfortunately the signature of BL1 inside the s-boot image seems not fit the mass production units.
In other words no boot message here at all... at least while trying to boot from sdcard.
mass production sboot on external SD-card
On the other hand the mass production units sboot images are ready to boot from sdcard as well.
Find the second log attached below.
The error messages are normal, because i blocked eMMC all the time, to prevent bricking during my experiments.
security key validation
As you'll see in the logs i dumped the region at 0x10100000 for the security key values.
Here's a snippet of the secure boot function header in the u-boot sources:
Code:
#define MAX_EFUSE_DATA_LEN 16
typedef struct
{
unsigned char rsa_n[128]; /* RSA Modulus N */
unsigned char rsa_e[4]; /* RSA Public Exponent E */
} RawRSAPublicKey;
typedef struct
{
RawRSAPublicKey rsaPubKey; /* RSA PublicKey */
unsigned char signedData[20]; /* HMAC Value of RSA PublicKey */
} PubKeyInfo;
/* Secure Boot Context */
typedef struct
{
RawRSAPublicKey stage2PubKey; /* Stage2 RSA Public Key */
unsigned char code_SignedData[128]; /* RSA Signature Value */
PubKeyInfo pubKeyInfo; /* Stage1 RSA PublicKey and it's HMAC value */
unsigned char func_ptr_BaseAddr[48]; /* Function pointer of iROM's secure boot function */
unsigned char test_eFuse[MAX_EFUSE_DATA_LEN];
unsigned char reservedData[36];
} SecureBoot_CTX;
If i assume S3 still uses V1.1 security with 1024Bit RSA (BL1.bin is 8192Byte) the efuse key would be 128Bit, which results in 4 registers with 32Bit length.
Exported to a hex dat file this is 16Byte of Hex data.
Dump at 0x10100000 gives:
Code:
10100000: 0d19a391 2a0502af 1576987a 212121bc .......*z.v..!!!
We'll have to re-arrange the bytes for little endian order:
Code:
91a3190d af02052a 7a987615 bc212121
... use a hex-editor and put these into a file named: eFuseData.dat
Next i took codesigner_v21 and tried to validate stock BL1 files if they match.
codesigner_v21 -v1.1 <BL1.bin> <eFuseData.dat> -VERIFY
Unfortunately no succes yet... signature verification always failed.
This is a mistery, because the position of the key should be correct and i used valid bootloader files as well.
Anyway this had been only a proof of concept if we got the right tool and the right efuse values.
TBC
Cheers,
scholbert
@scholbert
Please, need collection of GT-I9305 Bootloader....
Something like this:
http://forum.xda-developers.com/galaxy-s3/general/guide-extract-bootloader-make-flashable-t2864264
http://forum.xda-developers.com/galaxy-s3/general/ref-galaxy-s3-stock-kernel-bootloaders-t2189063
For now I was only able to find
RESTORE_BOOTLOADER_I9305XXALI4.zip
http://forum.xda-developers.com/showpost.php?p=32760677&postcount=1
I need few more for stupid tests.
For now my test GT-I9300 PCB is able to start this sboot.bin from GT-I9305... with tweezer.
sboot.bin is copied successfully... but not start in "normal mode"...
Here I can see other method... sboot.bin is not copied to eMMC but fully executed from eMMC, with Boot menu:
http://forum.xda-developers.com/showpost.php?p=64664423&postcount=278
I will check if GT-I9305 has similar Bootloader and if it will executed on my GT-I9300 test PCBs.
Thanx in advance.
Best Regards
I found this:
I9305XXUFNL1-DBT.zip
Here is sboot.bin from GT-I9305 inside... I have attached.
Search for text String THOR... you can find:
Code:
- Thor is connected!
This could mean... I9305 is Tizen enebled... not only this...
Chance to play with U-Boot.
Tried on I9300 with no luck...
Volume + or Volume - do nothing... maybe Hardware Keys different...
I hope to find something working for my I9300...
Btw.
First time I saw THOR string also in Note 4 N910C:
http://forum.xda-developers.com/showpost.php?p=64663039&postcount=65
Best Regards

[GUIDE] Build AOSP for zerofltexx by Astrubale

DELETED
but there is some aosp build usable ( incall micro working on fine ) for galaxy s 6?
thanks for the guide Master
supera3 said:
but there is some aosp build usable ( incall micro working on fine ) for galaxy s 6?
thanks for the guide Master
Click to expand...
Click to collapse
Depend on what source zero-common, zerofltexx and kernel are based.
Very cool guide, I'll have to give this a shot later just for fun! Sorry for doubting you before.
If there are new commits, before ". build/envsetup.sh" tipe "repo sync" for upgrade.
Hi @Astrubale,
I tried to build cm-13.0 with your tutorial, but build fails non-stop on:
Code:
target SharedLib: libexpat (/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libexpat_intermediates/LINKED/libexpat.so)
/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libexpat_intermediates/lib/xmlparse.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
build/core/shared_library_internal.mk:80: recipe for target '/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libexpat_intermediates/LINKED/libexpat.so' failed
make: *** [/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libexpat_intermediates/LINKED/libexpat.so] Error 1
make: *** Waiting for unfinished jobs....
make[3]: Nothing to be done for 'dtbs'.
or
Code:
/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libcrypto_intermediates/android_compat_hacks.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
build/core/shared_library_internal.mk:80: recipe for target '/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libcrypto_intermediates/LINKED/libcrypto.so' failed
make: *** [/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libcrypto_intermediates/LINKED/libcrypto.so] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory '/home/sebek/android/system'
The solution is to remove xmlparse.o or android_compat_hacks.o and I guess it continues the build. Almost at the end of compilation (I presume) it throws out that very error and after a while I get:
Code:
/home/sebek/android/system/kernel/samsung/exynos7420/scripts/Makefile.fwinst:45: target '/lib/firmware/tsp_stm/stm_z1.fw' given more than once in the same rule
/home/sebek/android/system/kernel/samsung/exynos7420/scripts/Makefile.fwinst:45: target '/lib/firmware/abov/abov_valley.fw' given more than once in the same rule
make[1]: Leaving directory '/home/sebek/android/system/kernel/samsung/exynos7420'
make[1]: Entering directory '/home/sebek/android/system/kernel/samsung/exynos7420'
INSTALL net/ipv4/tcp_htcp.ko
INSTALL net/ipv4/tcp_westwood.ko
/home/sebek/android/system/kernel/samsung/exynos7420/scripts/Makefile.fwinst:45: target '../../system/lib/firmware/tsp_stm/stm_z1.fw' given more than once in the same rule
/home/sebek/android/system/kernel/samsung/exynos7420/scripts/Makefile.fwinst:45: target '../../system/lib/firmware/abov/abov_valley.fw' given more than once in the same rule
DEPMOD 3.10.61
make[1]: Leaving directory '/home/sebek/android/system/kernel/samsung/exynos7420'
make: Leaving directory '/home/sebek/android/system'
#### make failed to build some targets (26:29 (mm:ss)) ####
Maybe you'd be willing to give me some advice on how I could finish this build ? I am building on Ubuntu 16.04, dl'd the newest kernel from Brandon's git repo.
My best
djseban2 said:
Hi @Astrubale,
I tried to build cm-13.0 with your tutorial, but build fails non-stop on:
Code:
target SharedLib: libexpat (/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libexpat_intermediates/LINKED/libexpat.so)
/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libexpat_intermediates/lib/xmlparse.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
build/core/shared_library_internal.mk:80: recipe for target '/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libexpat_intermediates/LINKED/libexpat.so' failed
make: *** [/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libexpat_intermediates/LINKED/libexpat.so] Error 1
make: *** Waiting for unfinished jobs....
make[3]: Nothing to be done for 'dtbs'.
or
Code:
/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libcrypto_intermediates/android_compat_hacks.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
build/core/shared_library_internal.mk:80: recipe for target '/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libcrypto_intermediates/LINKED/libcrypto.so' failed
make: *** [/home/sebek/android/system/out/target/product/zerofltexx/obj/SHARED_LIBRARIES/libcrypto_intermediates/LINKED/libcrypto.so] Error 1
make: *** Waiting for unfinished jobs....
make: Leaving directory '/home/sebek/android/system'
The solution is to remove xmlparse.o or android_compat_hacks.o and I guess it continues the build. Almost at the end of compilation (I presume) it throws out that very error and after a while I get:
Code:
/home/sebek/android/system/kernel/samsung/exynos7420/scripts/Makefile.fwinst:45: target '/lib/firmware/tsp_stm/stm_z1.fw' given more than once in the same rule
/home/sebek/android/system/kernel/samsung/exynos7420/scripts/Makefile.fwinst:45: target '/lib/firmware/abov/abov_valley.fw' given more than once in the same rule
make[1]: Leaving directory '/home/sebek/android/system/kernel/samsung/exynos7420'
make[1]: Entering directory '/home/sebek/android/system/kernel/samsung/exynos7420'
INSTALL net/ipv4/tcp_htcp.ko
INSTALL net/ipv4/tcp_westwood.ko
/home/sebek/android/system/kernel/samsung/exynos7420/scripts/Makefile.fwinst:45: target '../../system/lib/firmware/tsp_stm/stm_z1.fw' given more than once in the same rule
/home/sebek/android/system/kernel/samsung/exynos7420/scripts/Makefile.fwinst:45: target '../../system/lib/firmware/abov/abov_valley.fw' given more than once in the same rule
DEPMOD 3.10.61
make[1]: Leaving directory '/home/sebek/android/system/kernel/samsung/exynos7420'
make: Leaving directory '/home/sebek/android/system'
#### make failed to build some targets (26:29 (mm:ss)) ####
Maybe you'd be willing to give me some advice on how I could finish this build ? I am building on Ubuntu 16.04, dl'd the newest kernel from Brandon's git repo.
My best
Click to expand...
Click to collapse
Can you send me a screen of /android/system/kernel/samsung/exynos7420/ ?
Astrubale said:
Can you send me a screen of /android/system/kernel/samsung/exynos7420/ ?
Click to expand...
Click to collapse
Sure, it looks like this:
hxxp://imgur.com/M5sAjIo
@edit: I deleted exynos7420 dir and unzipped it (dl'd zip from github) once again, this time through Terminal. Turned out it was something wrong with that, therefore I succeded with building the ROM, but my S6 hangs on "Kernel is not seandroid enforcing", after flashing the ROM (tough luck, I guess). What's more I tried flahyboy's ROM, to see if it's maybe something wrong with my S6 - well, you can say flahyboy's ROM starts instantly, but in-call mic is not working. I'd be grateful for any hints on what might be wrong. One and only thing I noticed is flahyboy's ROM is slightly greater in size (~40MB) that mine.. maybe the build solution did not add something to my zip.. Anyway - great tutorial, thanks for that. Installing AOSP just made me even more anxious to wait for making this system stable :good:
djseban2 said:
Sure, it looks like this:
hxxp://imgur.com/M5sAjIo
@edit: I deleted exynos7420 dir and unzipped it (dl'd zip from github) once again, this time through Terminal. Turned out it was something wrong with that, therefore I succeded with building the ROM, but my S6 hangs on "Kernel is not seandroid enforcing", after flashing the ROM (tough luck, I guess). What's more I tried flahyboy's ROM, to see if it's maybe something wrong with my S6 - well, you can say flahyboy's ROM starts instantly, but in-call mic is not working. I'd be grateful for any hints on what might be wrong. One and only thing I noticed is flahyboy's ROM is slightly greater in size (~40MB) that mine.. maybe the build solution did not add something to my zip.. Anyway - great tutorial, thanks for that. Installing AOSP just made me even more anxious to wait for making this system stable :good:
Click to expand...
Click to collapse
Thank, but can you compile now?
Astrubale said:
Thank, but can you compile now?
Click to expand...
Click to collapse
Yeah, I compiled it at last, but if i flash the zip from out folder, then the phone hangs on first bootsplash ("Galaxy S6") with "Kernel is not seandroid enforcing"
djseban2 said:
Yeah, I compiled it at last, but if i flash the zip from out folder, then the phone hangs on first bootsplash ("Galaxy S6") with "Kernel is not seandroid enforcing"
Click to expand...
Click to collapse
Search for errors inside /proc/last_kmsg
Wow cool clean and easy Guide. Thanks for this.
Weil try myself on that.
Astrubale said:
Search for errors inside /proc/last_kmsg
Click to expand...
Click to collapse
Code:
Samsung S-Boot 4.0 for SM-G920F (Apr 22 2016 - 16:59:51)
EXYNOS7420 EVT 1.3 (Base on ARM CortexA53)
3048MB / 0MB / Rev 11 / G920FXXU3DPDP / (PKG_ID 0x0) / LOT_ID N3N1P / RST_STAT (0x10000)
__if_pmic_rev_init - MUIC API is not ready!
MON: 0x8(1)
MON[0] = (1)[0x1c, 0x7a]
MON[1] = (2)[0x1a, 0x56]
MON[2] = (3)[0x1a, 0x3d]
MON[3] = (4)[0x1c, 0x4e]
MON[4] = (5)[0x1a, 0x39]
MON[5] = (6)[0x1a, 0x30]
MON[6] = (7)[0x15, 0x44]
MON[7] = (0)[0x0c, 0x07]
pmic_asv_init
(ASV_TBL_BASE+0x00)[11:0] bigcpu_asv_group = 2184
(ASV_TBL_BASE+0x00)[15:12] bigcpu_ssa0 = 0
(ASV_TBL_BASE+0x00)[27:16] littlecpu_asv_group = 2457
(ASV_TBL_BASE+0x00)[31:28] littlecpu_ssa0 = 0
(ASV_TBL_BASE+0x04)[11:0] g3d_asv_group = 2184
(ASV_TBL_BASE+0x04)[15:12] g3d_ssa0 = 0
(ASV_TBL_BASE+0x04)[27:16] mif_asv_group = 2184
(ASV_TBL_BASE+0x04)[31:28] mif_ssa0 = 0
(ASV_TBL_BASE+0x08)[11:0] int_asv_group = 3276
(ASV_TBL_BASE+0x08)[15:12] int_ssa0 = 6
(ASV_TBL_BASE+0x08)[27:16] cam_disp_asv_group = 2184
(ASV_TBL_BASE+0x08)[31:28] cam_disp_ssa0 = 0
(ASV_TBL_BASE+0x0C)[3:0] dvfs_asv_table_version = 15
(ASV_TBL_BASE+0x0C)[4] asv_group_type = 0
(ASV_TBL_BASE+0x0C)[7:5] reserved01 = 0
(ASV_TBL_BASE+0x0C)[8] shift_type = 0
(ASV_TBL_BASE+0x0C)[9] ssa1_enable = 0
(ASV_TBL_BASE+0x0C)[10] ssa0_enable = 1
(ASV_TBL_BASE+0x0C)[15:11] reserved02 = 0
(ASV_TBL_BASE+0x0C)[16] asv_method = 1
(ASV_TBL_BASE+0x0C)[31:17] reserved03 = 0
(ASV_TBL_BASE+0x10)[3:0] main_asv_group = 0
(ASV_TBL_BASE+0x10)[7:4] main_asv_ssa = 0
(ASV_TBL_BASE+0x10)[11:8] bigcpu_ssa1 = 0
(ASV_TBL_BASE+0x10)[15:12] littlecpu_ssa1 = 0
(ASV_TBL_BASE+0x10)[19:16] g3d_ssa1 = 0
(ASV_TBL_BASE+0x10)[23:20] mif_ssa1 = 0
(ASV_TBL_BASE+0x10)[27:24] int_ssa1 = 0
(ASV_TBL_BASE+0x10)[31:28] cam_disp_ssa1 = 0
(ASV_TBL_BASE+0x14)[8:0] bigcpu_ssa_ema = 0
(ASV_TBL_BASE+0x14)[17:9] littlecpu_ssa_ema = 0
(ASV_TBL_BASE+0x14)[26:18] g3d_ssa_ema = 0
(ASV_TBL_BASE+0x14)[31:27] reserved04 = 0
chip_status = f, bin2_efuse = 0
muic_register_max77843_apis
muic_is_max77843 chip_id:0x43 muic_id:0xb5 -> matched.
MUIC rev = MAX77843(181)
init_multi_microusb_ic Active MUIC 0xb5
max77843_init_microusb_ic: MUIC: CDETCTRL:0x2d
max77843_init_microusb_ic: MUIC: CONTROL1:0x00
max77843_init_microusb_ic: MUIC: CONTROL2:0x3b
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
max77843_muic_get_chg_typ: STATUS2:0x00
max77843_muic_get_chg_typ: CHGTYP:0x00
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
max77843_muic_get_chg_typ: STATUS2:0x00
max77843_muic_get_chg_typ: CHGTYP:0x00
load Secure Payload done.
Chip ID : 060f4d16dd28 / 0x00007700
EL3 monitor information => Built : 16:48:28, Jan 18 2016
bConfigDescrLock: 1
sw_lock success
sw_lock success
sw_lock success
SCSI CMD : 55 11 00 00 00 00 00 00 14 00
SCSI Response(01) : Target Failure
SCSI Status(02) : max77843_set_muic_uart_early: MUIC: CONTROL1: 0x00
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
[Debug Info.]
S-BOOT : VERSION_-+F0
SecureOS : 20 (MB)
- read_bl1
blk_bread_bootsector: LUN 1, from 0x0, size 0x10, buffer 0x45708000
Verify_Binary_Signature 0x45720120 [email protected], [email protected]
pit_check_signature (PIT) valid.
PARAM ENV VERSION: v1.0..
blk_bread_bootsector: LUN 1, from 0xffe, size 0x1, buffer 0x441204c0
initialize_ddi_data: usable! (3:0xf), warranty reason : (0x0303)
MAGIC_RAM_BASE: 4000000, MAGIC_RAM_BASE2: 100001, ompin: 2000a
[ldfw] Pass LDFW partition!
[ldfw] read whole CM partition from the storage
ldfw: 0th ldfw's version 0x20151027 name : CryptoManagerV20
ldfw: 1th ldfw's version 0x20151203 name : fmp_fw
ldfw: init ldfw(s). whole ldfws size 0x204110
[ldfw] try to init 2 ldfw(s). except 0 ldfw 2 ldfw(s) have been inited done.
[mobi_drv] add: 0x43e71940, size: 11401
MobiCore IDLE flag = 0
MobiCore Driver loaded and RTM IDLE!
[OTP] 27 bit read: 0x5
[OTP] 22 bit read: 0x0
[OTP] 21 bit read: 0x0
[OTP] 23 bit read: 0x1
[OTP] 26 bit read: 0x1
[OTP] NANTIRBK0 bit reading: start
[OTP] NANTIRBK0: 3 bit
[OTP] 28 bit read: 0x1
[OTP] 29 bit read: 0x0
[OTP] 30 bit read: 0x1
[OTP] 25 bit read: 0x1
[OTP] ETC value: 0
[EFUSE] SMC Read the 0x0 ...
[EFUSE] SMC Read Count value: 3
[EFUSE] SMC Read the 0x1 ...
[EFUSE] SMC Read Count value: 1
[EFUSE] SMC Read the 0x2 ...
[EFUSE] SMC Read Count value: 0
[EFUSE] SMC Read the 0x3 ...
[EFUSE] SMC Read Count value: 1
(1,5) vs (1,5)
[EFUSE] This is commercial device.
set_tzpc_secureport: successfully protected 0
eSE Protection!!
Authenticated data read request (Swapped)
Authenticated data read response (Swapped)
RPMB: get hmac value: success
HMAC compare success !!
update_rpmb_version skip.
initialize_secdata_rpmb: usable! (0x52504d42)
DDR SIZE: 3G (0xc0000000)
LPDDR4 manufacturer : Micron
bin2_efuse = 0
[TMU] 52, 53, 51, 51
UFS vendor: SAMSUNG
FW rev : 0200
product : KLUBG4G1BD-E0B1
UFS size (GB) : 32
UFS ID : XXXXXXXXXXXXXXXX
lun:196 Query Response : 0xfc
lun:196 Query Response : 0xfc
lun:196 Query Response : 0xfc
lun:196 Query Response : 0xfc
dNumAllocUnits error at LU7 0 0
PROVISION : FAIL
PROVISION : FAIL
max77843_muic_api_print_init_regs: INTMASK[1:0x00, 2:0x00, 3:0x00]
max77843_muic_api_print_init_regs: MUIC: CDETCTRL:0x2d
max77843_muic_api_print_init_regs: MUIC: CONTROL1:0x00
max77843_muic_api_print_init_regs: MUIC: CONTROL2:0x3b
max77843_muic_api_print_init_regs: MUIC: CONTROL3:0x00
max77843_muic_api_print_init_regs: MUIC: CONTROL4[0x16]:0xb2
init_ific : MAX77843(0)
init_ific : MAX77843(0)
set_float_voltage: max77843 battery cv voltage 0x9c
set_charger_state: buck(1), chg(1), reg(0x05)
max77843_get_charger_status: Invalid charger
set_auto_current: get_charger_status(0)
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
max77843_muic_get_chg_typ: STATUS2:0x00
max77843_muic_get_chg_typ: CHGTYP:0x00
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
max77843_muic_get_chg_typ: STATUS2:0x00
max77843_muic_get_chg_typ: CHGTYP:0x00
get_wireless_charger_detect: wireless check 0
get_wireless_charger_detect : CHG_DTLS(0x00)
set_auto_current: unknown_state, curr(475)
max77843_get_charger_status: Invalid charger
get_wireless_charger_detect: wireless check 0
get_wireless_charger_detect : CHG_DTLS(0x00)
set_charger_current: chg curr(137), in curr(0)
max77843_get_charger_status: Invalid charger
get_wireless_charger_detect: wireless check 0
get_wireless_charger_detect : CHG_DTLS(0x00)
fuelguage : wpc_status(0)
set_charger_state: buck(1), chg(0), reg(0x04)
init_fuel_gauge: Start!!
init_fuel_gauge : MAX77843(0)
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
adc_read_temp temp_adc = 1852
init_fuel_gauge temp = 25
init_fuel_gauge : MAX77843(0)
init_fuel_gauge: Battery type : SDI, capacity: 5177, status: 128
init_fuel_gauge: Already initialized (0x1439, SDI type)
check_validation_with_tablesoc: Start!!
fuel_gauge_read_soc: SOC(32), data(0x209a)
fuel_gauge_read_ocv: VFOCV(3774), data(0xbcba)
calculate_table_soc : low(0) high(6) mid(7) table_soc(0)
calculate_table_soc : low(4) high(6) mid(3) table_soc(0)
calculate_table_soc : low(6) high(6) mid(5) table_soc(0)
calculate_table_soc : low(7) high(6) mid(6) table_soc(0)
calculate_table_soc: vcell [3774] table_soc [31]
differ(1), table_soc(31), RepSOC(32)
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
max77843_muic_get_chg_typ: STATUS2:0x00
max77843_muic_get_chg_typ: CHGTYP:0x00
fuel_gauge_read_vcell: VCELL(3716), data(0xb9d8)
vcell(3716),soc_diff_limit(50), low_temp_reset(0)
fuel_gauge_read_ocv: VFOCV(3774), data(0xbcba)
fuel_gauge_read_vcell: VCELL(3716), data(0xb9d8)
fuel_gauge_read_soc: SOC(32), data(0x209a)
fuel_gauge_read_vfsoc: VFSOC(30), data(0x1ef3)
init_fuel_gauge : OCV(3774), VCELL(3716), SOC(32), VFSOC(30)
AP_PMIC_SDA = 1
PMIC_ID = 0x12
OTP:0x78 PWR_SEQ:1 G3D_OCP:1 PSoff:1 INT_Volt:1
PMIC_STATUS1 = 0x2f PWRON JIGONB ACOKB MR2B PWRON1S
PMIC_STATUS2 = 0x11 RTC60SE RTC1SE
PMIC_PWRONSRC = 0x08 MRST
PMIC_OFFSRC = 0x00
PMIC_INT1 = 0xc3 PWRONF PWRONR PWRON1S MRB
PMIC_INT2 = 0x11 RTC60S RTC1S
PMIC_INT3 = 0x80 RSVD
PMIC_RTC_CTRL = 0x02
PMIC_RTC_SMPL = 0x83
RTC TIME: 2016-08-13 07:27:29(0x40)AM
s5p_check_keypad: 0x10110000
s5p_check_keypad: recovery mode
set_oneshot_recovery: recovery mode set! sys_bootm=0x80000
s5p_check_reboot_mode: INFORM3 = 0 ... skip
ATLAS_PLL = 1200MHz APOLLO_PLL = 1200MHz MIF_PLL = 3104MHz
MFC_PLL = 468MHz CCI_PLL = 532MHz
BUS0_PLL = 1600MHz BUS1_PLL = 668MHz
board_uart_rustproof ifc_sense: 0
-user build & not FAC
-rustproof mode Enabled
s5p_check_upload: MAGIC(0x4000000), RST_STAT(0x10000)
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
s5p_check_upload: debug level is LO! (mask: 0x220)
max77843_ific_set_mrstb: TOPSYS: MAINCTRL1[0x02]: [0x07]+[0x07]->[0x07]
s5p_check_upload: disable dump_gpr
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
s5p_check_download: 0
max77843_muic_get_adc_value: STATUS1:0x1f
max77843_muic_get_adc_value: ADC:0x1f
max77843_get_charger_status: Invalid charger
get_wireless_charger_detect: wireless check 0
get_wireless_charger_detect : CHG_DTLS(0x00)
check_pm_status: charger is not detected
fuel_gauge_read_vcell: VCELL(3718), data(0xb9ea)
check_pm_status: voltage(3718) is ok
check_pm_status: 7 sec reset, continue.
scr_draw_image: draw 'logo.jpg'...
read 'logo.jpg'(112504) completed.
board_set_dev_pm: s2mpb02 enable for display
42, 0, 13, 0x420013
DETECTED LCD TYPE : S6E3HA2
mipi-dsi driver(CMD mode) has been probed.
decon-int: ver0, max win7, command mode, hw trigger
single dsi mode
decon0 registered successfully
afw flag is Unknown [afw flag : 00 00 00 00]
secure info base: 45720000 and SMC Num = 0x83000013
secure smc success!!! [ret = 0]
Set debug level to low(4f4c)
DMV: Successfully informed TZ of boot mode: Recovery
load_kernel: loading boot image from 139264..
kernel size = 0x114f000, ramdisk size = 0x5fc000
dt_size:1454080, dt_actual:1454080
Verify_Binary_Signature 0x45720120 [email protected], [email protected]
Kernel Image
Verify_Binary_Signature: failed.(-18022398)
pit_check_signature (RECOVERY) invalid.
[TIMA trusted boot]: SEANDROID ENFORCING
Set invalid sign flag
No need to update kernel type.
[EFUSE] warranty bit is already set.
ace_hash_sha_digest: passed.(0)
tboot ctx base: 45720248
SMC Num = 0x83000001
mobismc success!!! [ret = 0]
SMC Num = 0x83000007
mobismc for tima info success!!! [ret = 0]
Pass. DTBH size is smaller than a page.
<dtbh_header Info>
magic:0x48425444, version:0x00000002, num_entries:0x00000008
<device info>
chip_id: 0x00001cfc
platform_id: 0x000050a6
subtype_id: 0x217584da
hw_rev: 0x0000000b
dt_entry[06]
chip_id: 0x00001cfc
platform_id: 0x000050a6
subtype_id: 0x217584da
hw_rev: 0x0000000a
hw_rev_end: 0x0000000b
offset: 0x0010a000
dtb size: 0x0002c800
Selected entry hw_ver : 11
dt_entry of hw_rev 10 is loaded at 0x4a000000.(182272 Bytes)
[EFUSE] RB count: device(0x3), binary(0x3)
[OTP] SW LOCK Success
DDI value :0x0000000f
sw_lock success
sw_lock success
Forced Enable KAP
Warranty Bit Set - Blowing KAP_VIOLATION_FUSE
KAP status = 5afe0003
ATAG_CORE: 5 54410001 0 0 0
ATAG_MEM: 4 54410002 20000000 40000000
ATAG_MEM: 4 54410002 20000000 60000000
ATAG_MEM: 4 54410002 20000000 80000000
ATAG_MEM: 4 54410002 20000000 A0000000
ATAG_MEM: 4 54410002 20000000 C0000000
ATAG_MEM: 4 54410002 1E800000 E0000000
ATAG_SERIAL: 4 54410006 XXXXXXXX XXXXXXXX
ATAG_INITRD2: 4 54420005 43000000 5fbd8f
ATAG_REVISION: 3 54410007 b
check_rustproof [0,0] On
ucs flag is Unknown
ucs flag : 00 00 00 00
ATAG_CMDLINE: f0 54410009 'console=ram loglevel=4 bootmode=2 sec_debug.level=0 sec_watchdog.sec_pet=5 androidboot.hardware=samsungexynos7420 androidboot.debug_level=0x4f4c ess_setup=0x46000000 [email protected] [email protected] charging_mode=0x3000 s3cfb.bootloaderfb=0xe2a00000 sysscope=0x6b090719 lcdtype=4325395 consoleblank=0 lpj=239616 sec_debug.reset_reason=5 ehci_hcd.park=3 oops=panic pmic_info=35 cordon=c34c0eba5576148dc662cf43a6352c3b connie=SM-G920F_OPEN_EUR_c3811d70601ea690b7b0b2afca80be2c fg_reset=0 androidboot.emmc_checksum=3 androidboot.boot_salescode= androidboot.odin_download=1 androidboot.bootloader=G920FXXU3DPDP androidboot.selinux=enforcing androidboot.security_mode=1526595585 androidboot.ucs_mode=0 androidboot.hw_rev=11 androidboot.warranty_bit=1 androidboot.hmac_mismatch=0 androidboot.sec_atd.tty=/dev/ttySAC1 androidboot.serialno=XXXXXXXXXXXXXXXX snd_soc_core.pmdown_time=1000 zero_sdchg_ic=0 androidboot.fmp_config=0'
ATAG_NONE: 0 0
pack_atags: ramdisk size start 0x43000000, size 0x5fbd8f
Updating device tree @0x4a000000: done
Starting kernel at 0x40205000...
SWITCH_SEL(3)
BOOTING TIME : 2895
Here it is, mate. I can't seem to find anything suspicious besides
Code:
dNumAllocUnits error at LU7 0 0
PROVISION : FAIL
PROVISION : FAIL
but I can only guess
Hi I am having problems compiling due to the kernel. Which kernel source should I use? How should I configure it? Help pleaase
Added "extract files" guide.
Whenever I try to download the CyanogenMod repo, I get this error:
error: Exited sync due to fetch errors
I've tried using: repo sync -f and: repo sync --force-sync
I'm trying to download the CM13 repo.
I've also followed the steps exactly as they were written.
I'm trying to build cm-14.0. Fails at
HTML:
Starting build with ninja
ninja: Entering directory `.'
ninja: error: '/home/julian/android/system/out/target/product/zerofltexx/obj_arm/SHARED_LIBRARIES/libsecril-client_intermediates/export_includes', needed by '/home/julian/android/system/out/target/product/zerofltexx/obj_arm/SHARED_LIBRARIES/audio.primary.universal7420_intermediates/import_includes', missing and no known rule to make it
build/core/ninja.mk:151: recipe for target 'ninja_wrapper' failed
make: *** [ninja_wrapper] Error 1
make: Leaving directory '/home/julian/android/system'
.
Any ideas what could be wrong?
/android/system/kernel/samsung/exynos7420 contains github.com/CyanogenMod/android_kernel_samsung_exynos7420 cm-14.0.
Thanks for the great guide anyway

Categories

Resources