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



  • @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.