zador.blood.stained

Super moderator
  • Content count

    3391
  • Joined

  • Last visited


Reputation Activity

  1. Fourdee liked a post in a topic by zador.blood.stained in Orange Pi Zero H2+ missing modules TV   
    I think the issue here is an overall frustration by the core team due to many factors: stress, update failures (including ones that happened due to human mistakes), trying to support too many boards and too many features at once, failed expectations of users, board vendors and upstream developers. And this frustration exits randomly in random places, which definitely should not happen in public, especially for a relatively big and popular project.
     
    (off-topic) Unfortunately a lot of both kernel and non-kernel issues are out of our control too. And there will be those issues when dealing with cheap and popular low-end devices (like OPi Zero) that have close to zero software support from vendor (well, cheap things are usually cheaper than other similar things for a reason).
  2. zador.blood.stained liked a post in a topic by jernej in H3/H5/A64 DRM display driver   
    Today A83T HDMI driver was merged Now to the H3/H5 driver, which should be more straightforward for mainlining. Seems like with 4.17 there will be no need for DRM patches, except maybe for A64 (depends when Icenowy can get DE2 clocks & SRAM patches merged).
  3. Technicavolous liked a post in a topic by zador.blood.stained in Clearfog Pro 4.14.14 Network Manager fails   
    According to my tests this will be fixed in 4.16. Or it can be fixed right now by removing NM and using a different way for configuring networking (ifupdown, systemd-networkd)
     
    Edit: Though I don't have the Pro model so not sure if DSA will still be an issue with NM.
  4. Green Daddy liked a post in a topic by zador.blood.stained in Testers wanted: sunxi Device Tree overlays   
    From Armbian documentation (https://docs.armbian.com/User-Guide_Allwinner_overlays/)
     
    Most in-circuit and GPIO based interfaces (SPI, I2C, I2S, …) don’t have a mechanism for detecting and identifying devices connected to the bus, so Linux kernel has to be told explicitly about the device and its configuration details.
     
    While Device Tree is a way of describing hardware configuration to the kernel, Device Tree overlays are a way for modifying the DT in order to provide the kernel and kernel drivers with details about external devices or to activate interfaces disabled by default.
     
    What do we want?
     
    We want to add Device Tree overlays for the onboard interfaces and tested external devices so that they appear in future mainline Armbian images. This means that activating this type of hardware will not require recompiling the Device Tree or will require compiling just the overlay file which will be compatible with future kernel updates.
     
    What kind of help do we expect?
     
    We want people to participate in making and testing overlays for the hardware that they have.
    Participation requirements:
    An A10, A20 or H3 board that can boot the current mainline kernel Serial console adapter for getting the u-boot logs if they are needed Extra SD card to use for booting the nightly/beta images I2C, SPI or I2S (only A10 and A20 based boards since I2S driver is not present on H3 yet) device that you can connect to the board and that requires either generic driver (like SPIdev) or a special driver (available in the mainline kernel), with an exception of custom built boards that don't have commercially available compatible alternatives and devices that don't have in-tree kernel drivers. Some generic Linux knowledge (i.e. how to obtain a dmesg log, how to check file contents) At least a basic understanding of the hardware that you have and how does it integrate into Linux. For example I have no idea how to calibrate a resistive touch screen even if I can write a DT overlay for it. Please note that some hardware limitations (i.e. number of SPI chip selects, missing SPI DMA support) may affect possibility of supporting some devices  
    What overlays are already available?
     
    Please check the README in the subdirectory for your SoC in the overlays repository: https://github.com/zador-blood-stained/sunxi-DT-overlays-armbian
  5. jiapei100 liked a post in a topic by zador.blood.stained in Successfully built .img but failed to boot...   
    You are trying to solve a problem that doesn't exist in a first place - OPi Plus2 works with existing OPi Plus configuration - DRAM size is autodetected by the u-boot/SPL and eMMC size is not hardcoded anywhere too.
     
    I case you still want to go your way you need to add the missing DT file to the kernel too, if you provided a text boot log instead of pictures I'd copy the relevant part from it.
  6. lanefu liked a post in a topic by zador.blood.stained in H6 boards: Orange Pi One Plus, Orange Pi 3 Plus and Pine H64   
    ... or not. Merged here and renamed this thread to include "Orange Pi One Plus" in the title.
  7. jiapei100 liked a post in a topic by zador.blood.stained in Successfully built .img but failed to boot...   
    There is no such configuration in the Armbian build script. If you added a configuration or made any other modifications to the build script or its configuration you have to fix issues by yourself - add missing device tree files, fix u-boot configuration, etc.
  8. jiapei100 liked a post in a topic by zador.blood.stained in Orange Pi Plus 2 support...   
    Renaming/disabling the xradio patch file is a better option IMO.
  9. jiapei100 liked a post in a topic by zador.blood.stained in Orange Pi Plus 2 support...   
    This is caused by 4.14.17 kernel update - at least the xradio compilation is broken.
  10. Tido liked a post in a topic by zador.blood.stained in Kickstarter: Allwinner VPU support in the official Linux kernel   
    Yes, but in a long run this may not be enough, there are too many sunxi SoCs and not that many involved developers to get mainlining efforts close to Amlogic or Rockchip levels, and any documentation issue only makes it worse, especially for essentials like DRAM code.
  11. Tido liked a post in a topic by zador.blood.stained in Kickstarter: Allwinner VPU support in the official Linux kernel   
    Yes, but in a long run this may not be enough, there are too many sunxi SoCs and not that many involved developers to get mainlining efforts close to Amlogic or Rockchip levels, and any documentation issue only makes it worse, especially for essentials like DRAM code.
  12. chwe liked a post in a topic by zador.blood.stained in Bordsupport - general discussion / project aims   
    For me frustration comes from this:
    - legacy / backwards compatibility that prevents making advancements or fixes
    - trying to make "one fits all use cases out of the box" images - too much stuff to maintain
    - lack of communication/understanding of some issues, i.e regarding base firmware package contents (example of the results)
     
    Wrong user expectations come from existing problems - web pages contents, extra (IMO excessive) branding, overall project positioning
  13. chwe liked a post in a topic by zador.blood.stained in Problems with 5.38 update   
    Looks like u-boot MMC numbering changes broke backwards compatibility with our old boot script (that had "mmc 0" hardcoded everywhere, pre-23-08-2017), now the question is which images are affected.
    @Igor
    I would recommend removing new u-boot packages from the repository for all sunxi devices that have eMMC. Or simply for all sunxi devices since I'm not sure if other old (something like pre-5.30) images will be affected.
  14. zador.blood.stained liked a post in a topic by Igor in Bordsupport - general discussion / project aims   
    IMO, minimizing complexity and subsequently saving energy should be a recurrent activity. Its so simple to get lost in a pile of code, projects and tasks. Few of people, including myself, are too involved and sometimes is getting too much. I don’t want to get depressed or disabled by stress, so more tasks should be redistributed or cut. It's not just about board support count.

    When a board can come to a support list:
     
    - if there are not a lot of problems and most of the stuff already work. At least: network, (HDMI), thermal protection, to run as a server.
    - if there is at least one stable kernel,
    - if we got minimum of two boards/persons to cover, except special cases, where one board is stripped version of the one we already support
    - [new] if we have chosen a responsible person(s), not necessarily a developer, for editing board status and to join perhaps with personal motives and spread responsibility. Technical part of editing is under rework and will be done in some simple manner within a Wordpress only (no more WP + github .conf + github. Putting to other words – if we, as a community, wanted to have longer support for certain boards or their less aggressive moving to »deprecated« section, we need people to take a part in this maintainer/tester role - to take responsibility. BTW: last week I throw out some obvious deprecated candidates, while I still have some left: Odroid C1, Bananapi+, Beelink X2, Lime1. From a kernel perspective: sun4i, sun7i, odroid1
    - what else?
     
    From this perspective, H3 NEXT images should now get a support status. Should they? Shell we merge forums into one? Its yet another decision to make? Should I just do it or shell we spent "long hours on meetings"? BTW. There was an idea by @Tido that we should start to use some VOIP solution (https://wiki.mumble.info) to regularly, better and faster clear out opened questions. If this helps save energy, I fully support the initiative.
     
    Then, there is a question how a board becomes a WIP and why it is not just CSC? How is this path from nothing to WIP, something like »Board bring up« / »Support proposal«? It seems like a good idea, but the very first proposed board, Rock64, proved to be a hard nut or it is simply too early to do anything with? There are many uncertainties and it’s a hit and miss game per se. Or rather push here and there – only our initiative is anyway not enough – and move the board among supported, when we have enough "ifs" on the table?
     
    In essence is all about a kernel, not boards. I would rather start talking from there, always. And what @zador.blood.stained already exposed - there is usually a personal motive to work on some board or type of problems and we have to consider that, when doing some plans or talking and organising the work around the project, but certain things, those which might not require a lot of time and energy, could be agreed upon. 
     
    Reasonable minimal OS images, exactly. Perhaps we have to look on this more from the user side. But we face a big variety, from »I am new to Linux« down to kernel hackers. Well, first ones take a lot of time and ask stupid questions, while others don’t ask much, but when they do, sometimes is not possible to answer – because of quantity, complexity or we simply don’t know the answers.
     
    Cleaning is a very good idea but its some work.
    Yes, this is a good description, but how users see this? Each Linux distribution is nothing but a mix of just some packages. Some only mix and add a stamp, others do big changes. Nevertheless, how big changes are, we have to tell people, where we can help and for what we ask people that is better to use a Google or ask elsewhere. This makes me think to do some changes to a forum (at once) and remove »Common issues« since they are nothing but a generic Debian/Ubuntu problems (which should not be our problem) and merge them with »Peer to peer«.  There we add a sticky where and how to search. Also move all nontechnical stuff from »General chit chat« as well. I hardly catch up on topics and can't moderate forum content. If this is too much for current moderator team, it should expand. 
     
    New WEB is under construction and the person who is doing the actual work - from UX and design perspective - is doing this on biased limited input. Old WEB, the way it looks now, is a patch over patch over patch. Affiliate Amazon links are added value content, but since it’s tied to a kernel only, it might not show up completely correctly. This problem is being considered in the new database design. 

    Current WEB is not a representation of what I or what we wanted to show. That’s the reason something is going on in this field. A basic logical concept of WEB is already standing, without any content. It's possible to add direct comments and check actual navigations - currently, only me and Tido were added comments and if anyone wants to participate in the process, send me a PM and we will ger credentials. Currently, we have a basic frame, UX is getting better and database/web management is designing from scratch.
     
    It's a stereotype which won't just go away. We can only send those who come up with such questions to the place where all those common things, like power supply, SD cards, ...  essentially to the "Getting started"/"welcome to forum" and simply stating that Armbian is a generic Linux distribution and we don’t cover such special cases. KODI might work, but most likely won't and you better look after a special multimedia distributions like Openelec, Librelec, … In any case, users must be aware how to find such information from a very first page. Such questions are considered in a UX redesign over and over again.
  15. zador.blood.stained liked a post in a topic by Xalius in More details on PineH64 (H6) and RockPro64 (RK3399)   
    Just in time for FOSDEM some more infos on the new Pine64 H6 and RK3399 boards are available now...
     
    https://forum.pine64.org/showthread.php?tid=5614
  16. TonyMac32 liked a post in a topic by zador.blood.stained in Le Potato - writing armbian to eMMC   
    Usually from Linux this can controlled via sysfs like this (needs to be executed as root):
    echo 0 > /sys/block/mmcblk0boot0/force_ro  
  17. chwe liked a post in a topic by zador.blood.stained in Bordsupport - general discussion / project aims   
    My opinion (regarding project aims):
    - View Armbian as a base, reasonably minimal OS images. Unfortunately this doesn't work well for targeting inexperienced users, or rather when such users are attracted to the project.
    - Explaining "minimal" and "reasonable" to people who don't listen is hard. People expect Kodi to work out of the box on any hardware, expect a perfect desktop performance even on OPi Zero 256MB and expect Mali drivers to magically fix all performance issues.
    - Trying to add things to the base image is bad for the project if it can't be fully supported, if it can prevent making project-wide advancements. IMO a lot of things added to the image are not really required but they increase the maintenance efforts. For example for me it would be easier to make a build repository fork and clean it up than try to resolve all possible conflicts with the recently added Realtek wireless drivers (in addition to important device-specific patches) when I decide to upgrade devices that I use to mainline kernel v4.15.
    - We still fail to explain what Armbian is. I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config. A lot of support requests are related to upstream packages, a lot of problems are related to kernel/userspace compatibility and people want optional stuff to work perfectly (if it's available in the menu it should work, why not?) while we still have base platform issues. 
    - Current web pages and the direction they are changing doesn't help explaining what Armbian is and what level of support can be expected for different images and kernels, unless adding random affiliate links to Amazon should somehow help with this in the long run.
     
    The problem here is that "interesting" is subjective. @tkaiser is mostly interested in NAS type boards with high performance and recent enough kernel for using btrfs. Adding ECC RAM to such board multiplies the "interestingness" of a board by 10.
    Some people are interested in a generic home NAS device and don't care if its max sequential speed is 40MB/s instead of 400MB/s 100MB/s as long as it is much cheaper.
    A lot of people are interested in desktop/multimedia use cases, and here ARM devices in general have a lot of problems unless you are running Android on a well supported device.
    Some people bought the cheapest device they could find and expect it to do everything - NAS, desktop, multimedia player, IoT/GPIO stuff, etc.
  18. chwe liked a post in a topic by zador.blood.stained in Bordsupport - general discussion / project aims   
    My opinion (regarding project aims):
    - View Armbian as a base, reasonably minimal OS images. Unfortunately this doesn't work well for targeting inexperienced users, or rather when such users are attracted to the project.
    - Explaining "minimal" and "reasonable" to people who don't listen is hard. People expect Kodi to work out of the box on any hardware, expect a perfect desktop performance even on OPi Zero 256MB and expect Mali drivers to magically fix all performance issues.
    - Trying to add things to the base image is bad for the project if it can't be fully supported, if it can prevent making project-wide advancements. IMO a lot of things added to the image are not really required but they increase the maintenance efforts. For example for me it would be easier to make a build repository fork and clean it up than try to resolve all possible conflicts with the recently added Realtek wireless drivers (in addition to important device-specific patches) when I decide to upgrade devices that I use to mainline kernel v4.15.
    - We still fail to explain what Armbian is. I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config. A lot of support requests are related to upstream packages, a lot of problems are related to kernel/userspace compatibility and people want optional stuff to work perfectly (if it's available in the menu it should work, why not?) while we still have base platform issues. 
    - Current web pages and the direction they are changing doesn't help explaining what Armbian is and what level of support can be expected for different images and kernels, unless adding random affiliate links to Amazon should somehow help with this in the long run.
     
    The problem here is that "interesting" is subjective. @tkaiser is mostly interested in NAS type boards with high performance and recent enough kernel for using btrfs. Adding ECC RAM to such board multiplies the "interestingness" of a board by 10.
    Some people are interested in a generic home NAS device and don't care if its max sequential speed is 40MB/s instead of 400MB/s 100MB/s as long as it is much cheaper.
    A lot of people are interested in desktop/multimedia use cases, and here ARM devices in general have a lot of problems unless you are running Android on a well supported device.
    Some people bought the cheapest device they could find and expect it to do everything - NAS, desktop, multimedia player, IoT/GPIO stuff, etc.
  19. chwe liked a post in a topic by zador.blood.stained in Bordsupport - general discussion / project aims   
    My opinion (regarding project aims):
    - View Armbian as a base, reasonably minimal OS images. Unfortunately this doesn't work well for targeting inexperienced users, or rather when such users are attracted to the project.
    - Explaining "minimal" and "reasonable" to people who don't listen is hard. People expect Kodi to work out of the box on any hardware, expect a perfect desktop performance even on OPi Zero 256MB and expect Mali drivers to magically fix all performance issues.
    - Trying to add things to the base image is bad for the project if it can't be fully supported, if it can prevent making project-wide advancements. IMO a lot of things added to the image are not really required but they increase the maintenance efforts. For example for me it would be easier to make a build repository fork and clean it up than try to resolve all possible conflicts with the recently added Realtek wireless drivers (in addition to important device-specific patches) when I decide to upgrade devices that I use to mainline kernel v4.15.
    - We still fail to explain what Armbian is. I see it as Ubuntu/Debian + bootloader with customizations + available kernel(s) with customizations + minimal OS (userspace) customizations and some optional tools/scripts like armbian-config. A lot of support requests are related to upstream packages, a lot of problems are related to kernel/userspace compatibility and people want optional stuff to work perfectly (if it's available in the menu it should work, why not?) while we still have base platform issues. 
    - Current web pages and the direction they are changing doesn't help explaining what Armbian is and what level of support can be expected for different images and kernels, unless adding random affiliate links to Amazon should somehow help with this in the long run.
     
    The problem here is that "interesting" is subjective. @tkaiser is mostly interested in NAS type boards with high performance and recent enough kernel for using btrfs. Adding ECC RAM to such board multiplies the "interestingness" of a board by 10.
    Some people are interested in a generic home NAS device and don't care if its max sequential speed is 40MB/s instead of 400MB/s 100MB/s as long as it is much cheaper.
    A lot of people are interested in desktop/multimedia use cases, and here ARM devices in general have a lot of problems unless you are running Android on a well supported device.
    Some people bought the cheapest device they could find and expect it to do everything - NAS, desktop, multimedia player, IoT/GPIO stuff, etc.
  20. Joe_PS liked a post in a topic by zador.blood.stained in [SOLVED] OrangePi Zero Plus: How to disable Wi-Fi (WLAN)?   
     
    The easiest way would be blacklisting 8189fs.
  21. tkaiser liked a post in a topic by zador.blood.stained in Hardware line is missing on /proc/cpuinfo   
    Or, as I suggested before, read /proc/device-tree/compatible (null-separated array) which contains both the board name and SoC name, so even if the library doesn't support a new board it can at least support SoC specific pin map.
  22. zador.blood.stained liked a post in a topic by tkaiser in Odroid HC1 SATA disk switches between sda and sdb   
     
    23% 'one star rating' at least for me is a very clear 'never ever buy such crap' indicator. 2nd 1 star review names the problem already:
     
    As very often with cheap PSUs you can not trust in what's printed on them. 5V/4A would mean 20W if you multiply both numbers. But crappy PSUs either provide 5V (no load) or 4A but not both at the same time (voltage drop under load). And the same phenomenon can be observed with cables between PSU and board if wires are too tiny. Incoming voltage at the board dropping due to cable/contact resistance too high. And this happens only with some load generated (Ohm's law).
     
    Can a moderator now please move this whole thread to the subforum where it belongs too? Thanks!
  23. zador.blood.stained liked a post in a topic by tkaiser in Orange Pi Zero NAS Expansion Board with SATA & mSATA   
    There's a new JMS578 beta firmware available ready for test (don't forget to backup your currently running firmware -- see above). This should fix the issue of cutting power hard to connected disks, for details (and firmware link) see here please: https://forum.odroid.com/viewtopic.php?f=97&t=29069
  24. zador.blood.stained liked a post in a topic by jernej in Banana Pi: Mainline kernel with hw video acceleration / decoding   
    I'm not sure if I completely understand the issue, but recently I came across this LE PR: https://github.com/LibreELEC/LibreELEC.tv/pull/2382
     
    Long story short, kernel from 4.9 onwards has latency issues on USB, which could cause visible artifacts when using DVB dongles. It is not clear what is correct solution, but in this thread some possible workarounds are proposed: https://www.spinics.net/lists/linux-usb/msg163892.html
     
    I think that most promising workaround can be found in LE PR mentioned at the beginning.
     
    Let me know if this is what you're after.