<Esmil>
i'm still hoping i'll find time to push something like that to the starfive branch, but based on the latest upstream
Andre_Z has joined #riscv
<Esmil>
s/the starfive branch/the visionfive branch in the starfivetech repo/
pedja has joined #riscv
BootLayer has joined #riscv
Stat_headcrabed has joined #riscv
Wickram has quit [Quit: WeeChat 3.8]
<mps>
Esmil: speaking about your jh71x0 branch, I have 'dw_axi_dmac_platform 100b0000.dma-controller: apb_regs not initialized' kernel messages when playing audio
<Esmil>
mps: yes, that message has been a while. as far is I can tell it's harmless
<mps>
now I will build from latest commit to see if it still there
<mps>
yes, it is harmless, just wanted to note if you didn't see it
<mps>
I'm trying to build unified kernel for visionfive V1 and V2 for alpine linux
<Esmil>
as far as i can tell only the intel implementation sets a pointer to those registers, so not sure why everyone else should get that warning
<Esmil>
mps: that works for me on the jh71x0-6.2.y branch i linked
<mps>
could be commented out in kernels for starfive
<mps>
Esmil: one alpine user reported that NVME doesn't work with my config
<mps>
and I'm not sure if NVME works at all
<Esmil>
yes, i think Tenkawa was saying nvme was slow too, but this is just 1st revision of the pcie patches starfive sent. hopefully that will improve
<mps>
hope that announced V2 will arrive in near future to me and then I could test deeply
MaxGanzII has quit [Ping timeout: 255 seconds]
enoq has quit [Quit: enoq]
MaxGanzII has joined #riscv
Armand has joined #riscv
bauruine has quit [Remote host closed the connection]
ldevulder has quit [Remote host closed the connection]
jacklsw has joined #riscv
jacklsw has quit [Changing host]
jacklsw has joined #riscv
jacklsw has quit [Client Quit]
ldevulder has joined #riscv
jacklsw has joined #riscv
Tenkawa has joined #riscv
Armand has quit [Ping timeout: 240 seconds]
Armand has joined #riscv
MaxGanzII has quit [Ping timeout: 255 seconds]
MaxGanzII has joined #riscv
Stat_headcrabed has quit [Ping timeout: 240 seconds]
Guest75 has joined #riscv
Guest75 has quit [Quit: Client closed]
<conchuod>
> commented out
<conchuod>
Should just fix it upstream /shrug
prabhakarlad has quit [Quit: Client closed]
aerkiaga has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
prabhakarlad has joined #riscv
MaxGanzII has quit [Ping timeout: 255 seconds]
<mps>
conchuod: right
<conchuod>
I'll send a patch for it once I run into it, if no-one beats me to it.
Stat_headcrabed has joined #riscv
Stat_headcrabed has quit [Client Quit]
vagrantc has joined #riscv
<mps>
I hate sending patches, takes a lot more time than to fix something and keep patches localy
jmdaemon has joined #riscv
<bjdooks>
anyone done a study on which compressor is best for the kernel image to make it smallest for uboot loading? we're currentily using xz
<conchuod>
stat_headcrabed: btw, would you mind CCing me on future versions of your pmic series? Just wanna know when it gets applied mostly.
<conchuod>
Also, stat_headcrabed - your cover letters seem not to make it to lore for some reason
KombuchaKip has joined #riscv
jobol has quit [Quit: Leaving]
prabhakarlad has quit [Quit: Client closed]
heat has joined #riscv
Armand has quit [Read error: Connection reset by peer]
Armand has joined #riscv
KombuchaKip has quit [Quit: Leaving.]
<courmisch>
when compresssion is enabled, uncompressed instructions can be unaligned, can't they?
KombuchaKip has joined #riscv
<jrtc27>
yes
<courmisch>
doesn't this create an opportunity for some x86-style JIT spraying??
<courmisch>
where attacker reinterprets the byte code by jumping mid-instruction
<jrtc27>
somewhat
<jrtc27>
so don't use an architecture that lets you hijack control flow arbitrarily
<courmisch>
well... not many CHERI RISC-V-capable boards on the market
aredridel2 has joined #riscv
<courmisch>
obviously my code is always perfect and totally free of any bug that would corrupt the spilled RA, but there are other programmers...
<courmisch>
</sarcasm>
aredridel has quit [Ping timeout: 255 seconds]
aredridel2 is now known as aredridel
davidlt has quit [Ping timeout: 246 seconds]
<jrtc27>
:)
vagrantc_ has joined #riscv
<courmisch>
the real reason why I don't like it that way, is disassembly can get confused about the offset
<courmisch>
especially if read-only data is interleaved in the code
KombuchaKip has quit [Quit: Leaving.]
eroux has quit [Ping timeout: 240 seconds]
<jrtc27>
that's what mapping symbols are for
BootLayer has quit [Quit: Leaving]
eroux has joined #riscv
heat has quit [Remote host closed the connection]
Andre_Z has quit [Ping timeout: 260 seconds]
eroux has quit [Ping timeout: 255 seconds]
eroux has joined #riscv
vagrantc has quit [Ping timeout: 250 seconds]
vagrantc_ is now known as vagrantc
eroux has quit [Ping timeout: 255 seconds]
sh1r4s3 has joined #riscv
eroux has joined #riscv
prabhakarlad has joined #riscv
ldevulder has quit [Ping timeout: 250 seconds]
eroux has quit [Ping timeout: 248 seconds]
eroux has joined #riscv
acharles has joined #riscv
vagrantc has quit [Quit: leaving]
billchenchina has joined #riscv
pedja has quit [Quit: Leaving]
eroux has quit [Ping timeout: 276 seconds]
eroux has joined #riscv
heat has joined #riscv
prabhakarlad has quit [Quit: Client closed]
pharonix71 has quit [Remote host closed the connection]
jmdaemon has quit [Ping timeout: 246 seconds]
armand_ has joined #riscv
Armand has quit [Read error: Connection reset by peer]
MaxGanzII has quit [Ping timeout: 255 seconds]
rory_be has joined #riscv
<rory_be>
Is there any work on big-endian support for riscv on Linux?
<palmer>
rory_be: IIRC everything fizzled out
billchenchina has quit [Ping timeout: 246 seconds]
<rory_be>
Hmm... Imagine my surprise at having built a big endian rootfs only to find no kernel support! It does not seem too complex; however the lack of support in qemu means waiting for my hardware to arrive.
nikolam has quit [Quit: Leaving]
vagrantc has joined #riscv
<palmer>
rory_be: it should be fairly easy to add QEMU support, the kernel will likely be a bit harder but not super bad. You'll probably also had a ton of userspace bugs to deal with...
<rory_be>
I've been through it before on aarch64_be - btw @palmer, did you do the early qemu work for riscv?
prabhakarlad has joined #riscv
<jrtc27>
given how dead other BE arches are and how little traction aarch64_be has had, do you *really* want to be maintaining BE support?
<jrtc27>
the riscv world seems intent on creating every possible combination of everything... ilp32, be, 32-vs-64, ...
<jrtc27>
rv64e...
<jrtc27>
just because you can doesn't mean you should
<jrtc27>
(see also nommu linux?)
<rory_be>
The only reason I bother with big-endian is to catch sloppy code in test... It is getting harder and harder to find big-endian systems with PCIe slots to test on...
<rory_be>
*should be reasonably priced big -endian systems with PCIe slots
<conchuod>
jrtc27: no
<conchuod>
especially if it is just for a handful of FPGA based toys :)
<sevan>
rory_be: last gen powermac g5 has pcie, but I'm guessing you want current hardware rather than 1st gen PCIe
<jrtc27>
finding code bugs and fixing them is generally good
<pabs3>
rory_be: how about RaptorCS POWER systems? I think those are bi-endian (on a per-process basis)
<pabs3>
kind of expensive though, but there are big-endian POWER ports, like Debian's ppc64
<sevan>
difficult to source out of the US too
<pabs3>
the other thing is I heard IBM are working towards rackmount s390x
<rory_be>
Gentoo built riscv64be relatively weel with cross compilation - openssl was the only riscv specific issue (gcc12 does not cross compile, but that is not riscv specific)
JTL is now known as jittle
jittle is now known as JTL
aerkiaga has quit [Remote host closed the connection]