Modify

Opened 8 years ago

Last modified 4 years ago

#6202 new defect

Atheros AR231x/5312: Engenius (Senao) EOC-1650 hangs after software reboot

Reported by: anonymous Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:

Description

Tested in both 8.09 latest build and trunk 18459.

When issuing the command 'reboot' on command line, the router will shut down all LAN ports and cannot be pinged/reached and will not initiate a proper reboot. It remains a 'brick' until a powerdown/powerup reboot is done.

The same effect occurs if the reboot is triggered by the mtd command with -r option.

Attachments (1)

100-board-trunk-b18541.patch (1.1 KB) - added by albe 8 years ago.
patch with the right GPIO pin for EOC 1650 (AR2315)

Download all attachments as: .zip

Change History (26)

comment:1 Changed 8 years ago by albe

I confirm this problem. Some more details:

If the wifi interface remains disabled in /etc/config/wireless since the last boot, reboot works.

After the wifi interface has been activated, no matter if it is brought down again using wifi down, the reboot stops after the last K99 rc.d script.

Could the cause be the madwifi driver?

comment:2 Changed 8 years ago by dvdwalt

Hi,

See my reply on the forum about this problem.

Had the same problem on the EAP-3660 and managed to fix it by reverting this patch:

/ticket/3953.html

Here's my reply:

https://forum.openwrt.org/viewtopic.php?pid=97933

Hope the developers can use this info and fix the trunk perhaps.

For now I'm one big smile :)

Cheers

comment:3 Changed 8 years ago by albe

I reverted that patch but reboot still does not work on EOC 1650.

But I tested that EOC 1650 can be successfully rebooted through GPIO pin 0.

Function ar2315_restart(char *command) in the trunk board patch is the right way for EOC 1650, exept that AR2315_RESET_GPIO has to be 0, not 5.

comment:4 Changed 8 years ago by anonymous

I tested the trunk 18541 on EOC 1650, applying the following patch of the patch (funny eh?) and it works fine.

I suppose that AR2315_RESET_GPIO was set to 5 for some different board (neither EOC-1650 nor EAP-3660); then my patch should be modified to consider all the other board types.

I hope that the 100-board.patch will be modified in the trunk and in the stable release soon.

Index: target/linux/atheros/patches-2.6.30/100-board.patch
===================================================================
--- target/linux/atheros/patches-2.6.30/100-board.patch	(revisione 18541)
+++ target/linux/atheros/patches-2.6.30/100-board.patch	(copia locale)
@@ -1037,7 +1037,7 @@
 +#define AR2315_GPIO_INT_LVL_HIGH			2   /* High Level Triggered */
 +#define AR2315_GPIO_INT_LVL_EDGE			3   /* Edge Triggered */
 +
-+#define AR2315_RESET_GPIO       5
++#define AR2315_RESET_GPIO       0
 +#define AR2315_NUM_GPIO         22
 +
 +/*
Index: target/linux/atheros/patches-2.6.31/100-board.patch
===================================================================
--- target/linux/atheros/patches-2.6.31/100-board.patch	(revisione 18541)
+++ target/linux/atheros/patches-2.6.31/100-board.patch	(copia locale)
@@ -1039,7 +1039,7 @@
 +#define AR2315_GPIO_INT_LVL_HIGH			2   /* High Level Triggered */
 +#define AR2315_GPIO_INT_LVL_EDGE			3   /* Edge Triggered */
 +
