This method allows to flash Ford Sync 3 multimedia module(APIM) through USB cable even if it was bricked 🧱. You don't need to solder either the eMMC card reader or any other wires. The only thing you need is to disassemble the Sync module and short circuit of two pads.
TL;DR ➡️
Ford Sync 3 module consists of two boards:
- Main board - IPC/CCPU with TI Omap5432 SoC as main CPU, RAM, eMMC flash.
- Second board - VMCU. CPLD and microcontroller placed on it. This part is responsible for the CAN interface (since Omap5432 doesn't have it) and this board also acts as an external watchdog for the main CPU.
IPC and VMCU communicates through UART interface (speed 500kbps, for packets exchange uses COBS encoding). More on this maybe some other time 🙃
According to public datasheet OMAP5432 Multimedia Device
we can get info about ways and order of Omap5432 booting (paragraph 2.6 SYSBOOT configuration).
Boot table.
Look at sys_boot3. Exact this pin corresponding to boot priority from USB. If pull down sys_boot3 pin to GND, then Omap SoC will be booting from USB at first.
But how to find sys_boot3 ? 🤔
Answer on this question we could find on another datasheet OMAP5432Multimedia Device Engineering Samples 2.0. This paper contains terminal description and ball locations(Figure 2-1. OMAP5432 AAN S-PBGA-N754 Package (Bottom View)).
Looking for sys_boot3 and see that it's located at V31 place.
But how to get access to V31 ball? 🧐
Since this ball is located under Soc. we can't get to it without a special tools.
Fortunately mate Cusco came to the rescue. He ring out Omap Soc pads and many test points which located at board.
And he found V31!
USB boot MY18.5 (Thanks to IgorStr. for this find)
So, now we ready to boot Sync 3 module from USB.
Time to connect Sync to PC with Linux through miniUSB cable.
Next we need to wake up Sync by CAN packages.
Short two pads circled in red and then enable power 12V.
Look at dmesg log:
kernel: [431083.350475] usb 1-3: new high-speed USB device number 114 using xhci_hcd
kernel: [431083.499541] usb 1-3: New USB device found, idVendor=0451, idProduct=d011, bcdDevice= 0.00
kernel: [431083.499555] usb 1-3: New USB device strings: Mfr=33, Product=37, SerialNumber=0
kernel: [431083.499561] usb 1-3: Product: OMAP5430
kernel: [431083.499566] usb 1-3: Manufacturer: Texas Instruments
Perfect, TI SoC is enumerated on USB bus and awaiting to code download...
But what code we should load to SoC? 🤓
A small remark should be made here. TI Omap5432 USB boot is not actually boot from USB flash drive. Instead we must transfer our executable code (bootloader) to Soc via USB. Then in this bootloader we have to implement the functions to access the Sync eMMC.
After several days of googling, I managed to find links to articles about the TI OMAP5 5432 uEVM ES2.0 (Panda5) debug board
refers to http://omapedia.org. Trying to open that links and ... it's redirected to www.ti.com.
The site was removed. Fuck! 🤬
However, web.archive.org remember everything, or at least a lot 😌
Most of the links to the source code repositories are still alive.
The most interesting tool is UsbBoot(Omapboot).
Getting sources git clone git://git.omapzoom.org/repo/omapboot.git usbboot && git checkout 33af7cb409b603cf7988306ab2ea70f052a9a02b and try to compile them.
To build UsbBoot for Omap SoC, we need a toolchain for ARMv7. First option is to get it from Android repository which is linked in the Omap wiki article. Second and easier option is to get assembled toolchain from here.
Compile UsbBoot
export CROSS_COMPILE=/path/to/toolchain/bin/arm-linux-gnueabihf-
make MACH=omap5 BOARD=omap5uevm
And run...
user@pc:~/$ sudo ./out/omap5uevm/usbboot -f
reading ASIC ID
CHIP: 5430
rom minor version: 02
IDEN: 0000000000000000000000000000000000000000
MPKH: 0000000000000000000000000000000000000000000000000000000000000000
CRC0: 071a9a31
CRC1: 00000000
device is GP
using built-in GP iboot of size 23-KB
sending 2ndstage to target...
waiting for 2ndstage response...
received 2ndstage response...
After loading 2ndstage bootloader to Omap and receiving response from it we can try to attach to SoC with fastboot (yes, it's Android tool) and attempt to execute some commands.
The reformat package is intended for a factory (clean) installation of the Sync 3 OS. It consists of 2 parts:
- MLO - bootloader
- QNX-IFS-REFORMAT - OS image which performing a factory installation of Sync 3 system.
These are exactly the files that we want to flash on the Sync eMMC.
It remains to understand where exactly in eMMC they should be located.
To do this, let's see at the original reformat installation script.
It contains the following line:
update_boot -t -i /tmp/QNX-IFS-REFORMAT -m /tmp/MLO
So, there is some utility called update_boot that flashes the bootloader and OS firmware.
Let's look under the hood...
First of all do strings update_boot:
Usage: %s [-i] [-m] raw partition
-i Path of IFS image file
-m Path of MLO image file
-t Toggle active IFS partition
-r replace current IFS with new one
raw partition Path of raw partition to write IFS and MLO image files, default value is /dev/hd0.
Great, we found a help strings, and now we know which params are accepted by this utility.
Well, let's find out what exactly this software does.
Take Ghidra🐉 and import update_boot to it.
Deсompilation process will not be described in this article. If someone interesting here is
link to shittypseudocode obtained by decompilation.
As a result, we get following layout of Sync 3 eMMC.
| block | offset | name |
|---|---|---|
| 0x0000 | MBR | |
| 0x0002 | 0x0000400 (1024) | boot bank info |
| 0x0100 | 0x0020000 (131072) | MLO |
| 0x0184 | 0x0030800 (198656) | IFS first bank |
| 0x7cd2 | 0x0F9A400 (16360448) | IFS second bank |
Well, it's time to learn how to flash eMMC Sync with custom images transferred via USB from a PC.
Omap usbboot which we previously compile already has fuctions for eMMC read\write. Let's modify it a bit by adding ability to flash custom images into MLO and QNX-IFS-REFORMAT offsets.
👉 sync3flash.
Requirements:
- PC with Linux (virtual machine may not work1, but you can use a livecd Linux on a flash drive, for example puppy linux)
- sync3flash tool
- MLO and QNX-IFS-REFORMAT files from REFORMAT package (you can get patched reformat package here)
- miniUSB cable
So, now we have everything we needed for flashing Sync 3. Let's start:
- Disassembly Sync 3 module to get physical access to main board with Omap SoC.
- Connect Sync directly to PC through USB cable. (Don't try to connect through Sync 3 USB hub. This will not work)
- Start waking up Sync by sending CAN packages.
- Run sync3flash tool
sudo ./sync3flash -i QNX-IFS-REFORMAT -m MLO - Short contacts circled in red
- Enable 12V power supply to Sync module.
If everything goes smooth, you should see output like that:
user@user-PC:/tmp$ sudo ./sync3flash -m MLO -i QNX-IFS-REFORMAT
waiting for device...
reading ASIC ID
CHIP: 5430
rom minor version: 02
IDEN: 0000000000000000000000000000000000000000
MPKH: 0000000000000000000000000000000000000000000000000000000000000000
CRC0: 071a9a31
CRC1: 00000000
device is GP
sending 2ndstage to target...
waiting for 2ndstage response...
sending image to target...size (22696-B/22-KB/0-MB)
sending image to target...size (9279956-B/9062-KB/8-MB)
After 30 seconds Sync 3 will reboot and reformat will start. That's it 😎
This article is for entertainment and educational purposes only. All characters are fictional and coincidences are accidental.
Many thanks to Cusco for the hardware help, Sanek2033 and Au{R}oN for inspiration and Lynx for the idea. 🙏
NOTE:
You can use virtualized Linux on Windows to make it work. Below is example for VirtualBox:
Settings -> USB -> Add Empty Filter
Name: OMAP5 sEVM
Vendor Id: 0451
Product Id: d011
Then sudo ./usbboot -f and do as usual with your board:
* first time should fail as drivers will be installed
* next time will work OK.
Note: We don't support this, so if you have any issues please direct it to the omap5 mailing list.
Footnotes
-
How to flash using Virtual Box (from OmapWiki) ↩
Hi! I have an APIM that was bricked after an update and now only shows a black screen.
MFG date 06/26/2017
ford escape
HJ5T-14G370-KCB
I have set up a test bench as per https://github.com/EtoTen/stm32_can_sim and with everything set up my bricked APIM starts the backlight only after receiving the can bus messages. When I remove the can bus wires and supply 12V the backlight instead does nothing which shows I set the bench up correctly at least.
I should also note my unit has a transistor populated between the 2 pads that you have circled for V31 and GND.
My unit has 2 USB ports a grey and a black one. I have my linux computer connected to the black one.
I can't get the watch -d lsusb suggestion to work nor can I get the sync3flash command to say anything other than waiting for device.
My order of operations:
Plug in the usb into the black connector.
Start the program.
"Waiting for device"
turn on the test bench.
Backlight comes on a second later.
short the 2 sides of the transistor V31 and GND with tweezers for a second
observe nothing changes and I'm still stuck at waiting for device.
Do you know what I could be doing wrong?
UPDATE!
I've soldered a male and female dupont wire to the pins on the board so it stays shorted during running the sync3flash.
After running watch lsusb, I noticed while holding the two pins together
I see for a second texas instruments OMAP5430 show up and then disappear. This looks like great news!
I'm pretty sure the reason it keeps disappearing after a couple seconds is because the canbus thing is sending the start message in a loop? Not sure. I need comments on if the code running in a loop from https://github.com/EtoTen/stm32_can_sim is safe to use or if I was just lucky.
I turned everything off.
I ensured the two wires I soldered to V31 and GND were attached together.
I started the sync3flash.
I applied 12V to the test bench.
I got past the waiting for device section and it uploaded the payload image correctly!
I got it into a Please Insert USB stick... screen.
It's got interesting background images including a mustang logo, a shelby cobra, and a ford logo.
Mine says version:306.
It's alive! now I just have to insert a usb stick with the appropriate update files. Watch me brick it again lol.
TLDR:
If your unit has a transistor where the screenshot doesn't this will still work.
make sure the pins are shorted together for the duration of the sync3flash operation.
monitoring lsusb is a great way to diagnose if you're having usb issues or not going into the boot mode correctly.
Can you update the readme to make sure the exact times when the pins should be shorted are made more clear?