Is it possible to downgrade to a previous firmware without returning to the original ChromeOS firmware

I’m either having some crazy coincidences, or somethings is up, and I was hoping to restore a previous firmware in order to investigate more.

Initially did an update to fix a battery error issue that would send a critically low battery shutdown notification to my laptop when the attached bluetooth mouse was running low.

After that update, starting having trouble with the charger I was using at work. My laptop has a USB-C Charge port on both sides, and both would have trouble making a connection, and then, when unplugged, rather than getting rid of the charging notification, would instead switch to saying “charger is still plugged in but not charging.” I would be closing opening the lid long enough to put the laptop to sleep for a few seconds that reset the charging notification.

Took that charger home to test on other devices, and sure enough, it wouldn’t charge the other ones without the same trouble making a connection. So figured it was a hardware issue. Replaced it with another charger from home (the original one that came with the Asus chromebook) and it charges the other devices without issue, but still has trouble making a connection on the laptop and still doesn’t trigger the charging/not charging notification on either side port.

So either:
a) It’s software, and the cables both were damaged by my “wiggling” them to make a connection after the update began giving me problems with that.
b) Same as the above, but I’ve screwed up the actual ports by “wiggling” them.
c) It’s straight up firmware preventing a solid connection, my ports are fine, my original charger is fine, and the first charger not working any is just a coincidence that happened at the same time (It’s a cheap no-name deal)

So anyway, that’s a very long way to ask "is there a way to downgrade the firmware to test the issue before investing in a new laptop, a new charger, or buying parts to fix the ports on this one?

Thanks

what’s the context here? board? firmware version?

If you’re running my UEFI Full ROM firmware, downgrading and returning to stock have nothing to do with one another, they are orthogonal. Not only that, returning to stock doesn’t magically allow you to flash an older firmware.

Running UEFI Full ROM Firmware. I’m assuming the script installs the latest available update.

I wouldn’t be able to return to stock even if I wanted to unfortunately. This little guy has been on linux for so long, the original ChromeOS backup is probably lost on some USB stick in a drawer somewhere I’ll likely never find it.

System:
  Kernel: 6.12.34-1-MANJARO arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 6.3.5 Distro: Manjaro Linux
Machine:
  Type: Laptop System: Google product: Shyvana v: 1.0
    serial: <superuser required>
  Mobo: Google model: Shyvana v: 1.0 serial: <superuser required>
    UEFI: coreboot v: MrChromebox-2503.0 date: 04/27/2025
Battery:
  ID-1: BAT0 charge: 34.9 Wh (90.9%) condition: 38.4/48.1 Wh (79.8%)
    volts: 12.2 min: 11.9
CPU:
  Info: dual core model: Intel Core m3-8100Y bits: 64 type: MT MCP cache:
    L2: 512 KiB
  Speed (MHz): avg: 900 min/max: 400/3400 cores: 1: 900 2: 900 3: 900 4: 900
Graphics:
  Device-1: Intel UHD Graphics 615 driver: i915 v: kernel
  Device-2: IMC Networks USB2.0 HD UVC WebCam driver: uvcvideo type: USB
  Display: wayland server: X.org v: 1.21.1.18 with: Xwayland v: 24.1.8
    compositor: kwin_wayland driver: X: loaded: modesetting dri: iris gpu: i915
    resolution: 1920x1080~60Hz
  API: EGL v: 1.5 drivers: iris,swrast
    platforms: gbm,wayland,x11,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 25.1.4-arch1.1
    renderer: Mesa Intel UHD Graphics 615 (AML-KBL)
  API: Vulkan v: 1.4.313 drivers: intel surfaces: N/A
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    de: kscreen-console,kscreen-doctor wl: wayland-info x11: xdpyinfo,xprop
Audio:
  Device-1: Intel Sunrise Point-LP HD Audio driver: snd_soc_avs
  API: ALSA v: k6.12.34-1-MANJARO status: kernel-api
  Server-1: PipeWire v: 1.4.5 status: active
Network:
  Device-1: Intel Wireless 7265 driver: iwlwifi
  IF: wlp1s0 state: up mac: <filter>
Bluetooth:
  Device-1: Intel Bluetooth wireless interface driver: btusb type: USB
  Report: rfkill ID: hci0 state: up address: see --recommends
Drives:
  Local Storage: total: 299.83 GiB used: 19.99 GiB (6.7%)
  ID-1: /dev/mmcblk0 vendor: SanDisk model: DA4128 size: 116.48 GiB
    type: Removable
  ID-2: /dev/mmcblk1 vendor: SanDisk model: SC200 size: 183.35 GiB
    type: Removable
Partition:
  ID-1: / size: 113.8 GiB used: 16.59 GiB (14.6%) fs: ext4 dev: /dev/mmcblk0p2
  ID-2: /boot/efi size: 299.4 MiB used: 320 KiB (0.1%) fs: vfat
    dev: /dev/mmcblk0p1
Swap:
  ID-1: swap-1 type: file size: 512 MiB used: 0 KiB (0.0%) file: /swapfile
Sensors:
  System Temperatures: cpu: 39.0 C pch: 28.0 C mobo: 25.9 C
  Fan Speeds (rpm): fan-1: 0 fan-2: 0 fan-3: 0 fan-4: 0
Info:
  Memory: total: 4 GiB available: 3.72 GiB used: 2.08 GiB (55.8%)
  Processes: 200 Uptime: 1h 21m Shell: Zsh inxi: 3.3.38

the script supports restoring the stock firmware via a ChromeOS recovery USB in that case

Charging is a function of the Embedded Controller (EC). The EC firmware is updated as part of the UEFI firmware on many boards, but not yours. That means you’re running the same EC firmware as before you flashed my firmware, and any charging issues are almost certainly unrelated to the UEFI firmware.

Cool. Thanks for the info.

The hunt continues. Thanks for narrowing it down for me.