lanefu

Moderators
  • Content Count

    280
  • Joined

  • Last visited


Reputation Activity

  1. Like
    lanefu reacted to TonyMac32 in board support - general discussion / project aims   
    There is a difficulty here, because we do not host the kernel sources.  Updates to kernel sources often break the configs/patchsets.  If you wish to continue an EOS board it would be recommended to clone the kernel, u-boot, and Armbian buildscript at the point of eos. 
     
      I agree money isn't the best discussion, I also see, however, a constant demand for professional-level support with no hint or interest of contribution of even time.  That is just as ugly, but hard to point to as easily.  
     
    There is a reasonable technical answer with some supporting information:
     
    - We have no requirement to support any board.  If it is not in our personal interest or benefit it simply won't happen.  I think some of the "regular devs" feel pressure and get frustrated that they can't satisfy the whims of the general public.
    - We have too small of a team to deal with demands and general Linux questions.
    - the code is all public and opensource, anyone can contribute/fork to do whatever they like board support wise.
     
    My personal action in this has been that I don't answer any general questions I don't have an immediate answer for.  If no one else does either I can't help that.  I think it works out in the end.
  2. Like
    lanefu reacted to chwe in board support - general discussion / project aims   
    Well that one went into personal insults of each other which is for sure not what both of you want... Let's try to figure out where and why this went wrong.  Starting from here:
     
    Well the answer was more or less there:
     
    understandable, it's frustrating. when 'your board' gets dropped.. But you must also understand that we can't support every board for years, especially if it's not sold anymore.. It's work to adjust the related patches everytime, to test it before we provide a new image and the support over forum. This thread was meant as a 'board support - general discussion / project aims' not a how to I get *random board supported*. For such a topic you should open your own thread.. E.g. here: https://forum.armbian.com/forum/25-peer-to-peer-technical-support/ (Armbian support ended or never existed - 3rd party boards and external hardware). Hint (since the SoC is still supported you basically need an ubuntu image, a device tree (or fex file in case you deal with the old kernel which I don't recommend) for your board, a defconfig for uboot, the buildscirpt and some time to build your images and see if and what's working (so you get also a clue what it means to support a board... and we support a few more than one)..
    Such questions show up constantly.. This can be frustrating.. Sometimes you get then a less polite answer.. that's human.. your first post maybe wasn't a rant.. the follow up here clearly were.. From there you can answer (as @Igor did) or as I do quite often... Just ignore it.. I'm mostly not in a mood to answer to stuff which just annoys me, why should I? As others, I donate my time for free and it's not worth to deal with annoying stuff. There's enough funny stuff to do on a project like Armbian. Even helping other people to get familiar with the buildscript can be fun, but clearly not if someone drops partly into the wrong thread, complaining multiple time why his question isn't the most important one we should answer to.. and then complaining about bullying... In case you still want to bring back your board working:
     
    Here's one where I implemented a whole new SoC family into armbian:
     
    And in this thread I tried to basically show *my workflow* to patch a kernel and u-boot to bring in a feature into an existing board:
     
    with those two, and enough time, you should be able to bring back your board into the buildscript.. And if there are still open questions, you can open a thread in P2P and maybe someone is willing to give you some guidance who knows.. I hope we can keep this thread now as for what it was for, in case not I'll either close it for a cool down phase or just delete the off-topic part, depending if I've a good day or not..
  3. Like
    lanefu reacted to Tido in board support - general discussion / project aims   
    but it sounds like we have to look around the corner, something is coming
     
    EFI Support
    We are moving towards having standardize boot by supporting EFI.  However, the bootloading process is using the EFI facilities and you will now have a EFI-based GRUB GUI that lets you control boot parameters where as it was hard coded before.
    https://libre.computer/
     
  4. Like
    lanefu reacted to Igor in board support - general discussion / project aims   
    It's simple to implement this on image for one machine, while implementing this on all armbian supported boards looks more complicated. For users perspective, things as such
    bring more on the table. But I do agree we shell pay attention.
  5. Like
    lanefu reacted to Igor in Improve 'Support over Forum' situation   
    This is irreversible. Any objections?
  6. Like
    lanefu reacted to Igor in Improve 'Support over Forum' situation   
    Proposed actions:
     
    1. Renaming section "Technical support" to "Bug tracker" (leave restrictions as is)
    2. Merging "Common issues" with "Peer to peer" and place under "Community forums" section
    3. Creating new section "First aid" 
        - move "SD card and power supply"
        - create "Board doesn't boot"    
        
        or move "SD card and power supply" one level up and rename to "Board doesn't boot"    
     
    Alternatively:
    4. Make "armbianmonitor -u" field mandatory for "Bug tracker" section except "board doesn't boot"
    5. Move NXP and Armada A388/A3700 under "Other supported boards"
  7. Like
    lanefu reacted to TonyMac32 in Improve 'Support over Forum' situation   
    That's a separate issue, but it lies in the reality vs. what we would like to see be true.  The simple reality is you can't force people into line without draconian policy/rules/etc that will choke off the community in general.
     
    Now, if it were possible, I would say, along some reorganization lines as Igor posted, that we have a "select your board" drop down requirements for the Support subforum, and if we can go even further, sort them appropriately by that tag.  Then it gets easier, we only have spammers posting in whatever the first board on that list is.  ;-)
     
     
    Well, the forum is the part people see above ground, a lot of its issues relate to the roots, so it's bound to get complicated.  For example, WIP/CSC's having downloadable images on armbian.com results in user questions, which increases our support traffic for boards we obviously don't find interesting enough to support directly.
     
    Ignoring them is somewhat effective, but like I said above, making a single part of the forum a "gated community" with curated/controlled input should make it so stuff like that can be ignored with a documented reason, without necessarily causing any collateral damage.  And of course keeping boards to a minimum or at least defining what the core boards are should help as well. 
     
    My thoughts on this fall more into the perception and the actual scale of the project.  The act of imposing regulation and setting a bar is viewed as pretentious or exclusionary by the human psyche in general.  That's not necessarily a bad thing, however it's being introduced into a space that was previously open to admittedly "too free" of discussion.  Is it possible to sort posts automatically by tag and then by age?  At that point, a fully filled out questionnaire (with a check so that http://Idontfillout.form won't be accepted ;-) ) would receive a tag that puts it at the top of the non-pinned pile, and above anything that skipped a step.  That simple feedback of basically demoting the content instead of downright blocking it should passively take care of the issue, and if someone gets noisy a mod can point out their stuff is under all the properly filled threads because it wasn't done correctly.  I'd guess there'd have to be some sort of qualifier based on age for when that sorting stops, otherwise the first improperly filled out post would be on page 12 or some nonsense.
     
     
  8. Like
    lanefu reacted to Tido in Selling Pi-based products very hard to hack   
    Hi Pietro,
     
    If your software is so good, that people are willing to pay money "if they rather use it than steal it", well done.
    If you offer it to others who do not have the money but use it, test it and give you feedback and even help you to make it better - win - win.
    This is how https://www.invoiceninja.com/  built a great company - listen to the podcast on https://twit.tv/shows/floss-weekly/episodes/506?autostart=false
     
    so long
  9. Like
    lanefu reacted to guidol in v5.73 mini bugfix release   
    WOW  on a OPi Plus2 H5 the time - which was displayed - was gone down from 15 to 4 Minutes with 5.73 for transfering armbian to eMMC
  10. Like
    lanefu reacted to sgjava in Improve 'Support over Forum' situation   
    They manage OpenCV on github, so I think that would be great to continue there for Armbian. Jira is chock full of unnecessary complexity. We use it at work and you become a slave to the process instead of programming.  This is really the only method that really works http://programming-motherfucker.com
  11. Like
    lanefu reacted to TonyMac32 in Improve 'Support over Forum' situation   
    I see some structural challenges here.  One is a perceived hierarchy perhaps keeping some people from mentioning issues (to be honest we already have that problem, I've had small issues in images for months before someone pointed it out).  If we take this route, then the forum has to be as open as possible to general user complaints.  Restricting access results in a shrinking of community in general, it's a difficult position because in order to grow the community you have to allow "know-nothings" to ask questions and hopefully become "know-somethings".  We also need to find a good way to appeal to a more diverse user base, application wise. 
     
    People like @Larry Bank and @sgjava have done some great work, but our willingness (and ability) to support ends with server-type environments (nothing wrong with this, but it is a *very* limited niche of people who can contribute to that specific task thing)
     
    @JMCC is doing great work with media, if we can roll at least some of what he's doing into the build script it would be fantastic (I was thinking we should package his scripts as part of a board or family specific armbian-config menu)
     
    So we have the groundwork for IoT and Multimedia applications, which will make our little Linux project more interesting for the general public, especially if we can make these things somewhat standard, we get more users.  from those users, some programmers/maintainers/mods/etc will show up.  The issue is the age old one of humanity:  Talent and interest are hard to find together. If the vendors are not willing to help, despite the value, then we need to move an insane number of people through the forums to snag ones that are able and willing to contribute.
     
    I think we do need to approach the "slimming down" of our boards a bit more carefully.  This is something along the lines of @tkaiser's comments about this being a project for us, with our help to everyone else being a happy side-effect.  If we are not overwhelmed, we make better things, the community benefits.  If a high-level user wants their board supported badly enough, they will work to support it (Me with Tinker Board)  We need to add a "maintainers" list or something similar, this is for one simple reason:  boards with no maintainer need to be put on probation.  A stronger definition of individual roles (not in a leadership sense, just in a contribution sense) will help as well I think. 
    If a board has no maintainers and no vendor support, it should be "CSC'd", with a list on the website with "looking for maintainers"  I would propose we not make images for those boards available on the download page, allow people to build them if they want.  That alone filters who would be asking questions.
     
    So, for boards:
     
    Each board entry should include 2 additional fields:
    Maintained-by  (Member or members) Vendor-supported (Does the Vendor give Armbian anything more than just a couple boards?  I include technical support here) So Tinker Board and Le Potato would look like:
    supported-by: tonymac32 vendor-supported: yes  (or we could make tiers, everything from boards on demand, technical support, direct code contribution, money)  
    For Member-contrubtors:
     
    boards hosting documentation etc So Igor (sorry if I massively under-represent:
     
    Build Script Author (obviously multiple people can have each tag) Web Admin Build Hosting Family-Allwinner Family-Freescale Documenter etc I can expand on this later in a specific thread since it covers a wide topic matter.
  12. Like
    lanefu reacted to umiddelb in Improve 'Support over Forum' situation   
    Here's a reference for an open source project using jira ...
  13. Like
    lanefu got a reaction from TonyMac32 in Improve 'Support over Forum' situation   
    Okay im not gonna lie...that makes me pretty excited..    i cant believe im saying this but id gladly admin jira.
     
    I have it running in my nomad cluster on one of my opis.  (I dont recommend such insanity btw)
  14. Like
    lanefu reacted to chwe in Improve 'Support over Forum' situation   
    well which project do you think?
    Let's look at a few which have some similarities.
    Retropi:
     
    Raspian:
    https://www.raspberrypi.org/forums/viewtopic.php?t=208814#p1291227
     
    OpenWRT:
    https://openwrt.org/bugs
     
    DietPi:
    mostly forum, a bit on GitHub
    ________________________________________________________________________________________-
    There's no project which is 100% similar, otherwise one of them would be obsolete.. A few of them scale bigger, some have a different focus. Some ideas:
    manual transfer: as soon as a experienced user/mod/maintainer realizes that the forum post is related to an issue he opens it, summarizes it and links to the related forum post. It's time consuming but we would keep track on all those bugs we spot through forum posts.
    As soon as we have an issue tracker outside forum or github, we've to train people once again to use it.. we've to maintain it.. and those not willing to register somewhere will still use the forum for that. The only idea which comes to my mind is either one on a well established platform so that the average user has it anyway (e.g. github) or mailing-list (I assume most people will still have a mailaccount ) but not sure if maintaining a mailing list would solve any problem - I would assume not.
     
    Maybe we can implement a bug Tag? once figured out that a thread is bug related mods/admins/devs could just add the bug tag to the related post/thread? Keeping an eye on threads with such a tag might be easier.. Still, the tag has to be removed once the bug is fixed, but it could be a starter.
     
  15. Like
    lanefu reacted to umiddelb in Improve 'Support over Forum' situation   
    Atlassian offers free-of-charge licenses for Open Source projects ...
  16. Like
    lanefu reacted to TonyMac32 in Improve 'Support over Forum' situation   
    !!!  We use Jira at my day job...  interesting
  17. Like
    lanefu got a reaction from Werner in Improve 'Support over Forum' situation   
    Hey @Igor  Here's an alternative version of the board maintainer text.   Feel free to tune as you see fit.

    https://gist.github.com/lanefu/7c54235264d0f8e442c8799249220bf6
  18. Like
    lanefu got a reaction from typoinmyname in Just a test   
    link didnt work.... but hey I'm glad to see you, wonderin where youve been
  19. Like
    lanefu reacted to Igor in Improve 'Support over Forum' situation   
    Updated with wanted list:
     
  20. Like
    lanefu reacted to gprovost in Helios4 Support   
    Let me explain a bit more the issue that was experienced by @integros @lanefu and could happen to anyone that did a fresh install using release 5.67 and then attempting a system upgrade.
     
    This boot issue happens because new u-boot package (5.70) doesn't anymore update automatically the u-boot bootloader binary on target however bsp package (aka linux-****-root-next-helios4_5.**_armhf.deb) still update the bootscript. Therefore it will create an incompatibility case between bootloader and bootscript that we experience already in the past following upgrade form u-boot 2013 to u-boot 2018. We did address this incompatible use case previously but we didn't foresee it would happen again because of that recent decision that u-boot package shouldn't anymore be automatically updated.
     
    We unfortunately created a tricky situation and we need to find a solution that works for everyone,  that includes people running release 5.67, they should be able to upgrade without being aware of this issue. In the meantime :
     
    To everybody, when you do a fresh install please don't use version 5.67 on Armbian website, but use our latest image build (5.68) that is available on our wiki here until a new image build is done by Armbian.
     
  21. Like
    lanefu reacted to aprayoga in Helios4 Support   
    I'm sorry, my bad, I accidentally include UHS-I SD card patch on that test kernel, the DTB to be exact, and apparently your card does not compatible. You can read more about this at SDIO (SD Card) page on our wiki. You just need to install the linux-image package. No need to install the dtb and headers.
     
    Regarding XOR, yes i notice it too. I think it would default to software implementation first then override later by async_tx if the hardware offload engine is available.
    You can see on kernel message below, the async_tx initialized quite late compared to xor and raid6.
    [ 0.004600] xor: measuring software checksum speed [ 0.043885] arm4regs : 2533.000 MB/sec [ 0.083885] 8regs : 1947.000 MB/sec [ 0.123884] 32regs : 1804.000 MB/sec [ 0.163884] neon : 1840.000 MB/sec [ 0.163887] xor: using function: arm4regs (2533.000 MB/sec) <...> [ 0.240055] raid6: int32x1 gen() 262 MB/s [ 0.307944] raid6: int32x1 xor() 271 MB/s [ 0.376037] raid6: int32x2 gen() 351 MB/s [ 0.443939] raid6: int32x2 xor() 329 MB/s [ 0.512026] raid6: int32x4 gen() 393 MB/s [ 0.579947] raid6: int32x4 xor() 319 MB/s [ 0.647890] raid6: int32x8 gen() 422 MB/s [ 0.715956] raid6: int32x8 xor() 324 MB/s [ 0.783897] raid6: neonx1 gen() 1212 MB/s [ 0.851888] raid6: neonx1 xor() 1150 MB/s [ 0.919918] raid6: neonx2 gen() 1296 MB/s [ 0.987897] raid6: neonx2 xor() 1347 MB/s [ 1.055893] raid6: neonx4 gen() 1349 MB/s [ 1.123902] raid6: neonx4 xor() 1377 MB/s [ 1.191883] raid6: neonx8 gen() 1073 MB/s [ 1.259882] raid6: neonx8 xor() 1041 MB/s [ 1.259885] raid6: using algorithm neonx4 gen() 1349 MB/s [ 1.259888] raid6: .... xor() 1377 MB/s, rmw enabled [ 1.259891] raid6: using neon recovery algorithm <...> [ 1.425544] mv_xor f1060800.xor: Marvell shared XOR driver [ 1.457595] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) [ 1.457693] mv_xor f1060900.xor: Marvell shared XOR driver [ 1.485586] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) <...> [ 4.580251] async_tx: api initialized (async)  
    I built another test kernel with "DMA Engine verbose debugging" option enabled. These lines printed repeatedly (well, not exactly same address) during dd from /dev/zero to /dev/md0 and the interrupt counter increased.
    [ 416.505470] mv_xor f1060800.xor: mv_xor_prep_dma_xor src_cnt: 1 len: 4096 dest 0x216eb000 flags: 32 [ 416.514571] mv_xor f1060800.xor: mv_xor_prep_dma_xor sw_desc ed89d780 async_tx ed89d79c [ 416.522719] mv_xor f1060800.xor: mv_xor_tx_submit sw_desc ed89d780: async_tx ed89d79c [ 416.530582] mv_xor f1060800.xor: mv_chan_start_new_chain 190: sw_desc ed89d780 [ 416.537865] mv_xor f1060800.xor: activate chan. [ 416.542544] mv_xor f1060800.xor: intr cause 2 [ 416.546915] mv_xor f1060800.xor: mv_chan_clear_eoc_cause, val 0xfffffff8 [ 416.553658] mv_xor f1060800.xor: mv_chan_slot_cleanup 280 [ 416.559076] mv_xor f1060800.xor: current_desc 7f056380 [ 416.564253] mv_xor f1060800.xor: mv_chan_clean_completed_slots 227 [ 416.570461] mv_xor f1060800.xor: mv_desc_clean_slot 247: desc ed89d780 flags 32 [ 416.577803] mv_xor f1060800.xor: mv_xor_prep_dma_xor src_cnt: 1 len: 4096 dest 0x2ceaf000 flags: 32 [ 416.586894] mv_xor f1060800.xor: mv_xor_prep_dma_xor sw_desc ed89da00 async_tx ed89da1c [ 416.595019] mv_xor f1060800.xor: mv_xor_tx_submit sw_desc ed89da00: async_tx ed89da1c [ 416.602890] mv_xor f1060800.xor: mv_chan_start_new_chain 190: sw_desc ed89da00 [ 416.610142] mv_xor f1060800.xor: activate chan.  
    ---
     
     
     
    Initially I had no idea why the update break the system. I did several time testing the update scenario from 5.64 to 5.68 & 5.69 (both are internal release). Then I realized that I missed that you started from 5.67 which i thought never released. 
     
    I would say,  the 5.67 contains broken u-boot 2018.11. It only compatible with boot-mvebu-next.cmd. It already fixed on this commit part of PR #1169.  So version 5.68 onward should be compatible with both, boot-marvell.cmd and boot-mvebu-next.cmd.
     
    Since the fix just modify the environment variable, I suggest to run these commands to make it also compatible with boot-marvell.cmd. 
    setenv boot_a_script 'load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; setenv boot_interface ${devtype};source ${scriptaddr}' setenv loadaddr 0x02000000 setenv fdt_addr ${fdt_addr_r} saveenv I have tested it on 5.67
  22. Like
    lanefu reacted to Igor in Improve 'Support over Forum' situation   
    New features and restrictions for "Technical support" area:
     
     1. Validating users, those who just register are unable to reply to topics. They are forced to open a new topic.
     2. All users have to accept conditions (cookie last one day): 1. Call to use docs and search 2. Call to support us 3. Call to provide info
     3. Each time a topic is created, you need to add: armbianmonitor and accepty several conditions
     4. Auto lock topics is now set to 365 days, pinned and featured are exempt, ... and it will take a few days before locking will be completed. 
  23. Like
    lanefu reacted to Igor in Helios4 Support   
    Fixed by removing broken files from repository:
    pool/main/l/linux-bionic-root-next-helios4/linux-bionic-root-next-helios4_5.70_armhf.deb
    pool/main/l/linux-stretch-root-next-helios4/linux-stretch-root-next-helios4_5.70_armhf.deb
  24. Like
    lanefu reacted to gprovost in Helios4 Support   
    Sorry guys for late reply. I'm getting soon married and I'm pretty overloaded between Helios4 delivery follow-up and taking care of this big personal event. So please bare the latency in the coming days. Everything will be back to normal in February.
     
    @gabest To be honest we haven't done much experiment with ZFS but we have couple of people that reported good feedback and performance with ZoL on Helios4. Most of them where using mirror vdev instead of raidz mode, you can find plenty of discussion on this topic but it's an important factor in the case of Helios4. The other important factor for good ZFS perf on Helios4 is deduplication. Actually the dedup mode is the main reason why ZFS need so much memory, so with 2GB in Helios4, you need to disable dedup if you want good perf.
    In regards to ZoL maturity / stability on 32bit system, I don't have much insight on this. I just know that starting v0.7.0 some improvement were made for 32-bit stability. So for this reason it is recommended to use ZFS from stretch-backports (https://packages.debian.org/stretch-backports/zfsutils-linux)
     
    @djurny Actually we modified fancontrol on purpose in order to set the fan speed to 0 when fancontrol exit. This was to address the use case when someone power down the system, in this case you don't want the fan to go full speed. But after the message from Harvey and my response below, I think there is a bit of contraction in our logic. Let me think about this and we might just revert the fancontrol to its original behavior.
     
    @Harvey Helios4 Power Management is rather simple since it was designed for a system that is running 24/7 (or in IDLE/DEEP IDLE state if you want to use Wake-on-LAN).  We didn't include a PMIC in our design to address this specific use case of powered off system. When you halt your system, the Helios4 SoC power domain will remain ON and since there is no more OS running so there no more CPU Dynamic Frequency Scaling (DFS), so my guess is the SoC is running at its highest clock when system is halted compared to idle. This would explain the difference between in power consumption System IDLE and System Powered-Off. However we will need to double check that.
     
    @djurny Humm very good point. When I was doing benchmark during the early stage of the project, it didn't get to my mind to check the /proc/interrupts. Only later when working on the CESA engine I figured out checking the interrupts was the way to check if engines were used to offload operations. It completely slipped my mind to do the same check again for XOR engines. Well thanks to you, I can see my early assumption was wrong. We will need to investigate how to force system to use the MV_XOR and how it would improve performance and/or system load.
  25. Like
    lanefu reacted to jock in Is Mali GPU driver available in Mainline for H3?   
    The answer is yes, it can be done, but you need a bit of knowledge about compiling kernel modules.
    I made it on an Orange PI PC (Allwinner H3) to test my armsoc drivers and it worked, although Mali-400 MP2 embedded into H3 was quite slow.
     
    You should be able to take everything you need (both the kernel driver and the userland EGL+OpenGL ES drivers) from https://github.com/mripard/sunxi-mali
    Kernel and userland libraries should match their versions to be sure that they work correctly together: if you use r6p2 kernel driver, use r6p2 for userland too.
    Instructions are easy but here are some hints:
    You need the kernel headers package installed, you won't get far without this; you should be able to use apt-get to install the appropriate package for your armbian version You can compile the kernel driver on your very same board (I strongly suggest this), so you don't need to export the CROSS_COMPILE environment variable export the KDIR env variable to point to your kernel headers. Typically: export KDIR=/lib/modules/$(uname -r)/build export INSTALL_MOD_PATH env variable to point to your kernel modules:. Typically: export INSTALL_MOD_PATH=/lib/modules/$(uname -r)/kernel follow the instructions as described, but expect some patch won't work or compile fail. Just don't be scared to get your hands dirty, it is common that you may need to do some little manual adjustments (a missing kernel file here, a missing header there...) Once the driver is compiled and installed, you should be already able to modprobe it.
     
    Follow the instructions to install the userland EGL and OpenGL ES libraries too.
    If you are using the X server, you need the x11_dma_buf flavour and you also need to compile this armsoc driver too (maybe you can try the already compiled version I published on this post, it should work for your SoC too. Ignore the media script part which is for rockchip socs).
    If you don't use X you can use the fbdev flavour, in this case add extraargs=drm_kms_helper.drm_fbdev_overalloc=200 to /boot/armbianEnv.txt as per-instructions.