jstefanop

Members
  • Content Count

    16
  • Joined

  • Last visited

About jstefanop

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Looking for same thing...is there a FEX option to disable the GPU during boot?
  2. Hi I am referencing below from this closed thread: So currently I set up wifi through an initial ethernet connection, but the issue is when the wifi connection is successfully setup, that connection does not become active until ethernet is unplugged and board rebooted. Wifi is setup through nmcli...is there an option we are missing that is preventing both network interfaces from working simultaneously? currently just using "sudo nmcli dev wifi connect ssid password password"
  3. Ok so some further research it looks like the sunxi hardware watchdog IS installed and compiled directly into the kernel....I was looking for the sunxi_wtd.ko module and thought just the software watchdog was installed. That option only disables the Magic Close feature, so it has nothing to do with enabling the hardware watchdog. I need that feature anyway since there are instances where we disable the internal controller software and dont want the system to reboot in that case.
  4. Awesome thanks! Looks like this worked. Kernel loads: sunxi_wdt_probe: initialized (g_timeout=16s, g_nowayout=0) What does the nowayout option do? Even though I have it set to "1" in ArmbianEnv kernel still seems to load 0. There are also two watchdog file (/dev/watchdog and /dev/watchdog0) Im assuming one is for the software and the other for the hardware...anyone know which is which?
  5. FYI If anyone has some experience around this or knows how to enable this from mainline armbian build im more than willing to pay for someone's time.
  6. Thanks! Let me know if you find it. I dont see the .ko installed in the mainline system anywhere though so I still think the source needs to be compiled and installed into the kernel. I am also running kernel version 4.14 Armbian 5.60 (Ubuntu 16.04.4) if that matters.
  7. How is some guy that compiled a custom kernel with it helpful? If I knew how to do that I would have already done it. Im trying to figure out how I would go about installing it on the mainline kernel. From what I can tell the option is already turned on in the mainline source compiler options, so it might be a matter of enabling it via ArmbianEnv.txt or through some other mechanism I dont know about. This is why I am asking the question since Im sure more experienced amrbian users would know the answer.
  8. Thanks, already saw those threads otherwise I wouldn't be asking this question. Those have nothing to do with how to install the hardware watchdog driver on the mainline kernel (or to enable it if it does come with the kernel).
  9. Have the same question...running mainline kernel though and it does not seem like wdt driver is installed there as well...
  10. So it looks like by default only softdog.ko is installed, not the hw version that is present on the H2/3. How would we enable to hardware watchdog?
  11. We have deployed the zero for an integrated MCU on one of our products, and in rare occasions we are experience random lockups of the MCU (possibly related to overheating). Its pretty much impossible to debug this since it happens very rarely, but we are trying to mitigate all possible causes. The MCU is controlling a bigger and more expensive board and a fan. If there are internal failsafes that are being triggered by the MCU and locking it up (like temp) we want to disable as many of them as possible (we would rather have the MCU burn up than our main board). Anyone have any insights on orange pi zero OTP or OCP in kernel or uboot parameters we can disable?
  12. Is there anyway to disable GPU and lower DRAM frequency with mainline? Looks like overlays are the best way to do this? Haven't been able to find anything online though.
  13. So trying to run some GPIO interrupts using wiringpi. Using the wiringPiISR function and setting and interrupt handler seems to work, but as soon as the first interrupt happens, the handler gets stuck in some sort of loop and just get infinitely called. Pretty sure this is some bug in sys, since the wiringPiISR function just uses sys gpio calls to do the interrupts. Could be wrong and just be an issue with how wiringPi does it. Either way has anyone come across this and know of a workaround to fix this?