Hi all,
View mins ago I setup linux on my HTC.
Well, it does work and i can connect to my device with ssh.
But I have some problems, it cant find the MMC Card (I format it as ext2) on my desktop (debian)
my dmesg
# dmesg
<5>Linux version 2.6.16.27-omap1 ([email protected]) (gcc version 4.1.1) #4 PREEMPT Fri Jan 5 16:56:42 CET 2007
<4>CPU: ARM926EJ-Sid(wb) [41069263] revision 3 (ARMv5TEJ)
<4>Machine: HTC Wizard
<4>Memory policy: ECC disabled, Data cache writeback
<7>On node 0 totalpages: 24576
<7> DMA zone: 24576 pages, LIFO batch:7
<7> DMA32 zone: 0 pages, LIFO batch:0
<7> Normal zone: 0 pages, LIFO batch:0
<7> HighMem zone: 0 pages, LIFO batch:0
<4>Unknown OMAP cpu type: 0x00
<4>OMAP0000 revision 1 handled as 00xx id: 0000000000000000
<6>SRAM: Mapped pa 0x20000000 to va 0xd0000000 size: 0x32000
<4>htc_wizard_map_io done.
<4>CPU0: D VIVT write-back cache
<4>CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets
<4>CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets
<4>Built 1 zonelists
<5>Kernel command line: root=/dev/ram0 init=/linuxrc
<4>htc_wizard_init_irq.
<4>Clocks: ARM_SYSST: 0x1040 DPLL_CTL: 0x2793 ARM_CKCTL: 0x6506
<6>Clocking rate (xtal/DPLL1/MPU): 13.0/195.0/195.0 MHz
<4>Total of 96 interrupts in 3 interrupt banks
<6>OMAP730 GPIO hardware
<4>PID hash table entries: 512 (order: 9, 8192 bytes)
<4>Console: colour dummy device 80x30
<4>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
<4>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
<6>Memory: 96MB = 96MB total
<5>Memory: 92444KB available (1656K code, 403K data, 96K init)
<7>Calibrating delay loop... 89.70 BogoMIPS (lpj=448512)
<4>Mount-cache hash table entries: 512
<6>CPU: Testing write buffer coherency: ok
<6>checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
<6>Freeing initrd memory: 2604K
<6>NET: Registered protocol family 16
<4>Tornado init.
<4>OMAP730 Watchdog seems to be activated, disabling it for now.
<4>trying to enable USB.
<4>USB_EN to 0 after 0 tries.
<4>MMC host reset done: remaining tries: 100
<6>OMAP DMA hardware version 1
<6>DMA capabilities: 000c0000:00000000:01ff:003f:007f
<4>Initializing OMAP McBSP system
<3>mcbsp: could not acquire dsp_ck handle.
<3>omapdsp: unsupported omap architecture.
<4>USB: hmc 4, usb0 2 wires (dev)
<4>NetWinder Floating Point Emulator V0.97 (double precision)
<6>io scheduler noop registered
<6>io scheduler deadline registered (default)
<4>HTC Tornado Backlight driver.
<4>VSFB Frame buffer driver for HTC OMAP Based Phones.
<6>vsfb: framebuffer at 0x20001020, mapped to 0xc6800020, size 150k
<4>Console: switching to colour frame buffer device 40x29
<6>TI OMAP Watchdog Timer for OMAP730
<4>RAMDISK driver initialized: 1 RAM disks of 8192K size 1024 blocksize
<6>udc: OMAP UDC driver, version: 4 October 2004 (iso)
<6>udc: OMAP UDC rev 3.6
<6>udc: hmc mode 4, integrated transceiver
<6>udc: fifo mode 3, 648 bytes not used
<6>usb0: Ethernet Gadget, version: May Day 2005
<6>usb0: using omap_udc, OUT ep2out-bulk IN ep1in-bulk STATUS ep3in-int
<6>usb0: MAC 9a:17:46:70:a0:3b
<6>usb0: HOST MAC c2:20:66:22:69:ae
<6>mice: PS/2 mouse device common for all mice
<6>OMAP Keypad Driver
<4>omap_kp_probe.
<6>input: omap-keypad as /class/input/input0
<6>NET: Registered protocol family 2
<3>MMC1: Command timeout, CMD0
<4>IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
<4>TCP established hash table entries: 4096 (order: 2, 16384 bytes)
<4>TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
<6>TCP: Hash tables configured (established 4096 bind 4096)
<6>udc: USB reset done, gadget ether
<6>TCP reno registered
<6>TCP bic registered
<6>NET: Registered protocol family 1
<6>NET: Registered protocol family 17
<6>NET: Registered protocol family 15
<5>RAMDISK: Compressed image found at block 0
<6>udc: USB reset done, gadget ether
<6>udc: USB reset done, gadget ether
<6>udc: USB reset done, gadget ether
<6>udc: USB reset done, gadget ether
<6>udc: USB reset done, gadget ether
<6>udc: USB reset done, gadget ether
<6>udc: USB reset done, gadget ether
<6>udc: USB reset done, gadget ether
<6>usb0: full speed config #1: 100 mA, Ethernet Gadget, using CDC Ethernet
<4>VFS: Mounted root (ext2 filesystem).
<6>Freeing init memory: 96K
<6>vsmmfb: ioctl helper driver for framebuffer 0.1.1, Copyright 2007 Thomas Reith
<6>vsmmfb: loaded, got minor 63
Click to expand...
Click to collapse
# df -h
Filesystem Size Used Available Use% Mounted on
/dev/ram0 5.8M 4.4M 1.4M 75% /
Click to expand...
Click to collapse
# mount
/dev/root on / type ext2 (rw,nogrpid)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
sysfs on /sys type sysfs (rw)
Click to expand...
Click to collapse
The problem is , even in /dev
mmcblk0
mmcblk0p1
mmcblk0p2
mmcblk0p3
mmcblk0p4
there isnt anything, so if i cant find my mmc, i cant fdisk so i wont have any os.
The next problem is, i dont have gcc?
Because it it not a debian system (i want to) apt wont work, no RPM, just nothing.
How de heck can i compile gcc without gcc? so i can start using my os?
the next thing, but the last one.
When i have my OS ready to play.
It is possible to write it to ram? so it will remove windows and replace it with my linux version?
Any help/tips would be helpfull
thx
MMC and NS.exe on HTC prophet
Hi:
You can activate your sd card using Nico's program sd.exe
Look the web of the linwizard project in sourceforge:
http://sourceforge.net/tracker/index.php?func=detail&aid=1593777&group_id=174107&atid=867988
Luck!!
Sesh maat setep n ra
For those interested, Amazon FireTV JTAG pinout is very close to the standard 20-pin ARM JTAG. See atached image for the actual pinout. If anybody has an OpenOCD config file for QUalcomm Krait 300 (SnapDragon 600), please share. Rooting can be done by bypassing a couple of checks in the bootloader.
Huh. Question. Is it snapdragon 600 you want or S4 pro. I dug pretty deeply before I got the box to figure exactly what processor is in there. Amazon gives: snapdragon 8064, krait 300, 1.7 GHz with adreno 320. I couldn't actually find a direct match for those specs in Qualcomm info, but the only thing that matched those specifications was the S4 pro, the same thing in the Nexus 7. Not to derail what you started, just want to be sure you're seeking the correct thing.
from my N5
Edit: let me clarify a bit. Amazon says it's the 8064. I went to qualcomm's site and that wasn't listed anywhere. So through deductive reasoning: CPU speed and the adreno 320 match the S4 pro which is also in the N7 2013. I haven't actually looked what xda says it has, but that's how I came to the S4 pro.
DroidIt! said:
Huh. Question. Is it snapdragon 600 you want or S4 pro. I dug pretty deeply before I got the box to figure exactly what processor is in there. Amazon gives: snapdragon 8064, krait 300, 1.7 GHz with adreno 320. I couldn't actually find a direct match for those specs in Qualcomm info, but the only thing that matched those specifications was the S4 pro, the same thing in the Nexus 7. Not to derail what you started, just want to be sure you're seeking the correct thing.
from my N5
Edit: let me clarify a bit. Amazon says it's the 8064. I went to qualcomm's site and that wasn't listed anywhere. So through deductive reasoning: CPU speed and the adreno 320 match the S4 pro which is also in the N7 2013. I haven't actually looked what xda says it has, but that's how I came to the S4 pro.
Click to expand...
Click to collapse
Being curious, I did some reading. I'm pretty sure it's a S4 Pro as well. 600 uses LPDDR3, has higher clock speed 1.7 vs 1.9GHz, and has wireless AC.
http://forum.xda-developers.com/nexus-4/help/snapdragon-600-vs-snapdragon-s4-pro-t2157201
http://www.ifixit.com/Teardown/Amazon+Fire+TV+Teardown/23856
Luxferro said:
Being curious, I did some reading. I'm pretty sure it's a S4 Pro as well. 600 uses LPDDR3, has higher clock speed 1.7 vs 1.9GHz, and has wireless AC.
http://forum.xda-developers.com/nexus-4/help/snapdragon-600-vs-snapdragon-s4-pro-t2157201
http://www.ifixit.com/Teardown/Amazon+Fire+TV+Teardown/23856
Click to expand...
Click to collapse
Yeah they didn't match up to me. I see xda just says 1.7 ghz, etc and not the 600. I'm thinking S4 Pro too. Good to get a confirmation though. :good:
DroidIt! said:
Yeah they didn't match up to me. I see xda just says 1.7 ghz, etc and not the 600. I'm thinking S4 Pro too. Good to get a confirmation though. :good:
Click to expand...
Click to collapse
The 600 was mentioned in some specs on the web, but it may have been a guess.
Actual JTAG device IDs:
4BA00477 (dap)
2071E0E1(cpu) <- googling this one yields nothing
Luxferro said:
Being curious, I did some reading. I'm pretty sure it's a S4 Pro as well. 600 uses LPDDR3, has higher clock speed 1.7 vs 1.9GHz, and has wireless AC.
http://forum.xda-developers.com/nexus-4/help/snapdragon-600-vs-snapdragon-s4-pro-t2157201
http://www.ifixit.com/Teardown/Amazon+Fire+TV+Teardown/23856
Click to expand...
Click to collapse
the original apq8064 was dubbed the 'S4 Pro' (before the new naming scheme kicked in). Later variants (apq8064t, apq8064ab, etc) are dubbed 'snapdragon 600'. The newer variants have newer krait and newer revision of a320 (gpu), clock bumps, etc.. but basically tweaks of the original.
Determined said:
For those interested, Amazon FireTV JTAG pinout is very close to the standard 20-pin ARM JTAG. See atached image for the actual pinout. If anybody has an OpenOCD config file for QUalcomm Krait 300 (SnapDragon 600), please share. Rooting can be done by bypassing a couple of checks in the bootloader.
Click to expand...
Click to collapse
I've got a third FireTV hooked up to my riffbox now, but having issues. If I can get a successful read and write, I'll post a dump with a hacked bootloader to run unsigned images.
Issue I'm as is im not getting any response from RTCK. Fuses indicate that jtag was not disabled, and this isnt my strong point.
jcase said:
If I can get a successful read and write, I'll post a dump with a hacked bootloader to run unsigned images.
Click to expand...
Click to collapse
No need to pull that dump, it is provided in the OTA (emmc_appsboot.mbn). There is a procedure (located at 0x88F01144 in OTA 51.1.0.1) that checks unlock code, if you force it to return 1, you will be able to boot anything as well as run "oem unlock" and other restricted commands.
Determined said:
No need to pull that dump, it is provided in the OTA (emmc_appsboot.mbn). There is a procedure (located at 0x88F01144 in OTA 51.1.0.1) that checks unlock code, if you force it to return 1, you can boot anything as well as run "oem unlock" and other restricted commands.
Click to expand...
Click to collapse
Not what I was referring to, sorry for my bad wording.
I have already rooted and unlocked mine, but I an unable to release the root at this point (will shortly, waiting on Amazn not confirm a patch is done for the root exploit). I was trying to say I would release a riffbox flashable binary, with a bootloader hack allowing booting of custom images.
Booting unsigned recovery with modified res images:
I can't get a response over jtag, will put more effort into it this week.
emmc_appsboot.mbn itself can not be alternated, sbl3 validates it before continuing with boot.
jcase said:
emmc_appsboot.mbn itself can not be alternated, sbl3 validates it before continuing with boot.
Click to expand...
Click to collapse
Hah! If you step through it using a jtag and skip the checks it won't actually need any changes.
Determined said:
Hah! If you step through it using a jtag and skip the checks it won't actually need any changes.
Click to expand...
Click to collapse
Hah? Stepping through it is impractical for most uses. For the few of us that have one sitting on our desk? Sure ok, for those that have it in their entertainment center? Not practical at all.
If you are going to jtag it, might as well hack it proper once, and not worry about having to step through it each boot.
If you choose to jtag and step through it, have it return a value of being unlocked will result in androidboot.unlocked_kernel=true being passed to cmdline, and /sbin/adbd will not drop root when that exists. Would be a easy-ish root through jtag without actually flashing anything.
jcase said:
If you are going to jtag it, might as well hack it proper once, and not worry about having to step through it each boot.
Click to expand...
Click to collapse
That is your [much appreciated] thunder. I don't have time to generate public-friendly hacks anymore.
Determined said:
That is your [much appreciated] thunder. I don't have time to generate public-friendly hacks anymore.
Click to expand...
Click to collapse
Thunder is over, I'm done after I provide a few promised ones come Blackhat (including this one). Too much of time sink, and the public factor of the amusement has long gone.
If you have gtalk/hangouts give me a shout to the address in my signature.
There is also a serial debug port.
Are the pins known which is which?
{ParanoiA} said:
Are the pins known which is which?
Click to expand...
Click to collapse
I'll try and verify tomorrow
Sent from my HTC One_M8 using XDA Premium 4 mobile app
iNT0XiC8D said:
There is also a serial debug port.
Click to expand...
Click to collapse
Nothing to see there, just kernel messages:
Code:
Android Bootloader - UART_DM Initialized!!!
[0] welcome to lk: current version is lk_rel_3.0.1_02272014
[10] platform_init()
[10] target_init(): platform_id 109
[10] Its BUELLER. revision 3
[70] display_init(),target_id=7337.
[70] hdmi_msm_panel_init: default format=4
[2730] splash_screen_mmc :235, 67
[2750] Config HDMI PANEL.
[2750] Turn on HDMI PANEL.
[2760] EDID: no DTD or non-DTD data present
[2760] EDID: no DTD or non-DTD data present
[2760] hdmi_edid_get_audio_data: No adb found
[2770] hdmi_audio_playback: 48KHz not supported by TV
[2770] hdmi_msm_audio_acr_setup: video format 0 not supported
[2780] aboot_init: calling idme_initialize
[2780] Idme version is 2.0 and set related function to V2.0
[2790] IDME INFO: checking for new items to add (stored items:12 specified items:12)
[2790] serial num from idme: XXXXXXXXXXXXXXXXXX
[2800] Reboot -- restart_reason=427810811 (0x197fdffb)
[2800] aboot_init: IDME - device boot up info
[2810] idme items number:12
[2810] name: board_id, size: 16, exportable: 1, permission: 292, data= XXXXXXXXXXXXXXXXXX
[2820] name: serial, size: 16, exportable: 1, permission: 292, data= XXXXXXXXXXXXXXXXXX
[2830] name: mac_addr, size: 16, exportable: 1, permission: 292, data= XXXXXXXXXXXXXXXXXX
[2830] name: bt_mac_addr, size: 16, exportable: 1, permission: 292, data= XXXXXXXXXXXXXXXXXX
[2840] name: productid, size: 32, exportable: 1, permission: 292, data= 00000000000000000000000000000000
[2850] name: productid2, size: 32, exportable: 1, permission: 292, data= 00000000000000000000000000000000
[2860] name: bootmode, size: 4, exportable: 1, permission: 292, data= 1
[2860] name: postmode, size: 4, exportable: 1, permission: 292, data= 2
[2870] name: bootcount, size: 8, exportable: 1, permission: 292, data= 32
[2880] name: eth_mac_addr, size: 16, exportable: 1, permission: 292, data= XXXXXXXXXXXXXXXXXX
[2890] bootcount = 33
[3080] aboot_init: Boot linux from MMC
[3090] boot_into_recovery=0 idme_bootmode=1 (NORMAL)
[3090] use_signed_kernel=1, is_unlocked=0, is_tampered=0.
[3100] Loading boot image (6344704): start
[3340] Loading boot image (6344704): done
[3340] Authenticating boot image (6344704): start
[3350] Attempting to enable ce3_src_clk before setting its rate.[3360] TZ channel swith returned 0
[5070] TZ channel swith returned 0
[5070] Authenticating boot image: done return value = 1
[5090] cmdline = 'androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3F ehci-hcd.park=3 maxcpus=2'
[5100] Power on reason 1
[5100] Its bueller again 3.
[5100] cmdline_length=170, n=172, n1=45
[5110] IDME: idme atag init (export to kernel), atag_size=514
[5110] name: board_id, size: 16, exportable: 1, permission: 292, data: XXXXXXXXXXXXXXXXXX
[5120] name: serial, size: 16, exportable: 1, permission: 292, data: XXXXXXXXXXXXXXXXXX
[5130] name: mac_addr, size: 16, exportable: 1, permission: 292, data: XXXXXXXXXXXXXXXXXX
[5140] name: bt_mac_addr, size: 16, exportable: 1, permission: 292, data: XXXXXXXXXXXXXXXXXX
[5140] name: productid, size: 32, exportable: 1, permission: 292, data: 00000000000000000000000000000000
[5150] name: productid2, size: 32, exportable: 1, permission: 292, data: 00000000000000000000000000000000
[5160] name: bootmode, size: 4, exportable: 1, permission: 292, data: 1
[5170] name: postmode, size: 4, exportable: 1, permission: 292, data: 2
[5180] name: bootcount, size: 8, exportable: 1, permission: 292, data: 33
[5180] name: eth_mac_addr, size: 16, exportable: 1, permission: 292, data: XXXXXXXXXXXXXXXXXX
[5190] The atag idme items number:11
booting linux @ 0x80208000, ramdisk @ 0x82200000 (368957)
No JTAG Debug
Connecting to JTAG with OpenOCD needs a few changes in the cortex_a.c source to enable support for Cortex-A15. If you actually make those changes and play with debug registers, you will discover that DBGEN and SPIDEN signals/fuses are disabled, so debug mode is not accessible.
I have not yet tried flashing.
Determined said:
Connecting to JTAG with OpenOCD needs a few changes in the cortex_a.c source to enable support for Cortex-A15. If you actually make those changes and play with debug registers, you will discover that DBGEN and SPIDEN signals/fuses are disabled, so debug mode is not accessible.
I have not yet tried flashing.
Click to expand...
Click to collapse
ohh, openocd? I'm listening..
I have a number of snapdragon devices that I'd love to use jtag with.. but no windows machine for the riffbox sw.. openocd would be awesome
I spent a bit trying today, I never could get a response from RTCK at all
Hi all,
Is there any way to recover my bricked Defy if the bootloader is not running (corrupt eMMC)? RSDLite will detect the phone as "Blank OMAP3630" if the option "TI Blank Flash" is selected, but flashing then fails immediately with "Error sending TI ROM data packet request. Device API Error: 0xE003009F".
Looking at the TI SoC documentation, the OMAP ROM code tries to boot from USB (hence the device is detectable for 3 seconds), so it should be possible to upload the original Motorola bootloader to RAM, execute it, then communicate with the (now running) bootloader to erase the eMMC and reflash it. The first file in the SBF (3.4.2-177UK) is the RAM downloader, which looks like the bootloader itself (it contains the same strings, eg. "OK to program" etc.) Can this be uploaded with only the OMAP ROM code running, or is it impossible to do anything if the eMMC is blank? Alternatively, would it be possible to load the bootloader from the SD card? This is possible on GP (ie. unsecured) OMAP devices.
Some background on the failure:
- MB525, green lens, CM710, running great for 2 years
- Got into a boot loop at the skater animation, for no apparent reason
- Used stock recovery to wipe data/cache (mistake?), didn't complete, battery out/in and booted to lock screen then froze, battery out/in and back into boot loop
- Used CWM recover to wipe data/cache, didn't complete, after a few seconds spontaneously rebooted to black screen, bricked
- Battery is fully charged
- With empty battery and plugged in, the white LED comes on, but in this state the processor is not running as the battery is trickle charged. When the voltage comes up, the OMAP starts, tries to boot over USB (3 seconds) and then hangs
- Various combinations of power/battery/volume up/down make no difference, the bootloader is not running
- I think the eMMC is corrupt (possibly hardware failure?)
Thanks for your help!
Defy boot process
Here's a summary of what I've learnt so far about the Defy boot process, from the many great posts on this forum and various other sites including the droid-developers wiki:
SoC:
- Defy SoC is Texas Instruments OMAP3630, locked by eFuse in HS (high security) mode, JTAG is disabled
- OMAP contains core boot ROM that runs first to start the boot chain
- OMAP contains Motorola 128-bit RSA public key hash programmed in eFuses, used to validate external bootstrap code (mbmloader)
- OMAP supports booting from external memory (MMC, NAND, NOR) and peripheral booting (USB, UART3)
- OMAP boot sequence is set by sys_boot pins, Defy configured boot sequence is 0b00101, ie. MMC2 then USB (only)
Storage:
- External flash is Sandisk SDIN5D2-2G (2GB eMMC, BGA package) connected to OMAP MMC2 interface, mapped as mmcblk1 in linux
- eMMC device is physically located under the metal can between the connectors for SIM card and battery
- eMMC behaves as conventional 512-byte sector hard disk and is partitioned with FAT MBR
- eMMC does not use separate ECC area, unlike the NAND flash used on the Droid, ECC is handled transparently by eMMC device
- SD card is connected to OMAP MMC1 interface, mapped as mmcblk0 in linux
The Defy (stock) power-on reset boot process works as follows:
- OMAP boot ROM code starts
- OMAP reads boot configuration 0b00101 from sys_boot pins
- MMC2 boot is selected
- OMAP reads first eMMC sector (the MBR)
- OMAP finds the first valid partition entry in the MBR
- OMAP reads the first eMMC partition (which is the Defy CG63/mbmloader) as a raw image (not a filesystem)
- OMAP processes the CH table (OMAP clock and SDRAM settings) from the first sector of the image (possibly unsigned)
- OMAP validates the public keys, PPA and ISW stored in the image, using the eFuse key hash
- OMAP copies the ISW (which is MLO, or the actual Motorola mbmloader bootstrap executable) into internal RAM
- mbmloader (if validated) is executed from RAM, otherwise the boot process skips to USB (below)
- mbmloader validates and loads mbm (the Motorola bootloader) from the second eMMC partition
- mbm detects the "volume up" button if pressed to interrupt boot and display the bootloader screen
- mbm displays the boot logo and loads lbl (linux bootloader)
- lbl loads the stock linux (android) kernel (or the stock recovery kernel, if the "volume down" button is pressed)
- linux kernel displays the startup animation
If MMC2 boot fails (no valid MBR/mbmloader):
- USB boot is selected
- USB is initialised (device is now detectable as TI OMAP3630 for 3 seconds)
- OMAP sends ASIC ID
- OMAP waits 300ms for response
- If no response, OMAP halts (infinite loop)
- USB host can send command to change boot device or upload (signed) boot image (unknown format) for execution in RAM
Therefore if the device is trying to boot via USB, it probably means that the eMMC MBR or the first partition (containing mbmloader) is corrupt, or the eMMC is blank. Presumably if the mbm (and mbmbackup?) partition is corrupt, the device will hang with screen off and no USB boot (unless mbmloader can exit to OMAP USB boot), and if lbl or the kernel is corrupt then mbm will stop and display the bootloader screen.
eMMC partition table for Defy (start/end sectors), based on a dump of mmcblk1 from a working Defy, noting respective CGs for SBF:
Code:
Device Boot Start End Blocks Id System CG ID Function
0 255 128 64 mbr FAT MBR
1 * 256 511 128 83 Linux 63 mbmloader Motorola bootstrap
2 1024 2047 512 83 Linux 30 mbm Motorola bootloader
3 2048 3071 512 83 Linux 55 mbmbackup
4 3072 31358975 15677952 5 Extended 65 ebr FAT EBR
5 4096 5119 512 83 Linux 56 bploader
6 5120 6143 512 83 Linux 31 cdt.bin CG table
7 6144 14335 4096 83 Linux 38 pds
8 14336 15359 512 83 Linux 34 lbl Linux bootloader
9 15360 16383 512 83 Linux 57 lbl_backup
10 16384 18431 1024 83 Linux 42 logo.bin mbm startup logo
11 18432 22527 2048 83 Linux 41 sp
12 22528 23551 512 83 Linux 61 devtree
13 23552 24575 512 83 Linux 62 devtree_backup
14 24576 32767 4096 83 Linux 45 bpsw
15 32768 49151 8192 83 Linux 35 boot Stock android kernel and ramdisk
16 49152 65535 8192 83 Linux 47 recovery Stock recovery kernel and ramdisk
17 65536 94207 14336 83 Linux 33 cdrom
18 94208 95231 512 83 Linux 44 misc
19 95232 96255 512 83 Linux 43 cid
20 96256 104447 4096 83 Linux 53 kpanic
21 104448 774143 334848 83 Linux 39 system
22 774144 775167 512 83 Linux 32 prek
23 775168 776191 512 83 Linux 46 pkbackup
24 776192 1185791 204800 83 Linux 40 cache
25 1185792 31358975 15086592 83 Linux 37 userdata
My understanding is that if the eMMC is blank, I need to flash an SBF that contains at least the RAM downloader, CG64, CG63, CG30, CG65 and CG31 to reinstate the eMMC partition structure and bootloader. I think RSDLite should be capable of this (with "TI Blank Flash" enabled), unless the flash loader (RAM downloader) somehow depends on some content of the eMMC containing valid data. I don't know if such an SBF exists, and in any case RSDLite so far fails with "Error sending TI ROM data packet request", and I don't know why (tested under XP and Windows 7/8).
Awesome references:
http://forum.xda-developers.com/showthread.php?t=1443678
http://www.droid-developers.org/wiki/Booting_chain
http://www.droid-developers.org/wiki/Mbmloader
http://blog.opticaldelusion.org/search/label/sbf_flash
https://docs.google.com/spreadsheets/d/1jF8LjoS1yiMxn775QDm-cn5kxpoYw_biIC70uf9_ldY/pub?single=true&gid=0&output=html
OMAP Peripheral Boot - booting via USB
I've found out a little more about the OMAP USB peripheral boot mode, as a possible way to unbrick my Defy. The Texas Instruments OMAPFlash command line tool (for Windows) can be used to send executable code to the OMAP3630 (first into internal RAM, and then into SRAM), via the ROM code peripheral boot. This might allow the eMMC to be reflashed without a functioning Motorola bootloader (which is needed by RSDLite).
I think the unbricking process could work as follows:
- The Defy OMAP3630 starts in USB peripheral boot mode (OMAP ROM code - 1st bootstrap), because the eMMC is corrupt/blank
- OMAPFlash uploads a signed USB bootloader executable (2nd bootstrap) to internal RAM, via the OMAP ROM code
- Defy validates the uploaded 2nd bootstrap and executes it - this is the USB equivalent of mbmloader
- OMAPFlash communicates with the now running 2nd bootstrap and uploads the signed Motorola bootloader (mbm) to SRAM
- Defy executes mbm from SRAM and is now running the Motorola bootloader
- RSDLite can now be used to flash the eMMC with a special .SBF file containing mbr, mbmloader, mbm and ebr
- Defy can now boot mbm normally from eMMC and can be reflashed via RSDLite with a normal full .SBF
The following would be needed:
- OMAPFlash configured for Defy - available and possible
- USB bootloader (2nd bootstrap) for the Defy, signed with Defy private key - not available?
- Motorola bootloader (mbm) for the Defy, signed with Defy private key - available, as dumped from eMMC on working phone
- .SBF file with CG64, CG63, CG30 and CG65 - can be created, as all these signed binaries are available from eMMC dump
OMAPFlash is supplied with an unsigned OMAP3 2nd bootstrap and a version signed with the TI private key. There is also one available for the Droid (called pbrdl.bin), signed with the Droid private key (Droid is OMAP4). None of these will run on the Defy. (The TI OMAPFlash installer is available via http at 59.124.231.13/index.php/OMAPFlash, as a new user I can't post a direct external link).
OMAPFlash also seems to be able to flash the eMMC directly via a binary driver that it uploads to the device, but the documentation claims that this is only possible for OMAP4 devices (and it would still need a signed 2nd bootstrap).
So, to use this method, we need a signed OMAP3 2nd bootstrap file (pbrdl.bin) for the Defy. Does it exist?
RSDLite - reason for "TI Blank Flash" not working
With the "TI Blank Flash" option selected, RSDLite detects the phone as "Blank OMAP3630", but fails to flash the full .SBF with the message "Error sending TI ROM data packet request. Device API Error: 0xE003009F".
The reason for this is that RSDLite attempts to send the RAM downloader in the .SBF, which is 315392 bytes. The OMAP internal RAM is only 65536 bytes and some of this is used for workspace by the ROM code. In fact the Defy seems to refuse to accept a file uploaded via USB peripheral boot (the USB connection is terminated) if it will exceed about 28664 bytes. The reason for this is not clear (it is not publicly documented for HS devices).
So I think that for RSDLite to be used with the "TI Blank Flash" option, there would need to be a special .SBF with a small sized RAM downloader that fits into the OMAP RAM. Maybe this small RAM downloader would be the signed Defy 2nd bootstrap that can download and execute mbm. I don't know if such an .SBF file exists.
When Linux is the Solution
Hi @Teedub, I had the same Problem with my Defy+. Dead, no bootloader,no recovery, Nothing. RSDLite didn't recognize my phone. So I tried sbf_flash on Linux. After downloading sbf_flash I typed this on the terminal
Code:
./sbf_flash name_of_the_sbf.sbf
And magically, it loaded the bootloader and flashed my Rom .
So I suggest you to try this program. It's very useful when RSD LIte does't want to work
Morning all.
I'm trying to debug and restore a Mi TV stick that is stuck in a boot loop. It happened after I switched it on, its video got stuck in xiaomi logo, and after power cycling it never worked again.
The LED doesn't switch on and have no video signal on the hdmi, so I disassembled it and connected to its serial port pins and saw the following trace, in loop:
Code:
GXL:BL1:9ac50e:bb16dc;FEAT:BDFD71BC:0;POC:3;RCY:0;EMMC:0;READ:0;0.0;0.0;CHK:5E6;READ:0;0.0;0.0;CHK:0;
TE: 444948
BL2 Built : 10:47:30, Jan 14 2019. gxl g152d217 - [email protected]
set vcck to 1120 mv
set vddee to 1000 mv
Board ID = 7
CPU clk: 1200MHz
DQS-corr enabled
DDR scramble enabled
DDR3 chl: Rank0+1 @ 912MHz - FAIL
DDR3 chl: Rank0 @ 912MHz - FAIL
DDR3 chl: Rank0 16bit @ 912MHz - FAIL
DDR4 chl: Rank0+1 @ 912MHz - FAIL
DDR4 chl: Rank0 @ 912MHz
bist_test rank: 0 21 03 40 2b 12 44 1f 02 3d 32 1a 4a 20 00 40 2b 14 43 26 08 45 27 0d 41 660 - PASS
Rank0: 1024MB(auto)-2T-18
AddrBus test pass!
eMMC boot @ 1
sw8 s
emmc switch 3 ok
BL2: rpmb counter: 0x00000020
emmc switch 1 ok
Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x00004000, part: 1
aml log : R1024 check pass!
New fip structure!
Load bl30 from eMMC, src: 0x00010200, des: 0x01700000, size: 0x0000d600, part: 1
aml log : R1024 check pass!
Load bl31 from eMMC, src: 0x00020200, des: 0x01700000, size: 0x0002b400, part: 1
aml log : R1024 check pass!
aml log : SIG CHK : 231 for address 0x01700000
Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x00004000, part: 2
emmc switch 2 ok
I assume that perhaps when I power cycled it was updating and its emmc got corrupted?
Is their a way of reflashing the firmware on these devices? I've seen this post here at XDA but wasn't able to enter in USB mode as described. I was able to find the 2 pins but after shorting them nothing happens.
Any tips on how to recover this device?
Thank you!
Did you try to change the charger and/or the cable?