ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] |
kwilczynski has joined #armlinux
Pali has quit [Ping timeout: 272 seconds]
TheCoffeMaker has quit [Ping timeout: 252 seconds]
TheCoffeMaker has joined #armlinux
prabhakarlad has quit [Ping timeout: 246 seconds]
CrashTestDummy2 has joined #armlinux
CrashTestDummy3 has quit [Ping timeout: 272 seconds]
<arnd> krzk: I'll take care of it today if olofj hasn't already
<arnd> tlwoerner, broonie: I think it's even closer than v6/v7, since both architectures are still continuing
<arnd> the initial v9.0 is defined as v8.5 plus SVE2, and then v9.1 is v8.6 plus SVE2 etc
<arnd> later v9.x releases gain additional features that are not part of v8.x
audgirka has joined #armlinux
guillaume_g has joined #armlinux
iivanov has joined #armlinux
sszy has joined #armlinux
sszy has quit [Remote host closed the connection]
sszy has joined #armlinux
prabhakarlad has joined #armlinux
<geertu> arnd: Can you please take the renesas-fixes PR, too? thx!
<geertu> broonie: Looks like several ASoC commits ended up on the spi/for-next branch
xdarklight has quit [Ping timeout: 252 seconds]
rfs613_alt has joined #armlinux
libera- has joined #armlinux
rfs613 has quit [Ping timeout: 252 seconds]
Pali has joined #armlinux
matthias_bgg has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 255 seconds]
<mort> if I have a stack trace like the one in, can I translate the function names + address into a source location somehow?
djrscally has joined #armlinux
Crassus has joined #armlinux
<punit> Assuming you had not figured this out already ;-)
Pali has quit [Ping timeout: 245 seconds]
<punit> Ah I spoke too soon - for what you're looking ./scripts/faddr2line (in the kernel source tree) is better
<mort> faddr2line looks ideal. I have to figure out where yocto puts a non-stripped kernel then
libera- is now known as xdarklight
xdarklight has joined #armlinux
xdarklight has quit [Changing host]
CrashTestDummy2 has joined #armlinux
CrashTestDummy3 has quit [Ping timeout: 258 seconds]
djrscally has quit [Ping timeout: 272 seconds]
audgirka has quit [Quit: Leaving]
djrscally has joined #armlinux
Crassus has quit [Ping timeout: 268 seconds]
apritzel has quit [Quit: Leaving]
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
torez has joined #armlinux
arnd_ has joined #armlinux
TheCoffeMaker_ has joined #armlinux
kristinam has joined #armlinux
broonie_ has joined #armlinux
nsaenz_ has joined #armlinux
kbingham_ has joined #armlinux
gcl_ has joined #armlinux
gpiccoli_ has joined #armlinux
ajb-lina- has joined #armlinux
mripard_ has joined #armlinux
nsaenz has quit [*.net *.split]
torez has quit [*.net *.split]
TheCoffeMaker has quit [*.net *.split]
kbingham has quit [*.net *.split]
gcl has quit [*.net *.split]
kristina1 has quit [*.net *.split]
mripard has quit [*.net *.split]
ajb-linaro has quit [*.net *.split]
shailangsa has quit [*.net *.split]
broonie has quit [*.net *.split]
arnd has quit [*.net *.split]
gpiccoli has quit [*.net *.split]
arnd_ is now known as arnd
<broonie_> geertu: ack
broonie_ is now known as broonie
torez has joined #armlinux
rfs613_alt is now known as rfs613
Shailangsa_ has joined #armlinux
rbutler1728 has joined #armlinux
<ukleinek> broonie: the spi-imx IP has some strange properties when the hardware-CS is used. One of the (few) advantages is that it could natively support SPI_CS_WORD. I assume I could do mode_bits |= SPI_CS_WORD if all CS are native and when some CS uses a GPIO don't advertise it. Is there a better option?
guillaume_g has quit [Quit: Konversation terminated!]
kbingham_ is now known as kbingham
<broonie> ukleinek: Hrm, not really ATM. It's not like there's a software fallback you can turn on.
<arnd> tlwoerner: another follow-up: After I saw the SME spec being public today, I looked up the ARMv9 definition at, and it turns out that all ARMv9 features are optional, including SVE2
<arnd> The only hard requirements for something to be called ARMv9.0 instead of ARMv8.5 are:
<arnd> - there cannot be aarch32 mode in EL1 or higher
<arnd> - if an embedded trace thingy exists, it has to be the new ETE instead of the old but almost identical ETM
<tlwoerner> arnd: interesting. i was expecting a longer list ;-)
<arnd> that is the list of all the features that are common between the two, and again most of these are completely optional (I have not checked if anything is mandatory at all)
<arnd> If I interpret it right, it seems that the main thing is that you have to be compliant with the corresponding armv8.x spec to be allowed any of the armv9.x features
<arnd> while within armv8.x it appears that you can always mix and match these, by picking e.g. an armv8.5 feature into an armv8.2 core that is not armv8.3 compliant
<arnd> though I have no idea how that would be enforced in the end. E.g. if some architecture licensee wanted to have an armv8.5 core with aarch32-el1 and sve2, would arm stop them from shipping it, or would they just not be able to call it armv9?
<tlwoerner> Q: Secure virtualization was added in Armv8.4-A. Would an Armv8.1-A processor be allowed to implement it?
<tlwoerner> A: No. An Armv8.1 processor must implement the mandatory features of Armv8.1 and may implement features from Armv8.2-A. But it is not allowed to implement features from Armv8.3, Armv8.4, or later versions, unless a special concession has been made.
<arnd> ah, that explains a lot. So a lot of CPU cores are based on "special concession" then, rather than following the architecture ;-)
<tlwoerner> also: "There is no field that reports whether a processor is Armv8.1-A. Instead, software reads the feature fields for the mandatory 8.1-A features, and if they all present, the processor is compliant with Armv8.1-A."
<arnd> And I guess in case of Apple Silicon, the current generation declares itself as ARMv8.5, and it would actually be compliant with ARMv9.0 as well (since it has neither aarch32 nor etm, and none of the optional features of armv9), but it's also not actually compliant with v8 .5 or v9.0 because it lacks a couple of mandatory features like nVHE virtualization
<arnd> tlwoerner: it would be nice to have a table of feature bits listed as mandatory/optional/invalid per architecture level, but I don't think that exists. Have you seen that anywhere?
<tlwoerner> arnd: not yet
<arnd> or even better, a list of which features are actually present on each of the implementations we know of
sszy has quit [Quit: - Chat comfortably. Anywhere.]
geertu has quit [Ping timeout: 256 seconds]
headless has joined #armlinux
geertu has joined #armlinux
<broonie> Given all the optional features I'm not sure how useful the ARMv8.x gradations are in practice. A matrix/database of features in chips would definitely be useful though.
Shailangsa_ has quit [Ping timeout: 252 seconds]
Pali has joined #armlinux
mwalle has quit [Ping timeout: 240 seconds]
nsaenz_ has quit [Remote host closed the connection]
nsaenz_ has joined #armlinux
shailangsa has joined #armlinux
<marex> subnodes, /axi@0 and /axi , is that actually valid ?
<robher> marex: Valid? Yes. Logical? No
<marex> robher: do those two things represent the same bus then or not ?
<robher> marex: It seems unlikely that the gic is sitting in the middle of the address range of the
<robher> ... 'axi' bus.
<marex> robher: the reason I'm looking into it is because u-boot apparently treats a DT with /axi@0 and /axi as if they were the same node , which is a bug, I just don't know where yet, whether in u-boot, libfdt, or the DT
<marex> robher: so, I wanted to know whether the DT is valid, now I think I have my answer to that part
<robher> Though I vaguely remember that some GIC implementations with cores, have tie off signals for the address and that would be decoded before anything else.
<marex> robher: the zynqmp should be fairy standard arm64 machine, I dont expect anything weird like that, but I can ask Michal about it on Monday, that's fine
<robher> marex: I think axi@0 should be axi@f9010000 or axi@f9000000 to limit the overlap.
<marex> robher: ah, I think I know what the gic node might be all about, the zynqmp has 32bit cortexR in it too, so maybe that is why it is separate
<marex> but renaming the axi to axi@something doesn't solve the problem I am after, it just hides one of the symptoms
headless_ has joined #armlinux
headless has quit [Ping timeout: 268 seconds]
<geertu> marex: Does the CR8 has its own GIC on zynq?
headless_ is now known as headless
<marex> geertu: it is cr5
<marex> geertu: it probably has nvic though, hum
CrashTestDummy3 has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 246 seconds]
Crassus has joined #armlinux
torez has quit [Remote host closed the connection]
mwalle has joined #armlinux
headless has quit [Quit: Konversation terminated!]
shailangsa has quit [Remote host closed the connection]
CrashTestDummy2 has joined #armlinux
iivanov has quit [Remote host closed the connection]
CrashTestDummy3 has quit [Ping timeout: 255 seconds]
macromorgan has quit [Killed ( (Nickname regained by services))]
macromorgan has joined #armlinux
rbutler1728 has quit [Read error: Connection reset by peer]
shailangsa has joined #armlinux
djrscally has quit [Ping timeout: 252 seconds]
matthias_bgg has quit [Ping timeout: 252 seconds]
Crassus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
matthias_bgg has joined #armlinux