tkaiser
-
Posts
5462 -
Joined
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by tkaiser
-
-
13 minutes ago, guidol said:
A40i (fully compatible to R40/V40)
Bullshit.
These chips are not "fully" compatible but according to the 'sinovoip bpi team' muppet provide 'PIN to PIN compatibility'. What does this mean? That a careless board maker can replace the reels in a pick-and-place machine and produces something which mechanically fits but where previous software does not work any more.
Allwinner H2+/H3 and H5 are pin compatible. Ever looked at how different software support situation looks like?!
It's all about software support. Pin compatibility is 100% irrelevant if you look at boards from the user's perspective (and not from board maker's perspective who brags about his ability to replace one SoC with another to re-use their PCBs).
Also you should keep in mind where the real work happens. That's linux-sunxi community or to be more precise wens and @Icenowy when it's about R40 and derivates (nobody else is working on these SoCs).
-
1 hour ago, Igor said:
Perhaps we could use this for our NEXT/4.14.y branch? It shouldn't be worse
Well, I believe FriendlyELEC did as much as possible to support their own H3 and H5 boards (partially doing things incompatible to upstream kernel/u-boot -- see their way to define DRAM clockspeeds and automagically detect the boards based on specific pin settings) but I doubt they ever took care about other platforms than H3/H5.
So no idea how much efforts it would take for this stuff to work since some of their stuff relies on using their (patched) u-boot anyway (of course me not being that interested in Allwinner hardware any more -- my only hope is that Armbian follows a conservative upgrade policiy and bricked boards after kernel or u-boot updates will never happen again)
-
53 minutes ago, Igor said:
which was the original firmware? Was it kernel 3.10.y?
They abandoned 3.10 pretty early and there was never support for the Core2 based on Allwinner's BSP. They started with 4.11 and are now at 4.14 (based on @megous branches): https://github.com/friendlyarm/linux/commits/sunxi-4.14.y
-
8 hours ago, guidol said:
I think we should have both type of people and they all should have fun with their systems
The lack of project goals and the way work is done (not coordinated, no communication) is not fun but only causes frustration.
-
36 minutes ago, Simonmicro said:
So do you have any further idea how to solve this problem?
Other than replacing the crappy fansink with a good heatsink... no.
Information would be needed (armbianmonitor -m) to get an idea why the fan starts to spin up (thermal trip points --> kernel/settings) and how temperatures look like. But to be honest: I bought my XU4 early 2017 and sold it 9 months later since the XU4 is so disappointing and I won't further waste any time dealing with the various issues.
My personal opinion: ODROID MC1, HC1 and HC2 are nice boards, XU4Q at least solves the problem of annoying fan noise (though I think the large heatsink would be better with more space between the fins to allow for more convection)
-
3 hours ago, guidol said:
in the past (older kernel) we had /sys/class/thermal/thermal_zone0/temp with about 45C
This is SoC temperature. There's no THS driver in mainline kernel for R40/V40 and if wens or Icenowy stop working on these boring SoCs there never will be one.
You're dealing with the AXP221s PMIC which has an own thermal sensor and exposes a bunch of data via I2C. You try for whatever reasons to use some raw values as something that pleases you. I've not the slightest idea why people are so obsessed by numbers without meaning all the time (same with benchmarks)
The correct way to deal with boards that use these SoCs is to avoid buying them. But since Igor sends out the signal they will be supported in the future people will never learn this lesson, buy this hardware and either deal with a crappy 3.10 EOL kernel or wait another few years until mainline kernel will be ready for these boring SoCs. What a waste of time and resources...
-
45 minutes ago, danglin said:
However, there is some issue with the sdhci@d0000 interface
Can confirm. I tried the '1000' and '1200' settings and when I ran off the SD card I always encountered ext4 errors after some time. Now the rootfs is on an USB3 pendrive.
800 and 1000 settings perform absolutely identical. The only difference is bogus cpufreqs reported with the 1000 settings. Compared to last year we have a 20% performance drop due to not being able to exceed 800 MHz clockspeed any more
-
1 hour ago, Style said:
This is the link you provided (you missed the last character). Please post the link again and this time without copy&paste errors. Without any information it's impossible to tell anything.
-
OMV can only be installed on Debian and you obviously use Ubuntu.
-
3 hours ago, tkaiser said:
So with 600 settings it's really 600 MHz (~596) and the 1000 settings use a divider that seems to be somewhat off (1000 MHz being 795 in reality).
And with '1200 MHz' ('flash-image-1g-2cs-1200_750_boot_sd_and_usb.bin') it gets even worse and performance drops even more
Checking cpufreq OPP: Cpufreq OPP: 1200 Measured: 742.904/742.370/742.454 Cpufreq OPP: 600 Measured: 367.340/367.847/367.739 Cpufreq OPP: 300 Measured: 178.783/180.299/180.009 Cpufreq OPP: 200 Measured: 117.394/117.781/117.879Full results confirming lower CPU and memory performance: http://ix.io/1l0T
There's seriously something really wrong in u-boot.
-
18 hours ago, guidol said:
I also will get the (real?) temperature in armbianmonitor -m
What's the ambient temperature of the place the board is in? If that's more than 20"C you obviously just managed to display an irrelevant number but nothing related to 'real' temperatures. 'iio:device0/in_temp_raw' already indicates that's just a raw value needing some calibration.
And you're querying the PMIC and not the SoC BTW... and all of this is just an insane waste of time given what boring and dead SoCs R40 and V40 are (only used on Bananas, not picked up by a single other SBC vendor)
-
11 hours ago, danglin said:
Here are the sbc-bench results for 600 and 1000 MHz, respectively:
This gives an aes-256-cbc score of 274785 at 8k.
11 hours ago, danglin said:And this is 368675. Those OpenSSL numbers are great since they do not depend on anything else other than existence of ARMv8 Crypto Extensions so we can draw conclusions from benchmark result to Cortex-A53 clockspeed. Comparison chart: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829
An Allwinner H5 clocked at 816 MHz scored 380482 back then so the 368675 we get is a clear indication of slightly below 800MHz. Same with the 274785 number --> slightly below 600 MHz. So with 600 settings it's really 600 MHz (~596) and the 1000 settings use a divider that seems to be somewhat off (1000 MHz being 795 in reality).
Interestingly in the above result collection there are EspressoBin numbers that indicate that some time ago we were running at close to 1000 MHz (462012). Numbers were generated exactly one year ago with no kernel cpufreq support back then: https://forum.armbian.com/topic/4089-espressobin-support-development-efforts/?do=findComment&comment=37981
-
17 minutes ago, Sergius Triticum Aestivum said:
Why not?
I was talking about letting the SoC do the job and not a PCIe card. The RK3399 equipped Orange Pi has HDMI input, most probably for a reason (yet unknown to me -- communication with Xunlong has always been a mess)
-
3 minutes ago, Sergius Triticum Aestivum said:
in fact I want to connect a card for video capture.
No idea. But this is clearly something I would try to avoid since all those ARM SoCs are equipped with a VPU able to do HW accelerated video decoding but also encoding. Unfortuantely this requires Android but not Linux (almost) everywhere to my knowledge.
-
1 hour ago, midix said:
I'm in Europe
So either buy directly from FriendlyELEC (asking for a quote via email if you're not happy with standard shipping costs) or check whether there's an ALLNET reseller near to you (ALLNET is FriendlyELEC's European distributor and at least here in Germany a lot of their products are available through normal retail channels. Of course twice as expensive compared to FE webshop prices)
-
1 hour ago, Sergius Triticum Aestivum said:
External graphics card connected to m.2 via the adapter for example
IIRC RK3399 suffers from not large enough PCI BAR for frame buffer access similar to this problem: https://bugs.freedesktop.org/show_bug.cgi?id=102497
So other PCIe cards using a smaller window work but not GPUs. SATA, network und USB adapters are known to work (Pine folks are currently testing a lot of stuff for RockPro64)
-
18 hours ago, danglin said:
I have to wonder if cpu frequency scaling is working correctly
Reported cpufreq clockspeeds by driver and reality is also something different. And I've to admit that I've not the slightest idea whether DVFS is implemented on this board or not (if not then it simply makes no difference whether the SoC idles at 100 MHz or 800 MHz -- incorrectly reported as 1000 MHz). It would be really great if you could run sbc-bench with both settings on your board and report back.
-
The company behind the Geekbox (my only SBC I still never booted
) in the meantime more known for their Amlogic Vim/Vim2 boards also joins the RK3399 bandwagon with a concept similar to Geekbox. A core module to be combined with a carrier board:
Since it's just another RK3399 design Armbian support later is likely. More info:
- https://www.cnx-software.com/2018/07/24/khadas-edge-rk3399-single-board-computer-system-on-module/
- https://docs.khadas.com/edge/
- https://forum.khadas.com/t/indiegogo-campaign-edge-developer-samples/2789
Khadas guys seem to hate the idea of appropriate heat dissipation so most probably this will be the slowest RK3399 device around (where's the huge heatsink that's needed to prevent throttling?)
-
8 hours ago, midix said:
Only Orange Pi offers small form factor
Nope. FriendlyELEC kinda defined a slightly larger form factor. Currently available with H5 and soon with RK3399:
Wrt audio processing have you read @Da Alchemist's posts?
-
5 hours ago, thomasgrzybowski said:
BUT, from what I read, only the Dual-Core Cortex-A72 is available to use from existing builds
Very weird statement especially directly below @hjc's post where he shows how performant all 6 cores are with adjusted cpufreq clockspeeds. All RK3399 devices have 6 cores and all of them are usable of course. It's just a matter how fast they and the memory is clocked: https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
-
On 8/20/2018 at 5:37 PM, Homoran said:
Is this what you wanted to have???
Yep. What happens if you call 'sudo depmod'? If it succeeds then another time 'sudo modprobe cifs' would be interesting.
On Rock64 the cifs module should be built as module and therefore modprobe should work. Unfortunately our settings are not consistent accross kernels:
macbookpro-tk:kernel tk$ egrep "CONFIG_CIFS |CONFIG_CIFS=" * | grep -v 'CONFIG_CIFS=m' linux-mvebu-dev.config:CONFIG_CIFS=y linux-mvebu-next.config:CONFIG_CIFS=y linux-mvebu64-dev.config:# CONFIG_CIFS is not set linux-mvebu64-next.config:# CONFIG_CIFS is not set linux-odroidc1-next.config:# CONFIG_CIFS is not set linux-qcomlt-default.config:# CONFIG_CIFS is not set linux-rockchip-dev.config:CONFIG_CIFS=y linux-rockchip-next.config:CONFIG_CIFS=y linux-s5p6818-default.config:# CONFIG_CIFS is not set linux-sun4i-default.config:CONFIG_CIFS=y linux-sun5i-default.config:CONFIG_CIFS=y linux-sun7i-default.config:CONFIG_CIFS=y linux-sun8i-default.config:CONFIG_CIFS=y linux-udoo-default.config:# CONFIG_CIFS is not set -
3 hours ago, frottier said:
Ok, so it's confirmed:On 7/13/2018 at 10:37 AM, tkaiser said:all 4 USB3 ports behind the internal VL817 hub sharing bandwidth (then OTG is routed to USB-C but only as Hi-Speed?)
Powering also possible through pins 2 and 4 so since the SoC is at the right side and heat dissipation is no problem @mindee could evaluate a 'SATA HAT' using the 2 PCIe lanes, a Marvell 88SE9235 SATA controller (x2 PCIe to host, 4 x SATA 3.0 to disks) and power circuitry with 12V input able to feed board and 4 x 3.5" disks.
If I understood correctly RK3399's VPU capabilities make it interesting as transcoding NAS (once video support is ready in Linux, though no idea how far things are. @JMCC do you know about the state of video transcoding with RK3399?)
-
10 hours ago, DrSchottky said:
Is there anyone here who has already worked on it and/or has info/symbols/pseudocode/whatever might speed up the reversing process?
This here is most probably the wrong location to ask for. Armbian is about adding stuff at the distro level and keeping track of kernel changes. We seldomly touch bootloader stuff.
If not already done I would better ask in linux-sunxi IRC (remain patient, people are from all timezones and all the regulars read the backlog so it's quite common to get individual answers hours or days later)
-
On 7/15/2018 at 8:25 PM, Vin said:
Regarding the automated nightly or user built, i took that picture off a freshly installed image, havent switched the kernel, or the built to nightly
C'mon. You're using a nightly built! These are unsupported for a reason. Period.
You show a screenshot with u-boot 2018.07 so requirement is an image built after June 2018 while all our stable images are from January or earlier: https://dl.armbian.com/pine64/archive/
Start over from scratch this time reading, understanding and following our documentation: https://docs.armbian.com/User-Guide_Getting-Started/
8 hours ago, carver said:a similar problem on orange pi win plus
Nope. Igor mentioned problems that affected a few batches of Pine64 that are related to the Gigabit Ethernet PHY on the board and require to set some undocumented bits adjusting registers in the PHY. How should another A64 board be affected by that?
Banana Pi M2U - A40 - ethernet interface problem
in Beginners
Posted
Where do you find 'info' over there? There are two pictures of the same board showing two different SoCs. And two links to a wiki that is flooded with BS since they still allow their copy&paste monkey to harm their reputation. Quick look at http://wiki.banana-pi.org/Banana_Pi_BPI-M2_Berry: 'he BPI-M2 Ultra has 4 USB A 2.0 ports' (BS!), picture shows R40 (BS!), 'cortex -A7,the most power efficient CPU core ARM's ever development' (BS!), 'dual-core MALI-400 MP2 and runs at 500MHz' (BS! It's 360), '1GB DDR3 with 733MHz' (BS! It's 576 MHz maximum and BSP code even throttles DRAM clockspeeds when overheating) and so on...
ZERO information AT ALL as usual. Only BS generated by one or more copy&paste monkey(s).
If they would provide information they would show at least a boot log. In case you are member of this forum over there you could ask for. My posts have been censored there way too often to ever write anything there again.