MT8173 OAK boot firmware (workaround)

[EMLommers]

I noticed you have been experimenting with boot firmware. The best result for me using original firmware is besides the GBB flags (Force dev, short delay, others you might have set) is using crossystem loc_idx=100 (flashrom CrOs must be installed) This will result in small text middle of screen, (white text on black screen) If it is possible to remove this 1 line of text in firmware, it will result in just black screen without text, before booting.

I have not yet tested (have to repair my SuzyQ cable), but if the elf file is not signed and extracted from the firmware, the text can be replaced by just zero-ing 0x00 the text (hexeditor) and imported again. This will not change the filesize, and other variable references. Above all keeping your NVRAM intact. The text can be found in the elf file. (fallback/payload, if I am correct)

Maybe the firmware has to be re-signed before flashing back.

[EMLommers]

I noticed it was other way around. White with buzyack text. My SuzyQ cable is working again and replacing the firmware graphic images with just black squares, same for font replacing with empty characters. The next step will be adding a secondary bootloader which is grub2 loader, and config on mmcblkxpx. I think this is the most user friendly approach, and easy to upgrade of kernel, distro etc. To use grub2 as secundary bootloader is to have a safety net if distro crashes and can still use ctrl+u/ctrl+a/esc+refresh for recovery image. Surprisingly board OAK was still used in 2019.

The advantage of using grub2 is easy use of LUKS partitions. Grub2 as firmware and LUKS security with partitions is in my opinion secure enough. If it is possible to embed the password/key in firmware, would be perfect. (not checked yet)

[hexdump0815]

just one note: i just remembered that suzyqable is not yet supported by oak - or is it?

[EMLommers]

CR50/GSC should be there. Could not remember as well. I have tested my SuzyQ cable, but think the board is broken, not working on any platform. Tested on Coral was well. I thought OAK had, but I can open my R13 to be sure....

https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/firmware-cr50-release-9308.25.B-chromeos-3.18/arch/arm64/boot/dts/mediatek/mt8173-oak.dtsi

[EMLommers]

The R13 has an Infinion TPM and STM ec. I was almost sure cr50 was there......

To be sure I opened the R13 and there it was... the screw, easy opening and closing. I was sure I could connect to it externally, it uses the stm32f09x (ec, not tpm) Cr50 is TPM 2.0, OAK has 1.2

[EMLommers]

I checked the Google manual...

Device Support The “Closed Case Debugging” column in the Chrome OS device list indicates whether CCD is supported.

If the device is ARM, the CPU/AP UART works by default in dev mode (you should see a login prompt). x86 devices disable it for performance / power reasons, but UART can be re-enabled with a custom firmware.

[EMLommers]

I made a quick fix for removing images in vbgfx, some examples as well. Can you check if it is working on your side? https://github.com/EMLommers/Chromebook/blob/main/README.md

[EMLommers]

I have checked almost all possibilities and the best solution is: The bin files are Coreboot Archive files; 4 magic bytes, version number, quantity of files, filename, file-offset en file length

1. blank the Background.bmp bitmap, the contents is only 0xFFFFFF, to replace by 0x00000.
2. copy the offset and length of Background.bmp to the rest of bmp files (there is no crc check in place), all the files are the same and size of 1366x768, black
3. replace the font.bin file inside the archive or xor 0xFFFFFF on offset 54 from each character or more. (replacing white with inverse, black) font.bin, is CBAR inside CBAR
4. modify depthcharge (src/vboot/screens.c) &white const value of (0xFF,0xFF,0xFF) to (0x00,0x00,0x00)
5. Also possible to change text color and background color when error (no image found or file corrupt), src/base/graphics.c/h)
6. rebuild original firmware with above mods, sign firmware
7. include new vbgfx.bin/locale_xx.bin
8. flash

Step 4-6 not tested yet. but seems only good solution. Have to use the coreboot/blob/vboot/depthcharge from chromium.googlesource.com to get the latest OAK/ELM firmware version.

-edit: currently building all toolchain configs for coreboot 4.9 to 4.15 and will modify depthcharge and rebuild, checking position of change in value and just patching the color value. The best solution is to modify text color and background color when in text mode, because the backlight is in this mode not enabled. (using loc_idx with invalid number) When needed to restore or recover chromeos, everything is just there. Also when building firmware with 'original firmware' automatic set GBB to 0x3d, overriding NVVARS. I made an error and system could not boot anymore, had GBB set on 0x0d only, so had to use recovery, rest of NVvars were gone. In my previous setup to null all images, not even recovery text or messages, had to switch to console.

When running firmware ELM ro 140 and rw 184, with the latest recovery image ro 140 rw 235, the recovery fails to recover the system because of the new EC firmware. updating the latest EC will result in error when verifying the EC image. If someone is not able to save a recovery image to have an alternative recovery image, when the latest fails, he/she is almost screwed. The latest google recovery image: https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_15474.84.0_elm_recovery_stable-channel_mp-v3.bin.zip is failing over and over when on ro 140 and rw 184

When someone needs text, just press one of the cursor keys (up/down/left/right) to enable graphic layout, else it is black , it is always possible to use a shell script at boot use automated crossystem with loc_idx=128, when pressing by accident on keys, it is removed again with next boot

[hexdump0815]

thanks a lot for sharing your investigations - i think for me this looks like too much effort and for offering it in general it seems a bit too risky to me, as one has to reflash the spi firmware which might worst case brick the device

