jstefanop

Members
  • Content Count

    16
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by jstefanop

  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?
  14. So I have an application which requires 1Mbps UART and wasted a few days trying to debug my board thinking that was the issue (was working perfect at 115kps), so I decided to scope the UART TX from the orangpi, and of course that signal was not actually working at 1Mbps. Scope is saying that its running at 750Kbps. Did some research and it looks like there is some sort of UART scaling frequency set in the driver, which excludes certain bitrates from running (check here https://github.com/jernejsk/linux/blob/master/drivers/tty/serial/sunxi-uart.c#L356-L381 ) Did some further tests and 460Kbps works fine as well as 1.5Mbps (so its not an issue with the driver not being able to go past 750Kbps), but both 921Kbps and 1Mbps default down to 750kbps. Has anyone run into this issue, and figured out how to reconfigure the UART driver to run at 1Mbps?