• Content count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    chwe reacted to botfap in One (bsp) Kernel f RK3399/RK3328 and RK3288   
    Hi @TonyMac32
    The HDMI script is very generic, I created it to handle most use cases for display output and is not SoC specific. I have an extended version that also covers LVDS and VGA output devices if you wanted to include a more generic version to cover all possible displays and SoC's for a generic Armbian script.
    Im working with some students, teaching (and creating) an embedded systems course for my local tech college till the end of the year. We are using Tinkers and some RK3399 dev boards that I managed to pick up very cheaply. I have built them a minimalist OS (glibc, busybox, weston/wayland, gtk3: ~56MB image size, not debian/ubuntu based) to get started with and their project is to create working kernel images, bug fix, add features and build a simple cloud management solution. My next step was to get them to examine Armbian's kernels to use as a starting point, compare to RK-BSP and mainline and figure out how to package it in a single code base to work across multiple RK boards and generic armhf / aarch64 qemu targets. So I have 3 unskilled but willing students I can point to help on this if you like.
  2. Like
    chwe reacted to Frank Wu in Tinkerboard S: What is ASUS view on voltage drops in cables?   
    Here is this power supply's spec sheet:
    - DC 5.0V / 3.0A 15W
    - 18AWG 150CM + Power Switch
    - SCP, OVP, OCP, OTP, etc Power Protection.
    - UL / CB / CE
    - US DoE Level VI / EU CoC Tier 2
    - LPS, etc lots of safety cert mark.
    No, currently I don't think I have kind of this data, but I can provide the result from my simple test for refer:
    - low current: avg. 4.99v
    - high current: avg. 4.87v (CPU 4 core, 400%.)
  3. Like
    chwe reacted to going in Incomplete clean-up of source code.   
    I wish you all good health.
    Using the "Armbian" build system, I noticed two bad points:
    1 - incomplete cleaning of the source code before starting a new compilation, seen when patches add new files to the tree.
    2 - Debian kernel source package includes the git directory.
    1) All I do I'm fixing the version kernel (KERNELBRANCH="tag:v4.14.40") and collect several variants for one Board, changing the patchset for each version, adding or removing some.
    Before each new compilation I'm doing a test of the purity of the source.
    clean_repo() { display_alert "clean_repo $PWD" #git status -s git reset --hard HEAD # First, return the modified files. git clean -df # Then delete all new, added files. #git status } compile_kernel() { # A simple check ensures that we start with a clean slate. cd $SRC/cache/sources/$LINUXSOURCEDIR if [ "X$(git status -s)" != "X" ]; then clean_repo fi # ... ... }  
    2) Manufacturer's code Debian package:      (--exclude='./.git/')
    if [[ $BUILD_KSRC != no ]]; then display_alert "Compressing sources for the linux-source package" tar cp --directory="$kerneldir" --exclude='./.git/' --owner=root . \ | pv -p -b -r -s $(du -sb "$kerneldir" --exclude=='./.git/' | cut -f1) \ | pixz -4 > $sources_pkg_dir/usr/src/linux-source-${version}-${LINUXFAMILY}.tar.xz cp COPYING $sources_pkg_dir/usr/share/doc/linux-source-${version}-${LINUXFAMILY}/LICENSE fi can be changed to view:    (--exclude="[.]git")
    if [[ $BUILD_KSRC != no ]]; then display_alert "Compressing sources for the linux-source package" tar cp --directory="$kerneldir" --exclude="[.]git" --exclude="[.]git[a-z]*" --owner=root . \ | pv -p -b -r -s $(du -sb "$kerneldir" --exclude="[.]git" --exclude="[.]git[a-z]*" | cut -f1) \ | pixz -4 > $sources_pkg_dir/usr/src/linux-source-${version}-${LINUXFAMILY}.tar.xz cp COPYING $sources_pkg_dir/usr/share/doc/linux-source-${version}-${LINUXFAMILY}/LICENSE fi  
  4. Like
    chwe got a reaction from parrotgeek1 in Banana Pi R64   
    The R2 has an mt7623 which is for sure not a phone/tablet SoC...  
    Actually, the R2 is quite well mainlined.. Not perfect but most features 'work' on mainline. I'm quite sure both SoCs could be maintained with one kernel (similar as we do for Sunxi in mainline). 
    CSC boards for a SoC which doesn't have any wip or supported boards is IMO pointless. As shown in the 2G-IoT, nobody cares and maintains those boards/kernels. IMO this doesn't make sense, better the users chose a distro which maintains the board as they stick to a csc armbian which doesn't get maintained. Cause both SoCs are well mainlined I still hope that other boardmakers pick up these SoCs for some boards. Something like a HC1 could be made out of it..  
  5. Like
    chwe reacted to Icenowy in Trying to compile Pine H64   
    Thanks to help from Jernej, the magenta display issue is solved in U-Boot commit 79405999d7ee43f830825751b200d739b53f20f5 ("video: sunxi: de2/3: clear all BLD address space").
  6. Like
    chwe reacted to yam1 in Mini handheld linux console :)   
    You could easily do that with any SBC discussed in this forum, e.g. k1plus dual screen + bluetooth keyboard, or a zero plus 2 h5, 5 inch hdmi + bluetooh keyboard, or a pi zero with double 18650 batteries and a 2.4" screen

  7. Like
    chwe got a reaction from NicoD in Benchmarking CPUs   
    Why so pessimistic/optimistic? (depends highly on point of view ) Just buy and add a cheap AI block, stick it to the SoC. RPi goes AI with Blockchain!!!1!  They will survive 2-3 years more with it..  
    If you accept that the RPi isn't a high performance SBC made to 'learn' programming, not really low level stuff, more different sorts of 'hello world' with GPIOs and/or camera. The RPi is still an affordable board. For this use-case their last iteration is worthless (you still can do this with a RPi3) but that's part of the deal to keep the people happy who pay their rent (seems that they aren't that happy at the moment, but hey, they sold over 19M devices so they can't be wrong right?  At least it seems to be their main excuse for every thing they didn't do right).
    Probably we should split the RPi rant part in the RPi thread, and @NicoDs 7zip results into this one?
  8. Like
    chwe got a reaction from NicoD in Benchmarking CPUs   
    Question out of curiosity.. What's a CPU only benchmark for else than miss information on the people reading it? Doesn't it lead to a situation which we still have? People buying CPU by:
    the more cores it has the better the more GHz is written on the box the faster it must be! For me there are two sides in benchmarking which should be kept in mind. First it should be reliable, means others should get 'the same numbers out' when they repeat your benchmark (e.g. I could benchmark wifi sticks somewhere in the alps here, for sure throughput would be a way higher than in my hometown were I've actually around 20 others wifis visible. A 'good' benchmark would involve both situations with a comment on why and how performance differs..). You should also think about who reads your benchmark. For the '30 years in computer science guy' it might be obvious that ram-speed, general IO speed etc. matters too, for the average smartass probably not.
    Things like "I bought *random sbc* cause *random guy* claimed that the CPU there is 10x faster than *random other boards CPU*. So others then have to explain the average smartass why this doesn't matter for his case due to someone smart enough to know it better decided to publish a benchmark which doesn't tell the full truth. Publish it with something like material and methods, discussion of this methods and a conclusion (somehow like a scientific paper). Otherwise your benchmark just lead to mis-assumptions which others had/have to correct.
    Best example, with the average smartass: "I bought a 2A PSU cause the RPi guys said buy a 2A PSU and your SBC will run fine and microUSB is better than the outdated barrel plug cause my tiny tiny connector is gold plated and my outdated big barrel plug with a huge contact area is only nickel plated.. " The reality showed that barrel plug SBCs works 'in general' more reliable especially under high powerusage situations but the RPi guys seem to disagree on this, otherwise they would never release the 3B+, or they think it's funny to troll their own community and make some extra bucks by selling 5.15V RPi branded PSUs, a microUSB powered board which needs a 'special PSU' is IMO just error by design (5V on the microUSB output should be sufficient otherwise your PCB designer failed).. but different story...  
    I tried once to 'benchmark' the CPU mostly with a tool called cachebench after reading through a paper written by Ulrich Drepper (and I'm quite sure, he knows what he's doing, for people interested, the paper is old but I think it's worth to read it) you could easily see if the benchmark happened in CPU cache or if it used RAM (as far as I've in mind, you could even distinguish between L1 or L2 cache mostly when it did memcpy) but I got results out of it which I could not explain, especially there were 'performance peaks' which shouldn't IMO be there which I couldn't explain in a rational matter. I decided to throw away the whole dataset and never published it cause it would only end in miss-assumptions (I think the bashscript which set-up the system reliable and converts data for analysis after its is still somewhere but I don't think it makes sense to work on it as long as I can't explain the results). 
  9. Like
    chwe got a reaction from gounthar in What would you choose to record and broadcast video?   
    'in theory' you  could do it on an asus tinkerboard with th 4.4 kernel. I got it working months ago, problem is that it breaks to much stuff and the kernel had so many issues that I kept the project 'on hold'.. From what I know, @JMCC tested it once with the ISP driver and it shouldn't perform that bad. Full HD recording should be possible...
    But there's a bit too much 'should' and 'could' so if you need a solution which works now and well tested it's obviously a bad idea. For sure there's some stuff to get it working. And you might compile the one or the other kernel on your own to test it. The isp driver should also work for RK3399 boards with a mipi csi but everything is untested there. 
  10. Like
    chwe got a reaction from tkaiser in Benchmarking CPUs (not yet a research article)   
    To late...   I think it makes more sense to split it yet otherwise it will be a hard nut to distinguish between what should be part of the research article and what's the left over from the original thread (this splitting often leads in headache for the one who has to do it). Feel free to change the title as soon as you think it's ready.  
  11. Like
    chwe reacted to mindee in NanoPI M4   
    Working on NanoPi M4 these days,  almost done, Here is the other side(not final version), would be available  in August, price is $79/99 (2GB/4GB RAM).


  12. Like
    chwe got a reaction from gounthar in OrangePi One Plus/Lite2, using H6 BSP 4.9 Allwinner BETA Kernel possible?   
    Learning by doing...  Nobody starts as a 'perfect' contributor doing everything right from the beginning. Read through this:
    and probably this one:
    H6 boards have plenty of stuff to step in. Try to fix something and then start to send patches. If you struggle somewhere report what you've tried, where you failed and maybe someone can give you some hints to solve it and maybe not, in case 42 isn't a sufficient answer.   The great thing armbian provides is the build-script which everybody can use, not only @Igor when he provides Images for a *random board*. It saves you in the beginning a lot of headache cause you don't have to deal with patch creation, applying those patches and choose a proper compiler for your tests (you'll understand the scirpt better and better as soon as you start to use it).  
  13. Like
    chwe got a reaction from gounthar in OrangePi One Plus/Lite2, using H6 BSP 4.9 Allwinner BETA Kernel possible?   
    Learning by doing...  Nobody starts as a 'perfect' contributor doing everything right from the beginning. Read through this:
    and probably this one:
    H6 boards have plenty of stuff to step in. Try to fix something and then start to send patches. If you struggle somewhere report what you've tried, where you failed and maybe someone can give you some hints to solve it and maybe not, in case 42 isn't a sufficient answer.   The great thing armbian provides is the build-script which everybody can use, not only @Igor when he provides Images for a *random board*. It saves you in the beginning a lot of headache cause you don't have to deal with patch creation, applying those patches and choose a proper compiler for your tests (you'll understand the scirpt better and better as soon as you start to use it).  
  14. Like
    chwe reacted to tkaiser in RockPro64   
    Already available: The official NAS enclosure which opens up plenty of opportunities for specific server and NAS use cases:

    Please check the product page for details (e.g. what's included and what you need to purchase separately)
    My understanding is that the drive cage can accomodate 2 x 3.5" disks and 2 x 2.5" disks though you can only use 2 of them at the same time with Pine's own SATA card (relying on an ASM1061 -- check performance numbers here, the tests were made on an ODROID-N1 which uses same SoC and SATA chip). The ASM1061 only provides 2 SATA ports (so eSATA and SATA can't be used at the same time) and is attached with just a single PCIe lane which is fine when connecting spinning rust but will already bottleneck two SSDs since PCIe will limit overall bandwidth then.
    Performance fanatics might skip Pine's cheap ASM1061 card and search for a PCIe card based on either ASM1062 or Marvell's 88SE9230 (both using 2 PCIe 2.x lanes, the latter providing 4 SATA ports). If it's just about attaching 4 SATA devices cards based on Marvell 88SE9215 will also do it (for performance numbers see here)
    External powering with one single 12V PSU (it's the common barrel plug with 5.5/2.1mm, centre positive) is sufficient. For 2 3.5" disks you should choose 5A.
    If you want to add Wi-Fi to this setup you most probably need to drill 2 holes to attach good external antennas (recommended since Pine's Wi-Fi module is a pretty decent one: AP6359SA is dual-band and dual-antenna and even RSDB capable which allows to use both bands at the same time so providing more bandwidth but especially lower latency if the AP also supports it)
  15. Like
    chwe reacted to martinayotte in 4MB sectors - aka "Optimizing Linux with cheap flash drives"   
    The "bs=" means "block size", it has nothing to do with "sector size" of a file system.
    It is only the size of the buffer used between reading the source and writing destination.
    Of course, a bs=4M will do the transfers faster than a bs=4096, which is not the same since the later means 4096 bytes.
  16. Like
    chwe got a reaction from gounthar in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    my fault..  
    Didn't have the 4.17 branch in mind (didn't know that you started with a 4.18 branch). So the statement is true for the masters branch where next is 4.14 and h6 boards only live in the dev branch. This is different for the 4.17/4.18 branch. So you might build your branch on top of them and then send PRs against those and not master.  @Igor will it make more sense to buid against 4.17 or 4.18?
    IMO it actually makes sense to name it different than armbians default names in case your git-fu is on a similar level than mine (in case a PR gets rejected it's just less work to sort this stuff out than to revert the git-history from the working branch and sync it properly with armbians branchnames, I can, but it takes me more time than just kill a dedicated branch for my idea).
  17. Like
    chwe got a reaction from gounthar in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    dev image only.. so you need a EXPERT="yes" tag set. Background: All sunxi boards share mostly the same kernel. Due to H6 initial support is based somewhere on top of 4.17 (probably partly 4.16), armbians "next" kernel (4.14) isn't an option for this board. 
  18. Like
    chwe reacted to frank-w in BananaPi R2 (.csc mt7623 as new boardfamily)   
    i changed Uart (Uart2=>ttyS0) and MMC (SD=0,emmc=1) from mainline to make my kernels compatible with official images (defined my images same way).
    i see some definitions...maybe they can be used to define which uart is used for debug-uart without changing the order in dts(i)
    aliases { serial2 = &uart2; }; chosen { stdout-path = "serial2:115200n8"; }; btw. 2nd gmac, hdmi, poweroff and some other stuff is working now in (my) 4.14...hnat is ported, but i don't know if it is working due to a "strange" test (cpu-interrupts increasing)
  19. Like
    chwe got a reaction from gounthar in Where to build Armbian in the cloud?   
    doesn't need to be an i7..  i5-2500k, 8GB DDR3 ram and a decent SSD (samsung evo).. besides the SSD, this system is around 6-7 years old and builds images in 10-20mins (depending on 'cachelevel'). Even on my 5 years old i5 notebook (i5-3317U with 4gb ram) I'm able to build an image in 20-30min. Both machines work obviously with native ubuntu without doker etc. (not recommended)
    Edit: the first build on my shitty notebook will take a way longer... probably 2 hours.. 
  20. Like
    chwe got a reaction from JMCC in v5.51 (desktop on top of cli, xu4 next upgrade, ...)   
    Fork it now and then stabilize it..  
    Actually I would prefer to get all RK SoCs under one hood. So, when we're able to get RK3399/RK3328 and RK3288 properly working with Ayufans kernel. Well then there's simply no reason to stay with the RK kernel. Okay there's no ISP1 driver  but this thingie doesn't work properly anyway (as soon as we think about DTBOs , I keep my rk default branch 'as is' in case we try it once again to get the ISP working without break everything else). 
    Reducing 'supported kernels' without dropping boards sounds good.  Might make sense to move this discussion to here? 
    Let me know when you want things from here moved to it.  
  21. Like
    chwe got a reaction from gounthar in What about Google Home   
    So the easiest way for me (others might do it differently) is:
    Fork the project on github clone your fork create a new branch on top of master for the stuff you want change switch to your branch in config-default.conf e.g. for my BPi R2 development  LIB_TAG="bpi"  
    Set create patches to yes:  CREATE_PATCHES="yes"  
    During build the buildscript says you when you've to make the changes. Test your new image and when it works as expected copy the generated patch to the corresponding patchfolder and rename it meaningful Test if it still works there and doesn't break any other patch (for your patch this will be unlikely but just make sure to follow 'good practices' from the beginning, it saves you and the maintainers time as soon as you create patches which may have the potential to break something). Push your new branch to your fork and create a Pullrequest against Armbians master branch where you describe what your patch does, the output of armbianmonitor -u (they may see stuff errors which came up with your patch which you didn't recognize). Why do I create branches on top of master and don't change things directly in master?
    Simply due to lazyness... In case my PR doesn't get accepted I don't have to play the git-ninja  I just remove the branch and sync my masters branch with armbians repo. As long as my master doesn't have any changes to armbians, sync is everytime fast forward means I don't create useless 'sync commits' which then confuse the armbian maintainers when I create a PR. For sure, when I'need longer for patching something (e.g. the BPi branch), I may have some sync commits in it but not for 'the short ones'.
    Why test two times?
    Just to make sure it doesn't break things. Armbian for sunxi has a bunch of patches this enhances the chance that your patch can break something, so better try your best to avoid it. You can't test everything, but test what you can test.
    Why use "create patch"?:
    You could also create patches in a different way.. But this way is known to work mostly without issues. Armbians current patches are applied before yours get applied so you work 'on top' of armbians patched kernel. So if you've to find a proper name for your patch you might check which patches touch the files you touch with your patch and make sure that your patch gets applied after them. Sometimes it also works the other way around but it's IMO not 'good practices'. 
    FYI: You may also switch to EXPERT="yes"  in default-config cause you'll build a dev image.  It may be also worth to just build an image without any changes before you start. Just to ensure that the build works as expected on the board. Saves you some headache if your changes don't boot anymore and you realize after its that the build was anyway broken at the moment... 
  22. Like
    chwe got a reaction from gounthar in Burn ISO Image to Micro SD Card   
    That's why the four (five) questions:
    Did you test the SD-Card with h2testw/f3? Did you use etcher? Describe us the powering situation? please report 'sudo armbianmonitor -u'? (show us the serial output during boot) come up on more or less every question which sounds a bit fishy. 
    Feelings and beliefs is the way people solve ~90% of their problems (90% was randomly chosen by feelings )... Similar to 'works for me' and 'I do *random thing* since 20 years so don't say that my approach is outdated since 19 years!!!' 
    I would suggest it with every hardware. It's just a question of time. Do you figure out immediately that your problem is related to 'faulty SD-Card' when it happens? When not, what needs more time? The few seconds each time to start up etcher for burning an image or the time to figure out that your card was corrupted since beginning (including the time you wasted to set up your system on top of an error you could avoid by using an appropriate tool)? If yes, fine do it. But don't expect that others are willing to look into problems you have when you don't follow the recommendations. 
    My SD-Cards for development aren't perfect (e.g. I use some old slow 4GB cards during testing). Mostly cause my best SD-Cards (SanDisk A1, known fast EVOs) are in the SBCs which run productive. My 'feelings' say that the BPi-R2 isn't that picky when it comes to SD-Cards. It 'seems' that the board works fine with them. Obviously, this can go wrong and then I have to blame my self for wasting my time. But cause this is during development and it would mostly waste my time and not others I'm fine with. During development, I burn a bunch of images but even then it's IMO not worth to switch to an alternative writer than Etcher (even when it uses more time due to crappy old SD-Cards), simply cause my development is also driven by 'feelings'. So, when a test-image doesn't work due to 'burn image went wrong' I may come to the wrong conclusion. This might drive my development in the wrong direction only cause I saved 2-3mins by burning an Image. Armbian shrinks the image to an appropriate size, you don't have those 8GB garbage Images as other 'distributions' have. So burning and validating took anyway less time. Is it worth to save some minutes more by use a 'dumb' image writer? IMO no. 
    I've a dumb bash script which checks my SD-Cards on a OPi Zero connected via a USB card reader. What it does is simple: It mounts my card, formates it, tests it with F3 and when it succeeds the GPIO with the green LED is toggled if it fails, the GPIO with the red LED is toggled. So I don't even need 'a real computer' during development to check my SD cards regularly to 'ensure' they're still okay... 
    'Everybody' believes that he doesn't use crappy hardware...   Read through this one:
    Most of them thought in the beginning their hardware was appropriate.. Sometimes hours of nailing down the problem showed that they were wrong. 
    That's what bug reports are for.  I don't know how the team reacts (simply cause I never had a reason to report a bug in their repo). But if you can show them that the same setup (e.g. same Image, same SD-Card, same card writer etc.) writes a working Image with win32DiskImager but not with etcher, they may be interested in knowing that.
    BTW @tkaiser etcher also provides a CLI tool, at the moment marked as experimental ( Do you have any experience with it? Is it worth a try? I've some automated buildstuff in mind (e.g. that my freshly compiled image gets written to an SD-Card automatically after build and I can go for a coffee and everything is prepared to test when I come back). 
  23. Like
    chwe got a reaction from gounthar in What about Google Home   
    the router is still questionable..  Due to shitty performance. There are some ideas to 'solve it' but all of them seems to be hacky... and not really wanted. But when you're driven by a need, this board might be fun.. 
    Why not? The board is basically here:
    E.g. The OPi One Plus has the same RTL8211E PHY attached as the PineH64. @Icenowy added support for this PHY for the pineH64:
    I'm not sure if just adding the DT-Nodes in 'sun50i-h6-orangepi-one-plus.dts' is sufficient to get it working.. But could be fun to get Ethernet working on this board, would make the board a way more usable. 
    FYI: this patch was added for the pine H64, but I don't know if and how well it works there (as said, I don't follow H6 development close enough):
  24. Like
    chwe got a reaction from gounthar in What about Google Home   
    Now you've to decide which 'pet project' you choose.  
    Personally, I don't think you should buy the SBC which needs most testing.. You should buy one in which you're interested. Debug & testing can be boring so at least the product you test should be interesting (for you). Therefore I don't recommend a specific SBC, maybe SoCs which (I think) are interesting makes more sense.
    RK3399, a bunch of boards are coming up, armbian just starts to support those boards. The 'overall' sources situation seems to be good in terms of documentation for the SoC and kernel sources. I'm not fully familiar how evolved u-boot (e.g. ram initialization, spl etc.) is. Drawback, they aren't that cheap (you've probably add a bit of money to the money you get from your colleague). RK3328, relatively cheap and powerful IO (e.g. USB3). Overall more evolved as the rk3399 but for sure still work to do. Just for fun: MT7623 - only cause I'm working on it . Only me works (sometimes) on this SoC, at the moment, only one board is widely available (BPi-R2) rumors are ongoing that other boards will show up, but I don't have much information here. Kernel is pure mainline and u-boot is very outdated (v2014). But as @tkaiser pointed out, this might also be one of these boards which don 't make that much sense, mostly cause there's only one board with the SoC available at the moment. In case more boards show up, it might get more interesting due to its decent mainline support.  Allwinner H6. Bloody edge, seems that after @Igors first commits there aren't many people interested in contribute to the related boards (I don't follow it close enough for a proper statement here).  
    It probably makes more sense when a developer presents one of his ideas/projects for armbian and you decide if this is interesting for you and if you want to join it. Some of these projects might be hardware depended others might be more generic. Your skills and/or topics you might want to dive in should also be considered (when I started with the MT7623 I had neither 'much' knowledge in the buildscript, kernel and u-boot but you'll learn things partly on the fly as long as you've a high frustration barrier  don't expect that you make everything right in the beginning ).
    Not to forget, documentation and/or tutorials are also always welcome. Show one of your project you deployed on top of armbian. 
  25. Like
    chwe got a reaction from gounthar in What about Google Home   
    I agree that the board is boring.. Most thingies with only one dedicated job are boring. They need to do one job good but not more. In this case, get more information from the user for googles databases.. 
    I partly disagree on your second point due the following reasons:
    Starting motivation is mostly driven by personal needs/abilities. I want to achieve something or I have this hardware and want to step into this 'low level stuff'. Starting with a boring board may save you from 'pressure to deliver'. Nobody cares when you fail with a 'boring board' whereas people can be really annoying when it's a board of interest. Why, why, why does *random feature* not work. From my own experience: The BPi R2 was/is mostly fun cause nobody cares.  The tinkercam was/is annoying cause people ask on a monthly base why this shitty thing doesn't work (in fact it would work but it breaks to much stuff to implement it at the moment).  'We' horrible fail in giving 'easy tasks' to beginners. There's a bunch of stuff which can be enhanced in armbian but a beginner may need some 'guidance' either to identify such a task nor guide/help them during this problem solving of such a task. I think this is mostly related to lack of time. Guide someone in the beginning will cost more time than do it on your own. Sometimes it's worth the efforts cause the one you guide will contribute after its on his own, sometimes it's not worth the efforts cause she/he will disappear after one 'sub-project' and you have to deal with code you've only reviewed, not written on your own.  Funnily we help a lot of people building their own 'pet project' or solve issues they have 'on top of Armbian'. But in the gray area between maintainers and end-users we somehow suck in supporting those people which may contribute more than one PR in the future. That's why I encourage people to try things even on 'boring board'. It may not help armbian in the beginning but hopefully the one or the other will learn some stuff to contribute after its to more interesting boards and/or more important tasks. Will it work? Is it worth? I've no idea...  Fact is, we support to many platforms/SoCs/boards for the current 'team of devs'. So we can either step down and support less boards or we try to encourage more people to contribute to the project. I'm not sure if this approach will work, but at least @JMCC could benefit from my experience with u-boot when he started to play with the renegade, wasn't IMO that a bad deal for the armbian project to help him with some basics in the beginning (u-boot is painful when you deal with it the first time).