Replies: 6 comments 21 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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 |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.



Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions