I don't believe SBOOT is encrypted or compressed - just run strings on it. If you see lots of recognizable strings, but don't see the eMMC model number, you can be fairly certain the BL doesn't contain a fix.
I ran strings in the following BL versions:
- My current EMA1
- First changed release ELLA
- ICS BL ALEF
I'm attaching the results and a diff for each version, a lot of the content is gibberish but there are some quite interesting differences, mostly around line 1100.
Maybe it can help us understand a bit more or determine if BL plays a role.
usb_write reg, val
Read the usb ic register
sdcard test command
I'm reversing sboot to see what have changed (no "VTU00M" string doesn't mean there's no fix).
It should be very easy since we have kernel sources (we know how to communicate with the eMMC controller - MMIO addresses etc.).
* If someone has a BinDiff license and wants to help, it'd be great!
It reads 0xFFC00 bytes from the eMMC boot partition and copies them to 0x50000000 (maybe this is an output buffer? I don't know yet).
I also think 0xFFC00 is the boot partition size, so it just reads it all...
U/ 4002.738352 c0 [keys]PWR 1 U/ 4002.983296 c0 [keys]PWR 0 ... U/ 4587.514100 c0 mshci: =========================================== W/ 4587.514336 c0 mmc0: it occurs a critical error on eMMC it'll try to recover eMMC to normal state .... V/ 4587.850296 c0 mmc0: recovering eMMC has been done ... W/ 4587.850849 c0 mmcblk0: unknown error -131 sending read/write command, card status 0x900 W/ 4587.851982 c0 end_request: I/O error, dev mmcblk0, sector 3126872 W/ 4587.852174 c0 end_request: I/O error, dev mmcblk0, sector 3126880 W/ 4587.852330 c0 end_request: I/O error, dev mmcblk0, sector 3126888
|Thread Tools||Search this Thread|