Omega2 won't reboot?

Nathan Neulinger

Everything else, including upgrade, wifi, etc. seems to be working just fine, but the unit will not reboot. It gets to

[ 254.315898] reboot: Restarting system

on the serial console, and then the lights go out, and it never goes any further. Turning it on/off with the toggle switch on the unit immediately causes it to boot back up.

Just to make sure (was pretty sure it wasn't since no sign of messages in dmesg on desktop) I tried powering with an external usb brick instead of via system usb port. Same result - reboot acts like halt.

Any ideas?

Luciano S.

Does it reboot when you use ssh instead of the serial connection?

WereCatf

@Nathan-Neulinger It's nothing you are doing wrong, reboot is broken. Just wait, it'll probably get fixed at some point in the future.

Pedro Peña

I have the same problem with Omega2+ (one of a lot).

I does not reboots whenever you use reboot command, system upgrade or even reset button on the dock.

seikan

I was having the same problem. I thought something wrong with my dock.

Larry Pinney

It's a known bug the SPI Flash is not being reset to 3B mode.
This will only happen with SPI Flash chips larger than 16M.

Where is the source code for uBoot?
I would look there first

WereCatf

@Larry-Pinney said in Omega2 won't reboot?:

Where is the source code for uBoot?
I would look there first

Nowhere, at the moment. The Onion-devs are completely ignoring my e-mails asking for their version of LEDE and u-boot. (I do have to say that just ignoring the e-mails completely, not even bothering to reply with "No, go away", feels quite shitty and doesn't give a good impression of them.)

Larry Pinney

Ticket submitted ...
#4075 Soft reboot

L. D. Pinney, reported 22 minutes ago
Omega2 fails to reboot when the command 'reboot' is issued.

SPI Flash needs to be reset to 3B mode.

Without access to Source Code I can't help....
Also opened a ticket on the Device Tree Source ...
dmesg |grep DT
[ 0.213727] alarmtimer alarmtimer: no of_node; not parsing pinctrl DT
[ 0.275348] serial8250 serial8250: no of_node; not parsing pinctrl DT
[ 4.208491] hub 1-0:1.0: no of_node; not parsing pinctrl DT
[ 4.316169] hub 2-0:1.0: no of_node; not parsing pinctrl DT
[ 10.420606] snd-soc-dummy snd-soc-dummy: no of_node; not parsing pinctrl DT
[ 10.739534] spidev spi32766.1: buggy DT: spidev listed directly in DT

Yes it's a problem

WereCatf

@Larry-Pinney What's your problem with the device-tree table?

Larry Pinney

@WereCatf

I posted it

parsing pinctrl DT
AND
spidev listed directly in DT

It's in target/linux/ramips/dts

But again ...no source code.

WereCatf

@Larry-Pinney The device-tree table is easy to get and I have already done it. Also, listing spidev directly inside it is not an issue. Some kernel-dev just didn't like it for aesthetic reasons and added that warning, nothing more.

Larry Pinney

@WereCatf

dmesg |grep WAR
[ 10.750853] WARNING: CPU: 0 PID: 474 at drivers/spi/spidev.c:719 init_module+0x6e33c/0x6edec spidev

WereCatf

@Larry-Pinney I just said that the warning was added in the kernel-tree for aesthetic reasons, it is not a bug or an issue. You can either ignore the warning or disable the warning in the kernel-sources, it doesn't change anything.

Larry Pinney

Really?

Let's list a few errors....
[ 0.213727] alarmtimer alarmtimer: no of_node; not parsing pinctrl DT
[ 0.275348] serial8250 serial8250: no of_node; not parsing pinctrl DT
[ 4.208491] hub 1-0:1.0: no of_node; not parsing pinctrl DT
[ 4.316169] hub 2-0:1.0: no of_node; not parsing pinctrl DT
[ 10.739534] spidev spi32766.1: buggy DT: spidev listed directly in DT

Then you can have a look at this LEDE commit to see how to fix a Device Tree Source file

commit b28e94d4bfa1f81219765fc395e63ca81badd8df
Author: L. D. Pinney ldpinney@gmail.com
Date: Thu Dec 29 01:43:08 2016 -0600

ramips: MiWiFi Nano fixes

Use the the dt-bindings macros and add the reset button.

Set the correct polarity for the LEDs and drop the default state.
Remove all trigger for the LEDs. According to the manual the LEDs are
only used to show the operation state, where blue means normal
operation.

Use the MAC-Addresses stored in EEPROM for the ethernet and the
wireless interface.

Signed-off-by: L. D. Pinney <ldpinney@gmail.com>
[use leds only for boot status indication, add proper commit message]
Signed-off-by: Mathias Kresin <dev@kresin.me>

WereCatf

@Larry-Pinney The other notices are not related to the spidev-warning.

Larry Pinney

@WereCatf

But you are wrong... all these errors come from the OMEGA2.dts and are therefore related.

Your question was.
"What's your problem with the device-tree table?"

I think it's been adequately explained.
The OMEGA2.dts file is defective and should be fixed.

WereCatf

@Larry-Pinney said in Omega2 won't reboot?:

The OMEGA2.dts file is defective and should be fixed.

Well, knock yourself out with e.g. https://github.com/WereCatf/source/blob/master/target/linux/ramips/dts/omega2p.dts I only changed a few things to better match how things are done in LEDE-proper.

Luciano S.

@WereCatf said in Omega2 won't reboot?:

Well, knock yourself out with e.g. https://github.com/WereCatf/source/blob/master/target/linux/ramips/dts/omega2p.dts I only changed a few things to better match how things are done in LEDE-proper.

Did you propose pull requests over Github too? Generally those things were not ignored.

Larry Pinney

@WereCatf

OK how about adding this line.
#include <dt-bindings/gpio/gpio.h>

and changing this
gpios = <&gpio1 12 1>;

to this
<&gpio1 12 GPIO_ACTIVE_LOW>;

and since the reset button seems non functional .
try this using another gpio.
such as 2, 11,15, or 17
<&gpio0 11 GPIO_ACTIVE_LOW>;

I would suggest 11 because it changes from high to low during testing.

Do we need to submit a ticket on the reset button too?

Larry Pinney

Do we need to submit a ticket on the reset button too?

Ticket #4088
Reset button does not work.