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
apritzel_ has quit [Ping timeout: 265 seconds]
elastic_1 has joined #armlinux
elastic_dog is now known as Guest497
elastic_1 is now known as elastic_dog
mraynal has quit [Read error: Connection reset by peer]
mraynal has joined #armlinux
macromorgan has joined #armlinux
_whitelogger has joined #armlinux
jclsn has quit [Ping timeout: 265 seconds]
jclsn has joined #armlinux
heat has quit [Ping timeout: 248 seconds]
prabhakarlad has quit [Quit: Client closed]
amitk_ has joined #armlinux
amitk_ has quit [Ping timeout: 265 seconds]
amitk has quit [Remote host closed the connection]
apritzel_ has joined #armlinux
apritzel_ has quit [Ping timeout: 268 seconds]
mcoquelin has quit [Remote host closed the connection]
<atorgue>
arnd: Hi Arnd, To boot, our STM32MP13 relies only on OPTEE and ARM SCMI. Do you think it is acceptable to add those configs in multi_v7_defconfig as built-in configs ? I tried in the past, it was contested.
<arnd>
atorgue: it's probably ok. Not sure what the objection was last time, but both are getting increasingly popular. It's likely that others are going to rely on them as well
prabhakarlad has joined #armlinux
<atorgue>
arnd: Ok thanks.
cbeznea has joined #armlinux
cbeznea1 has quit [Read error: Connection reset by peer]
Bitweasil has quit [Ping timeout: 246 seconds]
Bitweasil has joined #armlinux
cbeznea has quit [Ping timeout: 252 seconds]
cbeznea has joined #armlinux
monstr has joined #armlinux
luispm has joined #armlinux
marc|gonzalez has joined #armlinux
MWelchUK7 has joined #armlinux
MWelchUK7 has quit [Ping timeout: 250 seconds]
MWelchUK4 has joined #armlinux
MWelchUK4 has quit [Client Quit]
MWelchUK5 has joined #armlinux
MWelchUK5 has quit [Client Quit]
MWelchUK1 has joined #armlinux
MWelchUK1 has quit [Client Quit]
headless has quit [Quit: Konversation terminated!]
MWelchUK7 has joined #armlinux
cbeznea has quit [Ping timeout: 252 seconds]
MWelchUK7 has quit [Client Quit]
<dormito>
Last Tuesday I submitted a patch to the linux-arm-kernl ML (my first patch to upstream linux), however it seems to have no replies. Is a week too short of a wait for a new patch?
<krzk>
dormito: usually two weeks for resend or ping
<dormito>
krzk: alright, thanks
<krzk>
dormito: anyway silence can be a sign something was missing, so double check you followed the process of submitting patches (including checkpatch and get_maintainers.pl)
<krzk>
dormito: There are no unanswered patchsets on 21st of March...
<krzk>
ah wait, wrong filter, there might be
<dormito>
krzk: sorry I just realized it was the 20th (so monday), not tuesday
<dormito>
(in case you wondered, or want to take a peek to see if my submission process is correct). I think I followed the guidelines with checkpatch and 'get_maintainer.pl'
<krzk>
dormito: I think you did not follow...
<krzk>
dormito: no, wait, addresses look ok
<krzk>
but who should pick it up? If it is ARM, then I would expect FSL/NXP arch maintainers but they are not included in get_maintainers.pl output...
<dormito>
The first two addresses (all from get_maintianer.pl) have nxp address, which I assume means they'd be the ones to pick it up?
<krzk>
dormito: they haven't been picking up since 1-2 years, so I doubt. It's surprising a bit that the directory is not covered by FSL ARM SoC entry. Probably it's PPC-only thing/part of FSL? Then you are bugging wrong folks :)
<dormito>
That's qoriq stuff, which originated in PPC, but it's defintiely on arm chips. My use case is the LX2160A (a 16 core A-72). A
<krzk>
dormito: then the entry in maintainers might not be complete/accurate and you should bug shawnguo
<dormito>
Is there a typical way people do that: should I ressent the whole patch with Shawn added? Or just email exposition and a linking?
<bjdooks>
hmm, u32 *ret should really be __le32 *ret, did you try runing sparse over it?
<bjdooks>
and or drivers/soc/fsl who'd deal with it
<dormito>
bjdooks: I'm not familiar with sparse (in context), so I have not explicitly used it.
<bjdooks>
it should do things like show implicit endian conversions iff the source variables are set to __le32 or __be32
<dormito>
Hmm. That should let the result variable be dropped, and makes it much cleaner
<bjdooks>
but that also assumes the qbman_get_cmd() returns the right type for the dat
<bjdooks>
sorry, mplicit endian conversions, i meant casts
<bjdooks>
you'd still need to do the l32_to_cpu() call
<bjdooks>
you'd just have been warned by sparse if it wasn't there
<dormito>
oh I see. It's __le32 is "just" annotation for tooling and human readers.
<bjdooks>
yes
<dormito>
I'd have to go through the code again. I think "ret" is mostly/entirely an native endian structure (or endian swaps are present elsewhere). The networking fully works with just those changes.
amitk has quit [Ping timeout: 255 seconds]
<shawnguo>
drivers/soc/fsl patches should generally go to Li Yang <leoyang.li@nxp.com>
<shawnguo>
drivers/soc/imx is my stuff
<dormito>
ah, then I wont email you about it, lol
<dormito>
Yeah Li Yang was the 2nd person get_maintiner.pl suggested (and should have recieved the patch).
<arnd>
dormito: I would usually try to add a 'Fixes:' tag for a bug like this, but 'git log -p --follow drivers/soc/fsl/dpio/qbman-portal.c' shows that this dates back to when the function was originally added in commit 321eecb06bfb ("bus: fsl-mc: dpio: add QBMan portal APIs for DPAA2")
<arnd>
so it never worked in mainline
<arnd>
it's odd because layerscape was one of the two platforms that actually had vendor support for a big-endian BSP.
<arnd>
maybe not chips with this driver
<arnd>
dormito: I checked the source file file for other related bugs but couldn't find any, your patch (with the added __le32 annotation) looks correct
<dormito>
arnd: thanks. I'll look at adding the __le32 annotations (and look into running sparse against it).
Amit_T has joined #armlinux
<dormito>
I'm not overly surprised it never worked on BE. I believe DPAA2 is relatively new (only a one or two SoCs previously... I think, though the lx2160 is my first exposure to any DPAA).
<dormito>
There seems to be a bug on the LX2160 (at least), that triggers when trying to use the SMMU in BE mode. I'm planning to look into that next. And since that doesn't work (ATM I have to blacklist/compile out SMMU support), it suggests to me that BE hasn't really been tested on that chip.
<arnd>
dormito: Right. I also checked the references on nxp.com to their big-endian BSPs, they all seem to be for the older LS10xx series, in particular ls1043a and ls1028a
<arnd>
oh, apparently ls1088/ls1084/ls2048/ls2044/ls2088/ls2084 are also older and have dpio, but no BE BSP
<dormito>
Interesting. I thought I'd seen BE listed in the 2160 RM, but I just took a quick look, and if its there, it is not obvious.
<dormito>
gentoo works on it farely well (once zlib is no longer generating incorrect crcs).
<robmur01>
ooh, SMMU vs. big-endian, fun! Nominally we *should* support that (in as much as we set the SCTLR.E bit), but whether it's ever been tested...
<dormito>
lol. I intend to test it (more)... as soon as I get some free time, and have kgdb functional for my honeycomb (lx2160 comex+carrier board)
<arnd>
we should probably start marking it as 'depends on EXPERT' in the kernel and clarify that it's not actually recommended or expected to work in practice
<robmur01>
need moar BE distros!
<arnd>
I just checked my old emails for the last time someone asked about running big-endian arm armv7 or v8 kernels and sent fixes for it, that was 2016, and they only did it because they lost their last powerpc machine for testing a driver stack on big-endian
<maz>
I'd love a BE distro to finally reach userspace in BE guest!
<javierm>
arnd: they should get a s390x mainframe for that :P
<dormito>
I don't know. Might be a tiny bit difficult to fit an s390x in the ~ 10"x10" space I have for my honeycomb lol.
<maz>
a p/390 is what you need.
<dormito>
p/390? not familar with it: some quick searches suggest is a PCI(or ISA? can't tell yet) card with a single s/390 arch processor and other resources on board (and a microchannel expander!)?
<arnd>
dormito: there were PCI versions as well, but I think you need OS/2 as the host OS, and the CPU is probably too old to run even linux-2.4
<dormito>
interesting. I never knew there was scaled down hardware for IBMs mainframe chips.
<maz>
I *think* there was a version that you could fit in an RS6k...
<arnd>
Multiprise 3000 was the smallest one that could run Linux, but of course 31-bit support is long gone
<javierm>
arnd: I'm always amazed by your computer architecture history knowledge
<arnd>
I think some of the older ones (P/370?) were actually m68000 processors running a custom microcode to implement the 370 ISA in place of the m68000 ISA
<maz>
huh, I'd love a ucode-less 68k! or at least, one where I could implement my own crap!
<dormito>
is the docs for the uarch available?
sszy has quit [Ping timeout: 276 seconds]
viorel_suman has quit [Quit: WeeChat 3.6]
<arnd>
maz: isn't that just a coldfire? I have the vague memory of Motorola producing the same chip as a coldfire "RISC" version with little or no microcode, and the m68k "CISC" version that implemented all the complex instructions in microcode.
monstr has quit [Remote host closed the connection]
<arnd>
It's similar to how s390 millicode was implemented in the i390 ISA that is just a subset
<maz>
arnd: I had no idea coldfire had a "risc" flavor. I'll halt a look...
<maz>
but yes, I know about the millicode, now that I work with a bunch of ex-Z people... ;-)
<maz>
s/halt/have/... it's all going wrong...
cleger has quit [Remote host closed the connection]
cleger has joined #armlinux
cleger has quit [Remote host closed the connection]
guillaume_g has quit [Quit: Konversation terminated!]
<geertu>
maz: coldfire _is_ the risc flavor
<geertu>
arnd: IIRC, I tried running BE on R-Car Gen2 after 2016. Worked well, except for sh_eth that needs to be fixed for CONFIG_CPU_BIG_ENDIAN=y.
* geertu
wants a 64-bit m68k in an FPGA
<geertu>
or linux-on-litex-s390
headless has joined #armlinux
Lucanis0 has joined #armlinux
Lucanis0 has quit [Changing host]
Lucanis0 has joined #armlinux
Lucanis has quit [Ping timeout: 248 seconds]
<bjdooks>
geertu: iirc, the beagleblack worked ok bigendian and so did the xilinx stuff too
<bjdooks>
I did some work fixing atmel, I think by then someone had completely ducked our rcar-gen3 board so it never got tested
Lucanis has joined #armlinux
<bjdooks>
for a few kernel versions I was caring about arm32be
<bjdooks>
but then our client decided it was silly and stopped paying for that
Lucanis0 has quit [Ping timeout: 248 seconds]
heat has joined #armlinux
heat has quit [Remote host closed the connection]
heat has joined #armlinux
<dormito>
maz: halting and looking is fine. its HCF thats actually problematic
<geertu>
dormito: spilling HF is also problematic...
<dormito>
as in hydrogen floride? shouldn't that be pretty stable?
marc|gonzalez has quit [Quit: Leaving.]
<dormito>
oh nope. hydrogen being weird strikes again
luispm has quit [Quit: Leaving]
cbeznea has joined #armlinux
apritzel has quit [Ping timeout: 248 seconds]
cbeznea has quit [Quit: Leaving.]
cbeznea has joined #armlinux
cbeznea has quit [Ping timeout: 268 seconds]
cbeznea has joined #armlinux
headless_ has joined #armlinux
headless has quit [Ping timeout: 248 seconds]
Lucanis has quit [Quit: Leaving]
Lucanis has joined #armlinux
Guest6945 is now known as nsc
nsc has quit [Quit: Reconnecting]
nsc has joined #armlinux
nsc is now known as Guest2873
Guest2873 is now known as nsc
nsc has quit [Client Quit]
nsc has joined #armlinux
amitk has joined #armlinux
nsc has quit [Quit: leaving]
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #armlinux
hanetzer has quit [Ping timeout: 248 seconds]
hanetzer has joined #armlinux
Amit_T has quit [Remote host closed the connection]
heat has quit [Read error: Connection reset by peer]
heat has joined #armlinux
cbeznea has quit [Quit: Leaving.]
headless_ is now known as headless
apritzel_ has joined #armlinux
heat has quit [Read error: Connection reset by peer]
heat has joined #armlinux
headless has quit [Quit: Konversation terminated!]
iivanov has quit [Ping timeout: 246 seconds]
heat_ has joined #armlinux
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
sibis5 has joined #armlinux
sibis has quit [Read error: Connection reset by peer]
sibis5 is now known as sibis
haritz has quit [Read error: Connection reset by peer]