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
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
sszy has joined #armlinux
geertu has quit [Quit: leaving]
geertu has joined #armlinux
kevery1 has joined #armlinux
kevery has quit [Ping timeout: 240 seconds]
kevery1 is now known as kevery
milkylainen has joined #armlinux
kevery1 has joined #armlinux
kevery has quit [Ping timeout: 248 seconds]
kevery1 is now known as kevery
mort has joined #armlinux
sudeepholla has joined #armlinux
sudeepholla has quit [Ping timeout: 276 seconds]
matthias_bgg has joined #armlinux
kevery1 has joined #armlinux
kevery has quit [Remote host closed the connection]
kevery1 is now known as kevery
bencoh_ has joined #armlinux
bencoh_ has quit [Changing host]
bencoh_ is now known as bencoh
kevery1 has joined #armlinux
kevery has quit [Ping timeout: 272 seconds]
kevery1 is now known as kevery
<ukleinek>
Misanthropos, narmstrong: I have fixed the serial issue on oxnas where I first had to boot the vendor linux to be able to use the console from userspace
psydroid has joined #armlinux
<narmstrong>
ukleinek: what was the issue ?
<ukleinek>
Misanthropos, narmstrong: The issue was not some baudrate calculation or fifo stuff but there is a bit in the sys-ctrl block to enable the irq
<narmstrong>
ukleinek: I can't control the groups.io spam... and I don't have the mail in the pending list
<ukleinek>
narmstrong: does this have any consequences for me? Can I help with a bounce?
<mwalle>
mh, I have a device (vivnate gpu, fwiw) behind the SMMU, in theory this device should be capable of doing 40bit dma addressing. but it might be the case that the SoC has only 32bit of address lines connected to this device. Is there a way to specify this in the device tree? there is the dma-ranges property but this appears to be per bus (and other dma-capable devices work just fine)
<narmstrong>
ukleinek: I will ask support to unflag you, but I can see the mail via the arm-linux ML anyway
<arnd>
mwalle: if the 32-bit limitation is a bug in the GPU rather than the way it is hooked up to the system, I would add a quirk to the GPU driver to make it not ask for a 64-bit mask at probe time when dealing with the broken GPU
<arnd>
mwalle: which SoC is this?
<mwalle>
arnd: ls1028a, but accoring to the reference manual the imx8mm and imx8mq also have a "32bit address bus"
<arnd>
mwalle: if the bus is 32 bit (rather than the device), then that bus should be annotated with the correct dma-ranges property
<mwalle>
arnd: and if its not? because there is code to actually program the internal MMU of the GPU with additional 8bit, thus resulting in a 40bit address
<arnd>
often the people working on the device tree representation don't actually have access to the hardware specification, so it's possible that the chip has multiple physical buses with different constraints that are all represented with a single node in DT
<mwalle>
arnd: ok, but if only the GPU is attached to that bus via 32bit? then it would be a driver quirk?
<arnd>
mwalle: isn't this an AXI bus interface? AFAIU you can't "attach" a device to this using only 32 bits of addressing, since the address is transferred in data packets like on PCIe. In this case it would be the device sending truncated addresses
<arnd>
maybe there are even some chicken bits you can set in the GPU to turn on 64-bit addressing?
<mwalle>
arnd: yes its an axi bus, ok, good to know
<mwalle>
arnd: yep, i was told that 40bit adressing is only possible after enabling the internal MMU
<mwalle>
which in turn needs a DMA-capable buffer (with 32bits then)
<arnd>
that sounds like the GPU internally uses 32-bit addressing, and uses the MMU to map those to 40 bit addresses on the bus.
<arnd>
which in turn means that the driver should set its DMA mask depending on whether it uses the MMU or not
<mwalle>
arnd: ok, so the dma mask can be changed after enabling the MMU?
<arnd>
that depends on how the driver is written.
<arnd>
actually I'm not sure how this is normally represented when the MMU is a regular SMMU instance, rather than a custom IOMMU that is part of the GPU itself
<arnd>
mwalle: does the driver just use the normal dma-mapping interfaces to do DMA, or does it use the IOMMU interface to have application specific IOMMU contexts?
<arnd>
mwalle: I see drivers/gpu/drm/etnaviv/etnaviv_iommu{,2}.c has code to deal with a custom IOMMU.
<mwalle>
arnd: that is the internal iommu (which maps the internal 32bit address to an external 40bit address, as you've guessed), which is connected to the SMMU, all allocations are done via dma_alloc_wc() (or similar)
<arnd>
ah, ok. So from the perspective of the dma-mapping interfaces and the SMMU, the device can already access the entire 40 bit address space, which is what the DT should then describe.
<mwalle>
(that of_dma_configure() doesn't really work there, though, i needed to move that into the _probe())
<mwalle>
arnd: as far as i understand it, you have to enable the MMU first, which is done via a command buffer which in turn needs a dma capable buffer, so yes there seems to be chicken egg problem
<arnd>
mwalle: can you allocate that command buffer using GFP_DMA or GFP_DMA32?
<arnd>
I meant using the streaming API: kmalloc(, GFP_DMA), followed by dma_map_single()
<mwalle>
arnd: ahh, I'll try that
* mwalle
is outing himself as a dma newbie :p
<mwalle>
arnd: regarding the 40bit mask, I though this is the way to tell that the device can do 40bit addressing?
<arnd>
it's a two way handshake: the DT describes what the bus can do, and the driver uses dma_set_mask{,_and_coherent}() to tell the kernel what it can address, the actual mask you get in the end is the intersection of the two
<arnd>
if the driver writes to dev->dma_mask itself, it bypasses this process
<arnd>
At one point we changed all manual assignments of dma_mask to 'dma_coerce_mask_and_coherent)_
<mwalle>
arnd: ah, there is this commit 1a866306e0fbf3ca which changes dma_set_mask_and_coherent() to setting the dma_mask itself
<arnd>
' to annotate the fact that this is a bad thing of the driver to do, in the hope that new drivers would not attempt it
<arnd>
ah, I didn't notice that it sets both the initial mask, and then calls of_dma_configure().
<arnd>
this is not wrong then, it's just strange to set it to 40bit immediately before setting to the correct value
<mwalle>
arnd: i still wonder where the 40bit would come from if its not set by the driver
<mwalle>
i mean the bus (or maybe the iommu?) will set it to 64bit/48bit (the latter is what the iommu can do)
<arnd>
no wait, this still looks wrong. The code has changed not that long ago, and I keep thinking of the old version
<arnd>
dma_set_coherent_mask() only assigns dev->dma_coherent_mask value these days, and of_dma_configure() sets dev->bus_dma_limit
<arnd>
mwalle: I wonder if you could just start out with dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32)) then
<arnd>
and extend that to 40 bits after you have set up the internal IOMMU
<mwalle>
arnd: that should hopefully be an easy test, let me see
<arnd>
If I got things right, that should work with modern kernels, and correctly reflect what the hardware and the driver can do
kevery1 has joined #armlinux
kevery has quit [Ping timeout: 256 seconds]
kevery1 is now known as kevery
<mwalle>
arnd: thanks for the pointers and the explanations btw
monstr has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
<biot>
hi all
<biot>
where does the ATF usually live in memory?
<Xogium>
I'd say it depend on what SoC you have
<biot>
(and is it generally U-Boot that installs it?)
<biot>
Xogium: well what's a common case?
<Xogium>
ATF is the first thing that runs, aside from your board's rom
<Xogium>
before u-boot runs
<Xogium>
ATF is the first stage bootloader
<biot>
aha, so is it usually built into the SoC, not loaded from flash?
<Xogium>
typically runs on very minimal hardware, and only what the SoC has internally available. For example here on the stm32mp157c I work on, the ATF can only run in the internal sram
<Xogium>
and only max 256 kb
<Xogium>
nup the rom of the SoC searches for the ATF at a very specific position on the storage
<Xogium>
the ATF initializes all of the external peripherals, ram, etc. and then the second stage bootloader runs
<biot>
hmm, sounds like I need to read up on the ATF spec some more
<biot>
had no idea it did all that
<Xogium>
you ever used u-boot with spl ?
<biot>
spl?
<Xogium>
yeah
<biot>
not sure what that is
<Xogium>
on board that doesn't have ATF, a lot of them use this instead
<Xogium>
minimal u-boot that gets loaded by the rom, and does the rest of hardware init
<Xogium>
before switching to full u-boot
<mwalle>
Xogium: you could skip bl1 and bl2 and just load bl31 (from uboot spl for example)
<Xogium>
but I personally prefer calling them fsbl/ssbl
<Xogium>
really ? I wasn't aware
<biot>
mwalle: those are ATF stages, right?
<mwalle>
biot: yes
<Xogium>
at the risk of starting a flames war ;) but what are your thoughts on how ATF + bootloader should be handled ?
<mwalle>
Xogium: iirc imx8m and rk3399 does it that way
<mwalle>
Xogium: just skip ATF *gg if you don't need any secure stuff ;)
<Xogium>
that is, should u-boot wrap around ATF, or ATF wrap around u-boot, should they keep separate ?
<mwalle>
my board loads bl31 (optionally), so its bootrom -> u-boot spl -> uboot
<Xogium>
haha I wish. The only reason I use ATF is because I use barebox as bootloader, and it can't be used as fsbl on stm32mp1… yet ? Not sure if it will ever be able
<Xogium>
I didn't fancy building u-boot spl on top of it all, ant ATF seemed like the quickest solution
<mwalle>
what I'm still missing is PSCI though
<biot>
but ATF is not optional surely? I came across it because PSCI needs it for booting all CPUs, idle etc
<mwalle>
biot: well u-boot could also implement PSCI and for SMP one could also use spin tables
<mwalle>
so yes, NXP is telling me AT-F is mandatory but my board runs just fine in mainline linux without it
<biot>
aha, so U-Boot has an ATF implemenation, interesting
<biot>
(not that it helps me, I've got a vendor U-Boot on my hands of course)
<mwalle>
biot: no uboot might have a PSCI implementation
<biot>
mwalle: but that means being on the receiving end of PSCI's SMC calls right? so that's an ATF task?
jlinton has joined #armlinux
<mwalle>
biot: whats the split between PSCI and ATF task?
<Xogium>
yeah it all depends what you need
<Xogium>
or if you're like me and don't feel like dealing with u-boot because you find it a real mess
* Xogium
hides
<Xogium>
holy jeez, what a lag
<biot>
mind you I didn't know ATF existed until this morning
<mwalle>
for the ls1028a soc (which barely has any power saving control and even less on my board..) its just poweroff and reset which for the PSCI calls implemented in u-boot
<biot>
but AFAICS the PSCI calls are SMC calls into EL3, received/handled by ATF
<biot>
ATF being the EL3 firmware
<mwalle>
biot: or any other software which runs in EL3
<biot>
so I guess a bit of leftover U-Boot could do it
<mwalle>
biot: correct
<mwalle>
PSCI reserves some memory (or uses the [secure] on-chip memory) for its code page
gcl_ has quit [Remote host closed the connection]
<mwalle>
which means you could replace that code page and you'd end up in EL3, but I don't care about secure world (unless I use the bl31)
<mwalle>
main reason I don't use atf for now is that ls1028a support it is not in mainline atf.. and I don't want do use some crappy vendor code
<arnd>
biot: TF-A (formerly known as ATF) is probably the most common open-source EL3 firmware, but some SoC vendors have their own thing instead. Whatever runs in EL3 is what provides the PSCI interfaces to EL1 (technically PSCI can also come from EL2 if you have a hypervisor).
<arnd>
If u-boot itself is started in EL3 mode, it can provide a PSCI implementation, but that doesn't make it ATF
<biot>
right
<arnd>
biot: are you asking because of the EN7523 here, or some other chip?
<biot>
arnd: yeah, the EN7523 problem :)
<arnd>
and I assuem the situation is that you have a u-boot port and need PSCI, but you don't have a TF-A port?
<biot>
the problem is the vendor has that text offset hardcoded in the Makefile, which won't fly anymore in recent mainline
<biot>
and also has this in the dts:
<biot>
compatible = "blah";
<biot>
atf-reserved-memory@80000000 {
<biot>
no-map;
<biot>
};
<biot>
reg = <0x80000000 0x40000>;
<arnd>
ok, but is it actually atf running at that location?
<biot>
so it's clear why they set the offset to 0x88000
<biot>
that I don't know, I've got only this dts stanza + the fact that PSCI version call hangs if that text offset isn't there
<arnd>
biot: do you have the u-boot sources available online somewhere?
<biot>
I'm not 100% sure that's the exact version running on the board, but it's what I got
<biot>
there's an atf blob in there as well
<arnd>
right, I see ./unopen_img/en7523/atf/bl31.bin. From the strings in there, I'm guessing it's their own thing. I have not looked at TF-A sources, but this looks mtk specific:
<ukleinek>
narmstrong: do you consider your feedback a stopper for taking the oxnas patch? My idea was to just do what is currently possible with the mainline drivers
<biot>
nod, I noticed those
amitk has quit [Ping timeout: 245 seconds]
<arnd>
"u-boot-2014.04-rc1" also sounds like it's a bit outdated ;-)
<arnd>
and of course they did not include the git history
<biot>
it's more recent than 2011, which is somehow the common case :(
<narmstrong>
ukleinek: as is it's non functional, sooo
<biot>
arnd: anyway hence my question -- it looks to be at the start of memory, but where do other vendors put it usually?
<narmstrong>
ukleinek: I'll take it if you remove the comments about the missing bits and move them to a cover letter
<arnd>
biot: I wonder if that was the first u-boot that runs on 64-bit arm then
<narmstrong>
ukleinek: because yes technically the DT is valid against the platform bindings
torez has joined #armlinux
<arnd>
biot: fwiw, the u-boot tree is based on upstream commit e4b87e5b1d ("Merge branch 'master' of git://git.denx.de/u-boot-nand-flash")
<biot>
arnd: not sure if I'll get to port U-Boot as well for them
<arnd>
biot: I'm sure it helps understand what they did
<biot>
I should just dump that vector SMC calls use, if it's anywhere in 0x80000000+0x8000 it's confirmed
kevery has quit [Read error: Connection reset by peer]
kevery1 is now known as kevery
Pali has joined #armlinux
<ukleinek>
narmstrong: not sure I understood you. Should I adapt the commit log, or the comments in the dt?
sszy has quit [Ping timeout: 272 seconds]
headless has joined #armlinux
<prabhakarlad>
Hi all, I am trying to partition the L3 cache (on a55) and allocate it to individual core in the cluster has anyone tried this before? any pointers would be helpful.
tlwoerner_ is now known as tlwoerner
<HdkR>
I always thought of that feature as "locked cache" but did anything recent even support it?
iivanov has quit [Quit: Leaving...]
alpernebbi has quit [Quit: alpernebbi]
torez has quit [Ping timeout: 256 seconds]
torez has joined #armlinux
amitk_ has quit [Ping timeout: 248 seconds]
headless has quit [Quit: Konversation terminated!]
macromorgan has quit [Read error: Connection reset by peer]