sfx2000

Members
  • Content Count

    459
  • Joined

  • Last visited


Reputation Activity

  1. Like
    sfx2000 got a reaction from WarHawk_AVG in Best device for an "internet ethernet condom"   
    If one is running a DNS server for the LAN/WLAN - probably better to keep it on the wire
  2. Like
    sfx2000 got a reaction from guidol in uBoot fun stuff... pepe2k   
    Stumbled across this while working on something else not ARM related, but it's pretty cool - since Armbian is looking at devices that have eMMC, this might be useful
     
    https://github.com/pepe2k/u-boot_mod
     
    Short story - it's a uBoot with a micro web server that supports flashing images, including uBoot itself - basically it turns things into a bit of a fail-safe as long as uBoot can execute...
     
    (those playing with the fire that is uBoot, keep your UART connections handy)
     
    Do I have some security concerns - absolutely yes... but no different than the UEFI that is on many x86 boards these days.
     

  3. Like
    sfx2000 got a reaction from gounthar in Best device for an "internet ethernet condom"   
    PiHole works fine with most boards that are equivalent to a RPi2 for most home networks when wired up...
     
    NanoPI NEO would probably be perfect for this application with current Armbian...
  4. Like
    sfx2000 got a reaction from WarHawk_AVG in Best device for an "internet ethernet condom"   
    PiHole works fine with most boards that are equivalent to a RPi2 for most home networks when wired up...
     
    NanoPI NEO would probably be perfect for this application with current Armbian...
  5. Like
    sfx2000 got a reaction from devman in Support of Raspberry Pi   
    I would agree - and there's not a lot of value add for the effort that would be needed to support three different Broadcom SoC architectures - the RPi community has their own rich ecosystem, and there's formal support from Ubuntu (and other distros) if one wants more than what Raspbian has.
     
    Where Armbian shines - the project brings mainline support for SoC's (Rockchip, Allwinner, Amlogic are good examples) that do not have the best vendor support (old and outdated BSP's, bootloaders, etc) - RPi doesn't need that level of support. If Armbian wasn't there, many of these boards would be less than useful for many.
  6. Like
    sfx2000 reacted to Tido in Adafruit CircuitPython   
    35C3 - MicroPython – Python for Microcontrollers  https://www.youtube.com/watch?v=xCPnOxWxHIc 
    at min 5:30 you see also Adafruit, haven't seen it completely, but stumbled across it
     
  7. Like
    sfx2000 got a reaction from manuti in Best Kodi box?   
    Really depends - the Amlogic S905/S912's are interesting at the moment - some support Android 6, some are Android 7....
     
    Rockchip based boards are high performance, but there's some non-technical issues around the Kodi group and Rockchip - so things generally work until they don't...
     
    CNX-Software has a good follow-through on TVBoxes...
     
    https://www.cnx-software.com/2017/12/26/whats-the-best-android-tv-box-2017-2018-edition/
  8. Like
    sfx2000 reacted to Tido in picocom login on MacOS   
    I use "screen"  instead of  picocom. Have you ever tried this software?
  9. Like
    sfx2000 got a reaction from NicoD in FOSDEM 2018   
    And SBC vendors - they just look for the best solution to fit their needs and business plan for a certain board...
     
    The cost and efforts need to verify/validate ISA conformance are extremely high, as they should be - you look at companies like Intel and AMD, qualification of a chip can take years - and same with ARM folks like Apple and Qualcomm, where they take the ARM ISA and do their own designs - the chips you see on the market now were actually done 3-4 years ago in a cadence of development.
     
    And that's millions of euro's/dollars...
     
    You look at SoC vendors like Allwinner, Rockchip, Amlogic - they're using IP blocks that have been pre-certified by ARM (and others) with the fabs - so each block has tapeouts for a certain geometry node and process.. Grab the ARM core of choice, the Mali GPU block, wrap it around DesignWare blocks for peripherals for UART's, GPIO, Ethernet, etc... It's like lego's or ikea furniture...
     
    And to the CN side - this is all dependencies on foreign IP... whether is ARM, Intel, Imagination Tech (GPU's with PowerVR), MIPS, Oracle (ex-SUN), etc...
     
    With RISC-V - that's all out the door - which makes this interesting - going back to CN, there's enough government money at the local and national level to make things happen, and enough research in the academic space, along with the industrial resources to get things done...
     
    Remember the CN initiative - "Made in China 2025"
     
    I'm just an observer on the industry here - not being political...but it is interesting what the mainland is doing, and worth watching...
  10. Like
    sfx2000 got a reaction from NicoD in Benchmarking CPUs   
    that's ok, but what I have found is that UnixBench a good equalizer across different SoC's on these cheap little boards - even though UnixBench is still variable based on the compiler...
     
    It runs long enough (a full run can be 28 minutes) to show if thermals are a challenge (for TinkerBoard, absolutely with stock config compared to NanoPI NEO, where the Tinker has a much better architecture (A12) vs. NEO with A7, but the Neo can shed heat faster, and outperform the Tinker in the longer run - heck, even Pi3B+ runs UnixBench faster than Tinker...
  11. Like
    sfx2000 reacted to NicoD in FOSDEM 2018   
    Good questions, I've added them. Thanks.
  12. Like
    sfx2000 got a reaction from NicoD in FOSDEM 2018   
    How can SoC vendors help here with support for chips, interfaces, GPU/VPU, network, etc...
    The Armbian team has done a lot of development, how receptive has upstream been to accepting changes/pull requests?
    What's the best approach for SoC/Board Vendors to get Armbian ported to their board/chipset?
    Documentation is key for supporting a chip or board - where are the opportunities for the vendors to improve?
  13. Like
    sfx2000 got a reaction from gounthar in Support of Raspberry Pi   
    I would agree - and there's not a lot of value add for the effort that would be needed to support three different Broadcom SoC architectures - the RPi community has their own rich ecosystem, and there's formal support from Ubuntu (and other distros) if one wants more than what Raspbian has.
     
    Where Armbian shines - the project brings mainline support for SoC's (Rockchip, Allwinner, Amlogic are good examples) that do not have the best vendor support (old and outdated BSP's, bootloaders, etc) - RPi doesn't need that level of support. If Armbian wasn't there, many of these boards would be less than useful for many.
  14. Like
    sfx2000 got a reaction from JonatasPrust in Logrotate not working in /var/log   
    Hint - it's a feature mention within the armbian-zram-config script set - it calls armbian-ramlog
     
    Look at /etc/default/armbian-ramlog - you can change "enabled" to false, and then things start follow expected rules... and you can mount /var/log where ever you want... remember you need to be root or sudo to do this, and reboot after the change.
     

     
     
  15. Like
    sfx2000 got a reaction from guidol in [Info] NanoPi Neo/Neo2-OLED-Hat does work with armbian   
    easy enough for the script - I just changed shutdown to reboot... which the UI still shows "Shutdown Yes/No" for now, but I'll take care of that later...
    # os.system('systemctl poweroff') os.system('systemctl reboot') Anyways - @guidol - here's my updated script, it's based on the V2 script you posted from the DietPI folks... fixed the padding, and the provision for the second logo/splash screen...
     
     
    bakebit_nanohat_oled.py
  16. Like
    sfx2000 got a reaction from ftp-bin2fex in Lichee Pi zero   
    Nice work - must have been a bit of effort to squeeze a liter of code into 250 ml bucket...
  17. Like
    sfx2000 got a reaction from guidol in [Info] NanoPi Neo/Neo2-OLED-Hat does work with armbian   
    Cool - now we possibly know who to attribute the actual script changes to - it was not attributed over at the WLAN PI distro...
     
    I'm not on DietPI's group - but someone should encourage the author to do a pull request on FE's github, as it's obviously a good thing to include.
     
    FWIW - on the stats screen, you can change the padding from "2" to "0", which brings the bottom line back onto the screen... (it prints a couple of pixels down)
     
        elif page_index==1:         # Draw some shapes.         # First define some constants to allow easy resizing of shapes.         # padding = 2 # FE's script draws off canvas here, so we remove the pad for this screen padding = 0         top = padding         bottom = height-padding         # Move left to right keeping track of the current x position for drawing shapes.  
  18. Like
    sfx2000 reacted to guidol in [Info] NanoPi Neo/Neo2-OLED-Hat does work with armbian   
    Thanks for the information
    Additionally I did found "this" patch also in the dietpi-forum:
    [Tutorial] How to get your NanoHatOLED to work

    For dietpi there are much more dependencies, because it claims to be smaller than armbian in the basic-configuration
     
    There are also the .zip files of the complete patch - in 2 versions - written by the user Phillski (see inside the spoiler)
     
    for backup-reasons I will attach the 2 versions also here
     
    I had only to extract the .zip above the NanHatOLED-Directory and reboot - no need for an additinally installation
     
     
    NanoHatOLED_v2_2Minutes_DietPi.zip
    NanoHatOLED_v1_5Minutes_DietPi.zip
  19. Like
    sfx2000 got a reaction from guidol in [Info] NanoPi Neo/Neo2-OLED-Hat does work with armbian   
    Save the diff I posted about as bakebit_nanohat_oled.patch - then using patch, patch your corresponding file like this...
     
    patch -b < bakebit_nanohat_oled.patch
     
    This will patch the existing file, and create a back up of the original...
     
    That should do it - then for your logo file - you'll see where to put the name of the logo file, and keep the logo in the same dir...
     
    Then just run the install script, which will pick everything up and rebuild the nanohat oled
  20. Like
    sfx2000 got a reaction from guidol in [Info] NanoPi Neo/Neo2-OLED-Hat does work with armbian   
    Here's my local copy of the file in case you get stuck...
     
     
    bakebit_nanohat_oled.py
  21. Like
    sfx2000 got a reaction from guidol in [Info] NanoPi Neo/Neo2-OLED-Hat does work with armbian   
    Works perfect - sorting the dependency for pillow was the key....
     
    Works fine with 5.65 stable for Neo2
     
     
     
    Plays well with NanoPI NEO (the H3 version) as well.
     
    Thx!
  22. Like
    sfx2000 got a reaction from gounthar in Sunvell H3 2GB RAM + 16GB ROM TV Box   
    mtd should work - https://www.kernel.org/doc/html/v4.14/driver-api/mtdnand.html
     
    Would need to tweak uboot, build the partitions - jffs as a file system - but might just be use the NAND as a pseudo SPI, and boot the rest from USB or the SD Card....
  23. Like
    sfx2000 reacted to guidol in [Info] NanoPi Neo/Neo2-OLED-Hat does work with armbian   
    Today I swapped my old Neo2 against a Neo2 LTS 1GB in my NAS case - so I had a old Neo2 512MB free for the black Aluminum-OLED-case which I got in a drawer.
     
    Now I did try to activate the OLED in 
    ARMBIAN 5.67 user-built Debian GNU/Linux 9 (stretch) 4.19.4-sunxi64 Linux npi-neo2-27 4.19.4-sunxi64 #6 SMP Fri Nov 30 14:02:43 +03 2018 aarch64 GNU/Linux
    First (like on a i2c-clock" I activated i2c0 in armbian-config:
     
    root@npi-neo2-27(192.168.6.27):~# armbian-config System --> Hardware --> [*] i2c0 After the reboot I checked for the i2c-OLED-device and got:
     
    root@npi-neo2-27(192.168.6.27):~# apt install i2c-tools root@npi-neo2-27(192.168.6.27):~# i2cdetect -y 0      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f 00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- 3c -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- --  After some trial and error(-messages) I did found the following dependencies for compiling/installing the software for the OLED-Board:
    apt-get install python-setuptools libjpeg-dev  
    After that I did the normal "5 Enable NanoHat-OLED manually" from
    http://wiki.friendlyarm.com/wiki/index.php/NanoHat_OLED
    with
     
    root@npi-neo2-27(192.168.6.27):~# cd /home/guido root@npi-neo2-27(192.168.6.27):~# git clone https://github.com/friendlyarm/NanoHatOLED.git root@npi-neo2-27(192.168.6.27):~# cd NanoHatOLED root@npi-neo2-27(192.168.6.27):~# ./install.sh And after the next reboot the OLED-Display did work
  24. Like
    sfx2000 reacted to jerryn in GQRX RTL-SDR is working on NanoPC-T4   
    Here's a video of GQRX receiving NOAA Weather Radio on my NanoPC-T4
     
    armbian-nanopc-t4-gqrx-gnuradio.mp4
  25. Like
    sfx2000 reacted to mindee in NanoPi M4 performance and consumption review   
    Thanks for your suggestion, we made a SATA HAT prototype for NanoPi M4, it can connect  with 4x 3.5inch hard drive and work well.