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
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
Xogium_ has joined #armlinux
Xogium has quit [Ping timeout: 248 seconds]
Xogium_ is now known as Xogium
altf2o has quit [Remote host closed the connection]
altf2o has joined #armlinux
hanetzer has quit [Ping timeout: 250 seconds]
hanetzer has joined #armlinux
heat has quit [Ping timeout: 250 seconds]
hanetzer has quit [Ping timeout: 252 seconds]
hanetzer has joined #armlinux
mraynal has quit [*.net *.split]
mcoquelin has quit [*.net *.split]
scosu[m] has quit [*.net *.split]
xdarklight has quit [*.net *.split]
m5zs7k has quit [*.net *.split]
jeeeun has quit [*.net *.split]
suzukikp has quit [*.net *.split]
ukleinek has quit [*.net *.split]
zkrx has quit [*.net *.split]
tscherer has quit [*.net *.split]
ukleinek has joined #armlinux
mcoquelin has joined #armlinux
mraynal has joined #armlinux
jeeeun has joined #armlinux
suzukikp has joined #armlinux
tscherer has joined #armlinux
m5zs7k has joined #armlinux
xdarklight has joined #armlinux
zkrx has joined #armlinux
scosu[m] has joined #armlinux
atorgue has joined #armlinux
guillaume_g has joined #armlinux
frieder has joined #armlinux
frieder has quit [Remote host closed the connection]
frieder has joined #armlinux
rvalue has quit [Ping timeout: 268 seconds]
rvalue has joined #armlinux
cleger has joined #armlinux
frieder has quit [Read error: Connection timed out]
rvalue has quit [Ping timeout: 264 seconds]
cbeznea has joined #armlinux
matthias_bgg has joined #armlinux
frieder has joined #armlinux
prabhakarlad has joined #armlinux
luispm has joined #armlinux
sszy has joined #armlinux
altf2o has quit [Remote host closed the connection]
altf2o has joined #armlinux
iivanov has joined #armlinux
rvalue has joined #armlinux
iivanov__ has joined #armlinux
iivanov__ has quit [Client Quit]
iivanov__ has joined #armlinux
iivanov has quit [Ping timeout: 268 seconds]
viorel has joined #armlinux
headless has joined #armlinux
naoki has quit [Remote host closed the connection]
naoki has joined #armlinux
apritzel has joined #armlinux
iivanov has joined #armlinux
iivanov__ has quit [Ping timeout: 246 seconds]
monstr has joined #armlinux
linusw_ has joined #armlinux
audgirka has joined #armlinux
altf2o has quit [Remote host closed the connection]
altf2o has joined #armlinux
headless_ has joined #armlinux
headless has quit [Ping timeout: 252 seconds]
chipxxx has joined #armlinux
chipxxx has quit [Read error: Connection reset by peer]
chipxxx has joined #armlinux
atorgue has quit [Ping timeout: 244 seconds]
matthias_bgg has quit [Ping timeout: 252 seconds]
DarkL0rd has joined #armlinux
matthias_bgg has joined #armlinux
headless_ is now known as headless
headless has quit [Quit: Konversation terminated!]
<linusw_>
arnd: I found a really interesting thing when working with a bug that SMP would not boot the secondary CPU with kernel-in-vmalloc...
<linusw_>
The __idmap_text_start -> __idmap_text_end will get mapped in properly at e.g. the section 0x80200000, but when the second CPU sets TTBR to this table everything dies
<linusw_>
It turn out that the memory where the page table is stored also needs to be idmapped in the section 0x80000000
<linusw_>
I just can't figure out why! I thought the MMU is just using physical memory when reading the page table, so ...
<linusw_>
Also adding to the weirdness is that this issue is only seen on LPAE, not on the classic MMU.
<linusw_>
We haven't seen this behaviour before because we always had a linear map where 0x80000000 (or 0xc0000000) was includede...
<arnd>
linusw_: my best guess is that code running on the secondary CPU is actually accessing the page table here, e.g. from a pagefault handler
<arnd>
are you running this on hardware or in qemu at the moment?
<linusw_>
arnd: I thought so too but I single-stepped in QEMU and it dies at exactly the instruction where the new TTBR is set :/
<linusw_>
arnd: qemu
<linusw_>
now that you say it I will take out my actual vexpress because this is really puzzling
<linusw_>
what happens when I set TTBR is there is no memory map whatsoever. It executes fine in physical memory until we try to switch over to virtual memory...
<arnd>
I'm not sure how single-stepping in qemu works, but if this works by running a single insn and setting a breakpoint on the next one, running into a page fault would not actually be stepped through
<linusw_>
hm
<arnd>
can you add a breakpoint on the pagefault entry?
<linusw_>
I'll try!
<linusw_>
Just need to go and order some new glasses first...
<linusw_>
Literally speaking, not figuratively :D
<ardb>
gdb will happily step into the exception handler when an exception occures
<ardb>
linusw_: if this is secondary boot, setting the TTBR should only take effect once you enable the MMU
<ardb>
if just setting TTBR causes an exception, the MMU is maybe on already?
robmur01 has quit [Remote host closed the connection]
<linusw_>
ardb: sorry I was unclear, indeed enabling the MMU is what triggers it, mcr p15, 0, r0, c1, c0, 0 in __turn_mmu_on at ~0x80200000 is what explodes.
robmur01 has joined #armlinux
<linusw_>
ardb: also nice seeing you around :)
<ardb>
linusw_: likewise!
<ardb>
so the page table walker definitely doesn't need a virtual mapping to access the page tables
<linusw_>
yeah so I think too, so I'm conflicted about what happens here...
<linusw_>
especially since it works with the classic MMU.
<ardb>
are the other paging related system registers set correctly?
<linusw_>
ardb: we just hardcode-compile the kernel to 0xf1000000 for now, I looked into fixing the runtime patching but didn't get around to doing thar
<linusw_>
that
<ardb>
but the linear map and the vmalloc area are two different things now, right?
<ardb>
for the linear map, you will still need p2v patching
<ardb>
only static kernel code and data will not longer be part of it
<linusw_>
So this is why I patch the base PHYS_OFFSET for VEXPRESS to 0x80000000 as well
<linusw_>
ardb: yeah if I want to solve it properly I guess I should fix P2V :/
<linusw_>
hardcoding the kernel virtual addresses to 0xf1000000 might be more acceptable.
<linusw_>
In a way I'm amazed disabling PATCH_PHYS_VIRT is even working but it does.
<ardb>
but those are two separate tings
<ardb>
+h
<ardb>
by moving the kernel mapping out of the linear region, you are free to choose its virtual address
<ardb>
(as long as it is covered by the vmalloc region)
<linusw_>
indeed. so I chose 0xf1000000
<linusw_>
Then there is some code in phys_to_virt/virt_to_phys to compensate, so these two always work as expected.
<ardb>
but the linear region still needs a p2v translation that is accurate for the platform
<linusw_>
Yeah I implemented that. I think ...
<ardb>
on arm64, we have __pa_symbol() for instance, which is different from __pa()
<linusw_>
hmmm
<ardb>
__pa() works on address in the linear region
<ardb>
__pa_symbol() works on symbol addressed that are part of the kernel mapping
<linusw_>
That might be a more elegant solution!
<linusw_>
So ftrace & co will use __pa_symbol instead of __pa
<linusw_>
for example
<linusw_>
what I did was just if() clauses in phys_to_virt/virt_to_phys
<linusw_>
it works but probably not the most efficient, if efficiency matters around these things
<linusw_>
I haven't gotten around to checking how much these functions are actually called, and if it is on any hotpath.
Amit_T has joined #armlinux
<ardb>
your branch happily boots in SMP mode with the last patch reverted (with LPAE)
<ardb>
booting in mach-virt with PHYS_OFFSET set to 0x40000000
<linusw_>
so my takeaway is if I use __pa_symbol() I can just switch to that everywhere the kernel-internal address space is references and leave P2C as-is ... hmmm!
<linusw_>
P2V I mean
<linusw_>
ardb: damned
<linusw_>
ardb: I hate it when my code works better than it should
<linusw_>
Oh well off to another meeting, ardb you will get to review this eventually if I figure out what's wrong...
<ardb>
excellent
torez has joined #armlinux
ywnkmn has joined #armlinux
iivanov has quit [Quit: Leaving...]
<hanetzer>
hrm. is there a mechanism for saying that this dt-bound driver must load after that dt-bound driver?
<tagr>
you typically want to do that with deferred probing, which is not specific to DT
m5zs7k has quit [Ping timeout: 260 seconds]
elastic_dog has quit [Ping timeout: 260 seconds]
m5zs7k has joined #armlinux
heat has joined #armlinux
<hanetzer>
blerg. thing is, the two things are clock controllers, pretty early on
balrog has quit [Ping timeout: 268 seconds]
balrog has joined #armlinux
ywnkmn has quit [Quit: ywnkmn]
chipxxx has quit [Ping timeout: 260 seconds]
<robmur01>
fw_devlink should take care of clock dependencies that are described in DT (i.e. if one consumes some clock provided by the other)
<bjdooks>
you can return an EPROBEDEFFER and havei t come back the next round and try again... and again...
<hanetzer>
bjdooks: I think I've seen that approach... hrm.
<hanetzer>
robmur01: fw_devlink seems to be a kernel cmdline option? (btw what I currently have either just 'doesn't work' or 'works' but flips a div0 bug first)
<robmur01>
well, it's a whole dependency mechanism really, the command line parameter just turns it on and off in varying degrees
<bjdooks>
hanetzer: it's the best thing, esepcially as stuff can get loaded as modules, etc
<hanetzer>
bjdooks: 'it' being fw_devlink or the eprobe defer mechanism?
<bjdooks>
defer
<hanetzer>
tbh, I'm not even sure the purpose of the sp804's on this thing; all the peripherals pull from clocks in the main clock controller, it has the cp15 timer. only the 804's are from the secondary one.
audgirka has quit [Remote host closed the connection]
justache is now known as justHaunted
suzukikp has quit [Quit: WeeChat 3.5]
suzukikp has joined #armlinux
sakman has quit [Quit: Leaving]
cleger has quit [Quit: Leaving]
monstr has quit [Remote host closed the connection]
<robmur01>
the __get_free_pages() interface has always been a bit of a WTF to me... maybe it made more sense 30 years ago?
<CounterPumpkin>
should this driver even be calling __get_free_pages() or is there a more modern way to do this? It needs to implement half an iommu for... reasons, and I'm currently trying to debug why it's not working with a newer hardware IP of the iommu
plappermaul has joined #armlinux
<CounterPumpkin>
looks like one issue is that it shoves dma_addr_t inside of this unsigned int *, which... no.
<robmur01>
yeesh, the virt_to_phys/dma_sync abuse is even worse - in that particular instance I'd be inclined to replace {src,dst}_mmu_pages with proper coherent DMA buffers
<CounterPumpkin>
Guess I need to do some reading up on how DMA works on Linux if I want to clean this up, but also, nobody even really uses this driver so I don't know why I'm bothering fixing it for rk356x
sakman has joined #armlinux
frieder has quit [Remote host closed the connection]
<CounterPumpkin>
Okay I'm not going to touch this code because I don't understand it, and it seemingly needs a large-ish refactor.