<organizedglobals>
i guess different groups of people that cant tolerate each other's content, considering it a form of spam, splinter off and make their own groups. if you have a governmental collapse that happens too, just there aren't any crusades from one group online to another group per se since they would have to be large, and thus incoherent to begin with
<pierce>
i don't think it's that
<organizedglobals>
like how bratty mouthy children migrate to take over discord servers, hot-headed mods become spiteful and corrupt, or same-wavelength programmers stay on a forum
<pierce>
it could be the novelty is wearing off, or people have been a bit disappointed in the initial offerings of hardware
<pierce>
and along with the software support
<organizedglobals>
sorry i misunderstood the domain
<pierce>
personally speaking, work is getting in the way of learning
<pierce>
i set out to write a JIT, but I cannot dedicate enough time to upskill
<organizedglobals>
has anyone trained a GPT-3 or -4 model on the language you're interested in? last i heard that can take requests and expand it out into functional code
<jrtc27>
good luck with that
riff-IRC has joined #riscv
<pierce>
jrtc27: me?
<organizedglobals>
i think after -3 the world got scared of the intelligence of the model, but there are and were newer releases that do a better job
<jrtc27>
using machine learning to generate a JIT
<pierce>
oh... yeah, i'm not doing that
<organizedglobals>
just a thought
<organizedglobals>
another option is microdosing acid, psylocibin, or ketamine to improve your multitasking. like 1/10th of what you'd take to get high
<pierce>
dude
<organizedglobals>
ill just be leaving now
<pierce>
this is a risc-v chat
Sofia has quit [Remote host closed the connection]
Sofia has joined #riscv
vagrantc has joined #riscv
<somlo>
I've been successfully running opensbi on litex using fw_payload.bin (initrd.cpio embedded in the kernel, set as payload for opensbi, and also an embedded FDT configured via FW_FDT_PATH);
<somlo>
I tried separating them out (same kernel but w/o embedded initramfs.cpio), use fw_jump.bin, and "manually" load the blobs into RAM before starting opensbi.
<somlo>
to save a bit of space, since fw_jump.bin is only 0x19b50 in size.
<somlo>
The only "non-standard" thing I configured was FW_JUMP_FDT_ADDR=0x80100000,
<somlo>
So I have:
<somlo>
test.dtb at 0x80100000 (overridden at build via FW_JUMP_FDT_ADDR)
<somlo>
fw_jump.bin at 0x80000000 (default for generic platform)
<somlo>
...thru 0x80100b71
<somlo>
...thru 0x80019b50
<somlo>
Image at 0x80200000 (default for generic platform)
<somlo>
...thru 0x810b5600
<somlo>
init.cpio at 0x82000000 (specified via linux,initrd-start in dtb)
<somlo>
After loading all of these into RAM, and jumping to 0x80000000, I get crickets... Before I delve into debugging this whole mess, is there anything obviously stupid I'm doing that sticks out when eyeballing the above?
<jrtc27>
payload needs to be superpage aligned
<jrtc27>
so your space saving is illegal
<somlo>
you mean the dtb?
<jrtc27>
(0x80200000 being 0x80000000 + a 2 MiB superpage)
<somlo>
or each and every blob besides fw_jump.bin has to be 2MiB aligned?
<jrtc27>
oh you said FDT address
<jrtc27>
hmm
<jrtc27>
at one point Linux and/or FreeBSD assumed the FDT was *after* it in physical memory
<jrtc27>
I don't recall if that was and still is true of Linux
<somlo>
but in that case at least opensbi should be talking to me, before the kernel got upset :)
<jrtc27>
FreeBSD can handle the FDT passed to it not being superpage aligned these days, no clue about Linux
<jrtc27>
true
<jrtc27>
ah I reread what you said and I think FW_JUMP_FDT_ADDR has been misunderstood
<somlo>
but since the default dtb location is 82200000 (which is also 2MiB aligned) -- maybe my dtb move is in itself a problem?
<jrtc27>
FW_JUMP_FDT_ADDR is where fw_jump will put the DTB for the next stage (Linux)
<jrtc27>
not where it gets it from
<somlo>
I objdump-ed fw_jump.bin and it does load 80100000 into a0 at the right spot, but that's not saying much
<somlo>
oh
<jrtc27>
so you still need to either embed the DTB in OpenSBI or load it elsewhere in memory and set a1 to point at it
<jrtc27>
(and *not* put it where OpenSBI will copy it to)
<somlo>
so if/when I want to provide a fdt address for opensbi to use, how do I do that at build time ?
<somlo>
aaaaah
<jrtc27>
passed in a1 or embedded via FW_FDT_PATH, I don't think there's a magic "go look here for it" option
<somlo>
so does FW_FDT_PATH work with fw_jump.bin?
<somlo>
well, one way to find out :)
<jrtc27>
it should do
<jrtc27>
it's not FW_PAYLOAD_FDT_PATH
<somlo>
thanks for clearing that up, I thought FW_JUMP_FDT_ADDR was a way of telling opensbi where to find the fdt, which now I know is wrong -- that's one important thing about what I was doing that's obviously stupid, so this is progress!!!
<somlo>
thanks!
<jrtc27>
yep, should get you opensbi output again
<jrtc27>
and hopefully kernel, but we shall see :)
<somlo>
that worked, kernel and all -- thanks again jrtc27!
<jrtc27>
\o/
jacklsw has joined #riscv
<somlo>
one of these days I'll have to build the dtb into the litex bios, but first I'll have to figure out an alternative way to specify the initrd start and end (right now it's via the "chosen { ... };" block in the DT, and there's gotta be a way to separate that out and provide it later from someplace else...)
motherfsck has quit [Quit: quit]
riff-IRC has quit [Quit: PROTO-IRC v0.73a (C) 1988 NetSoft - Built on 11-13-1988 on AT&T System V]
EchelonX has quit [Quit: Leaving]
crabbedhaloablut has joined #riscv
pabs3 has quit [Remote host closed the connection]
pabs3 has joined #riscv
PyroPeter has quit [Ping timeout: 245 seconds]
PyroPeter has joined #riscv
panzeroceania has quit [Ping timeout: 265 seconds]
panzeroceania has joined #riscv
rlittl01 has quit [Ping timeout: 260 seconds]
rlittl01 has joined #riscv
rlittl01 has quit [Ping timeout: 265 seconds]
kailo has joined #riscv
rlittl01 has joined #riscv
DoubleJ has quit [*.net *.split]
GenTooMan has quit [*.net *.split]
Finde has quit [*.net *.split]
mjacob has quit [*.net *.split]
jtdowney has quit [*.net *.split]
aurel32 has quit [*.net *.split]
la_mettrie has quit [*.net *.split]
agraf has quit [*.net *.split]
merry has quit [*.net *.split]
jimbzy has quit [*.net *.split]
jrtc27 has quit [*.net *.split]
q66 has quit [*.net *.split]
sirn has quit [*.net *.split]
aurel32 has joined #riscv
jimbzy has joined #riscv
q66 has joined #riscv
jimbzy has quit [Changing host]
jimbzy has joined #riscv
DoubleJ has joined #riscv
GenTooMan has joined #riscv
la_mettrie has joined #riscv
Finde has joined #riscv
mjacob has joined #riscv
agraf has joined #riscv
jrtc27 has joined #riscv
jtdowney has joined #riscv
sirn has joined #riscv
merry has joined #riscv
pabs3 has quit [Ping timeout: 256 seconds]
pabs3 has joined #riscv
aburgess_ has joined #riscv
aburgess has quit [Ping timeout: 260 seconds]
BOKALDO has joined #riscv
vagrantc has quit [Quit: leaving]
motherfsck has joined #riscv
indy has quit [Ping timeout: 250 seconds]
frost has joined #riscv
pecastro has joined #riscv
<geertu>
jrtc27: Append DTB to [zu]Image is used on ARM platforms where the boot loader cannot pass the DTB separately (i.e. they predate the API to pass separate kernel and DTB addresses_
jacklsw has quit [Ping timeout: 265 seconds]
ddevault has quit [Remote host closed the connection]