<jedix>
geertu: I'm surprised I've not totally hosed nommu tbh
Tenkawa has quit [Quit: Was I really ever here?]
EchelonX has quit [Quit: Leaving]
<jedix>
..well, again
ncopa has quit [Quit: Ping timeout (120 seconds)]
ncopa has joined #riscv
Tenkawa has joined #riscv
Tenkawa has quit [Client Quit]
Armand has quit [Read error: Connection reset by peer]
jacklsw has quit [Ping timeout: 245 seconds]
Armand has joined #riscv
BootLayer has joined #riscv
freakazoid332 has joined #riscv
frkazoid333 has joined #riscv
frkzoid has quit [Ping timeout: 240 seconds]
freakazoid332 has quit [Ping timeout: 240 seconds]
Armand has quit [Read error: Connection reset by peer]
frkzoid has joined #riscv
frkazoid333 has quit [Ping timeout: 240 seconds]
freakazoid332 has joined #riscv
frkzoid has quit [Ping timeout: 240 seconds]
Armand has joined #riscv
GenTooMan has quit [Ping timeout: 246 seconds]
junaid_ has joined #riscv
GenTooMan has joined #riscv
jacklsw has joined #riscv
Armand has quit [Quit: Leaving]
<sorear>
palmer: I got around to reading the patch. It's a very good step forward and I can't see anything wrong with it, I'm merely unsatisfied that we won't be able to fully test it before releasing
_whitelogger has joined #riscv
<sorear>
anything ABI-related in a merge window makes me very twitchy, if you get anything wrong our grandchildren will be dealing with it
junaid_ has quit [Remote host closed the connection]
<muurkha>
hopefully
<muurkha>
maybe the ABI folks will take the YOLO approach the CPython maintainers have adopted
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Client Quit]
ldevulder has joined #riscv
jacklsw has quit [Quit: Back to the real world]
<conchuod>
sorear: merge window is closed as of Sunday gone
<conchuod>
Unless you mean some different..
<sorear>
thank you for the information and I'm definitely going to use "Sunday gone" in the future but in this case it would take a miracle for the patch to reach my usual standards of testedness by *next* merge window either, before the end of the year would be a huge achievement
<jrtc27>
if you invent ABI and circumvent the psABI TG then there are zero guarantees a future standard won't break whatever you're doing
<sorear>
the phrase "rock and a hard place" was invented to describe situations where the psABI TG and "don't break userspace" contradict each other
<jrtc27>
we have custom space for non-standard extensions
<jrtc27>
you could use that
<jrtc27>
and never be standard
<jrtc27>
(I use you to mean one, of course)
<sorear>
the new ABI in the patch we're discussing consists of the use of a1/a2/a3 at the ELF entry point and the behavior of ptrace(PTRACE_GETFDPIC) on riscv64, I don't see how either of those maps to the concept of custom space
<jrtc27>
I don't care about that kind of OS ABI
<jrtc27>
but what about all the relocations and code models?
<sorear>
n/a, binfmt_elf_fdpic doesn't apply relocations so they can be defined later
<arnd>
a lot of that probably also applies to riscv, but it does seem necessary for someone to go through and actually document that
elastic_dog has quit [Ping timeout: 246 seconds]
<arnd>
I found similar documents for fr-v and sh, both from around 2008, but google doesn't immediately find the corresponding documents for xtensa and m68k
<arnd>
gerg added kernel support for m68k fdpic last year, while jcmvbkbc did the same for xtensa slightly later
billchenchina has quit [Ping timeout: 246 seconds]
crabbedhaloablut has quit [Ping timeout: 260 seconds]
billchenchina- has quit [Remote host closed the connection]
billchenchina- has joined #riscv
crabbedhaloablut has joined #riscv
jacklsw has quit [Ping timeout: 240 seconds]
wingsorc has quit [Ping timeout: 246 seconds]
BootLayer has joined #riscv
billchenchina has joined #riscv
billchenchina- has quit [Ping timeout: 246 seconds]
billchenchina- has joined #riscv
billchenchina has quit [Read error: Connection reset by peer]
billchenchina- has quit [Quit: Leaving]
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Client Quit]
JanC has quit [Ping timeout: 240 seconds]
JanC has joined #riscv
JanC has quit [Ping timeout: 240 seconds]
JanC has joined #riscv
JanC has quit [Read error: Connection reset by peer]
JanC_ has joined #riscv
JanC_ is now known as JanC
Tenkawa has joined #riscv
jmdaemon- has quit [Ping timeout: 240 seconds]
billchenchina has joined #riscv
billchenchina has quit [Client Quit]
mahk has quit [Ping timeout: 246 seconds]
mahk has joined #riscv
awita has joined #riscv
BootLayer has quit [Quit: Leaving]
mahk has quit [Changing host]
mahk has joined #riscv
<palmer>
sorear: which patch?
nmeum has quit [Remote host closed the connection]
nmeum has joined #riscv
vagrantc has joined #riscv
smaeul_ is now known as smaeul
<palmer>
drewfustini: did you post anywhere on LKML about that camera firmware? that makes the t-head V stuff a bit higher priority
<drewfustini>
Not yet, the public annoucement of the board is today so was going to start chasing things on mailing lists now
<drewfustini>
we had to go with yocto based install using the thead sdk for the shipping board but would like to improve on it post launch
<palmer>
ya, that makes sense. No rush or anything, I think a lot of us had just been assuming there's nothing in userspace that actually depends on the T-Head V
<sorear>
do we have anything that talks about where to draw the line between "just a couple drive-by comments" and "you should add a r-b"? I've been erring on the side of not giving out r-bs because I'm not a maintainer and not very experienced with the kernel processes
<conchuod>
You're free to leave whatever comments you like & then never leave an R-b if they are addressed /shrug
<drewfustini>
ah, interesting, I think it is because digikey.com vs. digikey.be... I will ask our digikey person
<drewfustini>
> looks like also the "latest bootable images" doesn't have the Ahead yet?
<drewfustini>
thanks, yes, I think our updating the website for the new board was as atomic as i had expected
<geertu>
So only on digikey.com, not yet on digikey.be
<palmer>
drewfustini: ya, no problem -- there's always broken stuff on launch ;)
<conchuod>
unrelated geertu - but I sat on that DT warning for months because I was told it was related to the non-coherent DMA stuff
<conchuod>
and on that note, arnd: are you going to send a v2 of your cross arch dma series?
<arnd>
conchuod: yes, I definitely plan to, just have a few other series that I need to get out first
<conchuod>
👍
<palmer>
thanks, I feel kind of bad for Prabhakar -- he's been at this for a while now...
<conchuod>
Yah, I do too!
<arnd>
I think prabhakar's series can go in before mine after his latest rebase, right?
<conchuod>
AFAIK, his last version is also on top of your work.
<drewfustini>
geertu: I'm told it may take a little time for the Digikey cache servers to update worldwide.
esv has quit [Ping timeout: 246 seconds]
esv_ has joined #riscv
<geertu>
conchuod: It is related to the non-coherent DMA stuff ;-) When the non-coherent DMA stuff is in, Ethernet can be enabled on RZ/Five, and the issue will go away ;-)
<conchuod>
Right, but removing the W=1 complaint did not depend on it which is what I was lead to believe ;)
<conchuod>
Granted, I probably asked "will this warning go away when the non-coherent stuff is merged" and not "can you make this go away without the non-coherent stuff" ;)
bauruine has quit [Remote host closed the connection]
<sorear>
does anyone here actually have a RZ/Five? is the issue with the non-PIC load address actually real? the documentation of what's a configuration option and what isn't is confusing to the point I don't believe the analyses that have been posted
Andre_Z has joined #riscv
<geertu>
sorear: I have
<geertu>
However, I don't do much with it beyond booting kernels until they say "unable to mount root".
<geertu>
The board came with userland that was built with a modified compiler to work around the load address issue.
<sorear>
arnd: i firmly expect that when a fdpic abi exists it will be merged into riscv-elf-psabi-doc. my personal use cases for nommu linux (certain kinds of research hardware, certain emulation and cryptographic applications) mostly have enough memory that using normal elf executables is the reasonable approach; i'm unsure of whether it's worth spending the time to define a true abi for fdpic executables at this time
<sorear>
geertu: modified by the board vendor? presumably they are aware of what is and isn't an issue, then
<geertu>
sorear: I got the board straight from Renesas.
<geertu>
Unfortunately the mount command in the userspace does not supports NFS, so I cannot mount a Debian nfs, and chroot into that to try...
esv has joined #riscv
<arnd>
sorear: I'm not sure what you mean with "normal elf executable". The default CONFIG_BINFMT_ELF loader depends on CONFIG_MMU, while CONFIG_BINFMT_ELF_FDPIC can work with or without MMU (at least on arm)
esv_ has quit [Ping timeout: 246 seconds]
<sorear>
geertu: no ability to write to the sd card on another device, use the usb host interface, or curl a tarball?
<sorear>
arnd: is_constdisp(header) = 1, i.e. everything right now because we haven't allocated an e_flags or EI_OSABI for non-constdisp
pabs3 has joined #riscv
<conchuod>
Esmil: just a reminder in case you have a half written email with me in the to: line ;)
<drewfustini>
We were were going to ship this Ubuntu build on the board but could not get the CSI libraries to work in vanilla Ubuntu so quickly switch to Yocto-based image where all the libraries are the thead sdk versions. https://git.beagleboard.org/beaglev-ahead/xuantie-yocto