ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
<jn>
BaconV2: ok cool ;P
<BaconV2>
oh hey someone alive in here :P
<jn>
BaconV2: yes, there are likely a few dozen people here who know devicetrees, but you gotta ask an actionable question
<BaconV2>
right, one moment
<BaconV2>
so, I'm looking through a file called kernel.dtb for a device called the anbernic rg35xx, it's a chinese gaming handheld waith an actions atm7039s processor. Can't find any documentation on it, so I'm struggling (1/?)
<BaconV2>
basically the thing has a second ram port that is active (all the pads are withing working voltage ranges) and similiar chips have a capacity of 2GB, and it definitely accepts 1GB of ram on one pad
<BaconV2>
however, just soldering on the ram doesn't make it work, like it did when I upgraded from 256mb to 512mb
<BaconV2>
apparently there is a way to enable it via a device tree file
<BaconV2>
I'm just trying to figure out what the address of the second ram port is
<jn>
RAM init usually happens before linux is even loaded, in the first stage bootloader
<jn>
wait--- when you say "soldering on the ram doesn't make it work", how did you test that?
<BaconV2>
by soldering it on and checking for available ram in retroarch
<BaconV2>
in "information" there's an "available memory" section
<jn>
retroarch runs as an application under linux, and probably just reports what linux tells it, right?
<BaconV2>
sure, maybe, why?
<jn>
check that.
<BaconV2>
I don't think I'm able, it's not in my skillset. Are you referring to dmesg?
<jn>
`top` or `free` will do, finding the relevant lines in `dmesg` too
<BaconV2>
sorry but I have really minimal linux knowledge so this might be where I hit a wall
<jn>
and whether retroarch runs as a linux app is probably something you already know
<BaconV2>
I'm trying to learn I swear but it's hard
<BaconV2>
(for me)
<jn>
if that's the case, there are two things that need to happen before you get the desired result:
<jn>
2. linux needs to know about the initial memory. based on details that i don't know a priori, tweaking the DT might help with that
<jn>
1. all of the newly installed memory must be configured properly by the RAM init code. there likely isn't much you can influence here.
<BaconV2>
yeah tweaking the device tree is what I'm messing with right now :D
<jn>
BaconV2: don't worry, these tangential questions can
<jn>
... oops hit enter by mistake
<BaconV2>
lol
<jn>
BaconV2: don't worry, these tangential questions can result in a few hours or days of research, but will hopefully give you a more complete understanding of the system you're dealing with, and wisdom you can apply to more situations later
<BaconV2>
I know a guy that uses dmesg to check for changes on his unit but it seems like wizardry to me
<jn>
(linux often isn't easy, but as a journey of discovery and curiosity it becomes bearable)
<BaconV2>
I have linux mint running in virtualbox and I'm trying to figure out that myself :D
<BaconV2>
feels like it might be easier if I were a computer science student :D
<BaconV2>
I'm kust a lowly electronic engineering student
<jn>
i've studied computer science and it has taught me nothing useful except weird maths
<jn>
EEs are the real computer touchers
<BaconV2>
yeah I saw the weird logic etc that they were learning
<BaconV2>
didn't appeal to me
<jn>
the most important skill or habit is to formulate and ask questions (either yourself or others)
<BaconV2>
one question often leads to a chain of questions I've found :D
<jn>
curiosity is my weapon of choice. your mileage may vary, but it can be your weapon of choice too
<jn>
enough of a philosophy lesson from me; i can only show you the door, you're the one that has to walk through it, as Morpheus said
<jn>
BaconV2: ah, something i overlooked. you have that dtb file. have you managed to convert it into meaningful text?
Misotauros has joined #armlinux
<BaconV2>
yeah it's in .dts format
<BaconV2>
jn,
<jn>
Oh
<jn>
i thought you said dtb
<BaconV2>
it was in .dtb but I converted it
<jn>
ah, i see
<jn>
not as good as the original source dts, but still somewhat readable
<BaconV2>
I have to make do unfortunately :D
<jn>
such is life with shitty vendors
<BaconV2>
I think I might be onto something
<BaconV2>
an i2c bus scan
sakman has quit [Ping timeout: 240 seconds]
jclsn has quit [Ping timeout: 240 seconds]
jclsn has joined #armlinux
<BaconV2>
ayyy dmesg is finally working on my newer unit
<BaconV2>
I'm getting a LOT of information though gawd damn
sakman has joined #armlinux
macromorgan has quit [Remote host closed the connection]
<abelloni>
I guess REGMAP must not become user selectable
sudeepholla_ has joined #armlinux
dliviu has quit [Quit: Going away]
dliviu has joined #armlinux
<arnd>
abelloni: I don't see the entire background on this yet, but it looks to me like the line "default y if (REGMAP_I2C || REGMAP_SPI || REGMAP_SPMI || REGMAP_W1 || REGMAP_AC97 || REGMAP_MMIO || REGMAP_IRQ || REGMAP_SOUNDWIRE || REGMAP_SOUNDWIRE_MBQ || REGMAP_SCCB || REGMAP_I3C || REGMAP_SPI_AVMM || REGMAP_MDIO || REGMAP_FSI)" would need to be replaced with individual 'select REGMAP' statements from each of its users
<arnd>
I suppose I never saw this in randconfig builds because there are so many drivers that have a 'select REGMAP' statement, so it's unlikely to ever run into a randconfig that has them all turned off at the same time
<ccaione>
;Tr
amitk_ has joined #armlinux
<geertu>
abelloni: arnd: Oops, looks like I made a silly mistake there
<javierm>
geertu, abelloni: I would just revert that commit. I guess that KUNIT_ALL_TESTS select a lot of stuff anyways
<javierm>
but REGMAP_KUNIT selecting REGMAP sounds the correct thing to do for me
<geertu>
javierm: Enabling tests should not silently enable additional functionality aka attack vectors in your product
<arnd>
geertu: I think it's fine to 'select REGMAP' here, since that's a library module that nothing should ever "depends on"
<javierm>
geertu: fair, but then maybe the solution should be to not enable CONFIG_KUNIT_ALL_TESTS in your product ?
<javierm>
because yes, REGMAP_KUNIT select regmap but a bunch of other tests are going to select other options and increase your attack surface
<arnd>
it should not make a practical difference these days, since it's hard to build a product that doesn't use regmap already
<javierm>
arnd: agreed
<geertu>
javierm: CONFIG_KUNIT_ALL_TESTS=m would be fine, as it allows the developer to test anything by loading the module
<javierm>
geertu: I know but you can't have both :) there's a trade off between security and convenience
<geertu>
javierm: yes you can have both, if the tests are modular
<javierm>
geertu: yeah, but I meant not selecting what the test needs
<javierm>
not talking only about regmap in particular because as arnd said, that is more of a theoretical problem (hard to have a product without any driver using regmap) but in general
<geertu>
Indeed, in the past we had tests enabling e.g. extra file systems.
sszy has joined #armlinux
<geertu>
Tests should not select anything, but depend on it instead.
<javierm>
geertu: problem is that mixing depend and select is a recipe for circular dependencies
<geertu>
javierm: only if you can have circular dependencies
<geertu>
there should be no further links between drivers selecting e.g. REGMAP, and the tests depending on e.g. REGMAP
headless has joined #armlinux
<javierm>
geertu: yeah, until someone adds a driver that depends on REGMAP which will be user-selectable if KUNIT_ALL_TESTS is enabled
Crofton has quit [Ping timeout: 246 seconds]
drewfustini has quit [Ping timeout: 240 seconds]
drewfustini has joined #armlinux
Crofton has joined #armlinux
<javierm>
geertu: but don't get me wrong, I'm all to make it the kernel more configurable and I agree with you that tests shouldn't silently enable stuff
<javierm>
I just wonder if CONFIG_KUNIT_ALL_TESTS is a lost battle due all the things that could be enabled by every test
<geertu>
javierm: It shouldn't be that bad. I sent several patches to fix tests using select instead of depend.
<robmur01>
I guess the question there is intent - is it supposed to be "enable all tests relevant to the rest of the current config, to test the config" or "enable all tests ever written, to test the tests"?
apritzel has joined #armlinux
<javierm>
robmur01: my understanding is the latter (with the constraints imposed by depends on)
<javierm>
what I'm arguing though is that CONFIG_KUNIT_ALL_TESTS (even as a module) shouldn't be enabled in a production build
<javierm>
and the CONFIG_KUNIT_ALL_TESTS help text seems to agree
<robmur01>
makes sense to me too
<robmur01>
I think that tests are logically extensions of features, so should depend on features, thus a magic option to enable all tests should be responsible for enabling both the features *and* the tests
<javierm>
robmur01: I agree
<javierm>
just like `make allmodconfig` will try to enable all the possible modules and of course these would select a bunch of stuff
<javierm>
so for me REGMAP_KUNIT shouldn't be different than a driver that uses regmap and tries to select it
<javierm>
but you wouldn't want to ship a kernel with an allmodconfig configuration
<geertu>
config KUNIT_ALL_TESTS tristate "All KUnit tests with satisfied dependencies"
<geertu>
Note the "satisfied dependencies"
<javierm>
geertu: yeah, that's why I said with the constraints imposed by depends on
<javierm>
but it also says:
<javierm>
"Only useful for kernel devs running the KUnit test harness, and not intended for inclusion into a production build"
<geertu>
Yeah. I saw that.
<geertu>
Now, if you create a product, don't you want to be able to run all tests for functionality provided by the product?
<geertu>
I think some people are too deep into "testing for the sole benefit of testing", loosing track of the final goal of Linux
<javierm>
geertu: maybe what we need is a KUNIT_ENABLED_TEST or something and make drivers to do select REGMAP_KUNIT if KUNIT_ENABLED_TEST
<geertu>
javierm: I guess we can add such an option to force-enable dependencies for running as many tests as possible
<geertu>
I'm afraid we will run into something which cannot be force-enabled everywhere
<geertu>
like CONFIG_FORTIFY_SOURCE
prabhakarlad has joined #armlinux
<javierm>
geertu: yeah, I think that both POV have merit. Enable all possible tests but only for testing purposes and don't ship that config and enable all tests for the features/drivers that are enabled
<javierm>
so maybe we need to Kconfig to safisfy each
<javierm>
*two Kconfig
amitk_ has quit [Ping timeout: 246 seconds]
amitk_ has joined #armlinux
amitk_ has quit [Ping timeout: 245 seconds]
amitk_ has joined #armlinux
amitk_ has quit [Ping timeout: 245 seconds]
amitk_ has joined #armlinux
headless has quit [Quit: Konversation terminated!]
<marc|gonzalez>
Hello everyone :) I posted yesterday to LKML, but that list is such a firehose that most messages are probably never seen :)
<marc|gonzalez>
I want to speed up mm/memtest.c - one way would be to mark the zone as non-cached (perhaps WC). Any good resources or tips?
cbeznea has quit [Ping timeout: 246 seconds]
amitk_ has joined #armlinux
<marc|gonzalez>
Another promising approach is using SIMD loads/stores (to maximize throughput/instruction)
<marc|gonzalez>
ardb: I CCed your old Linaro address, but that bounced, doh! :)
<marc|gonzalez>
mrutland: is Vladimir M still at arm?
vireshk- has joined #armlinux
<broonie>
arnd: selects of regmap won't work since the things that should select regmap are themselves selected and seect does the wrong thing there.
vkoul- has joined #armlinux
<broonie>
and regmap has never been user visible, I really don't understand that e-mail at all.
amitk_ has quit [Ping timeout: 245 seconds]
<geertu>
broonie: What do you mean by "the wrong thing"? After my patch to switch to select REGMAP, none of the tens of .configs I ran "make oldconfig" on changed.
<broonie>
geertu: Selects from selected things are ignored.
<robmur01>
marc|gonzalez: AFAICS memtest is using __va(), so would be using the (cacheable) linear mapping, thus a non-cacheable mapping would be very much the opposite of faster
<arnd>
broonie: Kconfig ignores selects from other selects iff the dependencies are not met, but that's a different problem
<marc|gonzalez>
robmur01: Caches are pointless when data is used once? In fact, I got a 30% speed improvement by using non-temporal stores
<broonie>
arnd: Ah, that's a bit better.
<marc|gonzalez>
(though the improvement might also be due to larger grain size)
<marc|gonzalez>
robmur01: also if cache is enabled, then we can't test small areas (error would be hidden by cache)
<geertu>
arnd: They're not really ignored, they cause warnings
<marc|gonzalez>
(should have CCed you too but I forgot your name, and my archive was busted)
<arnd>
geertu: well, both: they cause a warning but then other things go wrong because Kconfig ignores conflicting requirements
<marc|gonzalez>
robmur01: is there an easy way to access RAM without the cache, especially if there's already an MMU entry for that area?
<robmur01>
on some architectures, yes (e.g. MIPS, I think); Arm/arm64, not so much
<marc|gonzalez>
robmur01: what if I unmap, remap as UC, do my thing, unmap, remap as C?
amitk_ has joined #armlinux
<robmur01>
then you'd be doing a load of invasive and highly-impractical work, in order to make doing your thing significantly slower ;)
<marc|gonzalez>
robmur01: why are you so sure of that?
<robmur01>
Experience. Last year we experimented with using a non-cacheable mapping for non-coherent SWIOTLB, and copying in and out of that turns out to be unacceptably slower than cacheable copies + explicit cache maintenance
<marc|gonzalez>
robmur01: OK thanks for sharing experience. Explicit cache maintenance: can I say OK flush this area to memory now?
<robmur01>
shouldn't matter - the nature of memtest touching every byte of memory should in practice pretty much ensure that everything gets evicted from cache before it's read back anyway
<marc|gonzalez>
You're making the same mistake as my boss :p
<marc|gonzalez>
Once we find a bad RAM cell, the memory segment gets split in two
<marc|gonzalez>
So possibly one of the 2 new segments will be smaller than L3
amitk_ has quit [Ping timeout: 252 seconds]
<marc|gonzalez>
I suppose one could argue that this is a small probability, but I have a box with 50 bad cells, and I am seeing some short segments
jpanisbl has quit [Quit: Konversation terminated!]
monstr has quit [Remote host closed the connection]
cbeznea1 has quit [Quit: Leaving.]
apritzel has quit [Ping timeout: 246 seconds]
cbeznea has joined #armlinux
apritzel has joined #armlinux
<milkylainen>
Hmm. OT question. Does anyone have a grasp on what read speeds to expect from parallel mapped nor flash? Typical nor flash. 16-bit, normal relaxed timings around 100ns. I'm getting 6M/sec sequential. My gut feeling tells me it's off. Couldn't find any useful resources and my heuristic calculations tell me it's off.
amitk_ has joined #armlinux
marc|gonzalez has left #armlinux [#armlinux]
amitk_ has quit [Remote host closed the connection]
<rfs613>
milkylainen: 100ns = 10 MHz and you get 16 bits (2 bytes) each time, so that in theory 20 MB/s
<rfs613>
that said I have no experience with those parallel devices.
<rfs613>
on the (non-parallel) QSPI chip I'm currently messing with, I get about 7.4 MB/sec on reads
<milkylainen>
rfs613: yeah. I'm also coming up a bit short on parallel device experience. Figured about the same (actually a bit more with read bursts, but those seem broken).
cbeznea has quit [Read error: Connection reset by peer]
cbeznea has joined #armlinux
amitk has quit [Ping timeout: 245 seconds]
rvalue has quit [Ping timeout: 240 seconds]
<broonie>
You will get some dead time on the bus between blocks read.
rvalue has joined #armlinux
<milkylainen>
broonie: yes. The initial calculation was with 16-byte / 32-byte page read. Since those are quite a bit faster I figured I should still hit more than 20M/s. Not 6.
<broonie>
Yeah, 6 seems rather slow. I don't think that path has been heavily optimised though.
<milkylainen>
Anyway. Page reads seem broken.
<broonie>
Slow and broken, what's to complain about? :P{
<milkylainen>
iiuc, the nxp ifc can't be told how many read bursts to perform. It derives the burst from whatever the system bus comes up with. Ie, it can't chunk the requests itself. So I guess it's either cacheline sizes or whatever the instruction or bus comes up with.
<milkylainen>
And if that doesn't fit the nor flash page buffer .. well. To bad for you.
bjoto has quit [Ping timeout: 250 seconds]
<milkylainen>
peculiar design. Don't know why one would even bother with a parallel design over the IFC nor interface.
bjoto has joined #armlinux
<milkylainen>
I had this question a while ago regarding the IFC in parallel mapped NOR. If I get this right, the actual transfer is just a memcpy and the IFC handles the incoming transactions and fills data? So what happens when a core issues loads that transfers out to a really slow memory mapped media? Feels like Pandoras box to me.
<broonie>
I gather that one of the big use cases for those things is firmware where you can get something a lot more performant without having to write a complicated driver.
<milkylainen>
Those loads in the kernel is going to stall for quite some time? Or how does that work?
<broonie>
For the kernel I've always been a bit unconvinced about non-DMA use (and hope that the DMA wouldn't tie up the bus).
<milkylainen>
Mm. This ties up the entire core when shuffling a measly 6M/sec.
<milkylainen>
:\
<broonie>
Can you not access it with a regular SPI interface as well (usually it's a regular SPI too since the memory mapped stuff is read only).
<milkylainen>
Nope. Not this one.
<broonie>
Oh :(
<milkylainen>
Conservative design. Made for a very long service life.
<broonie>
A truly conservative design would've had a regular SPI as backup for the fancy stuff! :P
<broonie>
Might be worth seeing if DMA does any better than memcpy(), it should at least let the processor get on with other stuff.
<milkylainen>
hmm. dma mtd physmap.
<milkylainen>
I don't think I ever saw such a driver?
<milkylainen>
In any form. Come to think of it.
headless has quit [Ping timeout: 240 seconds]
<cambrian_invader>
milkylainen: a lot of these memory maps also have some cache; so you can run code directly out of them (like at boot) without killing your performance
headless has joined #armlinux
<cambrian_invader>
even if the actual backing media is very slow
<milkylainen>
cambrian_invader: Mmm. The main purpose in this design seems to be very traditional flash usage. Very long life and intentionally very little wear.
headless has quit [Quit: Konversation terminated!]