Cannot activate console via UART connection

Hello,
I have a device running OpenWRT to which I'm connecting via UART. To achieve I have connected this to my raspberry pi and use minicom and also tried using an esp32.
In both case I can see and interact with the u-boot (1.1.4), stop it change things, restart. But when the kernel finishes to load and I can interact with the console I get the message:

Please press Enter to activate this console.

and pressing the Enter key i get the following:

1
3vGNd7Q3
Please press Enter to activate this console.

I tried sending 0x0d, 0x0a, 0x04 raw messages via the esp but no success, is there a way to bypass this or to have a direct login prompt? is there a specific raw hex i can send?

The device is a Hue Bridge with the following version:
MIPS OpenWrt Linux-4.14.241
Linux version 4.14.241 (ubuntu@runner-ozs6cf7j-project-41945310-concurrent-0m6kbh) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r11364-ef56c85848))

Kind regards,
dk

  • What device are you connecting UART to (you never mention)?
  • What version of OpenWrt are you running on said device?
1 Like

Just added the info in the main post

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

1 Like

I had this same problem today (and found this thread whilst looking for a solution). I managed to figure out a fix, by looking at the bootloader from Hue that hadn't had the latest firmware updated, and comparing to my Bridge that had this problem. Try the following:

Restart your device, interrupt the boot process and enter the following at the ath> prompt:

setenv bootslot=0
saveenv

And now restart the device. That should do the trick!

@teescdf thanks for the hint, I did try this (setenv bootslot 0) but always get the same result cannot activate the console... Please press Enter to activate this console.
any other ideas?

Hi there,

Did you definitely issue a "saveenv" before you rebooted? (please note that the double "e" in there is NOT a typo)

It may be worth doing the following again:

setenv bootslot=0 (and press enter)
saveenv (and press enter)

And then type in...

printenv (and press enter)

to check that the bootslot value has been updated properly.

1 Like

It has been known for a pretty long time that the Philips Hue hub use a very old and outdated OpenWrt base as firmware. But this device isn’t a router and it is a long way from the official firmware router capabilities. And it doesn’t have any meaningful router capabilities either with wifi (use zigbee to control the lights) and the ethernet is only 10/100Mbit. So I don’t see any point of keeping this post open since Philips Hue have their own support forum. @psherman

Yes I confirm

setenv bootslot 0
saveenv

and confirmed with printenv the bootslot has been updated but I still have the same issue

i just did this and it worked :slight_smile: not sure whats going on with urs

1 Like

serial baudrate mismatch?

Just revisited this myself and realised I made a typo in my previous posts…it should be:

“setenv bootslot 0”

and NOT setenv bootslot=0.

Apologies for the confusion…hopefully things might work now!

You might also try “setenv bootslot 1” to see if that makes any difference.