sfx2000

Members
  • Content Count

    594
  • Joined

  • Last visited


Reputation Activity

  1. Like
    sfx2000 reacted to Christian2607 in [INFO] H5 NanoPI Neo2 IS2 Dac 5102a   
    DTS overlay to activate I2S DAC 5102a on Armbian Buster 5.4.43
    armbian-add-overlay sun50i-h5-i2s0-out.dts If you don't have headers armbian-config (software->headers)
     
    Manual install whithout headers
    mkdir /boot/overlay-user/ dtc -I dts -O dtb sun50i-h5-i2s0-out-no-header.dts -o /boot/overlay-user/sun50i-h5-i2s0-out.dtbo add user_overlays=sun50i-h5-i2s0-out to /boot/armbianEnv.txt  
    sun50i-h5-i2s0-out.dts
    /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h5"; fragment@0 { target-path = "/"; __overlay__ { pcm5102a: pcm5102a { #sound-dai-cells = < 0x00 >; compatible = "ti,pcm5102a"; status = "okay"; linux,phandle = < 0x26 >; phandle = < 0x26 >; pcm510x,format = "i2s"; }; }; }; fragment@1 { target-path = "/aliases"; __overlay__ { i2s0 = "/soc/i2s@1c22000"; }; }; fragment@2 { target = <&i2s0>; __overlay__ { status = "okay"; pinctrl-0 = <&i2s0_pins>; sound-dai = <&pcm5102a>; pinctrl-names = "default"; }; }; fragment@3 { target-path = "/"; __overlay__ { sound_i2s { compatible = "simple-audio-card"; simple-audio-card,name = "I2S-master"; simple-audio-card,mclk-fs = <256>; simple-audio-card,format = "i2s"; status = "okay"; simple-audio-card,cpu { sound-dai = <&i2s0>; }; simple-audio-card,codec { sound-dai = <&pcm5102a>; }; }; }; }; };  
    sun50i-h5-i2s0-out-no-header.dts
    /dts-v1/; / { compatible = "allwinner,sun50i-h5"; fragment@0 { target-path = [ 2f 00 ]; __overlay__ { pcm5102a { #sound-dai-cells = < 0x00 >; compatible = "ti,pcm5102a"; status = "okay"; linux,phandle = < 0x26 >; phandle = < 0x26 >; pcm510x,format = "i2s"; }; }; }; fragment@1 { target-path = "/aliases"; __overlay__ { i2s0 = "/soc/i2s@1c22000"; }; }; fragment@2 { target = < 0xffffffff >; __overlay__ { status = "okay"; pinctrl-0 = < 0xffffffff >; sound-dai = < 0x26 >; pinctrl-names = "default"; }; }; fragment@3 { target-path = [ 2f 00 ]; __overlay__ { sound_i2s { compatible = "simple-audio-card"; simple-audio-card,name = "I2S-master"; simple-audio-card,mclk-fs = < 0x100 >; simple-audio-card,format = "i2s"; status = "okay"; simple-audio-card,cpu { sound-dai = < 0xffffffff >; }; simple-audio-card,codec { sound-dai = < 0x26 >; }; }; }; }; __symbols__ { pcm5102a = "/fragment@0/__overlay__/pcm5102a"; }; __fixups__ { i2s0 = "/fragment@2:target:0\0/fragment@3/__overlay__/sound_i2s/simple-audio-card,cpu:sound-dai:0"; i2s0_pins = "/fragment@2/__overlay__:pinctrl-0:0"; }; __local_fixups__ { fragment@2 { __overlay__ { sound-dai = < 0x00 >; }; }; fragment@3 { __overlay__ { sound_i2s { simple-audio-card,codec { sound-dai = < 0x00 >; }; }; }; }; }; };  
  2. Like
    sfx2000 reacted to DavidGF in Helios4 - Cryptographic Engines And Security Accelerator (CESA) Benchmarking   
    Not sure whether it's a good idea to bump this thread but just my 2cts on this:
    CESA is quite good for use cases such as LUKS. Obviously you will need to use aes-cbc (use 128 bits for maximum perf).
    In this mode the CPU usage is quite low (you can see two kernel workers doing 10% on each CPU and a ton of interrupts, but other than that works well) which is awesome to keep the load of the CPU which is already limited. In comparison on using pure CPU, in my current setup I get:
     
     - Plain access to disk: 180MB/s
     - LUKS2 + CESA: 140MB/s
     - LUKS2 (no CESA): 52MB/s
     
    I tuned LUKS using sector size= 4096 and keysize=128, as well as using aes-cbc-plain64.
    For me this is quite good already even tho CESA only supports some "relatively old" ciphers.
     
    Hope this helps other people!
  3. Like
    sfx2000 reacted to balbes150 in Armbian-NG, armbian's little brother project   
    The issue has already been resolved and the Armbian build works on ARM devices.
  4. Like
    sfx2000 reacted to crouchingtigerhiddenadam in [Info] NanoPi Neo/Neo2-OLED-Hat does work with armbian   
    If anybody is interested, I've got a single python script that works without needing to install any of the FriendlyElec software. Just enabled i2c0, python and a few dependencies.
     
    You can find the code on: https://github.com/crouchingtigerhiddenadam/nano-hat-oled-armbian
    The screen turns off after 15 seconds of inactivity to reduce burn-in, variable update rates, splash screen, date/time screen, computer stats screen and a shutdown screen.
  5. Like
    sfx2000 got a reaction from lanefu in Allwinner H5 phased out?   
    Allwinner will continue to make chips of any variant as long as there is a minimum order quantity (MOQ) commitment upfront with cash to spin up the fab...
     
    Might take a volume commitment - they will definitely make that happen, if the volume is enough to be profitable...
     
    Olimex went thru this exercise with the Allwinner T2/A20 chip...
     
    Just takes the money to make it happen...
  6. Like
    sfx2000 got a reaction from gounthar in Bridging Wi-Fi to Ethernet   
    Hit the easy button and install OpenWRT
     
    Done and done - solves your problem.
     
    Move on to other interesting things with your homelab.
  7. Like
    sfx2000 got a reaction from Werner in Armbian-NG, armbian's little brother project   
    In personal experience - it's generally doable... and it's really the makefiles for externals like device drivers that are the devils to be solved.
     
    In any event - cross-builds produce the same performance as native - ARM on X86, MIPS on ARM, ARM on ARM...
     
    For most folks - LEDE/OpenWRT has solved that particular problem...
  8. Like
    sfx2000 got a reaction from Werner in Help me to setup a Wifi AP via command line   
    ** Network Manager CLI **
     
    use NMCLI
    $ nmcli device status DEVICE  TYPE      STATE         CONNECTION          enp1s0  ethernet  connected     Wired connection 1  wlp2s0  wifi      disconnected  --                  lo      loopback  unmanaged     --    
    to check radio
    $ nmcli radio WIFI-HW  WIFI     WWAN-HW  WWAN     enabled  enabled  enabled  enabled 
    Let's see what's out there... scan for AP's
    $ nmcli dev wifi list SSID                  MODE   CHAN  RATE       SIGNAL  BARS  SECURITY  MYSSID         Infra  11    54 Mbit/s  100     ▂▄▆█  WPA2      MYSSID         Infra  132   54 Mbit/s  100     ▂▄▆█  WPA2      SOMEOTHERSSID  Infra  52    54 Mbit/s  49      ▂▄__  WPA2      MYSSID         Infra  149   54 Mbit/s  45      ▂▄__  WPA2      MYSSID         Infra  11    54 Mbit/s  42      ▂▄__  WPA2      SOMEOTHERSSID  Infra  1     54 Mbit/s  27      ▂___  WPA2  
    Now, let's connect to WiFi (note, one must be root or sudo access)

    Connecting to an open AP
    $ nmcli device wifi connect <SSID|BSSID> For a password protected AP, see below
    $ nmcli device wifi connect <SSID|BSSID> password <password>  
    Cool, eh?
     
    To set up a device as an AP - this assumes that WLAN0 is the wireless interface...
    $ nmcli dev wifi hotspot ifname wlan0 <SSID> password "<password>"  
    Cool, eh?
  9. Like
    sfx2000 reacted to balbes150 in Armbian-NG, armbian's little brother project   
    Please contact the administration to move this topic to the TV box section. I would like to (as far as possible) continue this direction (native Armbian build directly on ARM devices). For skeptics. Recently, I completely moved the LivreELEC build to the ARM platform (i.e. the entire process of creating LE images and Addons now takes place on ARM rk3399\s922x devices). My dream is (perhaps) to try to transfer the ArmbianTV build completely to the ARM platform and get rid of the x86 dependency.
  10. Like
    sfx2000 got a reaction from Igor in Guess the target   
    Fun stuff - and something that's kept me offline/busy for the last few weeks...
     
    # uname -a
    Linux blaster 3.4.0 #1 PREEMPT Wed May 13 14:43:07 PDT 2020 armv7l GNU/Linux
     
    # cat /proc/cpuinfo
    Processor : ARMv7 Processor rev 2 (v7l)
    BogoMIPS : 586.13
    Features : swp half thumb fastmult vfp edsp neon vfpv3 tls 
    CPU implementer : 0x51
    CPU architecture: 7
    CPU variant : 0x1
    CPU part : 0x00f
    CPU revision : 2
     
    Hint - it's old enough not to have a device-tree... actually, in CPU years, it's old enough to vote/drink, and in dog-years, it's probably dead.
     
    I'll sent $20USD and a possible job offer if you can ID the specific chip...
     
    No @Igor, you don't get to play here
  11. Like
    sfx2000 reacted to Igor in Armbian v20.05 (Kagu) Planning Thread   
    For those who couldn't made it, meeting logs: https://freenode.irclog.whitequark.org/armbian/2020-04-04 Meeting summary goes directly into Jira issues/bugs and the actual work. 
     
    Thank you all for attending the meeting!
  12. Like
    sfx2000 got a reaction from 5kft in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    Recently revisiting things with H5 stability under certain SMP load factors* with @5kft and assistance with @lanefu - and H5 tends to be stable around 1104Mhz CPU/504MHz DDR with a 1.3v regulator overlay, and 1008/504 at 1.1v on NanoPi NEO2 - which doesn't really use the Mali450 at all.
     
    @lanefu was using a different H5 board (Orange Pi something or other - pls comment) - but he was also able to reproduce the stability issue I noted.
     
    Might be more interesting on something that engages all cores on the CPU, and does the GPU stress as well.
     
     
    * openssl speed -multi 4 - which flexs the ARMv8 enhancements there, engaging more of the logical blocks in Cortex-a53 - note that the governor in use is schedutil, which tends to be a different code path than "performance" or "on demand"
     
    @5kft - has been super awesome at helping out - reproducing the issue, concurring with analysis, proposing fixes...
     
    sfx
  13. Like
    sfx2000 reacted to martinayotte in How enable SPI slave mode?   
    Most SoC are not "slave capable" but only "master" ...
  14. Like
    sfx2000 reacted to Da Xue in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    @tkaiser Allwinner only certifies the H3 to operate at 1008MHz @1.2V and H5 to operate at 1008MHz @ 1.1V with DDR clocks up to 672MHz. Designs and software support for adjustable voltage and higher clock rates must be validated by the third party that chooses to implementing such features.  DVFS will not be supported in the Allwinner H3/H5 BSPs since the transition to AXP8036. I have seen some small boards with 16-bit DDR3 (1 DDR chip) clocked at 744MHz but they are almost guaranteed to have memory errors and video playback issues.
  15. Like
    sfx2000 got a reaction from lanefu 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.
  16. Like
    sfx2000 got a reaction from lanefu in Placemaker - H5 crashing under SMP load   
    In any event, the clock diffs from "stable" to "unstable" - performance overall isn't enough to justify the risks, unless one looks at specific benchmarks...
     
    I'm not into benchmarking - I've got an interest in operational usage of the device.
     
    just my thoughts...
     
    sfx
  17. Like
    sfx2000 reacted to lanefu in Placemaker - H5 crashing under SMP load   
    Well.... that seemed to take it down pretty quick

     
  18. Like
    sfx2000 got a reaction from 5kft in Placemaker - H5 crashing under SMP load   
    Sounds good - and folks should test around the 504MHz DDR clock, along with the overlay to upclock on boards that support the 1.3V regulator... both at 1.2 and 1.3 GHz.
  19. Like
    sfx2000 reacted to 5kft in Placemaker - H5 crashing under SMP load   
    OK well that answers that...  I think it's clear that the memory tests used back in 2017 weren't sufficient to determine the stability of this clock.  Why don't I go ahead and set it to 504MHz as that's the FA default, then if desired people could look at overclocking this further.
  20. Like
    sfx2000 got a reaction from 5kft in Placemaker - H5 crashing under SMP load   
    ok - so the stock FA image also crashes on the same test - it behaves differently than the Armbian image, as it kills off the threads when it tries to do a privileged memory access...
     
    since we're working with armv8-a, we have kernel space (EL1) and user space (EL0) - hence the data abort, as the memory is marked as EL1, and an EL0 task cannot access that. I think that overclocking the CPU exposes a bug that is latent, even without the overlay, and this goes not to device tree, but to uboot and DDR ram init vectors there.
     
    The stress test (openssl) can show the bug, but this isn't the real problem, and the overlay just enables it to happen faster - getting board temp to around 60c, which on a small board like this, includes not only the SoC, but the DDR, can accelerate this issue, as some DDR can get a bit unstable at that temp.
     
    I don't have much time right now to debug further, as I'm in the middle of sfx's North America Tour - last week Austin, TX, next week Miami, FL, Atlanta, GA, Denver, CO, and a short trip to Salt Lake City, UT - about a week of downtime in the SAN, then back to Austin for a week.
     
    @5kft  -- Gnarly problem to sort, eh? But spending time might help other AW H5 targets...
     
    @Igor -- something to watch maybe
  21. Like
    sfx2000 got a reaction from Igor in Placemaker - H5 crashing under SMP load   
    ok - so the stock FA image also crashes on the same test - it behaves differently than the Armbian image, as it kills off the threads when it tries to do a privileged memory access...
     
    since we're working with armv8-a, we have kernel space (EL1) and user space (EL0) - hence the data abort, as the memory is marked as EL1, and an EL0 task cannot access that. I think that overclocking the CPU exposes a bug that is latent, even without the overlay, and this goes not to device tree, but to uboot and DDR ram init vectors there.
     
    The stress test (openssl) can show the bug, but this isn't the real problem, and the overlay just enables it to happen faster - getting board temp to around 60c, which on a small board like this, includes not only the SoC, but the DDR, can accelerate this issue, as some DDR can get a bit unstable at that temp.
     
    I don't have much time right now to debug further, as I'm in the middle of sfx's North America Tour - last week Austin, TX, next week Miami, FL, Atlanta, GA, Denver, CO, and a short trip to Salt Lake City, UT - about a week of downtime in the SAN, then back to Austin for a week.
     
    @5kft  -- Gnarly problem to sort, eh? But spending time might help other AW H5 targets...
     
    @Igor -- something to watch maybe
  22. Like
    sfx2000 reacted to hexdump in Choice of TV box.   
    this is just a quick note that in my experience the amount of tv boxes with fake specs has grown quite a bit in the last months and that this is something to always have in mind when getting a box for a surprisingly cheap (i.e. quite a bit cheaper than usual or most of the other offerings) price - you might be lucky and it will be a bargain or you might hit one with fake specs. some examples i saw recently: a qplus 4g ram / 32g emmc ended up to be 2g ram and 16g nand, a h6 box sold as 4g ram / 32g emmc ended up as 2g ram / 16g emmc, a x96mini 2g ram / 16g emmc ended up at only 1g ram / 16g emmc, a r39 2g ram / 16g emmc with rockchip rk3229 ends up as 1g ram / 16g emmc and an allwinner h3 cpu and so on. the fake specs are not that easy to spot: in android they even fake the storage size shown in the storage settings and with a terminal installed even the "free" command tells you most of the time that the memory amount is proper. what usualy works for storage is "cat /proc/partitions" and watching for the device itself (for instance mmcblk0) - this also quickly shows you if its emmc (=mmcblk) or nand (=nand) and for memory "dmesg | grep -i mem" (do this immediately after booting android, otherwise the memory lines from the bootup might run out of the log buffer) - both of course called in a terminal app. booting one of balbes150's armbian images usually quickly shows you the real specs of the box too.
     
    good luck at not ending up with fake boxes and best wishes - hexdump
     
    p.s.: one thing to keep in mind is that allwinner h6 boxes always only can use 3g ram, even if they have 4g installed - this is a limitataion of the soc ...
  23. Like
    sfx2000 got a reaction from TRS-80 in Surveying the hardware landscape 2019 and beyond, with an eye toward freedom (headless server)   
    Without getting into the file system wars - might consider BTRFS, which is much more GPL friendly...
     
    One of the challenges with the low memory platforms is that ZFS is fairly RAM and compute intense for what it does - that being said, for the right purpose, it's a good file system to look at.
  24. Like
    sfx2000 got a reaction from TRS-80 in Surveying the hardware landscape 2019 and beyond, with an eye toward freedom (headless server)   
    One of the side benefits of China becoming a surveillance society - Government needs lots of cameras to keep an eye on the folks over in Xinjiang....
  25. Like
    sfx2000 got a reaction from Jack953 in free software supported wifi card phone usable ESP8089 ESP8266 ESP32?   
    It's really hard to do in a power efficient manner - there are SDR's that can do all the right waveforms, the signalling, etc, but most of this is on an FPGA - the UMTS and LTE protocols are fairly complex, much more so that 802.11 wifi, and we know how hard that can be.
     
    It's also a massive minefield of patents, which makes GPL are very real challenge.
     
    Osmocom.org has made the most progress towards a free modem - https://osmocom.org/