Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
hentai has quit [Ping timeout: 480 seconds]
hentai has joined #linux-sunxi
rajkosto has joined #linux-sunxi
hentai has quit [Ping timeout: 480 seconds]
<smaeul>
hunbalazs: possibly, but I think it's unlikely with gcc. I'm using 11.1, which is close to your compiler version (11.3)
ats_ has quit []
<smaeul>
montjoie: the cache issue with crypto is a bug in the driver. if you map a buffer as DMA_FROM_DEVICE, you should expect any writes made by the CPU to be ignored/clobbered
ats has joined #linux-sunxi
<smaeul>
that is how ~all of the architectures work, not just riscv
vagrantc has joined #linux-sunxi
<smaeul>
so you either need to flush the cache before mapping the buffer, or map it as DMA_BIDIRECTIONAL
<hunbalazs>
smaeul: I tried with clan/LLVM too but the only difference is that it prints a different address
<hunbalazs>
(interestingly it is 0x000000*, with GCC it is 0xffffff*)
<smaeul>
were you able to get a booting kernel with any combination of sources/config?
<hunbalazs>
never, only with downloaded blobs
<smaeul>
and you tried the defconfig from my branch?
<hunbalazs>
yes, that was one of my statring points
<smaeul>
in that case, the only variable left is the toolchain. I notice that you are using gentoo hardened. maybe stack-protector or FORTIFY_SOURCE is breaking something.
<hunbalazs>
this is the current: # CONFIG_STACKPROTECTOR is not set
<smaeul>
hmm, right, the kernel does pass -fno-stack-protector if that option is unset, so the compiler default shouldn't make a difference
<hunbalazs>
and clang/LLVM does not have hardened variants
<smaeul>
can you paste the full boot log from any recent attempt? maybe that would give me some clue
<hunbalazs>
sure
<smaeul>
I just built a kernel with CONFIG_STACKPROTECTOR_STRONG=y and it booted fine here
<smaeul>
so that's not the problem (even though we already knew it probably wasn't)
<smaeul>
hunbalazs: thanks! I was able to reproduce by disabling preemption: https://tpaste.us/OqZ8
<montjoie>
smaeul: not a bug in driver, but in crypto selftests
<hunbalazs>
smaeul: nice (different topic: how do you fake build time?)
<smaeul>
montjoie: yes, true
<smaeul>
hunbalazs: SOURCE_DATE_EPOCH=0
<montjoie>
smaeul: it is why I found this strange, it is really the first arch doing that
<smaeul>
this makes incremental U-Boot compiles much faster. it used to not even relink if there were no changes, but recently they added some files that get regenerated every time (default environment)
<montjoie>
or perhaps the first arch with a DMA driver
<smaeul>
hmm? I pointed out on the ML that arm, arm64, openrisc, and powerpc have the exact same behavior
<smaeul>
though possibly D1 cache controller is very agressive with writeback
<hunbalazs>
smaeul: CONFIG_PREEMPT_VOLUNTARY or CONFIG_PREEMPT?
<smaeul>
hunbalazs: I have been using CONFIG_PREEMPT
<montjoie>
smaeul: could you try to update to v3 ? I am trying to do it but patch do not apply
<hunbalazs>
montjoie: you have to revert first, then it will apply
<hunbalazs>
(I couldn't disable line wrapping so it is cut at 80 chars)
<hunbalazs>
(or something like that)
apritzel has joined #linux-sunxi
<smaeul>
v3 of the CMO series is broken, so what I just pushed is broken, too. I'm working on a fix.
apritzel has quit [Ping timeout: 480 seconds]
ynezz has quit [Remote host closed the connection]
ynezz has joined #linux-sunxi
ynezz is now known as Guest1885
rajkosto has quit [Quit: Leaving]
<smaeul>
hunbalazs: montjoie: I pushed a fixed branch. Booting now works for me with or without preemption, the USB garbage is fixed, and so is a longstanding issue with the SD card sometimes not getting detected.