• Content count

  • Joined

  • Last visited

About tkaiser

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

10710 profile views
  1. S905/912 faulty clockspeed, arm trusted firmware

    Please do so. Getting tired of reading too much and repeating the same BS over and over again. Look how cheating works. You do not need to write numbers on your web page, you simply ship an Android that reports bogus values so people reyling on shitty tools (again Geekbench, CPU-Z, AnTuTu) get fake numbers and these are then used in reviews, advertisements and so on... mid 2016 situation: Amlogic 'talks' about 2 GHz: (of course back then the SoC was also only allowed to clock up to 1.4 GHz with single threaded loads) end of 2016 situation: Amlogic adjusts the faked top cpufreq number from 2.0 GHz to 1.5 GHz:✓ (it's still 1.4 GHz in reality and with multi-threaded loads it's even less) 2018 situation: BS numbers finally confirmed: (but I have no idea what those Vim2 users are doing? All brainwashed? It's so easy to check for real performance. Why is no one doing this but is instead blindly trusting in irrelevant BS numbers?)
  2. S905/912 faulty clockspeed, arm trusted firmware

    In case anyone with access to the hardware (be it a Vim2 or any other S912 device) wants to help with checking the issue:
  3. S905/912 faulty clockspeed, arm trusted firmware

    Expertise? Knowledge? You were talking about Rockchip now but what should've changed? Still their target audience are absolutely clueless people who buy numbers. Rockchips' customers (TV box makers) have to advertise their boxes with BS numbers (1.5 GHz and stuff like that), those tools used for reviews (CPU-Z, Geekbench and so on) have to report these BS numbers too and how high the CPU cores clock in reality is something entirely different (and irrelevant anyway! Why does no one get this? These boxes all have crappy thermal design so why does anyone expect el cheapo SoCs performing great in shitty plastic boxes?) Anyway: if you want to change something wrt Amlogic here (for whatever reason) you need to make some noise. The thread title here is absolutely useless (I proposed 'Amlogic cheating' for a reason) and it's rather useless to further discuss this stuff here. Hardkernel got some pressure by the 'MHz fanatics' who are too stupid to differentiate between performance and clockspeeds. If you want the same happen now with S912 you need to go to Khadas and annoy them about their flagship product Vim2 only running at 1.2 GHz when multi-threaded performance is needed.
  4. S905/912 faulty clockspeed, arm trusted firmware

    Only some 'MHz fanatics' were really concerned. Or to be more precise: people who do not understand the difference between performance and clockspeeds and who also do not understand the challenges to run chips at high clockspeeds (both consumption and heat increase a lot). Again: (there you can also read what happened then in detail to get more control over clockspeeds on C2) If I'm concerned about performance I need a use case first and then I test for performance with this use case (and don't rely on theoretical clockspeeds since this is plain stupid). That's what both Willy Tarreau and @willmore did unlike those people who for whatever reasons bought an ODROID-C2 instead of an RPi 3 due to '2 GHz' vs. '1.2 GHz' (those people exist en masse). So it was pretty obvious once that happened that an A53 'clocked at 2 GHz' performing like one clocked at 1.5 GHz is just that: limited to 1.5 GHz. So what? This is on those devices always the result of consumption and thermal constraints so why bother? Since I mentioned 'use case' and Raspberry Pi 3: If you need the performance for a use case called 'AES encryption' (VPN, full disk encryption, stuff like that) then looking at clockspeeds is what? Plain stupid as usual! Both ODROID-C2 regardless of being able to clock at 2 GHz or just 1.5 GHz performs as crappy as the RPi 3. They both do not support ARMv8 Crypto Extensions and perform magnitudes slower than any cheap NanoPi NEO2 or Orange Pi Zero Plus running at below 1 GHz CPU clockspeed: RPi 3 is the SBC with the most screwed up DVFS/cpufreq/clockspeed situation. The problem should be well known since 2015: an awful lot of RPi suffer from underpowering and run then frequency capped (limited to 600 MHz). But just like in situations when throttling is happening the kernel has not the slightest idea at which clockspeed the CPU cores are running and reports bogus values like 900 MHz on RPi 2, 1200 MHz on RPI 3 and 1400 MHz on RPi 3+ while in reality being limited to 600 MHz. Is this 'cheating' or at least a problem? Not when your target audience is only absolutely clueless people (RPi users). They're happy to achieve top clockspeeds only in idle and being limited to 600 MHz once performance would be needed and even start to complain once they are made aware of the real problem (seriously: check this link, it's unbelievable)
  5. S905/912 faulty clockspeed, arm trusted firmware

    This already happens. RealTek RTD1295 and RTD1296 devices do exactly this. They run an Android for the media stuff and an embedded OpenWRT for NAS stuff. No idea how it's done on the NAS boxes based on these RealTek SoCs. Which kernel version and u-boot do they use? How performant are these boxes? Nobody cares since all that's relevant are whether these boxes do what they're advertised for and then some BS numbers like count of CPU cores and their clockspeeds that keep clueless NAS and TV box consumers happy. RTD1296 will be used on BPi W2 and OPi R2. No idea whether we'll ever see sources for 'firmware', bootloader and kernel. No idea why anyone want to run Linux on devices that need such crap. But it clearly is absolutely irrelevant for RealTek as long as they think about their target audience (clueless people once again) who simply don't give a sh*t about all that stuff as long as the box does what it's advertised for (that's playing movies, doing some gaming and serving as a performant NAS thingy).
  6. S905/912 faulty clockspeed, arm trusted firmware

    LOL! It's now 5 months that I discovered S912 cheating wrt CPU clockspeeds as every other Amlogic SoC. What's the impact? None. Why should the average Amlogic consumer care? That's TV box manufacturers selling to clueless Android users that trust in BS numbers presented by CPU-Z. They see 2 GHz and are happy. Why should Amlogic care? It's those consumers that they have to keep happy and they are happy when they can tell their neighbour that their TV box has 8 cores running at 2 GHz while the neighbour's has only 4 cores 'at 1.5 GHz'. CPU clockspeeds are BS for the use case anyway so everything those clueless people care about are irrelevant numbers. Why should Amlogic SBC users care? Well, they are in fact the only ones affected but if they would care about performance and not clockspeeds they would've known anyway (since then you test the performance and not rely on BS numbers like clockspeeds). It's stupid to think something that's rated for 2 GHz is faster than something else that's rated for 1.5 GHz (but that's what all those disappointed ODROID-C2 users thought) And all of this including vendor reputation is completely irrelevant for their market. That's not Linux geeks and blog readers but clueless TV box consumers searching for the cheapest box possible that has best looking specs (many many CPU cores, high clockspeeds and all the other irrelevant BS that's irrelevant for the 'TV box use case' anyway. How many of those consumers know that video decoding happens on the VPU and gaming is the GPU's task? Exactly: none) And all vendors in this market behave the same. Even Rockchip (only a few Rockchip SoCs are 'open sourced' but the majority not and there the same funny stuff happens of course)
  7. S905/912 faulty clockspeed, arm trusted firmware

    The S912 is limited to 1.5 GHz with single threaded loads and way less with multithreaded CPU loads. For the very simple reasons that the device category targets absolutely clueless users (why is this so hard to understand?!). The difference between the two boxes below is simply that the upper one is made for people who know how heat dissipation works (it's ok or even great when the surface gets warm since this means heat is transported out of the thing) and the lower is bought by clueless people who want boxes that stay cool since they're clueless: Amlogic produces SoCs that are stuffed in those cheap plastic boxes. And since good heat dissipation is limited or impossible due to clueless consumers the 'thermal budget' dictates clockspeeds anyway (throttling!). And also only due to their customers being absolutely clueless they can't promote such facts but have to create the impression that there are many many CPU cores inside running at high frequencies. Since you mentioned 'premium' TV-Box SoCs: That's for example Broadcom STB SoCs like the BCM7271. Which CPU cores? ARM? MIPS? How many? Which clockspeeds? Nobody knows for sure since those things are put into boxes that are not bought by clueless consumers who want to base their decision on BS numbers but are given to TV consumers by broadband providers 'for free'. Nobody cares about technical details since these things just work. There's no need to cheat on consumers since consumers do not have to decide. And it's a pretty new phenomenon that those premium STB SoCs have more than one or two CPU cores. Since video decoding on the CPU is plain BS anyway!
  8. S905/912 faulty clockspeed, arm trusted firmware

    BTW: Not always: those people who are for whatever reasons fascinated by 'as much CPU cores as possible' and love octa-core SoCs for no reason should better have a look at NanoPi Fire3: Less expensive and faster than any Amlogic stuff (see Willy Tarreau's reviews -- he's the one who also discovered Amlogic cheating on us wrt clockspeeds 2 years ago) And can now a moderator please split all the 'Amlogic still cheating with clockspeeds' stuff into an own thread with that title? Thanks and sorry for hijacking the original thread.
  9. S905/912 faulty clockspeed, arm trusted firmware

    And BTW: It really doesn't matter for the 'TV box use case' (which is the only one Amlogic has to care of) whether their SoCs are artificially limited to lower clockspeeds when more cores are busy or whether thermal throttling does the same anyway. Their challenge is making products for absolutely clueless people. The products these SoCs end up in (cheap TV boxes) can't be designed with good heat dissipation since those clueless people who should buy the boxes will never understand that a warm or even hot enclosure is something good: -- a TV box with a good thermal design moving the heat efficiently out of the enclosure gets negative ratings and won't be bought since... clueless people being the target audience of these devices. TL;DR: If you as Linux guy want to use Android toys as hardware you have to accept Android rules (cheap consumer crap being the design principle). It's easy to choose appropriate hardware for any job but then (not so) surprisingly you pay a lot more.
  10. S905/912 faulty clockspeed, arm trusted firmware

    You should know since I discovered this here and we talked about this already wrt S905X. Here is the summary: The 'Gouwa' guy in the comment thread is an official person from Khadas (not helping to further diagnose the issue and now also part of the Amlogic cheating game)
  11. S905/912 faulty clockspeed, arm trusted firmware

    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.
  12. S905/912 faulty clockspeed, arm trusted firmware

    The challenge they face is getting TV boxes sold in millions. It doesn't matter what you think, it doesn't matter what I think or anyone else from those few thousand people using Amlogic based SBC. We are 100% irrelevant. It's all about how the TV box market works: Totally clueless Android users focussing on BS numbers (more cores, more MHz, more DRAM, not knowing that almost everything that's important inside a TV box does NOT run on the CPU cores, software video decoding being the only exception). For their market CPU clockspeeds are totally irrelevant when it's about real world performance, they only serve as marketing criteria. If the S912 running with 8 cores at 1000 MHz (of course thermally throttled since TV boxes are usually piles of crap wrt thermal design) is able to decode a specific video codec at a specific resolution: mission accomplished). That's the 'SoC in action' reality: No one cares about clockspeeds here, it's only about getting the job done. Then there's the 'SoC in benchmarks and reviews' reality: AnTuTu, Geekbench, CPU-Z. Here it's important to show nice numbers but again since these benchmarks are soooooo crappy clockspeeds still don't matter. It's important to show fake cpufreqs (which is easy to accomplish since those tools like Geekbench or CPU-Z are that crappy that they never check for real clockspeeds but simply show the highest cpufreq OPP defined. Even without any 'firmware' cheating this is how Amlogic boxes ended up showing 2 GHz, how Allwinner devices limited to 1152 MHz show up with 1536 MHz, how RK boxes limited to 1.3 GHz are shown as '1,5 GHz' and so on). Their target audience (clueless Android consumers) doesn't understand or care about what's performance relevant so all those TV box SoC manufacturers have to do is to provide SoCs that perform somewhat ok-ish in reality (which is a tough job given the 'race to the bottom' principle their market is affected by since people buy as cheap as possible ignoring that quality has a price and that good heat dissipation would require a more expensive enclosure) and show high BS numbers those clueless people are interested in (MHz). And that's what Amlogic is doing and what the market demands. Those BS tools like CPU-Z or Geekbench could easily test within a second how high the CPU cores really clock but they prefer to be part of the more general cheating game and show only BS numbers (while it is pretty easy to perform such a test). And now some Linux users who want to use SoCs made for Android toys as Linux servers are disappointed. But why should Amlogic care? They have to sell millions of Android toys and not please a few Linux guys like us. Especially since focusing on CPU clockspeeds is so stupid (see all this laughable whining by ODROID-C2 users who 'felt' their boards being slower after community discovered that clockspeeds above 1.5GHz are faked. Their C2 performed identical before and after this discovery, it was just that some overclocking morons had their feelings hurt).
  13. S905/912 faulty clockspeed, arm trusted firmware

    This is an octa-core design made for TV boxes. IMO it's totally understandable that Amlogic does something equivalent to Intel's TurboBoost: reduce possible clockspeeds when all cores are in use. That way you end up with only 1.2 GHz when all 8 cores are busy. Given how DVFS works (increasing the VCore voltage a lot to provide laughable MHz boosts at the upper end of the DVFS scale) this is understandable both from a consumption and thermal point of view. This is a TV box SoC made for clueless people (Android users who think 'higher number' is 'better number'). All that's necessary for S912 TV boxes to sell are some BS marketing numbers ('octa-core at 2GHz' confirmed by shitty tools like CPU-Z and Geekbench) and all that's necessary to let those S912 TV boxes work ok-ish is limiting the CPU cores to sane operational defaults. The way Amlogic implements it (controlling this stuff from a BLOB and let the kernel report only bogus numbers) allows for both. Since all Android TV box SoC vendors play the same game I wouldn't call this cheating any more. It's just what a specific market demands (clueless people looking at irrelevant numbers instead of what's important)
  14. Preparing for Ubuntu 18.04

    I would prefer to do it correctly: And IMO there's no need to hurry and I honestly do not understand the bunch of hacks recently added to get 18.04 built now...
  15. NanoPi K1 Plus to be released soon

    Not really. A barrel jack was only on the K2, all other FriendlyELEC boards only have Micro USB for DC-IN (they sell a very good Micro USB cable for as less than 2 bucks) a 4 pin connector suitable to be combined with their PSU-ONECOM module (allowing to attach a 4.0/1.7mm barrel PSU) Just check, scroll to the bottom and check Shipping List. The more expensive boards ready to attach a lot of USB consumers are always sold with their great Micro USB cable (20 AWG rated or something like that. Pretty safe wrt voltage drops)