Keyboard issue on boot

Making a new thread based off of this: Questions for using the Pocket Reform live on music stage - #8 by minute

The “keyboard doesn’t work at boot” sometimes concerns me, it sounds like you’re on an older u-boot version, because this bug should be fixed by u-boot from around May 2025 (it includes some code to properly reset our USB hub) Have you recently tried sudo reform-flash-uboot emmc?

I have run that command but the issues persist. I’m also on the most recent firmware versions.

Sometimes the keyboard just doesn’t enter any text, as seen by the disk encryption prompt not responding to the ENTER key. A reboot (HYPER+0 → HYPER+1) usually restores keyboard function but in some cases it takes multiple reboots or a full power-cycle via the standby switch. It happens on battery power and with external power connected.

The OLED menu does work and respond to key presses correctly in all of these cases though.

I have not yet tried whether this occurs with an external USB keyboard because I mostly use my Pocket when I’m not at home.

1 Like

Maybe this could be a problem with the usb connection cable between the keyboard and main board?

There are two connections/cables between the keyboard and main board. (1) the usb keyboard interface and (2) an interface for talking to the system controller for power on, off etc (stuff that a regular usb keyboard won’t do)

It sounds like (2) is working and (1) is intermittent. If it’s a hardware problem the best case scenario would be a bad cable or connection so I would try to check that, unplug and replug those cables and maybe swap them to see if there is a difference.

1 Like

When this happens, can you try OLED Menu → Reset USB (last menu entry)?

1 Like

I’m on slightly different hardware but I’ve noticed this sometimes happens when I try to power on with low battery, even if I’m charging. Powering off and waiting a few seconds seems to always fix it

I have observed this a bit more with mixed results. The issue is really inconsistent. There was a day recently when the issue was really bad, effectively rendering my Pocket useless for most of the day.

But after that day I opened up the keyboard cover and gave everything a good cleaning with a camera sensor cleaner (those little handheld air blower thingies). There wasn’t much dust in there but since the cleaning things have been working perfectly again.

I can’t really make sense on this because small amounts of dust shouldn’t really affect keyswitches.

However I have a hunch (without any hard data to support it): I think the issue is related to the trackball. The keyboard would often only stop working after I moved the trackball for example.

Is it somehow possible that the trackball when it’s impacted by dirt could make the whole keyboard/trackball assembly lock up? I don’t know, maybe it could produce faulty signals that overwhelm the keyboard controller or something? If that’s a possibility, maybe this issue can be mitigated with a software patch? sadly I just don’t know enough about the firmware and embedded programming in general to look into it.

Again, I’m just throwing out guesses here based on my observations. I hope these are helpful in some way.

2 Likes

I get this problem as well, and frequently. (I just did it now) - and sometimes doesn’t work. (moving through the menu too) I had to use the power switch to power off and on, and now it works. This is happening more frequently, now nearly every day.

Over the next couple of days, I’m going to open it up, and see if I can re-seat the connections, and see if that improves things. Suggestions on which ones to check?

Observation for another few days after the through cleaning: no issues since then, not once.

1 Like

Hello everyone,

I have an MNT Pocket Reform with BPI-CM4 Module (A311D SoC).

After a recent system update, the GUI froze completely and the keyboard became unresponsive (even keyboard input was dead).

To recover, I flashed the latest pocket-reform-system-a311d.img.gz (from source.mnt.re/reform/reform-system-image/-/jobs/17878/artifacts) to a microSD card using dd with bs=8M, conv=fsync, and multiple sync + eject for safety.

Now the device boots from the microSD:

  • OLED shows boot progress
  • U-Boot runs
  • Kernel loads
  • It reaches the Debian CLI first-time setup screen (adduser prompt asking to create a new user)

However, neither the internal keyboard nor any external USB keyboard works — no input is accepted at all.
The OLED, backlight, and trackball seem responsive, but no typing is possible.

I have tried:

  • Hard reset (remove both batteries, wait 30-60 seconds, reinsert)
  • Multiple re-flashes with fsync/sync/eject
  • Different external USB keyboards
  • Blind typing attempts (enter spam, “root” + empty password)

This matches reports of an old U-Boot USB hub reset bug, which was supposedly fixed in U-Boot updates around May 2025 (with proper USB hub reset code added).

The device is within the 2-year warranty period.
I plan to contact https://support.mnt.re/ soon, but I wanted to ask the community first:

  • Has anyone fixed this by forcing a U-Boot update (even without keyboard input)?
  • Is UART serial console the next step? (I have a 3.3V USB-serial adapter ready if needed)
  • Any other workarounds for this exact symptom?

Thank you so much for any advice or similar experiences!

I found an older image (from around April 28, 2025) and successfully booted from it on my microSD card.

The keyboard is now recognized and working properly, and I’m currently running the system update.

This seems to have resolved the unresponsive keyboard problem at the adduser prompt / boot stage.

I’ll keep monitoring after the upgrade, but for now it’s looking very promising!

1 Like

I am having the exact same issue on a pocket reform a311d. I’m kinda pulling my hair out trying to fix this. I’ll try the older image on the SD card and see how that works out.

Where did you find the April 28, 2025 img?

Edit: NVM, I found one that worked here. The image from June of last year works as well.

1 Like

Did you just upgrade packages or did you also run “reform-flash-uboot”?

Do you mean the MNT Reform Setup Wizard? That’s not a CLI but a GUI and it’s not from Debian but from MNT. It also does not have an “adduser prompt”. I’m a bit confused here.

Did your system upgrade involved uprading u-boot? Even if it did:

A system image on sd-card (even when it has different u-boot) will not affect which u-boot is being used. A311D will prefer u-boot from sd-card. Or was your previous setup that you had u-boot on sd-card and never flashed it to your emmc?

