Jump to content

jstefanop

Members
  • Posts

    28
  • Joined

  • Last visited

Posts posted by jstefanop

  1. After wasting way to much time on this finally figured it out...in case anyone NEEDs UART on Pin 8,10 (UART2B) this is how you do it

     

    Go to amrbian config and edit .dts file

     

    disable i2c3 port (shares same pins as UART2B) ...change status to "disabled" in i2c@ff130000

    hijack uart2 address to point to UART2B pins instead of UART2C (the debug pins)....change phandle-0 in serial@ff1a0000 to 0x143

     

    now this is all you technically need to do, but this is tied to ttyS2 which is also the serial console output which is configured i believe at the kernel level (if anyone know how to disable let me know), so we need to swap ttyS2 to another interface to voice this

     

    so i just changed serial@ff1a0000 to point to ttyS1 by doing below

    swap serial1 ->serial2

    swap uart1 -> uart2

     

    If anyone has an elegant way to do all of the above with a nice dts overlay lmk, have no idea how overlay syntax works. 

     

    BTW also tried directly hijacking serial1 and serial 3 which are disabled (by changing phandle-0), but it only works in serial@ff1a0000...i guess all UART2 ports (UART2a,b,c) are tied to this address. 

  2. So looking around this uart seems to be named uart2b, and is referenced in the current.dts overlay in the armbian-config editor. Figured I could try and edit the rockchip_uar4.dbto file, but guess it needs to be decompiled?

     

    EDIT

    Got it decompile but it does not help, since all that overlay does is disable the SPI port and enable the UART port

     

    So in the main overlay file this is what is referenced for uart2b:

     

    uart2b {

                uart2b-xfer {
                    rockchip,pins = <0x04 0x10 0x02 0xb7 0x04 0x11 0x02 0xb4>;
                    phandle = <0x143>;
                };
            };
     

     

    Would it work to simply copy these pin numbers and put it in the entry for uart4?

     

    Only thing im not understanding is each uart port is referenced to one of these "serial" addresses

     

    serial0 = "/serial@ff180000";
            serial1 = "/serial@ff190000";
            serial2 = "/serial@ff1a0000";
            serial3 = "/serial@ff1b0000";
            serial4 = "/serial@ff370000";
     

    Would I need to create a new one, or can I hijack one of them and point the new pins to it?

  3. On 4/7/2021 at 4:41 AM, disablewong said:

    hello jstefanop!

    Have you released your custom board at last>?

    I want to use the orangepi with my NvME SSD and 10Gbps network card but it seems not detect neither of them..... with the mini-pcie to PCI-E converter and PCIE hub it could not boot at all.....

    Did you built your own kernel to get it working? 

     

     stock kernel works, issue is with orange pi 4 has badly designed FPC connector for PCIE lanes. They didn't group the diff pairs so transmission over FPC cable sucks. We had to make a flex ribbon board to correct this and route as diff pairs so Gen 2 2x works great. Might make some extra and release the board if there is enough interest. 

    IMG_9477.jpg

  4. Looks like OPi4 has two active UART interfaces (ttyS2, S4). S2 is connected to the back 3 pins which are the debug ports, and S4 is uart on pins 19,21. 

     

    Is there anyway to bring up another interface for UART on Pins 8, 10?

     

    Ive tried adding uart1,2,3 etc in armbianEnv file in /boot as well as console=display but non of this works. 

  5. Trying to set frequencies and governor for both types of CPUs on this processor. armbian-config sets the max freq and governor correctly for the two big proccesors but no config for little. 

     

    Tried cpufreq-set for little, but it does not respect governor. If its set to a freq is stays there indefinitely, and if conservative governor is set the max freq goes back to 1.5. 

     

    How do we set max freq to 1.2 for little, and governor to conservative and have both stick like big does with armbian-config?

  6. On 12/11/2020 at 2:26 PM, piter75 said:

    We have Gen1 by default as it's the only one that's officially supported by Rockchip with RK3399:

    https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-current/add-board-orangepi-4.patch#L839

     

    You can however try switching it to Gen2 with pcie-gen2 overlay (overlays=pcie-gen2 in /boot/armbianEnv.txt) and see how it goes:

    https://github.com/armbian/build/blob/master/patch/kernel/rockchip64-current/general-rockchip-overlays.patch#L70

     

    Ok we just finished our 2x M.2 breakout board (uses both lanes exposed by the PCIE port on the orange pi 4). Is there a similar setting for link width? Its currently picking up a x4 Gen 3 M.2 drive with both link speed downgraded to gen 1 (as expected), and width downgraded to 1x. Should be 2x. 

  7. 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"

     

     

     

    Quote

     

    That's simply not true. In case you already established a Wi-Fi connection to your AP (using nmtui or nmcli) then simply do the following:

    shut your SBC down

    unplug Ethernet cable from your SBC (this is totally unrelated to OPi Zero, I emphasize on this since a few morons on the net constantly claim OPi Zero would have non working Wi-Fi)

    restart your AP

    power your SBC on

    Try SSH over Wi-Fi now and you're in. The whole 'problem' boils down to legacy sun8i kernel behaviour, MAC addresses, ARP tables/caches, routing settings on your AP when you first connect your SBC with both Ethernet and WiFi to the same network (your AP/router is involved here too). As soon as your AP doesn't remember to connect to your WiFi MAC address through the Ethernet interface the problem is solved. So what you're running into is only caused by (temporarely) connecting your SBC with both network interfaces to the same AP/router that is most probably configured as a bridge between wired/wireless using same IP address range.

     

     

  8. 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. 

  9. On 1/21/2019 at 5:37 AM, rufik said:

    To make watchdog performing hard reset you need to add this param to /boot/armbianEnv.txt :

    
    extraarg=sunxi_wdt.nowayout=1

     

    But I can't really recall if some quotation should be used (like extraarg="sunxi_wdt.nowayout=1") or not. Just try it yourself.

    This argument is required if you want your watchdog to perform hard reset SBC. And of course just install watchdog package using apt-get.

     

    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?

  10. 9 hours ago, rufik said:

    All you need is just to install watchdog service and set some parameter in armbianenv.txt file - I can't recall it right now, I'll try to search my notes later and post the solution.

     

    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. 

  11. 5 hours ago, Tido said:

    it is not enough wit looking at it...

     

     

     

    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. 

  12. 32 minutes ago, Tido said:

    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). 

  13. 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?

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines