MX_Master

Members
  • Content Count

    21
  • Joined

  • Last visited


Reputation Activity

  1. Like
    MX_Master reacted to Igor in Updated images for Rock Pi 4   
    Legacy and mainline kernel.
     
    https://www.armbian.com/rock-pi-4/
  2. Like
    MX_Master reacted to znoxx in missing recordmcount - looks like solved   
    Playing with freshly installed/updated armbian, tried to compile "patched" realtek drivers for those weird realtek 81xx things.
    Bumped error: ./scripts/recordsmcount not found
     
    Go to /usr/src/linux-headers-whatever-version-4.x/scripts
    then, sudo make  recordmcount
     
    After this even DKMS version installed/build without any issues.
    Not sure I will survive next kernel update without manual intervention with this "make", but anyway, it worked for me.
  3. Like
    MX_Master reacted to Igor in Next LTS kernel 4.19.y Allwinner A10, A20, A64, H2+, H3, H5, H6 debugging party   
    Images are building and uploading at this moment. A few more tests and repository will also be updated, so you will be able to upgrade your current build to 4.19.y
  4. Like
    MX_Master reacted to saman in Has anybody a good latency after the RT-PREEMPT patch?   
    Hello,
     
    enabled patch for OrangePi Zero H2+ 512 with build environment Armbian 5.41 on Ubuntu 16.04.3 LTS for build Xenial 3.4.113 with rt143.
    Following results:
    dev@orangepizero:~/rt-tests-1.0$ uname -a Linux orangepizero 3.4.113-rt143-sun8i #2 SMP PREEMPT RT Thu Feb 22 17:25:21 EET 2018 armv7l armv7l armv7l GNU/Linux dev@orangepizero:~/rt-tests-1.0$ sudo ./cyclictest -p 80 -t5 -n # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.47 0.41 0.70 2/138 20170 T: 0 ( 2844) P:80 I:1000 C:3969645 Min: 8 Act: 62 Avg: 54 Max: 2062 T: 1 ( 2845) P:80 I:1500 C:2646431 Min: 8 Act: 90 Avg: 56 Max: 571^C T: 2 ( 2846) P:80 I:2000 C:1984823 Min: 8 Act: 52 Avg: 55 Max: 346 T: 3 ( 2847) P:80 I:2500 C:1587859 Min: 8 Act: 91 Avg: 55 Max: 341 T: 4 ( 2848) P:80 I:3000 C:1323215 Min: 8 Act: 64 Avg: 55 Max: 297 Following interrupts are reported
    dev@orangepizero:~$ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 10: 564 440 442 277 sunxi_gpio_irq_chip xradio_irq 29: 3727320 3647150 3611500 1844956 GIC arch_timer 30: 0 0 0 0 GIC arch_timer 32: 446 0 0 0 GIC uart0 38: 24 0 0 0 GIC twi0 39: 18 0 0 0 GIC twi1 43: 0 0 0 0 GIC PA 49: 1723 0 0 0 GIC PG 50: 0 0 0 0 GIC sunxi_timer0 63: 0 0 0 0 GIC Thermal 72: 0 0 0 0 GIC sunxi-rtc alarm 77: 0 0 0 0 GIC PL 81: 0 0 0 0 GIC arisc_hwmsgbox_irq 82: 0 0 0 0 GIC sunxi_dmac 90: 0 0 0 0 GIC cedar_dev 92: 63924 0 0 0 GIC sunxi-mmc 93: 126255 0 0 0 GIC sunxi-mmc 97: 0 0 0 0 GIC spi0 98: 0 0 0 0 GIC spi1 103: 353 0 0 0 GIC sunxi_usb_udc 104: 0 0 0 0 GIC ehci_hcd:usb1 105: 0 0 0 0 GIC ohci_hcd:usb5 106: 0 0 0 0 GIC ehci_hcd:usb2 107: 0 0 0 0 GIC ohci_hcd:usb6 108: 0 0 0 0 GIC ehci_hcd:usb3 109: 0 0 0 0 GIC ohci_hcd:usb7 110: 0 0 0 0 GIC ehci_hcd:usb4 111: 0 0 0 0 GIC ohci_hcd:usb8 114: 1459073 0 0 0 GIC gmac0 119: 336585 0 0 0 GIC dispaly IPI0: 0 0 0 0 CPU wakeup interrupts IPI1: 0 0 0 0 Timer broadcast interrupts IPI2: 376490 1088699 535403 326760 Rescheduling interrupts IPI3: 111 112 111 106 Function call interrupts IPI4: 2 1 3 0 Single function call interrupts IPI5: 0 0 0 0 CPU stop interrupts IPI6: 0 0 0 0 CPU backtrace IPI7: 0 0 0 0 completion interrupts Best regards!
    Dani
  5. Like
    MX_Master got a reaction from MitchD in OpenRISC core (AR100) for the real-time tasks   
    Service monitoring and restart functionality can be made by any ARM Linux program or script.
     
    If you want to be shure that Linux OS is running normally, you can use a combination of ARM Linux program and ARISC program. If linux program didn't answering to ping from ARISC program, the ARISC program can restart whole device.
     
    I will use the ARISC firmware just for GPIO toggling. My ARM Linux program periodically will send to ARISC a commands to generate exact number of pulses on the specific GPIO pins, with specific frequency rate. 
  6. Like
    MX_Master reacted to jernej in OpenRISC core (AR100) for the real-time tasks   
    AFAIK, mainline kernel runs in unsecure mode, where you can't write to secured registers like R_CPUCFG.
  7. Like
    MX_Master reacted to James Kingdon in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    ... and here are the openssl/7z tests: https://pastebin.com/huSB5LhC
     
    @tkaiser updated results with the performance governor: https://pastebin.com/pUR5D7AA
     
    You were right, it makes a big difference to the openssl results at the smaller block sizes.
     
    The board has passive heatsinks only at the moment, fan is still to be added. I saw some temperatures in the high 60s during these runs, so it's possible/likely that some throttling still occurred.
  8. Like
    MX_Master reacted to James Kingdon in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    @tkaiser Memory test you requested on OPi one+ board: https://pastebin.com/ubszDSUH
     
    Temperature peaked at 53C during the test, so should have stayed well clear of any throttling. I added heatsinks this morning
  9. Like
    MX_Master got a reaction from MitchD in OpenRISC core (AR100) for the real-time tasks   
    Thanks again to the jernej.
     
    Finally i got what i want. Now I can upload a firmware and run the ARISC core without any problems with armbian mainline kernel.
     
    Here is a test firmware source - https://github.com/MX-Master/h3-firmware/blob/test_3/main.c (simple leds blinking)
    Here is the uboot script source - https://github.com/MX-Master/h3-firmware/blob/test_3/fixup.cmd
     
    If somebody wants to test it.. the firmware blob and compiled uboot script can be found here
    https://github.com/MX-Master/h3-firmware/raw/test_3/h3-firmware.zip
     
    Tested with Orange Pi One and Armbian mainline image.
  10. Like
    MX_Master reacted to smaeul in OpenRISC core (AR100) for the real-time tasks   
    @MX_Master If you didn't immediately leave IRC after saying something, I wouldn't have to keep logging in to the forum here 
     
    You mentioned using the MSGBOX for communication. I've written drivers for both sides of the MSGBOX (Linux and ARISC) that you can copy/modify from https://github.com/smaeul/linux/tree/msgbox and https://github.com/crust-firmware/crust/blob/master/drivers/msgbox/sunxi-msgbox.c, respectively. If you want to use more code from my firmware, I have a branch at https://github.com/smaeul/crust/tree/feature/more-boards with untested support for H3-based boards.
  11. Like
    MX_Master reacted to James Kingdon in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    My OPi one+ arrived. I burned the ubuntu image with etcher and it worked fine. I had to manually resize the fs but you expect a few rough edges with a new board.
     
    The bare board runs on the hot side, idling at a reported (but unconfirmed) 48C. Benchmarks quickly push it into throttling at 70C, but even so it is faster (just) than any of my other 4 core boards. I'll add a heatsink and fan and see if I can get the temps under control. If so, and if the board remains reliable it seems like excellent value for money. The H6 looks very promising.
  12. Like
    MX_Master reacted to jernej in OpenRISC core (AR100) for the real-time tasks   
    No, you have to either change u-boot code or edit boot script and add memory write command (mw.l), which writes right value to register.
  13. Like
    MX_Master reacted to jernej in OpenRISC core (AR100) for the real-time tasks   
    Yeah, that's tzpc. I forgot to mention, bsp kernel runs in privileged mode and mainline in unpriviledged mode. That's why you see a difference in behaviour.
  14. Like
    MX_Master reacted to smaeul in OpenRISC core (AR100) for the real-time tasks   
    @MX_Master Try booting with "iomem=relaxed" on your kernel command line. This will allow access to more of the address space from /dev/mem (see https://lwn.net/Articles/302048/).
  15. Like
    MX_Master reacted to chwe in Orange Pi One Plus   
    probably not as long as things do not improve:
    Xunlong provides an outdated 3.10.65 kernel (3.10.108 is the newest and reached EOL in Nov 2017), Mainline is... http://linux-sunxi.org/Mainlining_Effort#Status_Matrix on the way. (Edit: but for sure not ready yet, keep going @Icenowy ) There are no schematics released for the OPi One Plus (there are schematics in the 'user manual collection' but they are for the OPi Lite and it locks like copy paste...  (Design name: H6-PROTO, DC-In 12V/1A --> 5V/2A) spottend so far (xunlongs Ubuntu):
    Thermal zones are there powering over microUSB 'works' (don't do it, but I've to wait for my second 5V barrel plug..) cpu freq seems to stay at 1800 MHz idle TZ0 48°C (1488MHz stress -c 4 ~10min TZ0: 83°C, TZ1: 69°C) minerd (~5min Total: 4.61 khash/s at 1488MHZ TZ087-89°C,  trip_point_1 would be at 90°C) keep in mind,  those numbers do not benchmark the SoC (it might benchmark the current available combination of OS and SoC). Cause SD-card is near to SoC, I stopped minerd to avoid a SD-Card BBQ... 
     
    Hmm.. after minerd, the SoC idles sometimes at 480MHz...  Next topic might be the investigation of the  PMIC (AXP805).
  16. Like
    MX_Master reacted to Larry Bank in Orange Pi One Plus   
    Thanks for noticing that. I've got mine sitting on my desk as a paperweight waiting for someone to release a working Linux distro for it. I'll report back my power consumption and speed measurements later today.
     
    Ugh - now I remember why I appreciate Armbian so much. The Linux distro provided by OrangePi is 1.5GB, yet somehow is missing everything I need. This may take a while...
     
    Update: The board doesn't really seem to have any advantage over H5 boards. The max CPU frequency in the kernel shows as being 1.8Ghz, with the min set to 480Mhz. When pushed by my gcc_perf test, the results didn't fare much better than an RPI3. The power usage is what's really disappointing. The other H2+/H3/H5 boards I've tested usually max out at about 580mA when all 4 cores are cranking. The H6 is supposed to be a 28nm process and I thought that would mean lower power usage. The Orange Pi One Plus maxes out at 830mA when all 4 cores are stressed by gcc. Can anyone else do some testing to see if it matches my results?
  17. Like
    MX_Master reacted to joaofl in Orange Pi One Plus   
    My observations are:
     
    - Android distribution: sucks! Very premature. One can not do anything. I was intended to test video playing, but could not get Kodi to run, neither any other app since Google play is not installed. So, even the apps that show up in the menu do not work. So I rapidly gave up on it.
    Current when idle seemed stable at around 380mA
     
    - Ubuntu server: distro does not boot if you have HDMI plugged in....
    Idle current is 410mA
    Ethernet seems to be really Gigabit... Results for iperf below.
    in this case the current rises to 550mA.
    [ ID] Interval Transfer Bandwidth [ 3] 0.0-60.0 sec 6.34 GBytes 907 Mbits/sec when using bidirectional simultaneous transfers with the following command:
    root@OrangePi:~# iperf -c 192.168.1.100 -t 60 -d ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 192.168.1.100, TCP port 5001 TCP window size: 113 KByte (default) ------------------------------------------------------------ [ 5] local 192.168.1.143 port 37423 connected with 192.168.1.100 port 5001 [ 4] local 192.168.1.143 port 5001 connected with 192.168.1.100 port 51684 [ ID] Interval Transfer Bandwidth [ 5] 0.0-60.0 sec 4.56 GBytes 653 Mbits/sec [ 4] 0.0-60.0 sec 4.92 GBytes 705 Mbits/sec  
    Then I run the gcc_perf @Larry Bank from here: https://github.com/bitbank2/gcc_perf
    Average current was around 560mA, with peak 640mA.
     
    My conclusion is: This board makes sense as a remote video player, connected to some TV with Kodi, probably, so that you can stream from your main server. That because it has great ethernet, with great 4K video decoding capabilities....
     
    One USB3 would make it a good choice for servers... But no...
     
     
     
  18. Like
    MX_Master reacted to jernej in OpenRISC core (AR100) for the real-time tasks   
    Here is attempt to make mainline driver for AR100: https://github.com/mripard/linux/commits/sunxi/wip/ar100 But as branch name says, it's wip and not necessarly working. I didn't try it, I just though it might interest you.
  19. Like
    MX_Master reacted to Igor in Orange Pi One Plus   
    - H6
    - 1GB
    - gigabit
    - 26pin
    - powering only via DC input
    - PMU AXP805
    - 1 x USB2.0 host and 1 x micro USB 2.0
    - size: 69x47mm
    - weight: 50g
    - price USD20-25




  20. Like
    MX_Master got a reaction from MitchD in OpenRISC core (AR100) for the real-time tasks   
    Hi, guys. I need some help in understanding of usage AR100 (OpenRISC) coprocessor inside H3 SoC for the own real-time tasks.
     
    Now i'm using mainline kernel built with RT-PREEMPT patch. I'm using it with Machinekit (LinuxCNC) software to control stepper drivers/motors via GPIO step/dir pulses. But step pulses frequency is too slow (about 17 kHz) because the RT kernel latency is about 30 us.
     
    I think we can use the built-in coprocessor for the realtime GPIO toggling. The AR100 and main Cortex-A7 can talk to each other with built-in MSGBox. And the question is - how to launch my own firmware on the AR100 core?
  21. Like
    MX_Master got a reaction from MitchD in Has anybody a good latency after the RT-PREEMPT patch?   
    I'm using Machinekit with my GPIO driver. I have a big CNC machine (4 axes).
     
    yep. 2279 microseconds is bad result
  22. Like
    MX_Master got a reaction from MitchD in Has anybody a good latency after the RT-PREEMPT patch?   
    If somebody interested, here is a few photos where LinuxCNC running on the Orange Pi One.
    Debian Jessie, FULL RT patch.


  23. Like
    MX_Master got a reaction from Igor in Has anybody a good latency after the RT-PREEMPT patch?   
    If somebody interested, here is a few photos where LinuxCNC running on the Orange Pi One.
    Debian Jessie, FULL RT patch.


  24. Like
    MX_Master reacted to Erikk in Has anybody a good latency after the RT-PREEMPT patch?   
    Im running Armbian Debian Stretch mainline  with 4.14.3-rt4 on a NanoPi Neo Plus2 ( Allwinner H5 ).
    The patch applied just fine and performance is good.
     
    T: 0 ( 1634) P:99 I:1000 C:1810076 Min:      6 Act:    9 Avg:    8 Max:      32
    T: 1 ( 1635) P:99 I:1500 C:1206709 Min:      6 Act:    7 Avg:    8 Max:      44
    T: 2 ( 1636) P:99 I:2000 C: 905025 Min:      6 Act:    7 Avg:    8 Max:      37
    T: 3 ( 1637) P:99 I:2500 C: 724014 Min:      7 Act:    7 Avg:    7 Max:      31
    T: 4 ( 1638) P:99 I:3000 C: 603343 Min:      7 Act:    7 Avg:    8 Max:      42
     
    uname -a:
    Linux nanopineoplus2 4.14.3-rt4-sunxi64 #8 SMP PREEMPT RT Sat Dec 2 22:08:45 CET 2017 aarch64 GNU/Linux
     
     
    Latest Armbian = 
  25. Like
    MX_Master reacted to Christos in Has anybody a good latency after the RT-PREEMPT patch?   
    On 1st Dec. the latest 4.14 rt patch has been released
    -> https://www.kernel.org/pub/linux/kernel/projects/rt/4.14/
    So it might be possible to test now with new 5.36 and 'mainline' option.