lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<Armbian-Discord> <p​rofbbrown> Device trees are a new thing for me. I can read schematics and have identified the PMIC (power management IC?), but I'm not sure how to correlate that to an interrupt or I2C pin and where in the device tree file to make the change.
<Armbian-Discord> <p​rofbbrown> As I understand what you all are saying: Armbian and other distros are maintained by different sets of people. They may or may not have configured the OSes correctly and there's no guarantee that corrections made in one distro will find their ways to the others.
<Armbian-Discord> <p​rofbbrown> I downloaded and installed the image from orangepi.org. Same story: load average is >1
<Armbian-Discord> <T​onymac32> did you even bother to check the fusb302 thing tkaiser posted about? I haven't seen it on mainline, but I also haven't been looking, TBH.
<Armbian-Discord> <T​onymac32> well, they may or may not have dealt with ridiculous bugs, in this case, too many shitty patches get thrown all over everything on a daily basis to keep up with what is and isn't real. I need to make my own set of board defs in my own corner of the web so I can think straight on this mess for at least 5 minutes before someone adds a new kernel or tries to turn Armbian into LibreElec, or requests to merge
<Armbian-Discord> an entire patchset from a vendor without looking for collateral damage 🙂
<Armbian-Discord> <T​onymac32> tkaiser I didn't know the armbian-devel channel wasn't bridged, of course nothing of value happens in here anyway except archetech coming in and talking about how much he loves arch and his N2+ 😄
<Armbian-Discord> <p​rofbbrown> I saw that website and read it, but it refers to a different board (Radxa Zero), so I'm going to assume the pin numbers are different.
<Armbian-Discord> <p​rofbbrown> I could try simply disabling the fusb302 thing, but the website cautions that it completely disables something on the board and who knows what else might be affected.
<montjoie> could someone share me rk3588 TRM part1 ?
<Armbian-Discord> <M​axMatteo> @c0rnelius not hating you at all 😉
<montjoie> tkaiser: thanks
<Armbian-Discord> <R​ory> Hi I've just bought a rock64pro and I would like to install armbian to an external ssd connected to it, but does the armbian images have proprietary blobs in it or not ? I've heard it was possible to use the rock64pro with no blobs.
<Armbian-Discord> <R​ory> Thanks
<Armbian-Discord> <I​gorPec> build system has support for both. not sure which mode is used for this particular hardware
<tkaiser> You seem to be interested in 'blobless', right? https://github.com/armbian/build/search?q=blobless
<Armbian-Discord> <b​albes150> To understand this, tests are not needed, banal logical thinking is enough - random mechanical movements of the head over the disk and waiting for the desired disk sector to be under it, a priori, much slower than switching the "transistor" to the desired cell. 🙂
<Armbian-Discord> <b​albes150> There are minor inaccuracies in the article (not critical, but preferably to be corrected)
<Armbian-Discord> <R​ory> So you mean there is an armbian image with and without blobs ?
<Armbian-Discord> <R​ory> Yes
<Armbian-Discord> <I​gorPec> Armbian user land is the same, but otherwise Armbian = custom Linux image for each board, boot loader, boot way, some hw specific tweaks. And all this is open source. What you are asking can be found in the build system. I would need to search for you, but you can also do that
<tkaiser> @Rory: https://github.com/armbian/build/search?q=blobless shows in a single spot four RK3399 devices running blobless with Armbian. The others are condemnded to run with BLOBs.
<tkaiser> PinebookPro and RockPro64 are boards of the same family (rockchip64) from the same manufacturer and share same sources. But one boots blobless, the other not.
<Armbian-Discord> <R​ory> So rockpro64 is the one booting blobless ?
<tkaiser> And a third time the same URL again: https://github.com/armbian/build/search?q=blobless where you find in a single place all the four RK3399 devices running blobless with Armbian.
<Armbian-Discord> <R​ory> OK thanks sorry for my silly questions I didnt understand
<tkaiser> balbes150: of course the HDD sucks with random I/O but if you choose the wrong benchmark (e.g. hdparm that is often preferred in this stupid SBC world) then the numbers will 'proof' a SATA attached HDD being 'faster' than an USB2 attached external SSD while with most use cases the opposite is true since sequential transfer speeds do not often matter.
<tkaiser> And if this is true for an USB2 port it is true for a PCIe port and NVMe as well. Even behind a single Gen2 lane any NVMe SSD performs great as long as the settings are appropriate.
<tkaiser> And the latter is where Armbian sucks really hard since few years since nobody cares about these I/O settings any more. ASPM ofc has an influence on NVMe performance, (missing) tunables as well.
<tkaiser> So it's rather pointless to 'benchmark' any NVMe device on any device 'supported' by Armbian within the last few years since settings likely do not fit.
<tkaiser> @Rory no need to be sorry but I wonder why you're not asking... why PinebookPro can boot blobless and Rockpro64 not? :)
<Armbian-Discord> <R​ory> Wait what? On github it is written rock64 boots blobless but why not rock64pro ?
<Armbian-Discord> <I​gorPec> Reasons for that decision is probably written in the Git commit history. I would put my bet that board is probably too unstable in this configuration.
<Armbian-Discord> <T​enkawa> this has nothing to do with what I was quoting
<tkaiser> IgorPec: decision? Here's rockpro64 history: https://github.com/armbian/build/commits/master/config/boards/rockpro64.conf
<tkaiser> The 'blobless' story started as BOOT_USE_MAINLINE_ATF. Some individuals adding boards took care about this, majority of people involved didn't: https://github.com/armbian/build/search?q=BOOT_USE_MAINLINE_ATF
<tkaiser> So in reality nobody took care about rockpro64 which is understandable since everything around RK SoCs in Armbian's build system is a chaotic mess.
<Armbian-Discord> <b​albes150> for me, there is only one "test" that I believe in - real work. All other tests are an attempt to artificially change "something" and compare it with "something". I think it's no secret to you that, if desired, you can "program" (write code in the right way) so that the "test" gives the "desired" result. 🙂
<Armbian-Discord> <N​icoD> I do test it, if you don't, you know NOTHING. I use sequential and access time. And my software isn't being changed in between testing boards. And I don't see data as a holy grail towards everlasting life and happiness.
<tkaiser> 'Real work' is also affected by shitty defaults. You know what you're doing here all, right? Not dealing with 'Linux on ARM devices made for Linux' but dealing with 'Linux on devices from the Android e-waste world'. That's what Armbian is all about.
<tkaiser> Good luck with this ignorance. The kernel config for some crappy Android TV box differs from what a 'general purpose computer' running Linux needs.
<tkaiser> As such ASPM (PCIe's Active State Powermanagement) and other defaults.
<tkaiser> And if you realize that 'real work' on some RK thingy with a SATA SSD seems to be faster than with an NVMe SSD rest assured that's the fault of settings.
<tkaiser> 'Tests' either need to represent real-world use cases or need to be designed to find corner cases and irrelevant maximum scores. Starting with the latter is usually what you do when exploring a new platform since everything has its own cost.
<tkaiser> Only when you know how fast a certain subsystem can be (be it storage, network, CPU, GPU, whatever) then you can weigh in other aspects like power consumption and _only then_ come up with sane settings and hopefully a documentation for 'power users' how to adjust this and that to fit special needs.
<Armbian-Discord> <T​enkawa> @tkaiser as I'm sure you will agree... "testing" in general is important as wide/varied as variables you can get.
<Armbian-Discord> <T​enkawa> "absolute" numbers aren't always going to prove out in the end to be the "only" useful thing.. sometimes seeing trends in data from staged/virtual loads/tests can expose problems/conditions in software/environments just as well as real world usage
<tkaiser> I guess Oleg knows what I'm talking about. His claim 'the speed of NVMe is lower than SATA' in the context of RK3588s: https://forum.armbian.com/topic/22986-firefly-station-m3-rk3588s/page/2/#comment-146842
<tkaiser> This conclusion is based on an Armbian version as usual lacking all sorts of important I/O related tweaks. As such such a conclusion might be true 'for the state of settings in Armbian' but not in general.
<tkaiser> In Rockchip's kernel ASPM is set to 'powersave' which is long known to be responsible for trashing the performance of PCIe devices. And guess what an NVMe SSD is? A PCIe device...
<Armbian-Discord> <T​enkawa> I don't buy that
<Armbian-Discord> <T​enkawa> this is my R5
<Armbian-Discord> <T​enkawa> 4406 MB in 3.00 seconds = 1468.63 MB/sec4406 MB in 3.00 seconds = 1468.63 MB/sec
<Armbian-Discord> <T​enkawa> on my nvme
<tkaiser> Looking at the wrong benchmarks (e.g. this useless hdparm BS) the claim might even be true since sequential transfer speeds with SATA 6G are faster than a Gen2 PCIe lane with 5GT/s and both 8b10b coding.
<tkaiser> RK3588s is the crippled RK3588 version. No PCIe Gen3, just two Gen2 lanes.
<Armbian-Discord> <T​enkawa> ok my bad.. didnt see the s
<Armbian-Discord> <T​enkawa> I have heard the "s" is bad
<tkaiser> But sequential transfers are irrelevant for most tasks anyway and broken kernel defaults of course do their job harming NVMe performance with the more important random I/O numbers.
<tkaiser> Once these I/O settings are fixed any quality NVMe SSD should outperform any SATA SSD especially with massive parallel I/O loads since NVMe is a protocol made in this century and made for flash storage unlike AHCI from the ages of spinning rust.
<Armbian-Discord> <T​enkawa> I need to get my hands on a 3588s
<tkaiser> It's the same as RK3588 minus great I/O capabilities. Asides that pretty much the same.
<Armbian-Discord> <T​enkawa> ahh ok
<tkaiser> If all you need is CPU, GPU, VPU, NPU then RK3588s is fine.
<Armbian-Discord> <T​enkawa> I won't bother... I am looking to grow inventory on a few more SoCs...
<Armbian-Discord> <T​enkawa> I have most every major chipset out atm though
<tkaiser> As for your low '1468.63 MB/sec'. This was made with hdparm which is a tool coded last century. Also back then they hardcoded 128K block size for this pseudo-benchmark which was huge back then but is nothing in today's world where any average eMail exceeds the amount of RAM computers back then had.
<tkaiser> Just by using a larger blocksize (1M or 16M) you get better numbers. ~300 MB/s at least. Still way too low for a Gen3 x4 SSD.
<Armbian-Discord> <T​enkawa> it is all "relative". if you compare it to another piece of hardware using the same tool ... who cares?
<Armbian-Discord> <T​enkawa> its comparing the same thing
<Armbian-Discord> <T​enkawa> all I want to know is does this tool on soc#1 do "this" or "that" vs soc#2
<Armbian-Discord> <T​enkawa> and thats "exactly" what it gives me
<tkaiser> Yeah, ignorance, ignorance and ignorance. That's what makes up this place. The combination of broken cpufreq settings, broken PCIe powermanagement, using the wrong SSD (a cheap x2) results with no-one having any clue why the numbers are that low.
<tkaiser> LOL! You're not comparing 'soc#1' with
<Armbian-Discord> <T​enkawa> no. you are overcomplicating things trying to justify yourself
<tkaiser> 'soc#2' but an OS image running here with another running there. The reasons why the same tool spits out different numbers even with the same hardware can vary. It's all about settings. But hey, how to explain this here at Armbian.......
<Armbian-Discord> <T​enkawa> btw... I'm not from Armbian
<Armbian-Discord> <T​enkawa> stop assuming
<Armbian-Discord> <T​enkawa> rule/mistake #1
<tkaiser> And there are trivial things like PCIe link training or stupid device-tree fragments that limit PCIe link speeds.
<tkaiser> Oh, we aren't here in an Armbian Discord crap channel?
<Armbian-Discord> <T​enkawa> go back and fix your post to actually be relevant to the SoC IO and not the individual drives and then it might be useful
<Armbian-Discord> <T​enkawa> because with x*drives being of infinite quality of course you are going to get infinite amounts of results in speed
<Armbian-Discord> <T​enkawa> much better numbers are to measure a defined set of drives only
<tkaiser> What does this output? lspci -vv | grep -E "LnkCap|LnkSta"
<tkaiser> On your Rock 5B?
<Armbian-Discord> <T​enkawa> lspci -vv | grep -E "LnkCap|LnkSta"
<Armbian-Discord> <T​enkawa> wrong paste/
<Armbian-Discord> <T​enkawa> just a sec (new mouse)
<Armbian-Discord> <T​enkawa> LnkSta: Speed 8GT/s (ok), Width x4 (ok)
<tkaiser> Is this the same SSD you used in ODROID-M1?
<Armbian-Discord> <T​enkawa> nope
<Armbian-Discord> <T​enkawa> I have about 10 nvme drives sitting here
<Armbian-Discord> <T​enkawa> just for testing
<tkaiser> Ok, which exact model in Rock 5B?
<Armbian-Discord> <T​enkawa> whichever the dev model is from radxa
<tkaiser> I was talking about the SSD...
<tkaiser> smartctl -a /dev/nvme0 | grep ^Model
<Armbian-Discord> <T​enkawa> I've got to go do some work... I'll work on this later
<Armbian-Discord> <T​enkawa> bbl all
<tkaiser> Whatever... since you're most probably running some Armbian flavour on your Rock 5B everything I/O relevant is missing. If you want to change this open https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ROCK_5B.md#important-insights-and-suggested-optimisations
<tkaiser> Scroll down to '/etc/sysfs.d/tk-optimize-rk3588.conf', create this file with these exact contents, reboot and re-test.
<tkaiser> But most probably it won't work since Armbian's Rock 5B kernel has schedutil as default cpufreq governor so that these settings can't be applied early on when cpufrequtils aren't loaded.
<tkaiser> This might work as contents: https://pastebin.com/raw/8gwmMHgp
<tkaiser> If your SSD is not total crap performance should be twice as fast afterwards. Even 'measured' with hdparm
<Armbian-Discord> <T​enkawa> Back.
<Armbian-Discord> <T​enkawa> you really should stop assuming everyone runs default configurations
<Armbian-Discord> <T​enkawa> I don't even run even close to their kernel config
<Armbian-Discord> <T​enkawa> scheduler, io configurations, etc
<tkaiser> smartctl -a /dev/nvme0 | grep ^Model
<Armbian-Discord> <T​enkawa> WDBRPG5000ANC-WRSN Western Digital Black.. is there a reason you ask?
<tkaiser> No, of course not.
<tkaiser> Quoting https://www.tomshardware.com/reviews/wd-black-sn750-ssd,5957.html "The Black SN750 delivers peak speeds of up to 3,470/3,000MB/s read/write"
<tkaiser> You have no PCIe link training problems according to your lspci output.
<tkaiser> And your SSD performance is plain shit.
<tkaiser> But everything is alright, your settings are not defaults but superiour and so and so on...
<tkaiser> You're running into the same problem everyone else is running with Armbian on any recently added hardware: Shitty I/O performance caused by ignorance and stupidity
<tkaiser> The recipe to change this crap is well known, it's documented, the Armbian guys got it multiple times on a silver platter but to no avail.
<Armbian-Discord> <T​enkawa> io runs great here... I think you are trying to find problems where there are none
<tkaiser> Sure, absolutely. In the land of ignorance and stupidity 'io runs great' if caused by stupid settings a NVMe delivers '1468.63 MB/sec' while it could do 3470 MB/sec.
<tkaiser> And of course there's no problem at all. It's fine that all CPU cores remain at 408 MHz when storage is accessed. Who would want faster storage? Who would want to benefit from the 'race to idle' concept, finishing storage tasks as fast as possible?
<Armbian-Discord> <M​anoftheSea> so, the guy who knows what it needs to be, what blocked your pull request to get it into where everyone can use it?
<tkaiser> Still rotting around with wrong label and so on.
<tkaiser> Back to where we came from: the claim 'SATA is faster than NVMe'. No, it's just Armbian shipping with shitty settings. That's all.
<Armbian-Discord> <M​anoftheSea> you were talking about storage, that ticket is discussing soc temperatures. I don't understand
<tkaiser> Alright! @lanefu did a really great job preventing anyone from picking this up. Not being able to differentiate between two separate problems.
<Armbian-Discord> <M​anoftheSea> So, does fixing it interest you?
<Armbian-Discord> <M​anoftheSea> It seems like you're the only one that understands what you're talking about.
<tkaiser> The difference between the two numbers 1468.63 MB/sec and 3470 MB/sec?
<Armbian-Discord> <M​anoftheSea> more the "why" behind it.
<Armbian-Discord> <M​anoftheSea> and the "how to resolve"
<Armbian-Discord> <T​enkawa> And the "what are my expectations and did I ask it to be fixed?"
<Armbian-Discord> <T​enkawa> and the answer to that is "they are fine and no"
<Armbian-Discord> <M​anoftheSea> no, I think I understand those questions, as "it could go twice as fast" and "do I want it to go twice as fast, yes."
<Armbian-Discord> <l​anefu> tkaiser: are you angry with me?
<tkaiser> Nope, it's just sad that suggestions end up rotting somewhere around forever due to a ticket describing one problem and then containing the fix for another totally unrelated problem.
<Armbian-Discord> <l​anefu> that was my attempt at acknowledging preserving your concerns so they weren't lost. i'm sorry I made a mess of it. I can leave it as is, I can delete it, or you're welcome to rewrite it
<Armbian-Discord> <l​anefu> *acknowledging and preserving
<Armbian-Discord> <l​anefu> do you have a preference?
<tkaiser> Nope. In general I don't care much how projects manage work not getting done ;)
<tkaiser> The replacement code for what I wrote years ago is there, it can be tested, the results are obvious (not to everyone of course, some people are fine with halved I/O performance and justify this with whatever BS)
<tkaiser> But if @ManoftheSea is right and really nobody at Armbian even understands what I'm talking about then it is what it is: Armbian not able to adopt proper settings while all the time Armbian's Chief Advertising Officer brags accross the whole Internet about these low-level optimisations that do not happen any more since few years.
<Armbian-Discord> <M​anoftheSea> I'm reminded of the Lorax... unless someone like you cares a whole awful lot (and provides a pull request), nothing is going to get better, it's not
<tkaiser> ManoftheSea do you have a local clone of the build repo? If so chdir into and then
<tkaiser> git log | grep 'Author' | grep -E 'Thomas Kaiser|ThomasKaiser' | wc -l
<tkaiser> There's a reason I'm no longer directly contributing to this project. Since the way it is 'organized' it can't be fixed.
<Armbian-Discord> <M​anoftheSea> I assume this will give me a number bigger than zero
<Armbian-Discord> <M​anoftheSea> And that's great.
<Armbian-Discord> <M​anoftheSea> well, I don't know how to fix it either.
tkaiser has quit [Ping timeout: 265 seconds]
tkaiser has joined #armbian-rockchip
tkaiser has quit [Ping timeout: 268 seconds]
tkaiser has joined #armbian-rockchip
<Armbian-Discord> <T​onymac32> watches the new guys experience Tkaiser for the first time
<Armbian-Discord> <T​onymac32> So yeah, he's right on all counts. He makes sure everyone is too pissed off to listen to him though (possibly on purpose, but I somehow think not).
<Armbian-Discord> <T​onymac32> The hardware optimizations were his baby, and unfortunately no one took up the torch when he left. I've butted heads (gently) about the hilarious idea of "relevance" in this project since it comes exclusively at the expense of the quality of the project.
<Armbian-Discord> <T​onymac32> But, I'm a guy with no time and no patience, so 🤷‍♂️
tkaiser has quit [Ping timeout: 268 seconds]
tkaiser has joined #armbian-rockchip
tkaiser has quit [Ping timeout: 252 seconds]
tkaiser has joined #armbian-rockchip
tkaiser has quit [Ping timeout: 244 seconds]