-+#define AR2315_RESET_GPIO       5
++#define AR2315_RESET_GPIO       0
 +#define AR2315_NUM_GPIO         22
 +
 +/*

Changed 8 years ago by albe

patch with the right GPIO pin for EOC 1650 (AR2315)

comment:5 Changed 8 years ago by chillifire

Question: Are you sure the patch only affects 2315 based boards? or are other boards based on the 2317 or 57xx also affected by this patch?
Please advise.

comment:6 Changed 8 years ago by albe

Yes, that's what I mean when I say that the patch should be modified to consider all the other board types (probably some of these other boards work only with GPIO 5).
I hope the 100-board.patch's developer will correct it, setting AR2315_RESET_GPIO based on the detected board type.

byee

comment:7 Changed 8 years ago by chillifire

Is there a way to apply a patch to this effect in 8.09? Please advise

comment:8 follow-up: Changed 8 years ago by mike@…

Hi there.
Has anyone made a working image for the EAP-3660 that fixes this soft-reboot problem yet ?
Note it also happens to the ECB-3500

This is also a problem at X-WRT and Gargoyle-Router - all based on OpenWRT , and there are users reporting the same problems there too.

comment:9 follow-up: Changed 7 years ago by huey07@…

Don't know if anyone was still interested, but I ran into the same problem with my 3500 and wrote a patch so the kernel will check if it is an EnGenius/Senao and sets the reset_gpio and reset_button_gpio accordingly. I'm sure it could be cleaned up, but i've tested it with backfire 10.03 with 2.6.32.

comment:10 Changed 7 years ago by Hanno.schupp@…

Yes, very interested. Can you please post your patch here or send via email? Thanks

comment:11 Changed 7 years ago by huey07@…

Hey if you email me I'll send you over the patch to try it out. huey07@…

comment:12 Changed 7 years ago by anonymous

hey could you post the patch here? Appreciated it. Thanks.

comment:13 in reply to: ↑ 8 Changed 6 years ago by socrates.socrates@…

Replying to mike@…:

Hi there.
Has anyone made a working image for the EAP-3660 that fixes this soft-reboot problem yet ?
Note it also happens to the ECB-3500

This is also a problem at X-WRT and Gargoyle-Router - all based on OpenWRT , and there are users reporting the same problems there too.

Could you please send me the patch that you are referring to?

comment:14 in reply to: ↑ 9 Changed 6 years ago by socrates.socrates@…

Replying to huey07@…:

Don't know if anyone was still interested, but I ran into the same problem with my 3500 and wrote a patch so the kernel will check if it is an EnGenius/Senao and sets the reset_gpio and reset_button_gpio accordingly. I'm sure it could be cleaned up, but i've tested it with backfire 10.03 with 2.6.32.

Could you please send me the patch that you are referring to?

comment:15 follow-ups: Changed 6 years ago by huey07@…

Hey, sorry I just checked my email. I will rebase the patch and once you test it I will submit it for approval.

comment:16 in reply to: ↑ 15 Changed 6 years ago by socrates.socrates@…

Replying to huey07@…:

Hey, sorry I just checked my email. I will rebase the patch and once you test it I will submit it for approval.

Alright thanks. I will wait for it.

comment:17 in reply to: ↑ 15 Changed 6 years ago by socrates.socrates@…

Replying to huey07@…:

Hey, sorry I just checked my email. I will rebase the patch and once you test it I will submit it for approval.

Ok, I obviously misunderstood you. How do I get the patch once you rebase it.

comment:18 follow-up: Changed 6 years ago by nixcamic@…

I noticed that there's further discussion on this here:

https://lists.openwrt.org/pipermail/openwrt-devel/2012-February/013866.html

But then it just abruptly stops. Have any of these patches made it into trunk yet, or should I just compile my own image?

comment:19 in reply to: ↑ 18 Changed 6 years ago by jonbither@…

Replying to nixcamic@…:

I noticed that there's further discussion on this here:

https://lists.openwrt.org/pipermail/openwrt-devel/2012-February/013866.html

But then it just abruptly stops. Have any of these patches made it into trunk yet, or should I just compile my own image?

I was the one who submitted the patch to the mailing list. Unfortunately I did not receive feedback regarding if I needed to change anything. I will rebase the patch and submit it again and hopefully receive some feedback. I will also update this ticket with the new patch.

comment:20 Changed 5 years ago by nixcamic@…

I'm assuming this is still in the same place as it was before?

comment:21 Changed 5 years ago by ben@…

I can confirm that manually applying the patch described above to target/linux/atheros/patches-3.8/100-board.patch in current trunk (r36225) does correct the lockup problem for EOC-1650 and EOC-2611P when issuing a soft reboot. (Great!) However, do please note that other problems related to kernel-level GPIO changes to the atheros platform cause flash access errors that prevent these Engenius units from even booting. The work-around is to disable CONFIG_GENERIC_GPIO, CONFIG_GPIOLIB, CONFIG_GPIO_SYSFS, and CONFIG_LEDS_GPIO in target/linux/atheros/config-3.8, which also disables soft control of the LEDs, unfortunately.

--- target/linux/atheros/config-3.8	(revision 36225)
+++ target/linux/atheros/config-3.8	(working copy)
@@ -40,13 +40,16 @@
 CONFIG_GENERIC_CLOCKEVENTS=y
 CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
 CONFIG_GENERIC_CMOS_UPDATE=y
-CONFIG_GENERIC_GPIO=y
+#CONFIG_GENERIC_GPIO=y
+CONFIG_GENERIC_GPIO=n
 CONFIG_GENERIC_IO=y
 CONFIG_GENERIC_IRQ_SHOW=y
 CONFIG_GENERIC_PCI_IOMAP=y
 CONFIG_GENERIC_SMP_IDLE_THREAD=y
-CONFIG_GPIOLIB=y
-CONFIG_GPIO_SYSFS=y
+#CONFIG_GPIOLIB=y
+CONFIG_GPIOLIB=n
+#CONFIG_GPIO_SYSFS=y
+CONFIG_GPIO_SYSFS=n
 # CONFIG_HAMRADIO is not set
 CONFIG_HARDWARE_WATCHPOINTS=y
 CONFIG_HAS_DMA=y
@@ -79,7 +82,8 @@
 CONFIG_IP17XX_PHY=y
 CONFIG_IRQ_CPU=y
 CONFIG_IRQ_FORCED_THREADING=y
-CONFIG_LEDS_GPIO=y
+#CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_GPIO=n
 CONFIG_MDIO_BOARDINFO=y
 CONFIG_MIPS=y
 CONFIG_MIPS_L1_CACHE_SHIFT=5

cf. /ticket/11969.html

comment:22 Changed 5 years ago by florian

Is there any way we can runtime detect these EOC- boards and not register any GPIO led which would conflict with the serial flash? Would a matching against the OUI part of the MAC address work for instance?

comment:23 Changed 5 years ago by Jonathan Bither <jonbither@…>

Florian, I had initially attempted something like that after dumping the board_configs from each EnGenius model and unfortunately they match other models as well including the Meraki Mini from what I recall. I think the best way to move forward is to migrate it to target-profiles and generic like the ar71xx arch.

comment:24 Changed 5 years ago by ben@…

I've started a thread on the openwrt-dev list asking what are preferred next steps for moving atheros platform to board-specific profiles:

https://lists.openwrt.org/pipermail/openwrt-devel/2013-April/019676.html

comment:25 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.