[Samsung Galaxy SL i9003] hillbeast:
This next post is off topic on kernel 3.x but it's something I think is interesting.

So yesterday I took a break from the kernel because it's confusing me a bit at the moment, and was thinking about the recovery process for this phone. I remembered ages ago that I discovered when you take the battery out and put it back in while the phone is connected to your computer, it connects as a random USB device (USB\VID_0451&PID_d00e). I knew this had to be the CPU itself showing up as it pops up so quickly after connecting power to the device, there is no way the device could possibly initialise the NAND and load the RAM up in that short amount of time, and connect a USB device.

I did a little research on this ages ago and discovered it is indeed the OMAP processors internal recovery/debug system. As suspected and much like Samsung Exynos processors the processor has an internal firmware (Samsung calls it iROM, dunno what TI call it) and this is what begins very very early initialisation of the processor and NAND so it can then load the bootloaders (Pbl/Sbl on Samsung Exynos, X-Loader/uboot on OMAP). This iROM (it's probably not what OMAP calls it but I'll call it that anyway because it's what I know) has a built in function where it will initialise the USB port as well and provide an interface for debugging purposes, and this can also be used to program the device and send information to and from it.

Basically this is a function used mainly in service centres, but it's more popularly used for development boards, like the 3630SDP or the SMDK4210 so you can program firmware onto the device even if it's completely bricked. It's a very very powerful and very very low level system which comes before even the bootloaders are loaded from the OneNAND or wherever they are kept on the device in question (in our case the OneNAND, but in other phones it would be the eMMC or something like that), so even if you went into Odin and completely wrecked it by unplugging it halfway through a flash and then were a even bigger moron and didn't bother fixing it while you had the chance while it was still on, you can then restore it using this iROM by sending a few low level commands directly to the CPU telling it to write data (ie a bootloader) directly to the NAND.

The utility for doing this on OMAP is actually open source (thanks TI) and they provide it free of charge, and I had to get my hands on it to play around a little.

Now of course I wanted to do some safe testing on it to see what exactly I could dig up, but I didn't want to dig too much into it in case I really messed it up and couldn't figure out how to get it back. I couldn't do much apart from find a few numbers that seem to be like serial numbers and such and as a result I won't post them in case it will identify the devices IMEI or something (don't want to give losers my IMEI), but I'll censor the potentially bad info instead.

C:\Users\Hill Beast\Downloads\---\--->--- -v -omap 3 -2 -p SDP_MDDR_HYNIX_4G

» --- v4.15 (Aug 12 2011)

» -v
» -omap 3
» -2
» -p SDP_MDDR_HYNIX_4G
» Looking for device (omap usb)
» Please turn on device
» Waiting for device (omap usb)
» Found device (omap usb)
» Awaiting ASIC id
» AsicId items 05
» AsicId id xx xx xx xx xx xx xx
» AsicId secure_mode 13 02 01 00
» AsicId public_id xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
13 89 60 E4 5C
» AsicId root_key_hash xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx
» AsicId checksum 15 09 01 13 BF 3E EF 15 52 E7 03
» Searching 2nd for: SDP_MDDR_HYNIX_4G 363007 07 HS
» Loading second file Targets\2nd-Downloaders\dnld_startup_omap3_hs_4g.signed.2n
d
» Entering parameter file:---2nd.txt at line: 10
» -pheriphalboot_reopen
» Reading board configuration file Targets\Configurations\configuration_sdp3630_hynix_4g.txt
» Reading definition file .\targets\definitions\definitions_omap3.txt
» -board_config Targets\Configurations\configuration_sdp3630_hynix_4g.txt
» Leaving parameter file:omapflash2nd.txt
» Sending size of second file (0x00006D04 bytes)
» Transferring second file to target (0x6D04 bytes)
» Closing boot connection
» Waiting for device (omap usb)
» Timeout reopening connection for USB

Pretty much it did nothing but return a bunch of information, but it did work though in showing me information. That command however was supposed to load a bootloader into the RAM and tell it to do that. I tried various other commands like telling it to read the OneNAND but it kept spitting it out, so my guess is that because it's actually got an operating system on the device it can't accept any instructions (it's not multithreaded, it's only a bootloader), so short of bricking the device intentionally and digging further, there's not a lot that can be done from here.

Now there is no way in hell I would brick a device intentionally unless it was something I knew I can restore right back and have that system handy, and seeing I don't know if this system would work or if it needs something else I just won't take that risk. If it was say a Raspberry Pi where the operating system and bootloader are all stored on a SD card where I can reflash the firmware and everything from another system it's fine, but unfortunately we don't have that luxury here.

I will NOT and repeat NOT under ANY circumstances be giving you guys a download link or a link to where I got the utility I used. As you can see, I also censored the name of the program I used. Why? Because I don't want you guys thinking 'let's go play with it'. I know how flash happy some of you are, you are wanting me to even post links to the broken kernel 3.0 that still doesn't work yet, so I can't trust you guys enough to even tell you where you can look for this program. So why am I telling you any of this then? I'm telling you this because I thought I should let you guys know that there IS a system in place and with a few correct settings it WILL be able to restore a bricked SL. I know this because it has the configuration for the 3630SDP in the program (a very similar platform), and it has OneNAND support. It just doesn't work for me because my device isn't bricked.

Maybe someone with a broken phone could test it, but I'm not going to.