lanefu reacted to TonyMac32 in fix the basic - CONTRIBUTING.md
Hahaha no, I was excluded from "The list". Only a joke, and there has been some quite loud opposition to naming a "king of the project" or an "inner circle".
Personally I think a lot of this comes down to not wanting to assume the complexity of a larger project, but the project has decided it won't wait for that complexity and is now demanding it. We're at the point where Armbian gets mentioned in kernel mailing lists about various SoC's, so our ability to address issues is becoming quite public.
I only push the branches because if someone makes a stupid branch we can kill the branch, and changes won't be wound around anything else that may be useful causing a horrific mess.
lanefu reacted to Tido in fix the basic - CONTRIBUTING.md
I like a lot what you guys brought up over night. Some of it is already written somewhere in the forum/website/documentation, but it needs to get into meaningful stream, so I will try to reflect what I read in the 1. post in this thread.
- For example stable branch, just as an example (and needs a fix for github)
To me as an advocate of STABLE this sounds great, reflects the idea of @TonyMac32 if I understand you correct.
it is not only about size and complexity, it is also about having fun to develop armbian - that leads to some necessary improvement | a new concept and discipline. As already said a community of 3 is easy, more than that need some easy to follow guidelines.
What I want to say, the CONTRIBUTING.md should tell a lot, but shouldn't be to long, from my perspecitve.
Last but not least, I am happy that after all (I started this thread in March, the idea I had much earlier) that I receive some comments here - because it is not about me, but us
I guess this belongs to documenation and Website (on the download FAQ we explain that as well - I like your description)
lanefu got a reaction from Tido in fix the basic - CONTRIBUTING.md
Right so let me stab at delineation between supported, WIP, and CSC.
Supported - Board has a documented maintainer listed in the board config file or elsewhere... (Documented maintainer could be "armbian core team" woudlnt have to 1 person, but would have to some sort of consensus WIP - A board with a documented maintainer in config file that is intended to be "supported", but legitimately is a work in progress. CSC - A board with contributions, but no documented maintainer. Use at own risk. No image builds... or maybe nightlys, at best. If code is clearly atrophying, and doesn't seem to have any popularity, Core armbian maintainers (lords of master branch) purge at will.
As a general rule of them board related commits should not have any code impacting the build system overall and merge requests would be rejected.
Naturally a CSC board could get promoted into a WIP and ultimately a supported board, but that can be up to the Armbian core developers.
lanefu reacted to tkaiser in H3 board buyer's guide
H2+/H3/H5 boards overview (early 2018 update)
For the methodology/categorization please see above. This is just a brief overview adding the boards that appeared within the last few months (Banana Pi Zero, NanoPi Duo, Orange Pi R1, Orange Pi Zero Plus, Sunvell R69) and will appear soon or are just released (ACT Power X-A1, Libre Computer's H2+/H3/H5 Tritium, NanoPi NEO Core and Core2):
NAS category (only due to Gigabit Ethernet available):
Banana Pi M2+: H3, 1GB DRAM, 8GB slow eMMC, 1+2 USB ports useable, Wi-Fi/BT Banana Pi M2+ EDU: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable NanoPi M1 Plus: H3, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi M1 Plus 2: H5, 1GB DRAM, 8GB slow eMMC, 1+3 USB ports useable, Wi-Fi/BT NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable NanoPi NEO Core 2: H5, 512MB/1GB DRAM, eMMC, 1+3 USB ports useable, GbE on pin header NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+2+2 USB ports useable, Wi-Fi OrangePi PC 2: H5, 1GB DRAM, no eMMC, 1+3 USB ports useable OrangePi Prime: H5, 2GB DRAM, 1+3 USB ports useable, Wi-Fi/BT OrangePi Plus: H3, 1GB DRAM, 8GB eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2: H3, 2GB DRAM, 16GB slow eMMC, 1+4 USB ports useable (hub), Wi-Fi OrangePi Plus 2E: H3, 2GB DRAM, 16GB fast eMMC, 1+3 USB ports useable, Wi-Fi Orange Pi Zero Plus: H5, 512MB, 1+1+2 USB ports useable, Wi-Fi X-A1: H3, 1GB DRAM, 8GB eMMC, 1+2 USB ports useable IoT category (cheap, small, energy efficient, most of them headless):
Banana Pi Zero: H2+, 512MB DRAM, no eMMC, 1 USB port useable, Wi-Fi/BT, Fast Ethernet (pin header) NanoPi Air: H3, 512MB DRAM, 8GB slow eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet NanoPi Duo, H2+, 256/512MB DRAM, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet (pin header) NanoPi NEO: H3, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Fast Ethernet NanoPi NEO 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Gigabit Ethernet NanoPi NEO Core: H3, 256/512MB DRAM, optional eMMC, 1+3 USB ports useable, Fast Ethernet (pin header)
NanoPi NEO Plus 2: H5, 512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Gigabit Ethernet Orange Pi R1: H2+, 256MB DRAM, 1+2 USB ports useable, Wi-Fi, 2 x Fast Ethernet (1 x USB RTL8152) OrangePi Zero: H2+, 256/512MB DRAM, no eMMC, 1+1+2 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI OrangePi Zero Plus 2: H5, 512MB DRAM, 8GB fast eMMC, 1+0+2 USB ports useable, Wi-Fi/BT, no Ethernet but HDMI Tritium IoT: H2+, 512MB DRAM, 1+3 USB ports useable, Fast Ethernet
General purpose (HDMI and full legacy kernel support: video/3D HW accelerated):
Beelink X2: H3, 1GB DRAM, 8GB slow eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet NanoPi M1: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi Lite: H3, 512MB DRAM, no eMMC, 1+2 USB ports useable, Wi-Fi, no Ethernet OrangePi One: H3, 512MB DRAM, no eMMC, 1+1 USB ports useable, Fast Ethernet OrangePi PC: H3, 1GB DRAM, no eMMC, 1+3 USB ports useable, Fast Ethernet OrangePi PC Plus: H3, 1GB DRAM, 8GB fast eMMC, 1+3 USB ports useable, Wi-Fi, Fast Ethernet OrangePi Zero Plus 2: H3, 512MB DRAM, 8GB fast eMMC, 1+1+2 USB ports useable, Wi-Fi/BT, no Ethernet pcDuino Nano 4: See above, it's just an OEM version of NanoPi M1 done for Linksprite Sunvell R69, H2+, 1GB DRAM, 8GB eMMC, 1+1 USB ports useable, Wi-Fi, Fast Ethernet Tritium: H3, 1GB DRAM, 1+3 USB ports useable, Fast Ethernet Tritium: H5, 2GB DRAM, 1+3 USB ports useable, Fast Ethernet
lanefu reacted to TonyMac32 in Librecomputer Tritium H3
SoC's have built-in support for changing frequency, generally. So the "Magic" is a driver controlling a clock generator/multiplier. However, most of the time, with reduced frequency you can reduce operating voltage a little bit to save on power and reduce heat. In this case that isn't going to be an option, on the Allwinner-based boards that support it it's a bit of a hack in the first place, using a transistor on a gpio to change the target voltage of the system regulator by adding/removing a resistor from the regulator's "voltage setting". This board does not support that. On a board like the Tinker, Renegade, Rock64, there is a matched/recommended regulator chip PMIC that takes commands and adjusts the voltages accordingly in a much more controlled fashion.
lanefu got a reaction from TonyMac32 in Librecomputer Tritium H3
My Tritum h5 board came. I just built an image from Dev branch using Tony's tritium-5.csc. w/ Kernel 4.14.43 Fired right up..... Even has console login on HDMI. (although its not returning keystrokes at the console)
but I ssh'd in an all is well.
Trying to understand a bit more about regression bug. I'm running at 1.01ghz. Is that related to regression bug? Basically trying to understand on how I can help achieve parity with the Clock on my Opi PC2 or Prime. etc
lanefu reacted to TonyMac32 in Librecomputer Tritium H3
Correct. A bit strange. There is a dw-hdmi patch that needs a fixup, but I tried to to no effect.
@Igor my support patches for this board do the opposite of the OPi PC2 image I tried, I get debug console with uboot on mine, but no kernel hdmi, the opi image made today has no uboot hdmi but does have kernel. I'm sure I'm doing something ridiculous... Any argument about uploading as CSC even though it's headless? it's only a csc, uboot and kernel patch to add the dts's?
lanefu reacted to arre in Testers wanted Real Time Kernel image builds for H3 boards
Just wanted to share that I got the realtime patch working on an Orange Pi Zero on 4.18.8
I used the armbian build environment and the official RT patch.
A few tricky points were the CPU govenor and CPU operating points automatically switching by default, causing the realtime behavior to be really bad (max spikes around 3000 in cpu test).
By patching the device tree to only use a fixed operating point, I achieve the following output:
Linux orangepizero 4.14.8-rt9-sunxi #1 SMP PREEMPT RT Sat Jan 6 14:36:31 CET 2018 armv7l armv7l armv7l GNU/Linux /root/rt-tests/cyclictest -p 80 -t5 –n # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 0.85 0.49 0.22 4/168 3083 T: 0 ( 3079) P:80 I:1000 C: 3297 Min: 8 Act: 17 Avg: 16 Max: 66 T: 1 ( 3080) P:80 I:1500 C: 2198 Min: 8 Act: 24 Avg: 15 Max: 50 T: 2 ( 3081) P:80 I:2000 C: 1648 Min: 8 Act: 11 Avg: 16 Max: 60 T: 3 ( 3082) P:80 I:2500 C: 1318 Min: 8 Act: 12 Avg: 15 Max: 44 T: 4 ( 3083) P:80 I:3000 C: 1098 Min: 9 Act: 17 Avg: 18 Max: 57
If anyone is interested, I used this realtime kernel to run a virtual wifi guitar amplifier on the orange pi zero.
I documented the entire thing on http://arre234.blogspot.be/2018/02/linux-portable-wifi-guitar-amp-on.html , including the device tree and cpu govenor stuff.
Hope this helps anyone
lanefu reacted to Tido in Kickstarter: Allwinner VPU support in the official Linux kernel
Release the libVA improvements when the kernel driver patch series is ready for submission, sometime next week. read more here: https://bootlin.com/
lanefu reacted to NicoD in My new video about the Rock64 with Armbian
I've made a video about the Rock64. I've tried different distro's, but Armbian was the best for me.
The only problems I've found was that Synaptic Package Manager didn't work. It crashes when I press the search button. And sometimes surfing was extremely slow. Otherwise it did fix all the problems I've had with the other distro's I've tried.
Thank you for all the great work.
Now I've started my research with the Orange Pi +2, and again Armbian is the best choice.
Here is my video.
lanefu reacted to TonyMac32 in Patch and configuration directory organization
This topic is a response to the growing number of kernels, growing number of boards with... "unique properties", and for the increased complexity of some platofrms (aarch64 and the atf, etc). I think the coherency of the chosen organizational method is starting to fall apart.
So just a thought experiment on my part:
Currently, we have a sources directory, and the sources file has not just sources, but also executable script functions in it. We also do our patches per SoC, mostly, but the organization is by the thing being compiled rather than by the target, making finding/adjusting a bit cumbersome in some cases.
I would propose a directory tree looking something like this:
├── RK3288 │ ├── kernel │ │ ├── default │ │ ├── dev │ │ └── next │ ├── miqi │ ├── tinkerboard │ │ ├── kernel │ │ │ ├── default │ │ │ ├── dev │ │ │ └── next │ │ └── uboot │ │ ├── default │ │ ├── dev │ │ └── next │ └── uboot │ ├── default │ ├── dev │ └── next └── S905 In this case the organization is by SoC, then by board. All patches safe for the entire board population get put in the SoC-level kernel and uboot patch folders, anything unsafe (hardkernel-specific patches, Tinker board specific patches) go into the board-level folders. To reinforce that we want those folder to be "last resort", we could call them "C2_bugs, Tinker_bugs" etc.
For our 64-bit targets, the trusted firmware would likewise have it's directory. I think it might also make for a lower barrier to entry on committing fixes, I still worry about patching things when I don't have all the boards to test on, this way, as a novice or as someone doing something that I can't test on other hardware, I can drop the patch into the board(s) I have, then they can be evaluated by the other devs on the remainder of the hardware.
My particular set of boards benefit this way:
Tinker board specific patches are many, integrating them safely is one of the biggest reasons we lag the vendor kernel, changes to the architecture files, changes to rk3288.dtsi instead of just to rk3288-minarm.dts, changes to various drivers for specific hardware issues, etc etc etc etc. Differences in gxbb vs gxl Meson64 devices. Most of these coexist peacefully, but then you have vendor issues with u-boot of the C2, K2, etc (everyone has their own bootloader blobs)
I'd say we organize bootloader scripts similarly, rather than having executable scripts in the sources file we could place an include in the appropriate board folder covering the specifics. For example, if a board ships with a SPI boot flash, we don't need to burn u-boot, only provide the proper configuration of partitions/etc. That might be the only board in the series (an unusually awesome H3 board, for example).
Ideally, at that point, adding a new board would require a new board definition file, and then the proper patches folder.
lanefu reacted to TonyMac32 in Pi-Factor power solution
I've done some load testing of my first prototype power "mezzanine" board (can't say "hat") The voltage drop of powering the RPi touchscreen off of the GPIO while the tinker is on micro-USB is insane, I was reading 3.9 Volts on the USB ports when I ran minerd --benchmark. I may have finally worn out the Micro-USB connector...
This is a project for learning the ins and outs of kicad and get an idea of the capabilities of the PCB houses I have reasonably fast access to (Chinese ones unfortunately always get stuck in customs for a week or more on top of the normal shipping and fab times, so the cost savings is lost in time) I have some more interesting things in mind, but I thought I'd start out (very) small. The input is protected by the recommended ideal diode circuit from the RPi guys, stress testing didn't even make it warm. If a better solution is needed, it can obviously be designed, but this is extremely cheap all things considered and that was part of the G&O for this project.
By comparison, using this GPIO board to power everything resulted in a minimum 4.8 volts while also powering a USB 2.0 spinning disk HDD. (lower than I'd hoped, I'm going to make some adjustments to see if I can squeeze a bit more out once I get the redesigned version 2 back, I forgot about the temperature rise factor... )
One of the issues goes back to our friends at RPi, the 5V pins are on the outside edge, so you have to go around the inner row to get to them. This complicates moving big conductors around somewhat...
The chip in the back is a SPI NOR for booting the Tinker (experimental, I threw it in there as an experiment and never actually performed the experiment...) I'll probably wipe it from the board, perhaps leave an 8-pin SMT-adapter-sized pattern to the SPI for the adventurous.
Power supply used here is the Odroid XU4 supply. This initial run has no overvoltage or overcurrent protection. And I need finer tipped soldering iron...
I'll GitHub this one after some cleaning and citation of sources, normal disclaimers for those who want to build one. I will have moved one of the USB ports though since @chwe happily pointed out that Y-cables don't reach that far to get from the real ports to the power-only ones... (oops)
Boards successfully powered by this configuration (I don't / can't own one of everything... ):
Tinker Board Le Potato NanoPi K2 (Already has a barrel jack, by the way, but you never know, maybe you want the bigger one)