Da Xue
-
Posts
100 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Da Xue
-
-
@Tido It needs microcode for the Cortex M chip to support suspend and then a lot of software work to get out of it. It will be quite a while before that kind of work gets mainlined if at all.
-
Made a write-up for people to reference. Will build some libraries to simply.
https://docs.google.com/presentation/d/1u4Z7c7he3sVfFC5laRgGkQSrsFML22xEOw6-r-VxeQM/edit?usp=sharing
-
On 2/21/2018 at 3:23 AM, sbc_chrisb said:
P15=1:100
-
5 hours ago, datsuns said:
I just got my lepotato up and running with Armbian and I have a noobish question. Does this board need a heatsink or fan or am I ok to run it without? Does the board automatically throttle performance if it starts getting too hot to allow itself to cool down?
The ARM Trusted Firmware will automatically throttle the cores if the chip gets too hot to prevent damage. However, it is recommended to have a heatsink for best performance.
-
4 hours ago, JMCC said:
Well, Hardkernel got custom BLOB's for the C2. I'm not sure whether you are related to Libre Computer, but if you are, I think it is worth giving a try. It also seems like Khadas is also considering to ask for binaries with unlocked DVFS. If both companies (Khadas and Libre Computer) join in the petition, I think there are big chances that Amlogic listens.
As I said before, if Amlogic people are intelligent (and I assume they are), they will care about the developers opinion, even though they are a much smaller number than the mass of TV box consumers.
Hardkernel got it because Amlogic put them between a rock and a hard spot since customers can claim false advertising. The only thing that has the slightest chance of happening is a bl30 that ignores thermal and other factors and stay at 1512MHz. Unlocked DVFS for overclockers is never going to happen so don't bother thinking about it.
-
My setup is a programmable DC power supply set to 5.1V with the heatsink and a fan on it. Ambient temperature is about 20C. I get around 6.25ish for sysbench.
-
@chwe Any company like Amlogic (Rockchip, Allwinner, Actions, etc) only care about issues that affect customers putting in orders on the order of millions of chips. If Le Potato sells in the hundred thousand to millions of units, they will naturally care about the issues we bring up. As of now, we are nowhere near there so this discussions in this thread are moot.
-
@TonyMac32 Make sure that the performance governor is on and that there is a heatsink.
-
All of the benchmarks on libre.computer were ran on the standard bl30 from Amlogic's openlinux site. The blob I have is for my testing only since using them and advertising the results is cheating.
-
2 minutes ago, tkaiser said:
The Khadas guys know that S912 is limited to 1200 MHz when more than 3 cores are busy but of course they prefer to hide this information since their target audience can't cope with. Which is understandable given SBC users focused on CPU clockspeeds instead of CPU performance are not the smartest people.
Didn't know that. S912 can only do 1.2GHz with 4 cores? That seems a little overboard in terms of false advertising. I would expect at least 1.5GHz for all four cores of the fast cluster at all times.
-
3 hours ago, JMCC said:
That's my point. But Amlogic advertises some false specs about his SoC, that may cheat an unexperienced user into thinking that they are comparable. On the other hand, RK3328 and S905's are indeed direct competitors, but in this case false advertising makes it seems like Amlogic's is way superior. That caused, for example, many of the early buyers of Odroid C2, who thought they had gotten a board with a SoC capable of 2.0Ghz, that surpassed all the competitors by far, get really disappointed when they knew they had been cheated and it actually topped way below those 2Ghz.
I'm not criticizing Amlogic for not making SoC's as powerful as RK3299. I'm critizicing them for lying about the specs, and then making closed source binaries that report false frequencies, in order to support that lie. If there was anyone from Amlogic reading this, I'd tell them that those things only harm them in the long run, and they are completely unnecessary. I think their SoC's are good for the mid-low range they are really aiming: CPU speed is not bad, thermal management is more than decent, power consumption is very low, GPU performs fairly well, and VPU video decoding capabilities are excellent. They can present their SoC's as they really are, and given the affordable price they are still very interesting options. I think publishing false specs harms everyone: vendors, users and developers.
To be honest if they drive the chip at higher voltages like 1.3V like the Allwinner H3, I think they can hit 2GHz. However, power consumption, heat, and reliability become concerns. I think they originally tested at 2GHz and made all the marketing materials but had to scale back to make power consumption and other factors look pretty. Amlogic is pretty ahead of the curve in low cost quad-core A53 SoCs. We just started getting competitor chips last year which means Amlogic is almost 2 years ahead of the curve with S905.
-
8 hours ago, JMCC said:
That makes perfect sense. But, looking at the numbers in the post I quote, single-threaded tests also show that results don't scale proportionally with claimed frequency. I would expect, at least, the CPU to be able to reach the announced max speed when only one core is used (as is the case with Intel Turbo Boost, that you mentioned).
I'm not so sure. Rockchip SoC's perform as expected. Now, if you compare two SoC's released about the same time, as S912 and RK3399, both claim to use big.LITTLE arch, to have Mali 8xx, and a maximum clock speed of 2 Ghz. Even the Amlogic can have more punch for a non-expert user, since it is octa vs. hexa core. But the fact is that simply the "little" cluster of RK3399 is faster than the "big" of S912, not to mention when the two A72 come into play, and so many other advantages that Rockchip offers both in the hardware as well as in software support. Of course, that means that RK3399 TV boxes are about 30% more expensive than S912. But then, Rockchip offers a low-cost SoC (RK3328), again announcing its real specs, not cheating. I only hope that Rockchip's strategy of offering honesty and quality pays them off with good sales, and so the example spreads.
I totally agree with that. I bought a Vim2, in spite of not liking much Amlogic, because I think Khadas is doing a great job with their products. The good points of Vim2 are countless, and make the board go far beyond a simple TV box.
S912 and RK3399 are not direct competitors. RK3399 cost twice as much as the S912 and has many more capabilities than the S912. Really apples and oranges. No one has really invested in the A7x series outside of the cell phone market other than Rockchip.
-
On 17.4.2018 at 1:25 PM, JMCC said:
Cool. The main reason why I was asking is because I know that Hardkernel got to do real overclocking on the C2 up to 1.75 Ghz, and I haven't heard of anything like that for LePotato or Vim. So maybe that overclocking would also be possible in those other boards with Hardkernel's kernel.
Hardkernel either has access to the trusted firmware source for S905 or they have a custom blob generated from Amlogic with license to distribute that blob. For S905X, I have tested custom blobs that unlock the CPU frequency but I don't have license to distribute. S905X seem to be able to clock up to 1.68GHz but since Amlogic only guarantees chip to work correctly at 1.512GHz, I wouldn't bother trying to overclock since it's only a 10% boost for a lot more power and instability.
-
@Jay Tolleson What resolution is the 7" LCD? Recently several DMT modes were added to the mainline kernel but it is not all inclusive. If you provide the resolution, we can probably provide you with the necessary timing bits to drive the display.
BayLibre is still working on the display code to support even more resolutions but it will not land for a few kernel versions.
-
@tkaiser Allwinner only certifies the H3 to operate at 1008MHz @1.2V and H5 to operate at 1008MHz @ 1.1V with DDR clocks up to 672MHz. Designs and software support for adjustable voltage and higher clock rates must be validated by the third party that chooses to implementing such features. DVFS will not be supported in the Allwinner H3/H5 BSPs since the transition to AXP8036. I have seen some small boards with 16-bit DDR3 (1 DDR chip) clocked at 744MHz but they are almost guaranteed to have memory errors and video playback issues.
-
-
On 3/14/2018 at 4:08 PM, richard1937 said:
Help, I RPi, TinkerPi, OrangePi and now Le Potato. ( So far, Tinker is best, RPi next and OrangePi flakey!)
I have installed Armbian Ubuntu - Works so far but have several issues:
1. WiFi, Panda not working but Netgear works great. Just plug it in and select SSID.
2. HDMI Screen: Using 1280x720. On 3 different types/mfg Monitor board menus are off the screen. I have tried xrandr, and the Armbian-Configurator etc. etc. NOTHING changes. The Armbian-C accepts the change, and you can save it:? so it seems but NO actual change even with a reboot. This, Overscan issue is easily fixed if some TV is used. Or when running RPi etc. etc. ie, the other boards work with these monitors. HELP, any ideas?
3. I prefer a larger mouse, easily fixed on RPi and TinkerPi but NOT on Le Potato/Armbian. Also, on Laptop it is easy to change the board, for example around the Terminal, or other window, so scaling is easy. BUT not on Armbian Ubuntu on LePotato! Any ideas appreciated.
1) Do you know the chipset on the Panda? It's probably just a line in the kernel config to support that device. lsusb -v
2) The armbian images are based on mainline kernel. Before it only supported CEA modes but some DMT modes were just added to 4.17 and getting backported to the 4.14 LTS branch on libretech-linux. This should show up in a few weeks.
-
clk_ddrmon 0 0 24000000 0 0 pclk_ddr 3 3 98304000 0 0 pclk_ddr_grf 1 1 98304000 0 0 pclk_ddrstdby 0 0 98304000 0 0 pclk_ddr_mon 1 1 98304000 0 0 pclk_ddr_msch 1 1 98304000 0 0 pclk_ddrupctl 0 0 98304000 0 0 pclk_ddrphy 1 1 75000000 0 0 sclk_ddrc 2 2 1056000000 0 0 aclk_ddrupctl 0 0 1056000000 0 0 clk_ddrupctl 1 1 1056000000 0 0 clk_ddrmsch 1 1 1056000000 0 0My testing is done on the Rockchip's Linux 4.4.114 kernel with DDR4 timing adjustments. I am not that familiar with tinymembench but why are our outputs different?
-
For comparison sake, I got this from my AML-S905X-CC 2GB: https://drive.google.com/file/d/129ug_8iuMMmLqP5yKfpL-lzMUWTjWz_P/view?usp=sharing
Someone uploaded the ROCK64 tinymembench here which I can't verify since I don't have a board: https://forum.pine64.org/showthread.php?tid=4687&pid=28879#pid28879
The Renegade DDR4-2133 performance is about 33% over the ROCK64's LPDDR3-1600 for memset which is to be expected.
-
tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 1760.1 MB/s (0.9%) C copy backwards (32 byte blocks) : 1620.9 MB/s (0.7%) C copy backwards (64 byte blocks) : 1581.7 MB/s (1.0%) C copy : 1639.6 MB/s (0.7%) C copy prefetched (32 bytes step) : 1280.2 MB/s C copy prefetched (64 bytes step) : 1580.7 MB/s (0.5%) C 2-pass copy : 1938.4 MB/s (0.4%) C 2-pass copy prefetched (32 bytes step) : 1429.9 MB/s (0.2%) C 2-pass copy prefetched (64 bytes step) : 1432.1 MB/s (0.3%) C fill : 7627.5 MB/s (0.4%) C fill (shuffle within 16 byte blocks) : 7629.8 MB/s (0.5%) C fill (shuffle within 32 byte blocks) : 7640.7 MB/s C fill (shuffle within 64 byte blocks) : 7635.3 MB/s (0.5%) --- standard memcpy : 1616.5 MB/s standard memset : 7604.0 MB/s (0.4%) --- NEON LDP/STP copy : 1903.9 MB/s (0.3%) NEON LDP/STP copy pldl2strm (32 bytes step) : 1479.1 MB/s (0.4%) NEON LDP/STP copy pldl2strm (64 bytes step) : 1615.2 MB/s (0.2%) NEON LDP/STP copy pldl1keep (32 bytes step) : 1981.1 MB/s NEON LDP/STP copy pldl1keep (64 bytes step) : 2014.8 MB/s (0.2%) NEON LD1/ST1 copy : 1862.7 MB/s (0.3%) NEON STP fill : 7603.9 MB/s NEON STNP fill : 2310.3 MB/s (0.4%) ARM LDP/STP copy : 1931.4 MB/s (0.2%) ARM STP fill : 7610.2 MB/s (0.8%) ARM STNP fill : 2339.1 MB/s (0.6%) ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.1 ns / 0.1 ns 65536 : 4.9 ns / 8.5 ns 131072 : 7.6 ns / 11.9 ns 262144 : 12.3 ns / 18.2 ns 524288 : 56.9 ns / 89.5 ns 1048576 : 84.7 ns / 119.7 ns 2097152 : 98.9 ns / 131.8 ns 4194304 : 110.7 ns / 141.9 ns 8388608 : 117.4 ns / 147.9 ns 16777216 : 122.4 ns / 152.3 ns 33554432 : 126.5 ns / 155.6 ns 67108864 : 139.5 ns / 179.4 ns@tkaiser From Ubuntu 16.04 image running Rockchip's 4.4 kernel.
-
6 minutes ago, Hauke said:
Hi Da Xue,
thanks for pointing this out. Indeed LibreELEC for LePotato is currently on 3.14.29, and I really look forward to when mainline kernel is ready - or at least ready enough to support LibeELEC. Mainly the video hardware acceleration is the key in my eyes, since for a media center that's the key part.
My biggest fear is, that Le Potato will share the fate of many SBC's and never reach maturity.
Libre Computer Project is one of my hobby projects/money pits. Le Potato is only the first of 3-5 products planned so rest assured it won't be an issue.
-
On 3/16/2018 at 11:47 AM, richard1937 said:
I know, and use SSH to go into a server for standard work. I use putty and have for years to go into www.itu-int.us. My server for this is Centos. It is an interface for a server in Geneva.
There is a bit of Chicken/Egg issue for me at the moment. I am on the road, at daughters beach place, for several weeks (fixing some things for her) so limited resources for MY project. No Ethernet access, LePotato doesn't have Wifi, Panda doesn't work. etc. etc. I wish I had brought along several other items, but I didn't .
About asking, some folks are too proud to ask anything, not me, I read/google etc. try "thoughts" that I see. MOST post about this seem to be over a year old - some progress must have been made - etc. So I ask.
If you want to help - I would appreciate that. If NOT you are of course welcome to ignore me.
I picked trying Armbian as it seemed to support and advocate - armbian-config . I am working with Armbian 5.8 Stable
This seemed like a great way to iniially setup etc. basic things.
Unfortunately - when you use it to edit HDMI resolution, Mouse size etc etc. nothing changes. Even if directly logged in as root!
Last night I found a small TV at Kmart for $88. that I could set to accommodate the overscan issue. The TV solves this for the moment but it otherwise really sucks!
I would be NICE to change the mouse icon size. ( I have don't this on RPi, OrangePi, TinkerPi etc. but those methods don't work here. - and Armbian doesn't change ti either, It seems size is set at boot, and Armbian-config does not change the file where it is set, and that is actually viewed to ultimately set the size. _ I think this many be true for the overscan issuse as well.?
Actually, More important - any ideas on getting Panda WiFi dongle working?
Then I can do update and upgrade etc. and then install other needed items.
Thanks, for any help.
Richard
Run `lsusb` so we know what chipset is in the Panda wifi device. It's probably a kernel module issue.
Mainline linux display mode code was just merged into 4.17. It will take a while for it to land in Armbian.
-
On 3/11/2018 at 8:16 AM, Hauke said:
OK, thanks for clarifying. So I'll go deeper and start debugging. Furtunately, I've got crash data output on the debug UART, this should make it possible to locate the code that actually causes the problem. Have never done this kind of debugging before, but since noone from the few LePotato-LibreELEC-developers currently is working on this bug, I think I need to learn myself :-)
Most of the code used by LibreELEC and others are based on Amlogic's SDK code which has numerous bugs on a really old kernel (3.14). There's efforts to move everything to mainline so that it includes fixes like this. Currently mainline is missing some critical features like video codecs support that is getting worked on.
-
32 minutes ago, TonyMac32 said:
It is ttyAML0 on these kernels, I had to check and make sure something didn't sneak through in the boot command line. So far I'm not sure where it's coming from, /dev/ttyS0..S3 are present, so systemd is trying to do its work. @Da Xue I don't have one of your images running, could you verify this isn't happening on it? I'll dig into my u-boot next, but I don't think that's where it's coming from.
What's the output of `cat /proc/cmdline`? @HAm
Amlogic still cheating with clockspeeds
in Amlogic meson
Posted
I would imagine (random shot in the dark) that there's some current limits to the wiring bonding and fully loading the SoC would exceed certain reliability parameters. @tkaiser I haven't played around with the 16.04 images in forever and sysbench on 18.04 is completely different. It was using the bl30.bin from the openlinux 2016-06 if I recall correctly. @TonyMac32 sysbench numbers seem to fluctuate a lot more than what I observed before. When I build the next 16.04 image, I will revisit this.