Search the Community

Showing results for tags 'rfc'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Announcements & first aid
    • Announcements
    • Board doesn't start
  • Community forums
    • Common issues / peer to peer technical support
    • Reviews, Tutorials, Hardware hacks
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker - supported boards and images only
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner A64, H5 and H6
    • Armada A388, A3700
    • Amlogic S905(x), S922X
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Rockchip 3399
    • Other supported boards
  • Development
    • Development
    • Help wanted
  • TV Boxes's General Chat
  • TV Boxes's Reviews/Tutorials
  • TV Boxes's FAQ
  • TV Boxes's TV Boxes running Armbian
  • TV Boxes's Rockchip CPU Boxes
  • TV Boxes's Amlogic CPU Boxes
  • TV Boxes's Allwinner CPU Boxes
  • Android fanboys's Forums
  • Gaming on ARM's Reviews
  • Gaming on ARM's Issues
  • Kobol Forum's Helios4
  • Kobol Forum's Helios64

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start






Website URL






Found 16 results

  1. A thought occurred to me while watching my machine sync a bunch of repos while running the Armbian build script, and I couldn't help wondering: Could we put the board support patches into their own repo separate from the build scripts themselves? More specifically: board support for "Boards of Interest" to the Armbian maintainers would be in whatever "official" repos we dedicate, I recommend separating per board family or SoC board support for CSC goes into, predictably, a CSC repo board support for EOL boards can be spun off into their own repo TV
  2. I stumbled across this topic which lead me to the idea: I strip it down to a few notes: create a new sub-forums trade/marketplace where people can offer spare SBCs for trade or sale and can create requests if somebody is willing to sell his board XY To participate users need to fulfill TBD requirements like number of days registered, posts, reputation... User must agree to rules in order to create topics which will state that Armbian staff
  3. I know most of you probably don't want to hear any more about this chip, but I recently fixed quite a few long standing issues. It's not perfect yet, but it improves scanning/reliable reconnect, incoming frames missed in powersave, ping times, and rate selection. Here's the patch set: Edit: rebased from karabek: And some important comments about powersave: In short, relative to the current version, with powersave
  4. The current forum badges for subscriptions are very simplistic. They could be a bit fancier. Not much, just a bit so they do not look that crude anymore This is what I came up with In first place I though about some transparency but since there are multiple themes including a dark one available it needs to look decent on both. Also thinking about adding some further icons in the same design but they are not to be revealed to the public yet
  5. Hi - Would it be possible to switch dev builds to 5.8 rc kernels? It looks like megous is already prepared for it ( atm rc1 ). Certainly I do realise the massive work filtering DT duplicates and applying fixes, etc ( the usual ) does come in here ... But rgd H6 this 5.8 kernel should hold important additions rgd: CPUFreq (DVFS), IOMMU, and MsgBox ( as well H3,H5 ) Therefore kindly requesting to skip 5.7 in dev and go straight for 5.8 which allows +/- two months of testing wich should be perfect for upcoming "Caple"-release in August.
  6. I also noticed that the subforums SD card and PSU issues and the garbage collector Board doesn't start are kind of redundant. Should those be merged too?
  7. In my I need to dowload source via git and make it like user and not like root. Example of git clone /home/pi/xxx su -c "sudo -S /home/pi/xxx/" - pi This work when I build image for OrangePi4 (and all other rk3399 board) It dosen't work when build image for sun8i board like OrangePi Lite. Both git and su command return error and compilation fail. This happen with legacy and mainline kernel, with ubuntu or debian.
  8. Hi, There have been a couple of posts about this over time, but I was wondeing if somebody could please provide concrete example / sample code that uses DMA to TX out the GPIO pin(s)? I want to be able to TX outwards only from my Allwinner H3 device (Orange PI PC) to 16 pins in parallel (so 16 bit DMA in parallel) from a chunk of memory in RAM. Happy with a basic example if somebody has which just blasts out one GPIO pin even.
  9. Was in dire need of Armbian on my new toy, the HBP with a iMX8Q CPU ;-) The board features dual WWAN (PCIe + M.2) sockets for highspeed 3G/4G/5G modems with a SIM socket. The Debian build from SolidRun did not have any modem drivers enabled in the kernel so there was headache. Wipped up this WIP configuration and it builds and runs with: ``` $ ./ BOARD=hummingboardpulse-imx8q BRANCH=legacy RELEASE=buster BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no ``` NOTE: It uses the HDMI and LPDDR4 binary blobs from NXP. You will get a prompt during build to ac
  10. As far as I can tell, there is currently no hook to allow patching the out of tree wifi drivers, since they're merged into the kernel source after patching. I was able to add the ability to patch these drivers with just a one line change: Would it be possible to add that (or something similar) to the build scripts, or let me know how I can currently add the patches if it's already possible? Thanks!
  11. Hi - Are there plans to upgrade uboot from April (v2019.04) to October (v2019.10) for all boards as October final has been tagged ?
  12. There's been discussion in the past of switching to a YY.MM naming convention for releases (similar to Ubuntu) [citation needed -- I think it may be buried deep inside a github discussion] How does that impact us as a rolling release? What do we want to convey with our versions/releases? Should we do monthly releases? quarterly? I do think time-based releases would help us with priority.
  13. See conversation in this commit for background The current default, Next, Dev naming convention for the kernel source trees is confusing, and a bit inconsistent. I think it's time to rename them and provide clear definitions of what they are supposed to provide. I'll start with some ideas here: Vendor This Kernel is currently called Default . The Vendor kernel would be the BSP-derived kernel or vendor maintained kernel. Typically there for basic functionality early in a boards life. Armbian can supply patches for these kernels LTS This
  14. Currently all of the Armbian kernel defconfigs include the actual build configuration statically as part of the kernel. The standard Armbian build process also includes a copy of the .config file in /boot/config-<version>-<platform>. Are both required, or should the kernel configurations be updated to make Kernel .config support an LKM instead of static bind? True this is a minor item. The actual kernel configuration takes up a very small amount of memory, though on many SBCs with limited memory to start with every byte not used by the kernel can help.
  15. What about solving ramlog this way: - added cronjob on every 15 minutes - if space is 75% full do: logrotate --force /etc/logrotate.d/ write to SD card truncate and remove files It is better than now. Good enough for defaults?
  16. Just a thought. Over half of the boards we support feature a 26 or 40 RPi compatible GPIO header and all the other boards expose various protocols and GPIO on various pins and headers. Users coming from Raspbian and trying out any of our boards expect that basics work the same. While it's both impossible and not desirable to be 100% compatible with Raspbian a few things would make transition from Raspbian to Armbian for IoT folks more easy. Simple example: Default user pi in Raspbian has access to GPIO pins -- on Armbian it's currently root only. How's that done? A grou