• Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    lanefu reacted to sgjava in Fast GPIO access   
    After working with sysfs and libgpiod as cross platform solutions I was wondering if there was a faster way using /dev/mem or mmio? I know this gets more bare metal and SBC specific, but for some things you may want absolute speed. for instance claims 1 MHz GPIO writes in Java. However it only supports 3 SBCs as you can see from Is there a more generic way to do this and not lose performance? Using my generated JNA wrappers for libgpiod I get about 2K writes per second. In Python I think it's about 70K using libgpiod Python bindings. I realize you may not always need 1 MHz GPIO writes, but it would be neat to offer this in a more generic way.
  2. Like
    lanefu reacted to Heisath in Espressobin - Only 1 GB RAM detected on a 2 GB board   
    If this works consider to contribute ( and maybe add a PR with your changes to the Github
    We are always looking for helping hands, especially espressobin since this has currently no real maintainer (that I'm aware of).
  3. Like
    lanefu reacted to m][sko in What's your favorite heat sink   
    I mount this one on Hikey970
    I can only recommend!

  4. Like
    lanefu reacted to Igor in THE testing thread   
    FYI. I am talking with Olimex to produce this board in a quantity of around 20 pcs.
  5. Like
    lanefu reacted to klode82 in IDE like VSCode or Atom for Pine64 on Armbian Debian Buster   
    In these days I've spend time in order to searching for something useful.
    I've found cudatext CudaText 
    For me is a good chance to have a good IDE, expect for git integration, but as we says in Italy... "you cannot have a drunk wife and a full barrel"... 
  6. Like
    lanefu reacted to klode82 in IDE like VSCode or Atom for Pine64 on Armbian Debian Buster   
    Only to complete the information, on my Pine64 (with the script suggested by @lanefu:
     - Before Start : 580MB RAM
     - After Start : 1.22GB RAM
     - After 10 minutes with an opened project : 1.74GB RAM
    With CudaText:
     - Before Start : 615MB
     - After Start : 643MB
     - After 10 minutes with an opened project : 648MB
  7. Like
    lanefu reacted to yam1 in Big sale on Odroid MC1   
    Here is what I did with one of mine - added $7.5 neo core as standalone terminal with back to back ethernet and serial connections :-)

  8. Like
    lanefu reacted to guidol in SSH welcome message   
    I like this picture - as welcome message
    _ _ ____ _ _ _ ____ | \ | | _ \(_) | \ | | ___ ___ |___ \ | \| | |_) | | | \| |/ _ \/ _ \ __) | | |\ | __/| | | |\ | __/ (_) | / __/ |_| \_|_| |_| |_| \_|\___|\___/ |_____| Welcome to Armbian Buster with Linux 5.6.2-sunxi64 package bsp-kernel[20.05.0-trunk] u-boot[20.05.0-trunk] dtb [20.05.0-trunk] firmware [20.05.0-trunk] config[20.05.0-trunk] branch[dev] System load: 0.02 0.02 0.00 Up time: 7:49 hours Local users: 2 Memory usage: 21 % of 477MB IP: CPU temp: 44°C Usage of /: 12% of 15G storage/: 1% of 229G  
  9. Like
    lanefu reacted to Igor in THE testing thread   
    New Armbian CI autotest facility:

    USB PSU:

  10. Like
    lanefu reacted to Igor in Armbian v20.05 (Kagu) Planning Thread   
    Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks.
    @Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft
    @JMCC @Werner @karabek @martinayotte @tkaiser @selfbg @Siraj ... to name just a few which might find this move useful  
    I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

    As my example -  what I am currently working and IMHO could be implemented by 20.05:
    - setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs.
    - merging mainstream kernel config in the non-hardware areas could go into this release
    - firmware split up with @ning
    ... more Jira's during a week.
    Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira.
  11. Like
    lanefu got a reaction from Narly9999 in O Pi projects? Application?   
    they did another campaign recently
  12. Like
    lanefu reacted to grunlab in Enable PIDs cgroup   
    - I've reinstalled one of the cluster node using the last image Armbian_20.02.1_Odroidxu4_buster_current_5.4.19_minimal.img:
    adrien@bastion:~ $ kc get node worker-03 -o wide
    worker-03   Ready    <none>   11m   v1.17.3   <none>        Debian GNU/Linux 10 (buster)   5.4.19-odroidxu4   docker://19.3.8
    - pids cgroup is enabled on this image:
    adrien@worker-03:~$ cat /proc/cgroups | grep pids
    pids    3    97
    - No more warning at kubernetes logs level and the node looks stable for the moment :-)
    I think this topic can be closed now.
  13. Like
    lanefu reacted to mantouboji in SPI on OrangePi One Success   
    After some hack,  I use the SPI port on OPi One to connect with a MAX6675 board. 
    The SPI port on One is SPI0,  so armbianEnv.txt should include these:
    overlays=spi-spidev param_spidev_spi_bus=0 param_spidev_spi_cs=0  
    the MAX6675 connects to OPi One as:
    MAX6675                       One GPIO
    VCC                                 PIN17
    GND                                PIN20
    SCK                                 PIN23
    CS                                   PIN24
    SO                                  PIN21
    Then use the attachment program to read from MAX6675
  14. Like
    lanefu reacted to manuti in What's your favorite heat sink   
    Same here (I think @tkaiser shared this model here and everybody copied his idea). 
  15. Like
    lanefu reacted to goathunter in pine64: massive date/time clock problem   
    After about 10 days, two of my Pines are stable. The third one keeps time jumping. This morning, it took me several "set time/reboot" sequences before I was finally able to stop it from time jumping. There's clearly still a problem in 5.3.9 with some AllWinner clocks.

    The patch posted earlier in this thread still seems to be the best workaround to this problem, even if some think it isn't the correct workaround. I have not tried to patch 5.3.9 with that patch, though I may give it a try if I continue to have problems.
  16. Like
    lanefu reacted to Igor in Rename Supporter to Donator   
    Changed a little.
    @guidol Too late  I adjusted and applied all changes.
    red_donator.xcf white_donator.xcf green_donator.xcf
  17. Like
    lanefu reacted to guidol in Rename Supporter to Donator   
    no problem  I had issues to center the text - so you did it.
    I only did try to help out a little bit  
  18. Like
    lanefu reacted to Werner in Rename Supporter to Donator   
    Same as I do
  19. Like
    lanefu reacted to sfx2000 in PREEMPT-RT PATCH for Allwinner H5   
    Curious as to why one wants to apply the patches for preempt-rt in the first place? Do you have a reason/application that would benefit? Most times, one can see an overall decrease in application performance, and to take advantage of preempt-rt, the application must call pthreads in a very specific way - which means that many times, the app must also be rebuilt.
    My reason for asking - if preempt-rt was so awesome, it would already be in the upstream linux kernel mainline and not require the patch. Avoiding politics around preempt-rt - many of the benefits here can be done without the patches, by selecting an appropriate scheduler - schedutil looks fairly interesting at the moment.
    I work on networking oriented applications that have hard deadlines, on MIPS, PowerPC, ARM (both 32bit ARMv7a and 64-bit), and never had a need to apply the preempt-rt patches.
    By networking oriented applications - I'm saying 20mSec framing for SIP-RTP (VoIP apps), along with 3GPP/UMTS signalling - if that ain't close to real-time, I don't know what is.
  20. Like
    lanefu reacted to going in Switching SUNXI-DEV to 5.6.y   
    In the continuation of the conversation:
    PR #1836
  21. Like
    lanefu reacted to Igor in Switching SUNXI-DEV to 5.6.y   
    Functions that helps you can help someone else. If they don't break anything they are welcome and gets accepted into the code. Speed of acceptance further depends on review complexity.
  22. Like
    lanefu reacted to Werner in Is there a better way to prevent a custom kernel update than apt hold?   
    What may help is adding a custom version string in menuconfig when building the kernel package.
  23. Like
    lanefu reacted to Igor in THE testing thread   
    RFC on auto tests. Ideas how to shape this script are welcome!
    Its getting better and better so I hope we will soon be able to make regular use of it and equipment from the topic  
  24. Like
    lanefu reacted to rreignier in OV5640 device tree overlay for OrangePi One H3   
    Now that the camera interface has been merged in mainline Kernel, I would like to try to use the OrangePi OV5640 camera module on my OrangePi One.
    So with the latest Armbian Bionic (20.02.1, kernel 5.4.20), I have been trying to get a device tree overlay.
    But for now, it fails to compile with:
    $ sudo armbian-add-overlay sun8i-h3-csi.dts Compiling the overlay Error: sun8i-h3-csi.dts:27.23-24 syntax error FATAL ERROR: Unable to parse input tree Error compiling the overlay My current overlay looks like this:
    /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3"; fragment@0 { target = <&pio>; __overlay__ { csi_mclk_pin: csi-mclk-pin { pins = "PE1"; function = "csi"; }; }; }; fragment@1 { target = <&i2c2>; __overlay__ { status = "okay"; ov5640: camera@3c { compatible = "ovti,ov5640"; reg = <0x3c>; pinctrl-names = "default"; pinctrl-0 = <&csi_mclk_pin>; clocks = <&ccu CLK_CSI_MCLK>; clock-names = "xclk"; AVDD-supply = <&reg_aldo1>; DOVDD-supply = <&reg_dldo3>; DVDD-supply = <&reg_eldo3>; reset-gpios = <&pio 4 14 GPIO_ACTIVE_LOW>; /* CSI-RST-R: PE14 */ powerdown-gpios = <&pio 4 15 GPIO_ACTIVE_HIGH>; /* CSI-STBY-R: PE15 */ port { ov5640_ep: endpoint { remote-endpoint = <&csi_ep>; bus-width = <8>; data-shift = <2>; /* lines 9:2 are used */ hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; }; fragment@2 { target = <&csi>; __overlay__ { status = "okay"; port { csi_ep: endpoint { remote-endpoint = <&ov5640_ep>; bus-width = <8>; hsync-active = <1>; /* Active high */ vsync-active = <0>; /* Active low */ data-active = <1>; /* Active high */ pclk-sample = <1>; /* Rising */ }; }; }; }; }; So the line 27, which seem to trigger the error is: `clocks = <&ccu CLK_CSI_MCLK>;`
    Also, according to the documentation, the regulator fields are required but this board does not have much regulators (like AXP209), so I have no idea what to write here.
    But this is my first time writing a device-tree overlay so I am not sure what is wrong with this line.
    Could someone guide me to get my overlay right?
    And, does anyone already got the CSI interface working with OV5460 sensor on a H3 based board?
    Thank you.
  25. Like
    lanefu reacted to Igor in Mysql-Server Mysql-client packages not found   
    Yes, Jeedom should update their install scripts.