[EMLommers]

I just bricked my device during the weekend.... It won't startup, only when I connect my suzyqable the blue led lights up. I have been talking to some guys and ccd debugging is possible due to the STM32 inside. Confirmed by some guys at Google. THE Suzyqable is not intended for oak, I need a different cable together with servo. They claim I was already surpresed when nothing happened during plashing... No errors. No warning, nothing... I took privacy a bit too personal. Was bit cranky at Google, because of of the payloads they place in vpd area. Now they want going to use the i2s tunnel for protected firmware updates. They can hide payloads in memory, on disk, in tpm and every hour some where else. They can monitor every instruction send between Android OS and the end user, except when they have to take a leak.

[EMLommers]

They can use lots of GB area for just annoying persons, the tpm. As they are doing now, hiding payload in product name, Elm is ABA-ABC-ABD-, 5DF.. Including the gebinning of GB RO and RW. The 2 parts together is payload to hide the MmC2 or regulate low power bt and other peripheral busses. Google is becoming really dangerous. Came across their intention for more protection against end-user by using more hidden and non analysing bused in real world. They WI move to optee or even higher security. I was really annoyed, I removed my private data from the device. The name elm, with I'd number, other linked info, vpd info, both payloads, recovered tpm, I really do not want then to keep secure data and power over my laptop. So as a result of 0x00 my data and their payload I bricked my device. Haha. Grrr. This happened before on my other chromebook as well.. Cannot help but I really love some of their. Chromebook hardware. I noticed in the coding of chromiumos in the future they want to block human interaction with unlocking /updating etc.. No more recovery images in the future.. It will be more and more difficult in the future to not not (double) open the device, remove the firmware by external programmer, clearing tpm. and thank you Google for the hardware. Nowadays you can hide data, even for hourly updating, data stealing in almost any periferalinside or outside the machine. Everything has internet and a processor. They can mine coins when they notice the router is idle. Escalators. rollatoes, everything with a processor can do calculations for others and we do not even notice...

Have to delay my coding and research for Elm a bit, until I know how to build my cable. And I am sure the device, servo is just a sales pitch.. I am. 10000 percent sure they just want to sell in automotive industry. And they don't care spending the bucks.. I think it is just screwing people over.. IT IS a perfect approach, I read this weekend about hammer and other pieces they wrote aprox 10 years ago.. With code to prove, a hardware device is 'safer' and needed.. Fuck Google, this is robbing people. Everything decrypting is software.. But hards to make money on.. They are now making from software hardware and pretending hardware is safer.. Haha.. I was pissed. I am against bloatware on computer boards and non open source drivers or must be forbidden. For safety of mankind... What will Google know if you cannot alter the OS on your system... So that was the reason I cleared my vpd data.... I Payd for the device, so they have to solve it... I OWN IT.. You that's it for now... If you know some who can supply the parts for cable, and have info to debrick device, very welcome. If it is really taking it over a 3 months period I will ask one of my friends to just flash the STM32F09X with other content.. This was pushing limits.. NOW you know as well.. Google does not like when we modify our products manufactured by them and out of warranty. They want to make sure we replace all data and not a but, better no data than malformed data... Everything or nothing.. Will start investigatjng more and more in firmware, love it.. If someone can hijack the firmware, and I know it is possible. Because they want to interact more with GBb or tpm where they can hide Payloads and have less firmware upgrades, if the system is a bunker you can even sell their work notes and personal /data of company you work for, hide it, borrow it during the blinking if your eye, sell to your competitor and play Shephard over sheep's... Haha... Will continue on pixelbook... Really the best best best laptop ever build.. Of course running Matt's UEFI.... I do not have to think twice anymore.. Google software will be replaced as soon as possible.. El.M is open within 2 minutes, it is impossible to really damage a Machine bin flashing the regions intended for it.. It is dead. dlock, just new software and done. Happened so many times.. Cheers!

--edit Was just reading this https://wicg.github.io/webusb/#app-drivers ChromeOS will be totally webbased or cloud-based.. Running even on simplest hardware or even no hardware.. Just thin client and internet.

ELM/HANA/OAK and many others have CR50. It seems not so difficult to unbrick. Unfortunately my SuzyQ is dead. Ftdi will also Work, just read. https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/firmware-oak-8438.B/board/ The EC/STM32xx is 18d1:500f CR50: 18d1:5014 Tools to connect/update : :https://chromium.googlesource.com/chromiumos/platform/ec/+/refs/heads/firmware-oak-8438.B/extra/ Maybe EC should be updated first..

[EMLommers]

My OAK is running again.... will focus on enabling cr50 / STM32F09X and Firmware. The STM32 is mounted on the backside of mainboard.. I do not know wheter goolgle is playing around with voltage on VBUS and returns data on SBU1 / 2 .. But I realised using 2 22KOhm instead of 22 and 56 of 43K Ohm does the trick as welll.

Also Cr50 is VID5014 14 in hex is 20...... thererfore maybe cr50 uses 20k ohm , not yet tested for RYU (500F -> 15Kohm) etc etc...... INTEL has CCCD , GOOGLE has CCD , ARM has CCD STM has ccd..... just dirrerent resistors

To make it more convenient for myself , I will remove the Winbond W25 WSON8 package and replace by SOIC8 package. easier flashing.... keep u updated