RussianNeuroMancer

  • Content Count

    64
  • Joined

  • Last visited

Reputation Activity

  1. Like
    RussianNeuroMancer reacted to piter75 in HDMI is broken on RK3399-based boards for high resolution display since Armbian 20.08   
    The tag was always there but at a different configuration level so no need to change it manually ;-)
     
    Nonetheless the ideas to explore for this issue (which I will unfortunately have no time for in foreseeable future) would be:
    Disable HDMI support for rk3399 boards in u-boot again - something like this PR (may need adjustments)
    It was already disabled once because of similar issues (which were supposed to be fixed with v2020.07) but I am leaning towards disabling it for all rk3399 boards again; Blacklist panfrost module, reboot and see if it helps - there was quite some development in panfrost between 5.4 and 5.8
    This however does not apply to issues found in legacy; Try both of the above at the same time if none helps on its own; If you can spare some time - try testing the above scenarios.
  2. Like
    RussianNeuroMancer got a reaction from usual user in USB C to display   
    Pull request mention HDMI specifically:https://github.com/armbian/build/pull/2302 
     
    Although I not sure about what DWC3 driver limitation he is talking about. (HDMI+hub combo working fine for me on ROCKPro64 with legacy kernel.)
  3. Like
    RussianNeuroMancer reacted to aprayoga in USB C to display   
    @0utc45t, try legacy image. if it still not working, make sure your cable has converter chip inside.
    There are at least 2 standards regarding display signal in USB Type-C. one is DisplayPort Alternate Mode, which is the one supported on Helios64 (RK3399) and the other one is HDMI Alt mode.
    If you have cable that use HDMI Alt mode, it won't work on Helios64.
     
    @RussianNeuroMancer,
    yes. on legacy, HDMI+Hub combo working fine. The problem with mainline driver, it does not support OTG. You have to define the port as "host" or "peripheral" in device tree.
    That PR comment, before i knew https://github.com/armbian/build/pull/2299
    HDMI+hub combo working fine in LK5.9 if you also enable rockchip-dwc3-0-host overlay.
  4. Like
    RussianNeuroMancer got a reaction from Werner in USB C to display   
    Pull request mention HDMI specifically:https://github.com/armbian/build/pull/2302 
     
    Although I not sure about what DWC3 driver limitation he is talking about. (HDMI+hub combo working fine for me on ROCKPro64 with legacy kernel.)
  5. Like
    RussianNeuroMancer reacted to Igor in 2.5G Ethernet crash (r8152)   
    We are updating several kernel drivers with their best option - which is also a reason why Armbian is better then some generic Linux. Yes, it is used:
    https://github.com/armbian/build/blob/master/lib/compilation-prepare.sh#L201-L213
     

    I already update our fork to 2.14 and if you build kernel from sources, it will be v2.14. In case you want to change anything in the driver, send a PR. Either to upstream or our fork - just note about the changes since its not heavily monitored. Usually we just point to original source. I forget why we use a fork in this case. Not that important after all.
  6. Like
    RussianNeuroMancer reacted to Igor in Information for users of TV boxes on the Amlogic platform   
    I the past few days I got several messages regarding this problem, even all corespondent knows that Armbian official policy only support images that are digitally signed. That is Armbian and its supported under those terms (make sure to read them before making more damages). Everything else you found floating on the internet you are using on your own risk. Why this topic? Since majority of R&D costs are covered from our private pockets (for official Armbian public share is between 0.2 and 0.4%),  most of your requests (for more of our private time/cash) can only ends in "f* off", "stop wasting our time", ... This is open source and "you", the one that need this and that function, full working and supported OS on every cheap garbage you purchase for a few bucks ... fork the code and maintain it! Armbian base maintenance (also source for TV boxes) currently costs us between 2.000 and 5.000 EUR per day and I have no idea how much people that fork this project adds that things also works (no idea how well) on TV boxes, that are similar to SBCs. If only 10% its already a lot! And what do they / we get back for that? Extreme constant demand and dissatisfaction since its absolutely not possible to fix all problems (for just 100 hours per day) and people doesn't (want to) understand that.
     
    We - Armbian - doesn't want to do anything with our forks - focusing to single board computers represent an insane big project, which we have already have big troubles to keep up. This policy is present since ever and for several months we are trying at least to do something about. Many people were investing their precious time into the project "What to do with TV boxes" to make this clear, to find best relationship and perhaps also support important Armbian forks in some way. Project is again 99.9% covered from our private pockets.
     
    If @balbes150 decided to stop supporting free of charge for you, for whatever reason, we have nothing to complain and I am sure we all fully support his decision but perhaps his Google translated words might scared you off. If he stop maintaining things, he is no longer responsible that boards breaks down. HW defects because of leaving off maintenance are extremely rare, but possible - I think he wanted to emphasize that. One doesn't need to add any evil code, hardware starts to break down when support is canceled, slowly but surely ... Besides, he is not to blame. Open source projects are done together - if you don't help him (and apparently you don't, with rare exceptions) and at least inspect and correct his work, why complaining and worrying about bad/evil code? Join development process and stop being cheap consumer who is complaining over the product he got for free.

    Make sure to check his (and also our) code and also perhaps understand that he might need a full-time assistant(s) to roll things out at the present level. If not, why the fuck anyone complains? There is a fork button.
     
    How to help improving things? https://www.armbian.com/get-involved/ The same way for TV Box Armbian fork.
  7. Like
    RussianNeuroMancer got a reaction from NicoD in Build Armbian with Panfrost   
    I build today snapshot from oibaf for armhf too, but only for eoan: ppa:russianneuromancer/drivers
    https://launchpad.net/~russianneuromancer/+archive/ubuntu/drivers/+packages?field.name_filter=&field.status_filter=published&field.series_filter=eoan
     
  8. Like
    RussianNeuroMancer got a reaction from Igor in TigerVNC problems   
    This issue is fixed since version 1.10.1+dfsg-4 and Ubuntu 20.10 already ship newer package (1.10.1+dfsg-7).
    You can use TigerVNC 1.10.1+dfsg-7 on Ubuntu 20.04 as well, but this will require manual downloading of tigervnc packages here: https://launchpad.net/ubuntu/+source/tigervnc
     
    Relevant bugreports:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932499
    https://github.com/TigerVNC/tigervnc/issues/1023
  9. Like
    RussianNeuroMancer reacted to dhewg in EspressoBin mainline u-boot/atf   
    New patches for mainline u-boot have been posted, so that espressobin should finally work now.
    That gives us a recent version of u-boot, compared to that old and unmaintained marvell fork.
     
    I opened a PR for OpenWRT to ship mainline u-boot/atf builds. Those also include distro boot:
    openwrt/openwrt#3360
     
    And now we need testers
    openwrt/openwrt#3360 (comment)
     
    While this is a PR for OpenWRT, I boot vanilla debian with it. In the end the distro shouldn't matter
     
    Note:
    * All builds are currently CPU_800_DDR_800 only for stability reasons
    * There is no build for v5 with 2GiB RAM, does anyone have such a board? builds added in the posted v2 binaries
    * The v5 1GiB build is 2CS, does anyone have 1GiB 1CS? builds added in the posted v2 binaries
     
    And feedback is appreciated!
  10. Like
    RussianNeuroMancer reacted to Pedro Lamas in NanoPi M4V2 armbian-config is missing "hardware" entry   
    FYI, I found that this was due to a missing entry in debian-config-functions so I submitted a PR to add it (here) and this has now been merged so it should be available on the next update of armbian-config!
  11. Like
    RussianNeuroMancer reacted to balbes150 in Single Armbian image for RK + AML + AW (aarch64 ARMv8)   
    The new version 20.05.5 (20200522).
    All images are build entirely on the ARM platform (rk3399 + NVMe). After fixing bugs, the process of building the first image (including downloading sources, building all packages, building the kernel, u-boot, and so on) took less than 50 minutes. 
  12. Like
    RussianNeuroMancer reacted to Oleksii in NanoPC T4   
    If you are still interested in Type-C for mainline kernels. My patches at least explain what is missing in the present drivers and why this magic dr_mode = "host" is specified everywhere in the mainline dtbs
  13. Like
    RussianNeuroMancer got a reaction from Oleksii in M4 Died   
    A bit of offtopic, but if anyone is interested Hardkernel is more open about RMA.
  14. Like
    RussianNeuroMancer got a reaction from Oleksii in M4 Died   
    One of my NanoPC T4 also died a four months ago for no apparent reason, some symptoms was similar to description from Oleksii post. Initially it always printed long stack trace to serial console during rockchip_drm initialization, and then reboot on emmc initialization attempt. Later it stopped booting from emmc as if it's empty, but attempts to boot from microsd always lead to same outcome - boot loop. And finally it stopped even trying to boot from microsd with only red light.
     
    FriendlyARM send replacement for this board, but making them doing so certainly wasn't easy - when all troubleshooting steps doesn't help, they decided to stop answering until I tried to place a new order via sales e-mail and asked them to put replacement board into this order.
  15. Like
    RussianNeuroMancer reacted to guidol in Armbian v20.05 (Kagu) Planning Thread   
    @Igor @RussianNeuroMancer for the chronyd-bug with ubunutu focal you could take a look here
    https://bugs.launchpad.net/ubuntu/+source/chrony/+bug/1878005
    where they found a problem/solution:
    * Chrony can't start on platorms that map gettimeofday to clock_gettime64() * This is due to syscall filtering being correct on some but generic enough to cover all areas. as a temporary solution they wrote:
     
    So we will need to whitelist the clock_gettime64() system call in chronyd’s seccomp filter. I’ll send a patch upstream. Meanwhile, you can disable the seccomp filter by running (as root): # sed -i '/DAEMON_OPTS=/s/"-F -1"/"-F 0"/' /etc/default/chrony # systemctl restart chrony.service BTW: My NanoPi A64 with  armbian focal  kernel 5.6.12 is running
    chronyd v3.5-6ubuntu6 normally:

    System diagnosis information has been uploaded to http://ix.io/2mbU 
  16. Like
    RussianNeuroMancer reacted to Igor in Odroid C4   
    I don't need this board working now 100% and it is also impossible to do that in a short time. Even if we put all our resources into it. It is also expensive and slow to bring this support from where it is now, to perfectly working. Since we pay for everything and you for nothing, we proceed with our speed. Until then we will only rely on upstream fixes (like everyone else), which will ofc takes months to emerge: keep updating and once it will just start working ...
     
    I have zero time to deal with this, nor is anyone dealing with this board to iron out those problems ... if you can't debug and fix some problem, forget it and use stock images which I assume might be better, but also not without bugs at this early stage. Usually it takes months to year that a board is production stable.
     
    Temporally closing this thread since this board does not have end user support. If you are not a developer, you can only help this way: https://www.armbian.com/donate or doing something else that is in the project interest.
     
    We haven't decide if we will pay the costs for dealing with you for this board which is on average around 20.000 EUR / year. You expect some real help or someone who has no clue about?
     
    Edit: I also manage to kill the only board.
  17. Like
    RussianNeuroMancer reacted to Igor in Updated images for Odroid C4   
    Fixed issues with networking.
  18. Like
    RussianNeuroMancer reacted to Oleksii in NanoPC T4   
    It is not so obvious  I only consider the state in the mainline kernel as a reference (because I decided for myself to track changes since 5.* only). And I see that USB Type-C controller changes its state from "host" to "gadget" and almost immediately powers off during the boot. It should be correctly handled automatically by the driver on this board according to my understanding. And forcing to host mode is imho just a workaround for some issue in the current driver (or some other problems in device tree).
  19. Like
    RussianNeuroMancer got a reaction from balbes150 in RockPi4B - No audio from 3.5mm Jack   
    I guess he found it here: https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/codecs/es8316/EnableSeq.conf#L16
  20. Like
    RussianNeuroMancer reacted to jpegxguy in NanoPC T4   
    It was mentioned to me by email that the ethernet TX issue I describe here
    plagues this board as well (my board is the LibreComputer Renegade).
     
    It seems like the exact parameters might depend on each specific device, in which case the "best" solution would be some kind of "autoconfiguration" for the PBL, but that is in a future TODO. More about the issue andthe discussion here:
    https://patchwork.kernel.org/patch/10880481/
     
    Eventually this patch was merged for the Renegade upstream:
    https://patchwork.kernel.org/patch/11017833/
  21. Like
    RussianNeuroMancer reacted to balbes150 in Recommendation for new board   
    The performance of RK3399 is very good and if you do not play Windows games, it is able to replace the average home PC with Linux. Even without the addition of HW support for full-screen video, (in SW mode) the rk3399 works seamlessly with the 1080 desktop in all modes and without brakes. Conclusion about the unsuitability rk3399 Linux - sheer stupidity or intentional deception. But it is important to understand that to get all the performance of this powerful processor, it and the whole system needs a good cooling system and a good medium (the device from which the system starts). Only in this case rk3399 will be able to show all his abilities. For example , you can take a shitty SD card and then yell that the system is slow compared to the Android system that is run from eMMC. Or use a bad cooling system. The main disadvantage rk3399 , it is a  heat at work, but with the release of rk3588 is significantly change.
  22. Like
    RussianNeuroMancer reacted to Igor in Summer update. Bust.er4all boards   
    v5.90 / 7.7.2019
    All images were updated. It mainly goes for a bugfix update, cleanup, adding Debian Buster release. Beware that software maturity with Buster is not just there yet (even it was declared stable) and with some applications (like OMV) you will encounter problems. Kernel/BSP wise, Debian Buster is the same, uses Armbian kernel, as our other builds. Most of the builds were briefly tested, but bugs might be hiding somewhere. This is the best what is out there thanks to greater Debian community, those around boards and of course ours which pushes generic Debian/Linux to the sky . Enjoy the summer time.
     
    What's new? -> https://docs.armbian.com/Release_Changelog/
  23. Like
    RussianNeuroMancer reacted to Igor in Updated images for FriendlyARM T4/M4/Neo4   
    - enabled Bluetooth
    - align with latest upstream sources
    - tested on M4 and T4 http://ix.io/1MYD
    - updated repository
    - clocked back to normal CPU speed 1.5/1.8Ghz to minimise thermal throttling
    - added wireless drivers for 88x2bu
    - updated wireless drivers for Realtek 8811, 8812, 8814 and 8821
    - updated wireless drivers for rtl8188eus & rtl8188eu & rtl8188etv
    - added latest Wireguard driver 
     
    Download
  24. Like
    RussianNeuroMancer reacted to Igor in Banana Pi R2   
    Schematic for this board is not needed since it's most likely not that much different than the previous model. But if there is a completely new design on the table, there is much harder up to practically impossible to go on without proper documentation and board designers help.
     
     
    There are many topics and the longest issue on Github about R1. There is really no need to repeating things over and over again. It's getting boring and contra-productive. We saved lot's of troubles to people that use single board computers, but we just can't save them all. 
     

    Let's stay away from those.
  25. Like
    RussianNeuroMancer reacted to RagnerBG in Banana Pi R2   
    Hello. I just want to say - all this blah, blah, but you missing the point. People are not rude against you just like that, but because of your company actions. This is reputation you've earned. False advertising, incorrect information, hardware issues, this is the problem. TK is maybe sort of sarcastic, but it is for a reason. Most of his comments are not "full of malice and disgust", but full off useful information, for you and your potential customers. It's only better for you if you not ignore them, but take a notes. 17 years software and hardware development and you don't know, it's not all about open source (at lest for your company), but to provide support. If you care about open source support, provide the sources opened and proper documentation, so people can do development for you. But if the hardware vendor don't want to do this, there is nothing wrong in closed source, if it's workable and with proper license. But nor you, nor your vendors do any of this, it's just NO support at all. Let's see MTK now, but with your other partner AllWinner, we see a lot of circus with free interpretation of what "open source" and "GPL" means, reflection mostly on end customer. Things like these are the reason, people with experience with your company, been not so nice. Not your English language (mine is not good too). I personally have experience too. I own one of your products and use it for good, but only at 50% of what was advertised back then and with a lot of hardware and software interventions from my side to make it at least stable at these 50% of usability. How could i be very gentle and buy another product from you? And i could be potential buyer of this new R2, if only things were different this time. But from what we see so far, even in this thread, it's the same - hardware and software, a huge deja-vu. Poor new owners, they don't get it yet, but we do and with this exposure, in this very thread, you don's make things different. You had one good product - the first BPI-1, what's gone wrong since then?
     
    I will keep following this topic. It's really fun . And with latest efforts to use this forum for the same false advertising and reclame, make it even more interesting. Only need popcorn.