I just discovered something that's an issue, booting the ADB kernel from your tool changes the cmd line very slightly so (from a fresh image) it errors on trying to pull the active boot slot. Pictured below is the output of /proc/cmdline with your tool(top) and bulkcmd (bottom)

when trying to do anything except entering burn mode and finding device, i get "bulkcmd timed out!"
here is the output:

PS C:\Users\****\******\superbird-tool-main> python superbird_tool.py --boot_adb_kernel a
Spotify Car Thing (superbird) toolkit, v0.0.8, by bishopdynamics
     https://github.com/bishopdynamics/superbird-tool

Found device booted in USB Burn Mode (ready for commands)
Booting adb kernel on slot a
Booting images/env_a.txt, images/superbird.kernel.img, images/superbird.initrd.img
initializing env subsystem
 executing bulkcmd: "amlmmc env"
 Error: bulkcmd timed out!
 This can happen if the device ends up in a strange state, like as the result of a previously failed command
 Try power cycling the device by pulling the cable, and then boot up and try again
  You might need to do this multiple times
    If the device is connected through a USB hub, try connecting it directly to a port on your machine

Is there a recommended driver for the "GX-Chip" device that shows up in device manager? I found a few links on google for amlogic drivers however they all appear to be from sketchy sites and include executables.

After going through the code, and the dump/restore/ADB process a handful of times, I've gathered a few ideas on optimising the processes:

1. Device Dumping

While it is great to have full partition dumps, due to the speed limit imposed by the lack of mread in pyamlboot, it's not the best way forward to dump both A/B partitions and userdata as well.

My proposal to fix this is to make the dumping logic a bit smarter:

1. First step should be dumping env and parsing it to TXT
2. Then dumping other non-A/B partitions (bootloader, logo, misc, settings)
3. Reading out the active slot from env
4. Dumping boot/dtbo/fip/system/vbmeta of the selected slot
5. Ignoring data partition (it is unnecessary for a working dump

This altogether would reduce dump sizes by:

• ~3GB for data (2731MB if I'm not mistaken)
• 516MB for system
• 4MB for FIP
• 4MB for DTBO
• 16MB for boot
• 2MB for vbmeta

Making the dumping process from 4GB to ~863MB, while also reducing the dumping time from nearly two hours (or in my case, since on macOS the maximum bandwidth seems to be around 94kBps, from around 12 hours!) to around 30 minutes (or, in my case, "only" 3 hours).

Therefore, a future dump would look like this:

firmware_dump/
├─ boot.dump
├─ bootloader.dump
├─ dtbo.dump
├─ env.dump (and/or  env.txt)
├─ fip.dump
├─ logo.dump
├─ misc.dump
├─ vbmeta.dump
├─ system.ext2 (or system.dump)
├─ settings.ext4 (or settings.dump)

This also reduces duplicate/unnecessary data, as well as personally identifying stuff (I've seen a few people in the community share their dumps with a full data partition dump, containing their phone MAC addresses, etc.).

2. Device restoration

Similarly to the above approach, restoration could be optimised by not restoring all partitions, instead:

1. Taking the input dump (and using the old method if an old style dump is found)
2. Reading out the active slot from env
3. Writing non-A/B partitions (incl. env)
4. Writing the A/B partition dumps into the right slot
5. Writing zeroed out data to the inactive slot ( + optionally data, if the user chooses a "wipe" option - or possibly just wiping data's partition headers)

As by the looks of it, Android's A/B tooling is used, the handling of the inactive slot partitions is automatic - upon receiving an update, if an invalid/faulty partition (in our case, zeroed out) is detected, the current slot's appropriate partition is copied over before the OTA delta patch is applied. This means that zeroing out these partitions is perfectly fine.

This would similarly reduce the time needed to restore a device (especially since the nulling can be done by writing zeros to the memory once, then issuing the copy command from the same memory region again and again, speeding up things) as number 1 above.

3. ADB process

This is where you'll hate me. The current ADB process uses a prebuilt boot.img with ADB enabled. This poses a number of compatibility issues, as Spotify, to date, is issuing firmware updates to the CarThing, often patching the kernel/initrd, which can sometimes cause boot issues.

Therefore I'd like to propose a more dynamic approach to enabling ADB, by integrating mkbootimg and possibly abootimg into the process. Instead of booting a prepared boot.img, the ADB option should:

1. Pull env and get current boot slot
2. Pull boot_{activeSlot} and save locally
3. Unpack the newly pulled boot.img
4. Apply ADB enabling patch (and anything else if needed)
5. Build patched boot.img
6. Push that to the device (either write to eMMC or boot directly, dealer's choice)

I am having some issues with usb net on pop os, it won't forward the internet nor certain ports. Can you please elaborate on if there is any setup that needs to be done besides usb-gadget on the car thing?

P.S Sending a pull request eventually I noticed some issues that I know how to solve.

Since we have access to an older Amlogic update utility's source code (https://github.com/yangfl/update/), I was wondering if it would be feasible to port over the mread comment in its whole instead of relying on the incredibly slow flash->memory->host pipeline of the current version.

The above utility seems to be using considerably different commands with the Burn Mode peripheral/gadget, so I think the best approach would be to write completely new methods for this specific purpose.

I know it's somewhat out of scope for this project, but it would be nice to see a completely open source and cross-platform Python implementation that can be used on any host machine.

This is the command I used sudo ./superbird_tool.py --boot_adb_kernel it shows a blank grey screen

Hi, I used the "--boot_adb_kernel" option and it fails.
And I couldn't get the Logo stuck to let me flash the kernel
Does using wsl with usbipd matters?

If you replace line 129 in superbird_tool.py with this:

dev.bulkcmd(r'setenv storeargs "${storeargs} if gpio input GPIOA_3; then run update; fi;"')

It'll make it to where the car thing only goes into burn mode when preset 4 is held down while booting. You could also make it to where the user can choose which button should be held down by changing GPIOA_3 to one of the following:
Preset 1: GPIOA_0
Preset 2: GPIOA_1
Preset 3: GPIOA_2
Preset 4: GPIOA_3
Back: GPIOA_5
Select: GPIOZ_7
Power/Menu: GPIOAO_3

I have identified that setting the auto burn mode env setting with this tool https://github.com/frederic/superbird-bulkcmd then trying to adb boot does work but(after restoring the env) trying to use --enable_burn_mode then adb boot does not work and I am wondering if it's changing a setting it does not need to.