[MT8512/MT8113] stage2 mmc_write command not working

[tux-linux]

Hi,

I have bricked my Kobo Libra Colour (MT8113/MT8512 SoC) by writing a modified bl2 image to flash thinking that SBC/DAA were disabled. It turns out it was not the case, even if mtkclient said they were:

Preloader - 	CPU:			MT8512()
Preloader - 	HW version:		0x0
Preloader - 	WDT:			0x10007000
Preloader - 	Uart:			0x11002000
Preloader - 	Brom payload addr:	0x100a00
Preloader - 	DA payload addr:	0x111000
Preloader - 	CQ_DMA addr:		0x10214000
Preloader - 	Var1:			0xa
Preloader - Disabling Watchdog...
Preloader - HW code:			0x8512
Preloader - Target config:		0xe0
Preloader - 	SBC enabled:		False
Preloader - 	SLA enabled:		False
Preloader - 	DAA enabled:		False
Preloader - 	SWJTAG enabled:		False
Preloader - 	EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT:	False
Preloader - 	Root cert required:	False
Preloader - 	Mem read auth:		True
Preloader - 	Mem write auth:		True
Preloader - 	Cmd 0xC8 blocked:	True
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - 	HW subcode:		0x8a00
Preloader - 	HW Ver:			0xca02
Preloader - 	SW Ver:			0x100
Preloader - ME_ID:			ED8550CF4F003D82A6B4785F4FC67D46
Preloader - SOC_ID:			0000000000000000000000000000000000000000000000000000000000000000

I am now stuck at these glorious lines from the brom:

[DL] 00009C40 00000000 010716

F0: 102B 0000
F3: 1006 0033 [0200]
F3: 4001 00E0 [0200]
F3: 0000 0000
V0: 7027 6006 [0001]
00: 1017 0000
F3: 4002 0000
01: 1027 0001
02: 4002 0000
BP: 0800 02D0 [0002]
EC: 0000 0000 [0001]
T0: 0000 9E09 [000F]
System halt!

I have the exact same issues as @enthdegree when it comes to stage2 preloader reading (probably because the preloader is stored in flash): #1289
I am able to boot MTK_DA_V5.bin successfully up until the DA verify pass and jump to DRAM step, after which it hangs. I get the same [LIB]: No emmc info, can't parse existing preloaders. errors as enthdegree.

I have since been (quite desperately) searching for solutions, since I only need to write one byte back for the BL2 image to be valid against its signature once again - and for my device to be unbricked. I discovered that there was some msdc_pio_write function in this file:

mtkclient/src/stage2/drivers/sd.c

Lines 145 to 226 in e80f288

	int msdc_pio_write(struct msdc_host* host, void *buf)
	{
	(void)host;
	u32 num = 1;
	u32 *ptr;
	u8 *u8ptr;
	u32 left;
	u32 count, size = 0;
	u32 wints = MSDC_INTEN_DATTMO | MSDC_INTEN_DATCRCERR | MSDC_INTEN_XFER_COMPL;
	bool get_xfer_done = 0;
	uint32_t error = 0;
	// unsigned long tmo = jiffies + DAT_TIMEOUT;
	u32 ints = 0;
	sdr_clr_bits(MSDC_INTEN, wints);
	while (1) {
	if(!get_xfer_done){
	ints = sdr_read32(MSDC_INT);
	ints &= wints;
	sdr_write32(MSDC_INT,ints);
	}
	if(ints & MSDC_INT_DATTMO){
	error = (unsigned int)-ETIMEDOUT;
	msdc_reset_hw(host->id);
	break;
	}
	else if(ints & MSDC_INT_DATCRCERR){
	error = (unsigned int)-EIO;
	msdc_reset_hw(host->id);
	break;
	}
	else if(ints & MSDC_INT_XFER_COMPL){
	get_xfer_done = 1;
	if((num == 0) && (left == 0))
	break;
	}
	// if(msdc_pio_abort(host, data, tmo))
	// goto end;
	if((num == 0) && (left == 0))
	continue;
	left = 0x200;
	ptr = buf;
	while (left) {
	if (left >= MSDC_FIFO_SZ && msdc_txfifocnt() == 0) {
	count = MSDC_FIFO_SZ >> 2;
	do {
	msdc_fifo_write32(*ptr); ptr++;
	} while (--count);
	left -= MSDC_FIFO_SZ;
	} else if (left < MSDC_FIFO_SZ && msdc_txfifocnt() == 0) {
	while (left > 3) {
	msdc_fifo_write32(*ptr); ptr++;
	left -= 4;
	}
	u8ptr = (u8*)ptr;
	while(left){
	msdc_fifo_write8(*u8ptr); u8ptr++;
	left--;
	}
	}
	// if (msdc_pio_abort(host, data, tmo)) {
	// goto end;
	// }
	}
	size += 0x200 - left;
	// size += sg_dma_len(sg);
	// sg = sg_next(sg); num--;
	break;
	}
	// data->bytes_xfered += size;
	N_MSG(FIO, " PIO Write<%d>bytes\n", size);
	if (size != 0x200)
	error = -EIO;
	if(error) ERR_MSG("write pio data->error<%d>\n", error);
	//sdr_clr_bits(MSDC_INTEN, wints);
	return error;
	}

