Harman.Kardon.INVOKE.Flashing.zip

[rbeesley]

This is good. This has the Mrvl_WinUSB driver I was looking for. Also discovered a lot more about the base hardware than I knew before.

Maybe already common knowledge, but I hadn't seen it before, the compute module is a 88DE3006 (BG2CDP). That device hardware ID now makes more sense. Interestingly, based on a quick scan of the firmware and confirmed through other research, this is the same DPU used in Chromecasts v1, v2, and Audio, as well as the Google Home and Google Home Mini. It has an architecture similar to the MV88DE3100, and the image seems to be built around that, further confirmed that the uimage is based on berlin2cdp-dongle. The 79_IMAGE.examples actually mentions that this is using Chromecast's kernel, so there is potentially a lot of source information to pull from.

The next step would be to not directly flash an image, but to boot from a U-Boot ramdisk. This would allow us to build images which can run on the device without overwriting the nand and potentially bricking... That said, I would think this is probably built like Android devices, so there's a potential for soft locking, but if the bootloader isn't overwritten it should be recoverable.

[rbeesley]

And success booting into u-boot. I built the image in WSL, but I boot into the device from Windows. And now I have and ADB shell.

[rbeesley]

I'll have to provide that tomorrow. I followed the steps for running 82_IMAGE through cpio and then repackaged it up. Then I changed (I think) 70_IMAGE so that it had the updated boot parameters and added the loads... Everything except the mload command. Then I ran the usb_boot and changed some things to have it run putty correctly. This got me to the uBoot prompt and I ran the mload. I ran ADB devices and saw that it was present... The bootargs parameters adds debug so that ADB is enabled. That got me running it with an ADB shell. Saving a step, you could probably just add the debug bootargs parameter to use the existing image file and still add ADB.

I wouldn't say it's running perfect because I still have the yellow lights, but I'm connected to the compute board at this point. This mounted the symlinked galios user directory and firmware directories, so right now it's been running and ADB pull. I'm going to let that go for a few hours and see if I can get the system image.

I haven't figured out what 83_IMAGE or 99_IMAGE are yet. They aren't being detected as anything more than "data". I think they must be FS for other partitions, but not sure yet. Since I haven't wiped anything, other than what the reset button probably clears, everything else should be as it was. 99_IMAGE in particular is strange. Looking for strings in it there are lots of graphics references. Like shader and GL things. There are also references to GCastSDK and Microsoft PlayForSure. I figure it must somehow be related to codec playback, but it's going to take more research.

The important parts I see are that the 81_IMAGE is the Marvell Linux kernel for the compute board and 82_IMAGE is the uBoot legacy ram drive. Building something new might be as simple as creating a new ram drive image and keeping the current kernel.

[coggy9]

AFAIK, 99_IMAGE is a system image for another device, probably some Libre devkit with a display. It definitely doesn't work with the Invoke. Bricked my dogfood model, same as retail except for some "Developer Edition" branding on the back, by accidentally flashing it with 99.

You can get the system image by running binwalk on 83_IMAGE, at least the squashfs filesystems of some system partitions. One of those is the main "system" partition, with all the common Linux and Cortana binaries.

The general idea I had was replacing the main "cortana" binary with Mycroft or another alive voice assistant, depending on what that binary actually handles. Couldn't get it to properly start in an emulated chroot to see what it does, since I didn't have a way of getting any logs/output of the actual Invoke.

[rbeesley]

Okay, some more progress.

I was able to mount some of the mtdblocks and found that /dev/blocks/mtdblock11 and /dev/blocks/mtdblock16 has the cortana app. I mounted them in /tmp as it is a writable fs partition and then mounted mtdblock0-16 as yaffs2 read-only. From what I can tell reading through the init scripts, it looks like this is supposed to be mounted on startup, but doesn't seem to be and I don't have the correct location in the file system tree yet, but it is readable. There is PII in that flash memory, so I won't directly share that at the moment. I'm not sure what the difference is between mtdblock11 and mtdblock16. mtdblock0, 3, and 12-15 don't mount with yaffs2, so I'm not sure what those blocks are just yet. The rest don't seem to have anything although they mount.

