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.