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
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.
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.
RussianNeuroMancer reacted to TonyMac32 in Banana Pi R2
Perhaps as an aid to our mutual understanding, would it be possible to link to a schematic and all released technical documents here, and provide an up to date image/layout of the board? I see a few things on the Banana Pi site that are... awkward. There are at least 2 revisions of the board on display with different port layouts, and the power jack next to the microUSB is labelled as "12 V" is that accurate? I don't know what that PMIC is off hand, so I'd be very unlikely to use that power jack unless you provided the adapter.
I think there is potential, however I am an automotive engineer, everything document I make must be defensible in a court of law, so I am very specific and I require a lot of verified documentation.
I am by no means looking for perfection, but it should be accurate enough that I can
Follow it without destroying the device Compile a generic linux without relying explicitly on your repo. Observe something near the advertised performance specs during empirical testing Identify all the right parts found in documentation. We need a thread where @Lion Wang @Nora Lee and @sean.wang are following and replying as is needed. We are not asking any questions that should be unexpected, most vendors provide schematics and most vendors have reasonably accurate datasheets. Our feedback should be very carefully considered, we are an educated user base, something development teams almost never have access to. We have people that use these single board computers in industrial and other applications, when they say "It would be really great if..." They know what they're talking about.
Now, I do not speak for the team, I only speak for myself and hopefully as a sane and intelligent individual: My recommendation on getting Armbian support for boards is to come here, reach out to the Armbian community, and provide accurate and complete documents, ask us questions, listen to our answers, etc.
Lion_Wang, the figure you posted shows WiFi + BT as OK, but you say it isn't complete. I see it's listed as AP6212 here, but on the R2 manual it says: " banana pi BPI-R2 have support MTK6625L wifi&BT 4.1 chip onboard. " <--- That is the sort of thing that causes trouble and upsets people.
The schematics are better than nothing, but they are scrubbed of IC names, values, etc, so really there is a limit to what value they are. I do at least see +12V being specified there, and consistently through, so OK. I was bracing myself for magic smoke everywhere...
RussianNeuroMancer reacted to Tido in Banana Pi R2
@JohnnyWednesday, having people like you in our community is great and appreciated.
Just don't try to convince us that SinoVoip is a great manufacturer - because the past and current proof different.
And please, when you find errors and patch fixed it, send pull requests to SinoVoip and report back when they were added. I say this because we have seen it for more than 2years, not months, not days.
RussianNeuroMancer reacted to JohnnyWednesday in Banana Pi R2
Hey Armbian aficionados - it's me of 'I can confirm that sound support isn't compiled into the kernel' fame. Please don't rush me all at once, I didn't ask for this fame and glory and I've already turned to hard drugs and fast women.
Since I've got this board and I'm not entirely incompetent (open to debate) - please let me know if there's anything I can do from my end to provide you with information for your assessment.
I'm guessing from the smattering of posts I've read that I won't be encountering many fans of the manufacturers - I agree that their software practices and documentation is poor - there's basically no info on the battery connector, efficiency of the step-up, max draw etc - the barrel jack was a different size from their technical drawings (that's £1 on an adapter I'll never get back - it sits on my desk... mocking me) - I'm sceptical in regards to the simultaneous power draw of the 2-pin and 4-pin SATA power headers using the specified 2A supply (I got a 3A for testing but I'm not ready to risk two drives just yet - definitely need to be careful in regards to lithium battery draw) and there's an unpopulated position for a cap next to the 4 pin supply on my board that's present on their pictures for the v1.1 revision of the board - I'm a little suspicious as to why it was left out in this production batch - perhaps it was determined to be superfluous but I've popped a question to support - they've been really helpful so far (just remember to throw your sentences back and forth between English and Mandarin on a translator to ensure that meaning remains intact - you get much more detailed responses when you remove the ambiguity of translation)
But all that said - it's a really great bit of kit very well made, general IO is nippy, the mPCIe is great for development (got a lovely little mPCIe FPGA board coming for my SDR project) SATA is working (tested a an old 2 inch spindle drive - need better kit to probe bottlenecks) sound is working perfectly (when compiled in), GPIO, WAN/LAN, USB3, OTG all seem to be functioning fine (wrote 30gb of data to a flash stick on the device from a CIFS mount - calculated hashes match) - so far it's not crashed on me once - SoC gets a bit hot under load - fine with a heat sink - don't think the thermal sensor is supported yet or perhaps that's not selected for compilation either (there's a lot of MediaTek stuff in this kernel that's not enabled but a lot of it is for other MTK chips - some of it is ambiguous in description so I'm not 100% sure yet)
Waiting on support for the internal WIFI/BT - hardware video decoding isn't working or not enabled (480p mp4 ran smooth as silk at 1:1 - the moment you scale, performance bombs) - obviously no GLES on the Mali450MP4 (userspace blobs for 3.x kernels - 4.x kernel for the board - that old chestnut) - not eeeeentirely sure if the X11 driver currently used is optimal (gallium on llvmpipe reported under Xorg - will dig into that a bit more now).
I'm sure the experts here are rubbing their temples at this stage - please don't geek attack me - I'll probably cry. It'll be really pathetic and my face will be a mess - nobody wants to see that.
Anyway - if I can run any tests and what-not then please let me know - I'm fine compiling/tweaking my own distro for my needs but I'd be a lot happier with a pro distro like Armbian - if you ever deem this board a viable target that is.
RussianNeuroMancer reacted to tkaiser in Banana Pi R2
Welcome here! Just looked through your commits and it's really great seeing MTK become commited to open source in the meantime and how far you already got!
MT7623 hardware features sound great (is there something like the 'MT7623N Datasheet for Development Board' available for MT7623A too?) and I'm really looking forward to devices based on MT7623N/MT7623A from reputable board makers hopefully soon.
Wrt Banana Pi R2 unfortunately it's challenging. You chose to cooperate with a partner here who has a horrible history: not releasing sources, not releasing schematics (timely), providing insufficient/incorrect information (no one right in his mind would call this abstruse copy&paste mess 'technical documentation'), advertising their products with wrong specs (numbers too high), not supporting their own products responsibly, not cooperating with open source community (even ignoring every try to help, see their reluctance to merge pull requests above who would fix tons of security issues on another device, or fix stability issues and so on) and most importantly their inability to even realize these problems (an unbelievable high level of ignorance, that's most probably their main problem).
This could all be problems of the past but as you can see clearly it's not. All of the above still applies, Sinovoip fails at unbelievable low levels and just recently they crossed a red line and censored in their forum posts they found to be 'useless' (eg. the only one analyzing R2's boot log and giving some hints). In the meantime they stepped a bit back and reverted their censorship partially but the whole situation is still a mess and just inacceptable. Almost all parts of open source community simple gave up on them and only a few people still try hard to help them (even if they're too ignorant to realize this).
You know better than anyone else that MTK has not the best reputation in open source circles based on the past (no sources available, NDA required and so on). And while I highly appreciate MTK opening themselves now and becoming part of the open source world all your efforts are at risk! Soon your first open source dedicated board will available. The board maker you cooperate here has obviously no clues what people want to do later with your device (otherwise they would test network and storage performance and so on and focus on reasonable use cases and not moronically try to use this board as a 'Desktop Linux' thingie). And all of the above listed problems unfortunately still apply in 2017, it's only needed to read through this thread: http://forum.banana-pi.org/t/banana-pi-bpi-r2-open-source-smart-router-with-mtk-7623n-design/2697 (at the time of this writing still 11 posts of mine censored/hidden).
Soon all of the above will also be associated with MTK and your open source efforts if you don't step in now. I already fear the first R2 reviews appearing in the wild (since software/support situation will be as horrible as it was all the times in the past with SinoVoip). Please try to escalate this problem with a manager, let representatives get in touch with responsible people at SinoVoip (is Foxconn/Nora Lee also involved?). I think it's really necessary that your partner wakes up and ensures that the problems outlined above get addressed. Otherwise I fear that your whole 'dev board' and open source engagement will fail with the first device since without situation improving R2 starting to sell will just be the same fiasco as with R1 back then (but this time all those people talking about 'If you want open source avoid MTK' will simply move into 'told you so!' mode and blame Mediatek instead of your hardware partner here suffering still so badly from the same problems they had already 2.5 years ago -- most notably ignorance)
RussianNeuroMancer reacted to Igor in [RockPro64] Armbian upstream kernel/uboot test?
More people means more pressure (more wasted time) to already small and scattered developers base. I estimate that ratio is already very toxic, at least 1000 end-users on 1 developer. Most of end-users have no clue how much work is needed and they are usually reporting stupid, repeated and irrelevant things. We, on the other hand, are wasting time with educating, communicating to and support people and people are frustrated that things doesn't just work. And we are frustrated since its hard and expensive to deal with this complexity and people are not grateful ... even just a few regulars are investing 20-50 hours per day into the project which is public and everyone benefits at the end. This time is covered way way below 1% which means all project costs are covered from our private budget. And users again expect a services worth millions of dollars.
RK3399 is new and more complex. Much more than 10 years old Raspberry Pi design. Each ARM SoC is like a new architecture. Most of the kernels out there are private branches (legacy builds), mainlining is slow, expensive and mainly our cost. Some vendors financially support this process, most don't. I am mainly involved into Allwinner scene and there we have produced 300+ patches (just a few are distro specifics) on top of already patched mainline source. And (mostly minor) problems still exists. For some SoCs, Armbian and related groups (linux-sunxi, http://linux-meson.com(backed also by Amlogic), ... are the one bringing those boards up. Development eventually landed in the mainline, but late and as you already figured out, some features will never be accepted due to low quality or they remained "in development". We do accept them and sometimes polish, fix, maintain further. Since most of this development is done by amateurs with little support infrastructure and little help from public, work from development branches need year(s) to find the way to the mainline. Delay differs from vendor to vendor.
Armbian mainline support goes this way - 1st stage, we attach or create own development branch and stay on that until difference with mainline becomes manageable. Then base source is switched to mainline and diff is added with patches. When things progress, patches are getting removed when they start to appear in the mainline. Ofc in reality this looks a lot more messy, but you get the idea. It's much more manageable.
RussianNeuroMancer got a reaction from lanefu in could we start a thread to evaluate the usability of opensource GPU driver lima
I tried to build Mesa with enabled lima and kmsro drivers, seems like this work mostly fine: https://launchpad.net/~russianneuromancer/+archive/ubuntu/drivers (for Ubuntu 19.04 only, due to Mesa 19.0 dependencies).
However, attempts to interact with lima via X11 always result in "libEGL warning: DRI2: failed to authenticate".
...and attempts to run glmark2-es2-wayland under Weston reveal that it running on llvmpipe.
Testing on NanoPC-M1 with current dev kernel:
~$ dmesg | grep lima [ 9.943493] lima 1c40000.gpu: bus rate = 200000000 [ 9.943506] lima 1c40000.gpu: mod rate = 384000000 [ 9.950490] lima 1c40000.gpu: gp - mali400 version major 1 minor 1 [ 9.950539] lima 1c40000.gpu: pp0 - mali400 version major 1 minor 1 [ 9.950581] lima 1c40000.gpu: pp1 - mali400 version major 1 minor 1 [ 9.950629] lima 1c40000.gpu: l2 cache 64K, 4-way, 64byte cache line, 64bit external bus [ 9.960591] [drm] Initialized lima 1.0.0 20170325 for 1c40000.gpu on minor 1 (full log)
I wonder if anyone was able to install Lima from Mesa upstream with current Armbian dev kernel and replicate at least this results?