I looked at 83_IMAGE and 99_IMAGE again. 83_IMAGE looks like a partial version of what is in mtdblock11/16. Perhaps it is laid over them to reset a default configuration. 99_IMAGE looks like it would be for building as it contains a lot of test scripts, libraries, and includes. I'm also seeing a lot of references to anchovy. I suspect they started with a Gen1 Chromecast as the base image and then made it a Podium. This would also explain all the video/graphics content in that image file. They almost certainly aren't supposed to be applied directly as a firmware image.

Depending on how you applied 99_IMAGE, the device you ran it against should still be recoverable.... assuming that you tried to apply it in place of 82_IMAGE. If you wrote it elsewhere, in the flash then you might have problems. If you still have uBoot, then it should still be recoverable.

I took this project: https://github.com/google/adb-sync/blob/master/adb-sync and modified the adb-sync.py to pull the mounted image from the device, including those mtdblock mounts. The adb it expects behaves a little different, so it isn't a perfect match. Under mtdblock11/data1/data/cortana/.skype/ there are DataRv and DataRv. directories. Since my adb is connected through Windows I couldn't directly pull these since Windows doesn't like a filename/directory ending with a ., therefore to Windows these are the same thing. I came up with a hack to extract both with a renamed directlry and while not perfect it does give me a little more insight. There is also a really nasty file which is named \xFF * 256 and in several locations in the mtdblock11/16. That also causes Windows some problems so I didn't grab it. It's small and unclear why it is there. I haven't been able to see what is in it yet, but probably not especially necessary to understand yet either.

All said, I'm pulling about 104 MB from the ROM this way.

[coggy9]

I flashed 99_IMAGE using the same l2nand command given by Harman's instructions for 83_IMAGE. Unit appears to be stuck in some loop, with no U-Boot output, so it'll probably need hardware tools to have any chance of recovery. I even tried booting it into the other "bootloader"/green light mode of holding BT and Mic buttons while starting, and still getting the same unit connected/disconnected loop as flashing mode.

[rbeesley]

This is useful:

# busybox cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00020000 "block0"
mtd1: 00100000 00020000 "pre-bootloader"
mtd2: 00160000 00020000 "env"
mtd3: 00080000 00020000 "aligned"
mtd4: 00200000 00020000 "post-bootloader"
mtd5: 00200000 00020000 "post-bootloader"
mtd6: 01000000 00020000 "factory_setting"
mtd7: 01000000 00020000 "tz_en"
mtd8: 01000000 00020000 "tz_en-B"
mtd9: 01000000 00020000 "bootimgs"
mtd10: 01000000 00020000 "bootimgs-B"
mtd11: 0a900000 00020000 "rootfs"
mtd12: 00000000 00000000 "app"
mtd13: 00000000 00000000 "localstorage"
mtd14: 00000000 00000000 "BDlocalstorage"
mtd15: 00000000 00000000 "bbt"
mtd16: 10000000 00020000 "mv_nand"

So that gives a little more context. Doesn't explain why I'm not seeing things... maybe not yaffs2...

And from adb shell run, /usr/sbin/reboot_usb.sh. This lets you reboot without holding down the reset button and still have uBoot. With this, I think I can make it reboot and load the ramdisk image without complicated steps, so that should get us a little closer.

I scoured /mtdblock11 and 16 and they have lots of important pieces for making Invoke work, but I think /dev/mtdblock12 is the partition listed as the app. Interestingly /etc/init.d/rcS has the command /bin/mount_part --toolbox app /home/galois so maybe that's why I can't mount it... if it's already mounted?

[rbeesley]

Hmmm... disregard most of what I've written. I incorrectly believed that 82_IMAGE was a necessary piece for how things work. As with many things, it seems more complicated. All of these things I discovered have everything to do with booting from the ramdisk. This is why I believe I can't access those partitions. It does probably provide some insight for how to build a replacement custom ROM, but not what I thought I was seeing. I've not figured out a way to have adb access while 83_IMAGE is flashed, and it's quite possible that 83_IMAGE has that turned off in other ways TBD.

[Stedmister]

what about comparing the firmware to another one of HK devices made around that same time?

[coggy9]

AFAIK, this was Harman Kardon's first smart speaker. Other HK speakers from that time probably do not have the same advanced system/SoC that the Invoke does.

[Stedmister]

