<xypron>
drmpeg: U-Boot SPL loads the DT directly behind the main U-Boot image not considering the BSS section. sbi_dbcn_available is in the BSS section and written before relocation.
cousteau_ has quit [Quit: ♫ I can't forget the day I shot that network down ♫]
<drmpeg>
Does that mean this bug has been around for a long time, but went unnoticed?
naoki has quit [Quit: naoki]
shamoe has quit [Quit: Connection closed for inactivity]
<conchuod>
does anyone know what the bootloader setup on the pioneer is?
flakusha has joined #riscv
flakusha has quit [Client Quit]
<xypron>
drmpeg: not handling BSS in a consistent way is an old problem. The specific driver was implemented with commit dfe08374943c ("risc-v: implement DBCN based debug console") and enabled by default with commit e637e455ca76 ("riscv: enable CONFIG_DEBUG_UART by default").
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII_ has joined #riscv
<drmpeg>
So U-Boot v2023.10 was probably broken.
<xypron>
drmpeg: only if you manually enabled the driver.
<conchuod>
no real platform supported by U-Boot falls afoul I'd imagine, but qemu has `riscv,isa = "rv64imafdch_zicbom_zicbop_zicboz_zicntr_zicsr_zifencei_zihintntl_zihintpause_zihpm_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu";`
MaxGanzII_ has quit [Remote host closed the connection]
MaxGanzII__ has joined #riscv
<xypron>
conchuod: The better approach than a fixed size would be to change cpu_get_desc() to pass a pointer to size and return the required size as provided by snprintf().
<conchuod>
I'm not convinced that cpu_get_desc() should looking at riscv,isa to begin with. Something like the cpu compatible seems more appropriate to be honest.
<sorear>
looking forward to seeing the plots of average riscv,isa length vs. year in 2040 or so
greaser|q has quit [Remote host closed the connection]
EchelonX has quit [Quit: Leaving]
<jrtc27>
💀
<sorear>
hey, we already added numbers to extension names despite very clear messaging that would never happen, maybe we'll eventually add other legal character sets and reach emoji
MaxGanzII__ has quit [Ping timeout: 255 seconds]
frkzoid has joined #riscv
<pabs3>
what is the thinking around GPUs from RISC-V hardware people? will there be GPU compute cores that use RISC-V?
frkazoid333 has quit [Ping timeout: 260 seconds]
<sorear>
there's a Graphics SIG that talks about that sort of thing but I have no idea how credible it is
greaser|q has joined #riscv
greaser|q has quit [Remote host closed the connection]
greaser|q has joined #riscv
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
greaser|q has quit [Remote host closed the connection]
heat has quit [Ping timeout: 246 seconds]
greaser|q has joined #riscv
greaser|q has quit [Remote host closed the connection]
greaser|q has joined #riscv
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #riscv
mlw has joined #riscv
djdelorie has quit [Ping timeout: 240 seconds]
BootLayer has quit [Quit: Leaving]
raym has joined #riscv
JanC has quit [Ping timeout: 260 seconds]
JanC has joined #riscv
djdelorie has joined #riscv
Bluefoxicy has quit [Ping timeout: 256 seconds]
mlw has quit [Ping timeout: 268 seconds]
mlw has joined #riscv
raym has quit [Quit: brb]
davidlt has joined #riscv
scrts8 has joined #riscv
scrts has quit [Ping timeout: 252 seconds]
scrts8 is now known as scrts
MaxGanzII__ has joined #riscv
shamoe has quit [Quit: Connection closed for inactivity]
ezulian has joined #riscv
jacklsw has quit [Ping timeout: 255 seconds]
ezulian has quit [Remote host closed the connection]
heat has joined #riscv
ezulian has joined #riscv
naoki has joined #riscv
MaxGanzII__ has quit [Ping timeout: 255 seconds]
prabhakalad has quit [Ping timeout: 256 seconds]
prabhakalad has joined #riscv
naoki has quit [Quit: naoki]
ldevulder has quit [Quit: Leaving]
ldevulder has joined #riscv
mlw has quit [Ping timeout: 252 seconds]
mlw has joined #riscv
Bluefoxicy has joined #riscv
prabhakalad has quit [Ping timeout: 264 seconds]
prabhakalad has joined #riscv
Tenkawa has joined #riscv
hightower2 has joined #riscv
sevan has quit [Changing host]
sevan has joined #riscv
KREYREN has quit [Remote host closed the connection]
erg_ has quit [Remote host closed the connection]
psydroid has joined #riscv
MaxGanzII__ has joined #riscv
junaid_ has joined #riscv
junaid_ has quit [Remote host closed the connection]
Stat_headcrabed has joined #riscv
<sorear>
it occurs to me that at least on the cheri linux side there will be a demand for unified kernels that support both cheri-hybrid and pure legacy operation
suqdiq3 has joined #riscv
suqdiq has quit [Ping timeout: 255 seconds]
suqdiq3 is now known as suqdiq
mlw has quit [Ping timeout: 246 seconds]
mlw has joined #riscv
mps has quit [Ping timeout: 246 seconds]
Forty-Bot has quit [Ping timeout: 256 seconds]
Stat_headcrabed has quit [Quit: Stat_headcrabed]
crossdev has joined #riscv
unnick has quit [Ping timeout: 256 seconds]
unnick has joined #riscv
jmdaemon has quit [Ping timeout: 260 seconds]
heat has quit [Remote host closed the connection]
heat has joined #riscv
ntwk has quit [Read error: Connection reset by peer]
Trifton has quit [Remote host closed the connection]
Trifton has joined #riscv
lagash has quit [Ping timeout: 268 seconds]
MaxGanzII_ has joined #riscv
MaxGanzII__ has quit [Ping timeout: 255 seconds]
Forty-Bot has joined #riscv
mlw has quit [Ping timeout: 240 seconds]
mlw has joined #riscv
crossdev has quit [Remote host closed the connection]
crossdev has joined #riscv
Stat_headcrabed has joined #riscv
<jrtc27>
sorear: why?
<jrtc27>
it is intended that hybrid is a fully compatible extension to the non-CHERI ABI
BootLayer has joined #riscv
shamoe has joined #riscv
dh` has quit [Ping timeout: 256 seconds]
heat has quit [Remote host closed the connection]
heat has joined #riscv
<sorear>
I mean, unified kernels that run hybrid on CHERI hardware and non-CHERI on non-CHERI hardware
<sorear>
not suggesting running non-CHERI on CHERI hardware
<jrtc27>
you can't do that
<jrtc27>
it's called two kernels
<sorear>
can't or shouldn't?
<jrtc27>
I mean
<jrtc27>
you can, but the way you'd do it is to build two kernels and have the entry point choose which to jump to
<jrtc27>
it is almost as disruptive as having 32-bit and 64-bit hardware support in the same kernel
<jrtc27>
which nobody does
<jrtc27>
also I will tell you that you really don't want to be building large hybrid programs if you can at all avoid it
<jrtc27>
our cheribsd diff to freebsd is dominated by all the __capability annotations needed to support it being built as a hybrid kernel
<sorear>
i heard once that old OS X used a 32-bit kernel for mixed 32/64-bit userspace, i wonder if that supported mixed hardware as well
<jrtc27>
that's different though
<jrtc27>
you can have 64-bit integers in a 32-bit kernel just fine
<jrtc27>
uint64_t still exists
<jrtc27>
but you cannot have capabilities in a non-CHERI kernel
<jrtc27>
so everywhere userspace pointers flow, which are capabilities for the purecap userspace ABI, you need two copies of the code
<jrtc27>
which to a first approximation is everywhere
<sorear>
wouldn't you need two copies of everything anyway to support legacy-ABI processes where userspace pointers are addresses
<jrtc27>
no, because you do it like 32-bit compat
<jrtc27>
the system call layer takes those integers and turns them into capabilities (using that process's pcc or ddc as appropriate) to use the native implementations
<jrtc27>
with the usual exceptions for things like ioctls
<sorear>
couldn't you do that both ways if you were sufficiently determined