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
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.