If it’s not too much trouble that might help! I didn’t try A311D pocket reform with our latest changes.

Could you also please consider opening a new topic instead of writing your issue into this existing one? Thank you!

It would describe if you described what you did in more detail. Did you just upgrade your system packages? Did you uprade u-boot? You are with the MNT repos?

Which kernel did you upgrade from and which one did you upgrade to?

Yes, I’m using the MNT repos.

I ran the update a few days ago and then shut it down.

I returned to it today and couldn’t get it to boot properly and my Pocket Reform A311D had complete USB/keyboard failure.

I wasn’t getting the luks prompt on startup/reboot and it was dropping into busybox. I tried both the internal and external keyboards but neither worked in busybox. The OLED menu still worked and I could power on/off the machine via the keyboard.

I tried the latest system image on an SD card too and had the same issues with the internal and external keyboards. Come to think of it, nothing USB was working including a USB ethernet adapter.

To fix it, I booted from an older SD card image (tried June and ended up using November 2025), SSH’d in, chrooted into my encrypted NVMe drive, then:

apt remove linux-image-6.18.3-mnt-reform-arm64
apt-mark hold linux-image-mnt-reform-arm64

Now it boots on 6.17.13 with with luks decryption and a working keyboard.

Josch, I’m sorry for the confusion and for starting a new thread.

Thank you, josch and G3M, for your responses and questions. I appreciate the insights and suggestions.

To provide more precise details and address the points raised:

  • Update process: I performed a standard package upgrade using sudo apt update && sudo apt full-upgrade. I did not execute reform-flash-uboot at any point, and U-Boot was not explicitly upgraded during this process. I am using the official MNT repositories.

  • Setup screen clarification: Upon further reflection, the screen I reach when booting from the latest official image is a CLI login prompt (or possibly a rescue/emergency shell), not the expected MNT Reform Setup Wizard (GUI). My earlier description mentioning an “adduser prompt” was inaccurate; it was likely a misremembered fallback shell due to no input being possible.

    When I booted from an older image (approximately April 28, 2025), the MNT Reform Setup Wizard (GUI) displayed correctly, and the keyboard functioned normally during setup.

  • Behavior with the latest image on microSD: I used the following file for flashing:

URL:

FILE:
pocket-reform-system-a311d.img (size: 11,265,901,056 bytes ? 10.5 GB, from my local copy dated Jan 17).

However, when booted from this microSD, the system reaches a CLI prompt instead of launching the Setup Wizard. This is unexpected because a fresh official system image should trigger the GUI Setup Wizard on first boot.

The most likely cause is an incomplete or corrupted flash/write process during dd (e.g., possible issues with decompression if it was originally a .gz file, insufficient sync/eject commands, SD card errors, or write verification failure). This could result in a damaged root filesystem, causing the init process to fail and drop to a CLI fallback/resque mode instead of proceeding to the graphical wizard.

The fact that I had not run reform-flash-uboot is not the direct cause of this CLI fallback, as the official SD image should contain an up-to-date U-Boot. However, in the context of my previous eMMC setup (which was not recently updated), it may have contributed to overall firmware inconsistencies.

  • Temporary resolution with older image: Since my primary system had not been updated since around April 2025, the older microSD image likely used a U-Boot version that predates the known USB hub reset regression (reportedly fixed in U-Boot updates around May 2025). This avoided the keyboard input issue during setup. After applying recent package updates, the problem reappeared, consistent with the bug description.

  • Kernel versions: Unfortunately, exact previous logs are no longer available, but prior to the update, the system was almost certainly on an older kernel from the 5.x series (likely 5.15 or similar, based on early 2025 builds).

  • Boot setup: My main installation was previously flashed to the eMMC (including its U-Boot), but for recovery and testing, I am now booting exclusively from microSD, where the A311D module prioritizes the U-Boot from the SD card.

Next steps I plan to take:

  • Retry flashing the latest official image, ensuring proper decompression (if .gz), verifying file size/checksum if available, using dd with careful sync/eject, or alternatively using a tool like balenaEtcher for safer writing.

  • Proceed with UART serial console using my 3.3V USB-serial adapter. I will attempt to capture boot logs to identify where the failure occurs (e.g., rootfs mount issues or U-Boot USB init).

  • Test the hardware suggestions from josch (checking/reseating USB connection cables between keyboard and mainboard, trying “Reset USB” from the OLED menu).

josch: Thank you for the hardware troubleshooting advice regarding cables and the OLED USB reset.

G3M: If you have encountered a similar CLI fallback when booting fresh images, or have details on your kernel/U-Boot versions, that would be very helpful for comparison.

Thank you again for your assistance.

I am closing this thread. It has derailed from its original topic and given how we currently are facing multiple problem with the images like:

  • unit looses usb (and thus no keyboard)
  • gdm doesn’t start (see the pinned post I created)
  • new u-boot dosen’t reliably allow nvme to be detected by linux

It would be great to tackle each of the problems in their own post and stay on topic without mixing different issues. OP has said that their issue is solved.

I would also highly appreciate not having to read any LLM generated posts. The machines generating such content not only have a very negative impact on our climate, on democracy, on wealth, labor and society in general but by letting a machine generate text one will also miss out on learning about the topic oneself. I want to converse with real humans, learn from them and teach them. I’m not interested in reading half-wrong slop generated by a machine.

@Arasi If you continue to experience problems, please create a new thread where you describe exactly what you did and what is happening. Your post is very confusing and uses terminology which does not quite make sense to me. Lets solve your issue in a dedicated threat to not pollute this one.

@G3M If your issue is that you are dropped to a busybox rescue shell, then your issue is completely unrelated to this one. Please also create a new thread about your issue and describe exactly what you did and what you see.

Thank you!

3 Likes