Jump to content

Search the Community

Showing results for tags 'rfc'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Product Groups

  • Misc
  • Support


  • Armbian
  • Armbian releases


  • Volunteering opportunities


  • Community Calendar


  • Official giveaways
  • Community giveaways


  • Members

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start






Website URL







Found 15 results

  1. 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: ``` $ ./compile.sh 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 accept the license. The board is default configured to boot from SD using the Boot Select DIPs _ _ ____ ____ _ _ __ ____ _____ | | | | __ ) | _ \ _ _| |___ ___ (_) \/ \ \/ ( _ ) | |_| | _ \ | |_) | | | | / __|/ _ \ | | |\/| |\ // _ \ | _ | |_) | | __/| |_| | \__ \ __/ | | | | |/ \ (_) | |_| |_|____/ |_| \__,_|_|___/\___| |_|_| |_/_/\_\___/ Welcome to Armbian buster with Linux 4.19.72-imx8-sr-imx8 System load: 0.41 1.82 1.38 Up time: 29 min Memory usage: 4 % of 2997MB IP: CPU temp: 47°C Usage of /: 18% of 7.1G [ General system configuration (beta): armbian-config ] http://ix.io/27FC
  2. 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: https://github.com/fifteenhex/xradio/pull/12 Edit: rebased from karabek: https://github.com/dbeinder/xradio/commits/karabek_rebase And some important comments about powersave: https://github.com/fifteenhex/xradio/pull/11#issuecomment-616226880 In short, relative to the current version, with powersave on, idle consumption is lower by 200mW, but with powersave off, it is 300mW higher - so that should be a consideration if you want to integrate this into Armbian builds for tiny boards like OPZero. Of course a 65MBit chip will never be fast, but I'd say it is pretty usable as an IoT node now. This hasn't seen much testing, so your comments are appreciated.
  3. I stumbled across this topic which lead me to the idea: https://forum.armbian.com/topic/16426-selling-helios64/?tab=comments#comment-115128 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 does not and will not be involved in any way into trades. Armbian takes no responsibility for whatever may go wrong whatsoever and user shall use PM, email or any 3rd party messenger to exchange private details commercial sales will be forbidden. private trades/offers only What do you think? Waste of time or an idea worth a try? Let me know!
  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 customize-image.sh I need to dowload source via git and make it like user and not like root. Example of customize-image.sh: git clone https://github.com/xxx/xxx /home/pi/xxx su -c "sudo -S /home/pi/xxx/xxx.sh" - 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. 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!
  9. Hi - Are there plans to upgrade uboot from April (v2019.04) to October (v2019.10) for all boards as October final has been tagged ?
  10. 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.
  11. 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 kernel is currently called Next. The LTS kernel would follow a LTS version of mainline or fork. Ex: 4.19 of Megous's branch for orangepi, mainline:4.19 for espressobin. This should be our flagship kernel and the only one we "support" for end users. Armbian can supply patches for these kernels Unstable This kernel is currently called Dev. The Unstable kernel would follow a recent branch or fork of a kernel. Armbian can supply patches for these kernels. Mainline This is new. It would follow mainline:master. Its purpose is to provide a 100% mainline experience when practical. No patches will be supplied by Armbian.
  12. 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 boxes go into a TV box repo Advantages: Supporting every pet project wont result in build system bloat as it does today. Users of the script can maintain a csc board support repo with the required structure without hacking on the build script itself, making adding such a board to the "supported" repo much easier, if even necessary. While I don't "tiptoe through the tulips" with CSC boards, I do go to some effort not to break them with changes. Those boards won't be interacting with the others anymore, they'll have their own space. Cons: Perceived fragmentation of support. In reality this is a good way to disengage the build script from pet projects and focus on the boards we as a team care about. Some work to implement (although I think the biggest part can be laced into the menu where you choose the board (CSC/WIP vs supported) @lanefu, @Igor, Could we add an "RFC" tag? would be useful, and consistent with linux terminology.
  13. 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. This would amount to changing from: CONFIG_IKCONFIG=y to: CONFIG_IKCONFIG=m About the only thing that might "break" would be any tools that use 'extract-ikconfig' or similar against the on-disk binary to extract the built-in .config, but with the kernel configuration already included in the linux-image-*.deb and installed under /boot as a separate text file this should not be needed. I can submit a PR for -DEV if this sounds reasonable for all of the existing defconfigs in config/kernel but wanted feedback on whether this would be useful or whether this should be left as-is.
  14. 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?
  15. 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 group called gpio exists in Raspbian, pi is added to it and /etc/udev/rules.d/99-com.rules does all the magic: So adding a detection in automatic user creation (we don't want to ship with pre-defined users ) to check for pi as name we could add this in Armbian too. Another area are the various WiringPi library variants that exist for different SoCs that partially need adjusted settings since pin mappings differ (see example for BPi M2+). AFAIK the knowledge which lib has to be used on which SoC is present here but scattered all over the place. Wouldn't it be cool if people experienced with this stuff start to collect information (as a first step as part of our documentation, later maybe providing own variants of these libs for our most popular SoC variants)? Disclaimer: me is the wrong person for this stuff since I'm still an absolute IoT NOOB and always have a hard time trying out GPIO stuff So this thread is meant to collect ideas and opinions on this.
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines