RussianNeuroMancer reacted to Igor in Improve autotests script
I will just add a bit more.
We want to rewrite / make this from scratch with Ansible. Basically we seek Ansible expert or someone who wants to become one. We have this know-how but we are simply too overloaded to move on. This is yet another job for common good! To make Armbian support better. To make Debian support better. To make Arch better, OpenWrt, ... To make every Linux distro out there running better on your board.
The person(s) should focus only on testing. Creating and maintaining scripts for automated testing and later, when our support hardware is out of beta testing, implement that as well. It's a continuous project and will not end tomorrow. Also you don't need to stay on it forever. Do what you can. Help us get going ...
We would like to automate:
- initial board setup (after you flash the image, automated 1st login, setup network, different local repository, ...)
- simple tasks such as upgrade, change to beta repository, downgrade to specific kernel, etc.
- run various of tasks which can be added without limits
- run various of benchmarks which can be added without limits
- run tasks in parallel
- make reporting in HTML, XML (common and per board)
Most of those ideas are covered in some basic form in our first try: https://github.com/armbian/autotests
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.
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.
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.
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:
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.
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.
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
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
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:
And now we need testers
While this is a PR for OpenWRT, I boot vanilla debian with it. In the end the distro shouldn't matter
* 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!
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!
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.
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.
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
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
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.
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).
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:
Eventually this patch was merged for the Renegade upstream:
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.
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/
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