AFAIK, this was Harman Kardon's first smart speaker. Other HK speakers from that time probably do not have the same advanced system/SoC that the Invoke does.

True, but wouldn't some code be similar?

[coggy9]

Probably not. From what I can tell, the U-Boot interface and flashing methods are specific to Marvell SoCs, which the dumb speakers likely won't have, as they would have no need for relatively powerful SoCs for just aux input and possibly Bluetooth.

[Stedmister]

Nod, well i thank you guys for your hard work.

[coggy9]

I decided to try a dumb idea™️, and just remake the main squashfs in 83_IMAGE and replace the existing one in the image as a test. Only thing I changed was the first time boot voice located at /usr/share/sounds/tts_en-US/C_401_o_startupgreeting.wav with a custom one.

It failed at first, but l2nand was helpful and gave me the crc it got.

Fixed the CRCs in the image, still not sure how they're calculated, and it flashed the rootfs successfully! But apparently I wrote over some other partition named app and it failed there after erasing and flashing that part. Now I need to figure out where that other partition is, and avoid writing into that. The odd thing is that my modified FS is smaller than the original, so it shouldn't be overwriting anything else. Maybe app is just part of the squashfs and it flashes it again/separately for some reason? 🤔

[coggy9]

Never do things without proper rest. I was inserting the FS into the 2nd squashfs image, which is much smaller.

[coggy9]

@rbeesley I've got a test image ready, got an email I can send it to? Would like to confirm it blocks updates before publicly releasing it. I'm probably missing a rule somewhere in my network blocking the update servers, I made sure nothing connected could ever contact the servers.

[rbeesley]

I'll contact you by your listed email.

Request sent.

[rbeesley]

Flashing from Windows requires Advanced Windows Booting to disable unsigned drivers, might be possible (untested) using testmode, or will require Self-Signing the INVOKE drivers. If you are having problems connecting to your device under Windows, this is very likely why.

[coggy9]

Or your chipset just hates working with the Invoke in Windows for some reason. Even with driver signing disabled and with multiple cables, I couldn't get Windows to recognize the device, always had a device descriptor error, but Linux worked the first time.

¯_(ツ)_/¯

[rbeesley]

I spent a good portion of my time on this just getting back to a state where I can use the drivers.

I had previously just done the advanced boot process, but since I'm doing other development work right now, switching back and forth is painful. The testsigning mode only seems to work with Secure Boot disabled... Maybe, but if I'm going to run my system that way, if rather just use the temporary advanced boot. It wasn't enough just to set that BCD flag and reenable Secure Boot.

So today I learned how to self sign drivers. I don't think we'd want to provide a set of drivers we've signed just to make this work, but with self signing I was able to create Mrvl_WinUSB drivers I can load with my system in normal operation. It requires having the SDK and WDK installed to have the right tools, so it is still probably advanced for the typical user.

Anyway, started the uboot process with the updated drivers and got the uboot prompt. I then tried to just mload the new 83_IMAGE for ram drive use... But it's the wrong format. Didn't investigate any further yet as to why. I really would like to figure out how we could load any 83_IMAGE like we can do for the 82_IMAGE, TBD.

I went ahead and flashed the 83_IMAGE. I heard the changed start up sound, and went through the setup process. I did not receive any update notifications or prompts, and as expected the Cortana services don't work. I was not seeing adb over the service port.

However I then realized that it was probably using the WiFi connection. I ran adb connect <invoke ip> and connected. Interesting to see that it starts a shell without echo and isn't the busybox sh from the 82_IMAGE.

Overall, I think you've accomplished what you were trying to do with this image. It'd be interesting to try and keep the service port active as a serial port, but this is something which works.

[coggy9]

You can get a mostly fixed shell by typing adb shell bash.

I haven't touched 82_IMAGE, but after a quick glance at the files inside, I'm guessing its a barebones dev image from Marvell for testing devices with their CPU. 83 contains multiple partitions, including bootloader and DRM keys, so it's made only to be flashed, and is probably too big to fit in RAM to be loaded like that, even if we extracted the correct partitions and got them into an image format that mload expects.

I'm currently trying to get various things to compile for this system, using what appears to be a toolchain similar to what the system on 83_IMAGE was built with. I'll post a thread with info on that tomorrow.