[Fire General] stickfiretv2020:
Hardware related Ideas/Notes:

Tried hw method for CMD/DAT0/CLK and the emmc pin at front, no response (CMD jumps to preloader while all other test points result in no response - same as previous testers of newer Fire 7 device)

Anyone know what the other testpoints are, like:

VCOM/VGH/RST/ON/ID/VBAT/AUX_NTC/PWRKEY/USB_ID/DP/DM/VBUS/VGP3_PMU/FCHR_ENB/COL0

GND - Why did they put a pad for this when there is GND everywhere on the board?

CLK/CMD/DAT0 - MicroSD connection! NOT eMMC... Test with ohmmeter against MicroSD pins!

TX/RX - UART

SDI/SDO/SCI/CS

Is SDI/SDO/SCI/CS some kind of SPI or another interface? Likely it is SPI (anyone know how to talk to it? I have raspberry pi's / picos / arduinos / ch341a)

What about the covered over points?

VIO8_PMU - 1.8V to eMMC?

VCC_IO - Cant rememebr if it is this one or above, need to retest.

VEMC3V_PMU - 3.3V to eMMC?

VCCK_PMU - Voltage to SoC?

AVOD/VGL/LEDA/LEDK/SPK_N/SPK_P/VPROC_PMU/VMCH_PMU/VMCA_PMU/VCAMD_IO/VCAMD_PMU/HPL/HPR

Maybe can make a list of all points and how they behave for this board?

Anyone know of how to interface directly with the eMMC by soldering MMC adapter?

Tried to attach to dat0 from front of board but ended up tearing pad - need to use a better method than soldering, maybe use Rubber+Needles+Crocodile Clips

Any chance of doing stock recovery by UART RX/TX flash?

THOUGHTS: Probably not, likely only get boot logs.

Can I use a raspberryPi B to connect to UART, Do I have to use RS232 or TTL?

THOUGHTS: No, possibly dangerous, RaspberryPi B is at 3.3v whilst this is possibly 1.8v - need to measure using voltmeter. RS232 should be safe as it uses -13v-+13v for RX/TX. USB TTL would also need a logic level shift from 3.3v to 1.8v. Therefore USB RS232 adapter is best choice. (I think for TX from board to RX from USB Serial - But dangerous from RX from board to TX from USB Serial because of over voltage from adapter possibly supplying +13v - need confirmation as this is useful for potentially debugging other gear by UART) Problem with RS232 is signal is inverted when read, therefore needing inversion by another chip to display correctly - better RS232 USB adapters seem to be able to be flashed by EEPROM to invert signal (FTDI ones with mProg). Need a USB TTL for further testing. Need to see if PL2303 can be hacked to invert signal - maybe driver hack for linux possible? Anyone have any simpler solutions to see UART logging from this device, or do I need a logic level analyser?

If so how to connect it?

THOUGHTS: Connect TX to Pin 2 from RS232 and GND to Pin 5 (Dont attach RX from board, else possible over voltage from sending data from PC). Using CH340G attach RX to TX on PCB, GND to GND, Make sure cables are shielded or split due to interference from cabling touching each other. Connection currently without battery installed seems to output gibberish, need to test with battery installed (Maybe bootloader logs will output) -Currently despite gibberish output it is most likely 961200 baud Databits 8, no flow control, 1 stop bits for preloader. Bootrom logging sounds like it might be 115200 (according to older kindle device thread )

Since the device can seemingly only output from UART, why is there an RX pad on the board? How or what can you transmit to the device by UART?

Is there anything inside the console for flashing back 6.3.1.5? No Console

Managed to hook this pad up by UART - RS232, but despite trying all the baud speeds / settings only getting gibberish output - is this because the UART is spitting out MTK flashing protocol language since its in preloader mode without battery attached?

THOUGHTS: Think it is inverted signal logic rather than low level protocol.

Should I attach battery instead of USB power to see Bootloader logs? If so, how to attach battery to board whilst UART is soldered to cabling?

THOUGHTS: Unlikely to help, and potentially dangerous

Anyone tried any dongles with the Fire 7 or any other Amazon devices? MT/NCK/etc?

Last thing I can think to try is the NCC Group Hack on mt8163v chips using FPGA and chip whisperer. Anyone know how to simplify that process for this scenario of brick recovery rather than full unlock? - sounds like some well timed shorts in bootup might glitch it enough. Does this even work still or was this fully patched as part of mtk-su patching? Tried GND VCCK_PMU but couldn't get anything other than normal boot

There’s A Hole In Your SoC: Glitching The MediaTek BootROM

This research was conducted by our intern Ilya Zhuravlev, who has returned to school but will be rejoining our team after graduation, and was advised by Jeremy Boone of NCC Group’s Hardware &…

research.nccgroup.com