We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

poweroff and reboot don't do what they should



  • Hey all

    In the Omega firmware (b160), the busybox applets poweroff and reboot both reboot the Omega2.
    In the LEDE firmware (17.01), they both appear to power off the Omega2.

    Does anyone know how to get these two applets to do what their names suggest?

    i.e. poweroff should power off the device (or a reasonable facsimile thereof e.g. execute the shutdown scripts, turn off the LED and idle along at low power) and reboot should reboot it?

    TIA

    [edit]
    Ok, so more by luck than design, I stumbled across the Onion patch that implements the reboot: 481-mtd-add-spi-flash-reset-code.patch

    Does anyone know where Onion obtained the information about these reset codes (0x66, 0x99) for this m25pXX? I'd like to learn more about them, what they do and if there are any others of interest.

    I found the datasheet for the flash chip MX25L25635E which makes reference to 66h as the Reset Enable instruction, but can't get clarity on what the 0x99 or 99h refers to.

    [/edit]



  • @cas said in poweroff and reboot don't do what they should:

    In the LEDE firmware (17.01), they both appear to power off the Omega2

    Are you sure?
    You should measure the current consumption of the SoC Omega2(+).
    If the system hangs ("idle along at low power") then 30~35mA @3.3V is not a real poweroff state - I think.



  • @György-Farkas

    Are you sure?
    You should measure the current consumption of the SoC Omega2(+).
    If the system hangs ("idle along at low power") then 30~35mA @3.3V is not a real poweroff state - I think.

    Actually, I wasn't sure, which is why I used the word appear. 🙂
    But I wanted to know myself, so I have hooked up an O2+ on a mini-dock to my charger doctor to observe the results.
    When running with radio enabled, I see 0.10 to 0.12A
    After issuing a reboot, the shutdown processes execute, the radio and LED are turned off and the current consumption drops to 0.00A / 0.01A - so between 0 and 15mA I would guess (charger doctor isn't any more accurate than that).

    So there is still some current draw, until I flip the power switch on the mini-dock at which point it is constantly showing 0.00A.

    So the electronic power off is not really off, just a close facsimile of off.

    Before I open this particular rabbit hole, I suppose I have to really decide if I actually need to power off (or a reasonable facsimile thereof) my O2's or if I want to do it just because I'm accustomed to being able to shut down my usual devices (PC's, servers, phones etc.) electronically without the need to flip a switch?

    Well, I haven't decided that just yet. 😄



  • @cas maybe minidock is drawing current and not omega2.



  • @Douglas-Kryder @cas Sure it does. There's a 3.3 volt regulator on board which, like any other semiconductor, is going to have some, albeit low, leakage current. I suggest the same experiment with the O2 not in the dock. I suspect results would be similar.

    --Bill



  • @cas said in poweroff and reboot don't do what they should:

    ... I have hooked up an O2+ on a mini-dock to my charger doctor to observe the results.
    When running with radio enabled, I see 0.10 to 0.12A
    After issuing a reboot, the shutdown processes execute, the radio and LED are turned off and the current consumption drops to 0.00A / 0.01A - so between 0 and 15mA I would guess (charger doctor isn't any more accurate than that).

    So there is still some current draw, until I flip the power switch on the mini-dock at which point it is constantly showing 0.00A.

    So the electronic power off is not really off, just a close facsimile of off.

    It's very nice indeed. So I have to repeat my previous halt / poweroff / reboot experiments.
    I think you can do this with your custom-made 'LEDE firmware (17.01)' instead of the official b160.
    Could you share with us that FW?



  • @William-Scott said

    @Douglas-Kryder @cas Sure it does. There's a 3.3 volt regulator on board which, like any other semiconductor, is going to have some, albeit low, leakage current. I suggest the same experiment with the O2 not in the dock. I suspect results would be similar.

    Good idea, but I seem to recall from various posts on this forum related to powering the O2's without a dock, it seems that the device will not run reliably unless a regulator is used. Indeed, even Onion's docs about doing this employ a 3v3 regulator Powering the Omega with No Dock.
    But for this test, I suppose I only need the device to boot, enable the wifi and then shutdown, so I reckon I can try doing this with the bench PSU and breadboard dock and see what happens.
    Ah, and I just realised I'll have to employ some kind of USB to serial device for communication, which is something I haven't tried to do as yet, so this could take a little while to test.

    @György-Farkas said

    It's very nice indeed. So I have to repeat my previous halt / poweroff / reboot experiments.
    I think you can do this with your custom-made 'LEDE firmware (17.01)' instead of the official b160.
    Could you share with us that FW?

    Sure, I'll rebuild it without the Onion reboot patch and drop a link here. Will be several hours from now though.
    Bear in mind I just started playing with the LEDE/OpenWrt firmware build, so it's very raw - no Onion packages, wifi works but untested (but sounds promising based on a recent post by @luz) and just a few basic additional packages I find useful (file, screen, usb storage, ext4 & vfat).



  • Ok, here is the link to the fw 2018022002-cas-openwrt-lede-ramips-mt7688-omega2p-squashfs-sysupgrade.bin hosted on dropbox.

    The sha256sum is: 4cd9951daddd94e41781d482e7873a2cede386a7534309dc1fecb354adf27b7d
    File size is: 4194477 bytes (~4.2MB)



  • @cas OK I'll try it next weekend at the latest. Many thanks. 🙂



  • @cas I think I was unclear. My suggestion was to power a dock without an O2+ to see if it draws current. I suspect it will. If I had one we'd already know the answer, but I don't have one.

    Of course my suggestion doesn't get you any closer to a solution, it was just to confirm a theory that could play into your solution.



  • It's been awhile. My recollection is that
    when I use a lab power supply direct-feeding the Omega2 using 3.3V as the supply voltage <-- i.e., nothing but Omega2 consumes the power (no voltage regulator etc. used)

    (again only from my fading memory...)
    if I shutdown O2, the power it consumes is less than 5mA at 3.3V.

    If I intentionally "brown-out" my Omega 2+, <-- intentionally causing voltage dip during WiFi section powering-up time (about 20 second into the boot),
    the Omega2 will hang. In this (non-standard ???) state, it consumes about 40mA at 3.3V.

    ccs_hello



  • @ccs-hello That's really cool stuff to know! I'm in the midst of solving a power distribution problem and this data may help.

    Again, I think I still wasn't clear. Perhaps by now it's moot as it's not direct at your core issue. I had commented on Douglas Kryder's comment about the minidock itself.

    Keep the good info coming! I'll be doing some testing tomorrow (Wednesday) and may be able to add something useful to this issue.



  • @William-Scott said

    @cas I think I was unclear. My suggestion was to power a dock without an O2+ to see if it draws current. I suspect it will. If I had one we'd already know the answer, but I don't have one.

    Of course my suggestion doesn't get you any closer to a solution, it was just to confirm a theory that could play into your solution.

    Ah, yes, I did misunderstand.
    It's an easy enough test.
    The result is that the charger doctor shows no current draw at all with a mini-dock connected and no O2+ installed in it. Flipping the switch on shows 0.00A so if it is drawing anything, it is below the 10mA threshold of the charger doctor's display.
    This is definitely different to the draw with an O2+ installed and 'powered off'.

    Is it possible that an electrical circuit is not even being created unless an O2 is actually installed?



  • @cas said

    Is it possible that an electrical circuit is not even being created unless an O2 is actually installed?

    When you look at the minidock schematics Onion has published on github, you see that

    • the CP2102 USB-to-serial chip is unconditionally powered from the MicroUSB connector's 5V. However, according to its datasheet in suspended mode (not operating) it only draws max 100µA, not noticeable by far with a charge doctor type meter. However if it is not suspended, it will consume 20-26mA. That probably happens when the micro USB is not only delivering power, but is connected to an active USB host (but I am not sure).
    • the linear voltage regulator for the Omega2, the BL1117-3.3, is powered only when the power switch is on. But then, according to its datasheet, it draws a quiescent current of 4 to 8 mA (0.008A). Still too low for the charge doctor to see.
      Bottom line - as long as the CP2101 is not active, everything you see on a charge doctor type meter is what the Omega2 itself consumes.


  • @luz Excellent summary!



  • The underlying issue here has been covered many times before.

    The Omega 2+ has an ill-chosen flash chip, which cannot expose its full capacity unless operated in a 4 byte mode which is incompatible with the configured expectation at boot.

    There is no actual working poweroff command, and there never has been one. However, programs that reboot without putting the flash chip back in a boot compatible mode end up hanging in a tight loop at boot, giving the impression of being sort of "off".

    Also note that unexpected reboots, such as triggered by a watchdog will also result in a hang, rather than a successful boot.

    As the Omega 2 (non +) flash chip fits entirely in 3-byte addressing mode, it should not experience this problem.

    Flash chip commands can be found in the relevant data sheets, as well as the U-Boot and Linux Kernel sources.



Looks like your connection to Community was lost, please wait while we try to reconnect.