I saw it wasn't implemented yet in stage2.py, maybe also because of what I am experiencing. I tried to send the following commands over USB serial:

self.init_emmc()
self.usbwrite(pack(">I",0xf00dd00d))
self.usbwrite(pack(">I",0x1002))
self.usbwrite(pack(">I",1))
self.usbwrite(pack(">I",0xf00dd00d))
self.usbwrite(pack(">I",0x1001))
self.usbwrite(pack(">I",0xEE))
hex_data="0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
binary_data=bytes.fromhex(hex_data)
print(binary_data)
self.usbwrite(binary_data)

Of course, hex_data (512 bytes) has been modified for this issue just in case but I think you get the idea.
I can see that it is successfully receiving the data I want to write:

[DL] 00009C40 00000000 010716
(c) bkerler/k4y0z
WAIT
OK
WAIT
JMP
2ND stage payload
(c) xyz, k4y0z, bkerler 2019-2021
Entering command loop
0x0000CC29
00 00 00 EA  FE FF FF EA  FE FF FF EA  FE FF FF EA
FE FF FF EA  FE FF
Waiting for cmd
Waiting for cmd
0x0000CC29
Waiting for cmd
MSDC_CFG: 0x00000099
GO_IDLE = 0x00000000
SEND_OP_COND = 0x00000000 ocr = 0x00000000
new ocr = 0x00000000
SEND_OP_COND = 0x00000000 ocr = 0x00000000
ALL_SEND_CID = 0x00000000 cid = 0x000000DD 0x00000022 0x000000CC 0x000000FF
SET_RELATIVE_ADDR = 0x00000000
SELECT_CARD = 0x00000000
0x0000CC29
Waiting for cmd
Switch to partition 1 => 0x00000000
Waiting for cmd
Write block 0x000000EE OK
0x0000CC29

But, when I reboot, none of it has been preserved and it just seems like it has never written anything to the MMC (the devices still puts itself in DL mode in BROM and I am able to verify with

self.readflash(type_=1, start=211968, length=512, display=True, filename="test.bin")

that the sector I wanted to write to was not touched at all).

Any ideas why this doesn't work? I joined to this issue the MTK DA logs which say that boot area write protection isn't enabled either.

Thanks a lot for your time! :)
mtk_da_logs.txt

[R0rt1z2]

Sounds stupid, but adding a delay before rebooting the device might be worth a shot. We had similar issues with the Fire TV Stick 4K, and the delay seemed necessary to let the data flush to the eMMC.

[tux-linux]

Hi, thanks for reporting, but I have let the device wait for a very long time before resetting after the write command and it didn't seem to do much either. Thanks anyway!

[R0rt1z2]

Hi, thanks for reporting, but I have let the device wait for a very long time before resetting after the write command and it didn't seem to do much either. Thanks anyway!

I see. If you can dump the GPT, you could create a scatter file and try using SP Flash Tool's Write Memory option with the generic DA. Just make sure to run mtkclient's payload option first to disable DAA.

[notmarek]

Hi, thanks for reporting, but I have let the device wait for a very long time before resetting after the write command and it didn't seem to do much either. Thanks anyway!

I see. If you can dump the GPT, you could create a scatter file and try using SP Flash Tool's Write Memory option with the generic DA. Just make sure to run mtkclient's payload option first to disable DAA.

DAA isn't enabled on the chip according to mtkclient

[R0rt1z2]

Hi, thanks for reporting, but I have let the device wait for a very long time before resetting after the write command and it didn't seem to do much either. Thanks anyway!

I see. If you can dump the GPT, you could create a scatter file and try using SP Flash Tool's Write Memory option with the generic DA. Just make sure to run mtkclient's payload option first to disable DAA.

DAA isn't enabled on the chip according to mtkclient

Preloader usually lies about DAA, SBC, and SLA. On all my Amazon devices, it claims they're off, but in reality, they're enabled.

[tux-linux]

From what we have discovered, secure boot might be disabled, but we know it at least checksums the bl2 image upon loading and it refuses to boot if the sum is not a match.