Search the Community

Showing results for tags 'rfc'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements & first aid
    • Announcements
    • Board doesn't start
  • Community forums
    • Common issues
    • Peer to peer technical support
    • Feature Requests
    • TV boxes
    • General chit chat
  • Bug tracker
    • Allwinner A20
    • Allwinner H2 & H3
    • Allwinner H5 & A64
    • Armada A388, A3700
    • Amlogic S905(x)
    • NXP (Freescale)
    • Rockchip 3288 & 3328
    • Other supported boards
  • Development
    • Allwinner H6
    • Rockchip 3399
    • Development

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 5 results

  1. 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.
  2. 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.
  3. 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.
  4. 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?
  5. 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.