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
sudeepholla__ has quit [Ping timeout: 248 seconds]
sudeepholla__ has joined #armlinux
elastic_dog has quit [Ping timeout: 260 seconds]
elastic_dog has joined #armlinux
robmur01 has quit [Ping timeout: 272 seconds]
mmind00_ has joined #armlinux
mmind00 has quit [Ping timeout: 272 seconds]
robmur01 has joined #armlinux
elastic_dog has quit [Ping timeout: 272 seconds]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #armlinux
elastic_dog has joined #armlinux
Lucanis has quit [Read error: Connection reset by peer]
Lucanis has joined #armlinux
alpernebbi has quit []
alpernebbi has joined #armlinux
cbeznea_ has joined #armlinux
cbeznea has joined #armlinux
cbeznea_ has quit [Ping timeout: 260 seconds]
cbeznea_ has joined #armlinux
cbeznea has quit [Ping timeout: 272 seconds]
amitk has joined #armlinux
punit has quit [Remote host closed the connection]
punit has joined #armlinux
cbeznea_ has quit [Quit: Leaving]
prabhakar has quit [Ping timeout: 255 seconds]
ezulian has joined #armlinux
mraynal has quit [Remote host closed the connection]
iivanov has joined #armlinux
mraynal has joined #armlinux
monstr has joined #armlinux
bjoto has quit [Ping timeout: 245 seconds]
mvaittin has quit [Ping timeout: 258 seconds]
monstr has quit [Ping timeout: 272 seconds]
bjoto has joined #armlinux
monstr has joined #armlinux
mvaittin has joined #armlinux
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
iivanov has quit [Remote host closed the connection]
<biju>
geertu: Ok I have provided feedback to the patch thread.
sszy has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
gclement has joined #armlinux
paulbarker has joined #armlinux
luispm has joined #armlinux
ezulian has quit [Quit: ezulian]
ezulian has joined #armlinux
nsaenz_ has joined #armlinux
nsaenz has quit [Ping timeout: 255 seconds]
Amit_T has joined #armlinux
nsaenz_ has quit [Remote host closed the connection]
nsaenz has joined #armlinux
<ajb-linaro>
do all Neoverse derived cores imply ARM SMMU's and GICs or do some SoCs ship with different stuff?
<robmur01>
there's no requirement, but off-hand I can't point at an example of anyone licensing Neoverse CPUs without also taking the matching generation of GIC/CMN/SMMU system IP
<robmur01>
Ah, maybe Marvell - looks like the OCTEON 10 stuff puts Neoverse-N2 with at least their own interconnect, not sure whether they'd still be using the ex-Cavium GIC/SMMU implementations as well
<maz>
I hope not. this thing was a train wreck.
* maz
eyes the TX1 that's sitting right next to him...
prabhakarlad has quit [Quit: Client closed]
<maz>
robmur01: or maybe you were thinking of the BCM-designed versions?
<robmur01>
maz: yeah, TX2 plus the assumption that they were probably iterating on those for TX3 at some point. Thanks (not) for reminding me that TX1 exists :(
<robmur01>
I'd say you're about 3 weeks early for horrors like that...
<maz>
huh
<maz>
at some point, I'll need to pick your brain about getting the SMMUv2 up on running on this crap -- the DT is wrong, and the ACPI tables are worse. but hey, it boots mainline...
<bjdooks>
out of interest, anyone know what handles the secondary core startup for the qemu aarch64 virt machine? I know it seems to be writing into the start of sec-ram so i'm assuming there's some sort of microbiois / startup code that is doing a sit in WFI loop awaiting the command to go
<Guest8843>
bjdooks: I thoguht that always used PSCI?
Guest8843 is now known as mrutland
mrutland is now known as Guest4025
<robmur01>
maz: oof, TX1 DT hacking... according to my local branch it's now almost 7 years since I last went there :)
Guest4025 is now known as mrutland
mvaittin has quit [Ping timeout: 252 seconds]
<maz>
robmur01: I'm not surprised. but if you push that branch out somewhere, I can take it for a ride on this box (MT30-GS0 relocated in a PC enclosure, surprisingly silent...)
<bjdooks>
mrutland: when running tf-a the tf-a takes the psci and writes to magic sram area
<robmur01>
bjdooks: I think that's your answer then - presumably QEMU sees that write as a signal to start the CPU. The beauty of being a "virt" machine is that you're not constrained to always behave like physical hardware would have to :)
<bjdooks>
yeah, was wondering if that's a physical driver, or just firmware it is loading would be nice to know
<robmur01>
If you're already in TF-A, then anything below that is the "hardware" of QEMU's implementation.
<robmur01>
I guess you could pretend there's an invisible MCU polling the SRAM location and releasing the main CPU(s) from reset in response - that would be one physical equivalent
AlexM_ has quit [Quit: Connection closed for inactivity]
<arnd>
robmur01: I think I hadn't realized that octeon10 is derived from thunderx/cn8xxx/cn96xx/cn98xx rather than armada7k/cn91xx, but I suppose that makes sense as they have pretty much killed off all the other armada (and vulcan) derivatives
<robmur01>
arnd: TBF I don't know if it's "derived" as such or something completely new yet again, just inferring they're still doing at least *some* degree of in-house stuff since "XCalibur Interconnect" doesn't sound like Arm CMN
<arnd>
robmur01: I checked the public sdk sources that groups cn92xx/cn96xx/cn98xx into the same family as cn10k, and they all use the same device drivers. The main difference seems to be finally killing off their custom cpu cores that they had inherited from thunderx1
<arnd>
I haven't actually seen any of those in products, but I've seen plenty of cn91xx based machines mentioned, and those are just new revisions of armada7k/8k (cortex-a72 based) that have nothing in common with the cn92xx despite both being named "Octeon TX2" in marketing material
<arnd>
and of course neither of the two Octeon TX2 families have anything in common with ThunderX2, but I think that is widely known
<robmur01>
Well, AFAIK Octeon TX2 is the "real" ThunderX2 that was in development when they acquired Vulcan and decided to release that as cn99xx "ThunderX2" instead
<arnd>
right, that was my conclusion as well. The cn92xx/96xx/98xx material just mentions it's an Armv8.2 with 66K L1I$ and 41 L1D$, but that is clearly different from ThunderX, ThunderX2 and any Cortex/Neoverse cores
<arnd>
and of course they have the nitrox crypto unit that comes from the mips octeons
nsaenz_ has quit [Remote host closed the connection]
nsaenz has joined #armlinux
mvaittin has joined #armlinux
mvaittin has quit [Ping timeout: 258 seconds]
matthias_bgg has quit [Ping timeout: 245 seconds]
prabhakarlad has quit [Quit: Client closed]
<broonie>
What's the command to generate a minified defconfig again?
<Xogium>
broonie: mmake tinyconfig ?
<Xogium>
err make
<broonie>
I mean a reduced config from your current .config
<Xogium>
ah huh
<Xogium>
like a defconfig based on your .config ? make savedefconfig I think
<javierm>
broonie: if building on the target, I usually do `make localmodconfig`
<Xogium>
ah, yeah that works
<Xogium>
I wasn't sure in what sense broonie meant reduced
<javierm>
broonie: if is a DT platform, there's also ./scripts/dtc/dt_to_config
<Xogium>
holy damn I never heard of that script before
<Xogium>
wait so it builds a kernel with *only* the drivers you would need ?
<broonie>
That's not it either, the goal is to not include options that are at default so the comfig is as physically small as possible.
matthias_bgg has joined #armlinux
<Xogium>
and here I was, strugging to take out all the stuff I wouldn't ever need from the multi_v7_defconfig...
<Xogium>
*struggling
<Xogium>
broonie: sounds like you want a defconfig then, so my make savedefconfig seems to be the right thing ?
<javierm>
Xogium: yeah, what it does basically if identify all the compatible strings in your DTS nodes and then find the files where those are defined and from there get the Kconfig symbols
<Xogium>
defconfig only saves the config options that are not the default
<javierm>
Xogium: I just learned about that script recently thanks to geertu :)
<Xogium>
javierm: well... I guess one learns something new every day. So that would completely remove things that are useless like sata in my case... Nice
<broonie>
savedefcnfig that's it - thanks!
tleb has joined #armlinux
<Xogium>
broonie: np :)
<Xogium>
well, dang. This will save me a LOT of time trying to figure out what I need or don't need in a config... And still making the build as minimal as possible
* Xogium
was trying to master tinyconfig and just giving up at the complexity each and every time, going back to taking huge chunks out of the multi_v7_defconfig
<Xogium>
2016... Wow
matthias_bgg has quit [Quit: Leaving]
heat has quit [Remote host closed the connection]
heat has joined #armlinux
<Xogium>
javierm: hmm I don't quite get how that script works here... It doesn't seem to figure out a lot of things on my dts file and claim nothing has a valid config ?
rgallaispou has quit [Read error: Connection reset by peer]
iivanov has quit [Remote host closed the connection]
<Xogium>
geertu: what would you recommand, start with tinyconfig or take multi v7 ?
<Xogium>
to get the most of that script
<Xogium>
because this seems to not do like disabling all configs you might not need
<Xogium>
this makes a kconfig fragment to be applied on your existing config
<Xogium>
the dt_to_config thing
<geertu>
Xogium: I started from the multi configs, a long time ago.
<geertu>
Remove support for all SoCs you don't care about.
<geertu>
That's the easy part. The hard part is removing all the other stuff you don't need.
<Xogium>
this is exactly what I'm trying to reduce. I was hoping dt_to_config would help me doing this
<geertu>
These scripts are meant to add hardware support, starting from a pure software policy config.
<Xogium>
reducing the kernel starting with such a big defconfig takes a long time and a lot of trial and error for me at least. No idea for others ;)
gclement has quit [Ping timeout: 258 seconds]
<Xogium>
and it's rather tiring to have to do it with every single board / project you work on
<geertu>
You can start from tinyconfig and add hardware support (and will have to fight with hardware support options that depend on another symbol that is not yet enabled).
<geertu>
You still have to manually add pure software things, like EXT4, NFS, IPv6, ...
<geertu>
When making a config for a new board, I usually start from a config for an old board.
<geertu>
Remove hardware support for the old board, add hardware support for the new board.
<geertu>
Yes, it sounds simpler than it is :-(
<geertu>
All (most of) my boards use a Debian nfsroot, so most of the config is very similar.
matthias_bgg has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
<Xogium>
geertu: I mean I guess I'm lucky in the sense that these days I generally stuck to stm32mp based boards... But mp15 vs mp13, y'know ?
<Xogium>
and kernel config is still rather overwhelming after 6 years of toying with boards
<Xogium>
I guess, I wish that it was a matter of parsing out the dt, finding all that the hardware needs to work and taking out the whole rest of the hardware that is not needed
<Xogium>
;)
<Xogium>
I'd be fine dealing with adding ext4 and nfs and overlayfs and whatever really
<Xogium>
it's just the taking out the stuff I never need part that is really a lengthy process, even more so if you use a screen reader and have to listen to ever yhelp entry being read and that takes you at least 10 or 30 seconds possibly more on each option
<Xogium>
*every
<Xogium>
maybe I should ask Nicolas Pitre how he does it ^^
<Xogium>
it's ironic really considering my tts reads text at 500 wpm
iivanov has joined #armlinux
nsaenz has quit [Ping timeout: 255 seconds]
jclsn has quit [Ping timeout: 258 seconds]
jclsn has joined #armlinux
silurian_invader has quit [Ping timeout: 255 seconds]
headless has joined #armlinux
nsaenz has joined #armlinux
nsaenz has quit [Remote host closed the connection]
nsaenz has joined #armlinux
ezulian has quit [Ping timeout: 255 seconds]
silurian_invader has joined #armlinux
luispm has quit [Ping timeout: 255 seconds]
matthias_bgg has quit [Quit: Leaving]
prabhakarlad has joined #armlinux
biju has quit [Quit: Konversation terminated!]
iivanov has quit [Read error: Connection reset by peer]
Amit_T has quit [Remote host closed the connection]
<krzk>
ukleinek: no, it is not equivalent. base works for known commits. You cannot use it for work in the fly.
<krzk>
Plus it makes sense only for Kernel test robot, because for example my repo for maintained subsystems will not know these IDs... (unless that's the point :) )
headless has quit [Quit: Konversation terminated!]
<ukleinek>
krzk: well, if it's a patch that was just sent before, you can find it.
<ukleinek>
..ooOO(would be nice if you could search for a patch by patch-id on lore.k.o)