sorear changed the topic of #riscv to: RISC-V instruction set architecture | https://riscv.org | Logs: https://libera.irclog.whitequark.org/riscv
Xav101 has joined #riscv
jacklsw has joined #riscv
<rneese> found a riscv color keyboard
<rneese> this is cool
<rneese> welcome Localring
<rneese> wrong window
<Xav101> I'm trying to write a linker script to place sections in memory and I'm not quite sure what to do with the global pointer register
<Xav101> For example often you'll have an LMA and a VMA for data section because it resides in ROM and then gets copied into RAM
<Xav101> from what I understand you're supposed to set the gp to the center of that most used 4k area of data so it can do relative jumps easily or whatever
<Xav101> but do I set it to the center of that location in RAM or in ROM? And if it's in RAM what's the best way to do that with a linker script
<jrtc27> symbols will take the VMA, the LMA just affects the program headers
<jrtc27> and gp isn't used for jumps
<jrtc27> it's used for loads/stores
<jrtc27> normally you'd just put __global_pointer$ = . + 0x800; at the start of a section
<jrtc27> (the default has it doing that for .sdata)
<geist> Xav101: it's a bit of a question when it comes to a split RAM/ROM region like that
<geist> since you can't really cover both. I put it near the ram version of it, since the rom version can still compute relative addresses to the .text segment *fairly* easily
<geist> or, just reclaim the gp register in a split world and do something else with it
<jrtc27> that doesn't quite work, there's no way to turn it off in bfd without disabling linker relaxation entirely
<geist> that's what i mean
<jrtc27> you can give it an address in the linker script that's never going to be in range of something
<jrtc27> but that doesn't disable it and is a bit gross
<geist> just disable relaxation entirely and/or don't set the __global_pointer$ symbol and it never uses it
<geist> but yeah, YMMV
<jrtc27> there are lots of relaxations you *do* want
<geist> fair, eah
<Xav101> I mean relaxation of jumps is quite helpful
<jrtc27> like not having two instruction indirect(ish, without fusion) branches to all your functions
<Xav101> maybe less so on more advanced uArches
<geist> but i did leave myself a comment about what to do with .srodata
<geist> which gets 'left behind' in the ROM segment
<geist> oh or actually doesn't, but could be. that's the comment
<geist> i think i found in a limited amount of testing that the compiler doesn't really generate much in the way or .srodata as much as it likes to genera .sdata and .sbss
<geist> but honestly i found the whole sdata/gp thing to be kinda annoying, since it's hard to have it automatically do what you want, its just a best effort thing and based on whatever the linker did when it laid out things you may or may not get what you want in the small data area
devcpu has quit [Quit: leaving]
<Xav101> @geist can you explain how that linker script puts it in the RAM portion? The script doesn't seem to have much of a "RAM portion"
<geist> it's subtle: https://github.com/littlekernel/lk/blob/master/arch/riscv/linker-twosegment.ld#L53 is where it 'jumps forward' to the RAM portion
<geist> this is for an embedded riscv machine, where you have say ROM around 0 and RAM at 0x2000.0000 or so
<geist> externally the build system splits the two and the linker script builds two output segments here
<geist> the real trick is the AT() keyword in line 55
<Xav101> right, so AT makes it so the data is in ROM but stored in RAM?
<Xav101> *stored in ROM but should be loaded into RAM
<geist> line 53 shifted the virtual address the linker is generating up to the base of RAM but the AT() keyword keeps the addresses physically rooted at the original run, which is in ROM
<geist> right
<Xav101> ah, so when you set GP it's set to a value in RAM
<geist> it sets up some symbols like __data_start_rom and __data_start that some assembly code uses to memcpy the RAM portions out
<geist> right
<Xav101> ok
<Xav101> I'll have to try that with my linker script
<geist> there's probably other ways to do it, linker scripts are kinda a black art, but this has worked well for me
<geist> the 'one segment' version is the same script but doesn't have the shift: https://github.com/littlekernel/lk/blob/master/arch/riscv/linker-onesegment.ld
<Xav101> lol
<Xav101> I don't know if any of you guys have played factorio
<Xav101> but I ended up building what seems like a functional RISC-V CPU in it with the in-game logic system
<Xav101> so now I'm just asking about this stuff to see if I can get it to run C code
<geist> heh i have and i learned to stay far away from it. haha
<geist> omg that's awesome
<geist> probably at least a bit more reliable than building cpus out of redstone in minecraft
<Xav101> lol. Also faster. I think theoretically I could hit 10Hz if I rebuilt the design with some tight timing constraints and a pipeline
<geist> yah i wouldn't worry too much about the GP register then
<Xav101> well I mean the linker relaxation does help slightly with code size
<Xav101> just cause you don't need to double up all your jumps
<geist> that is true though
<Xav101> I'm struggling for RAM pretty badly.
<geist> but it probably wont use the gp register for jumps though
<geist> unless the code is so small it happens to also have some pieces of text within the gp register range
<geist> and you have some indirect jumps
<Xav101> yeah but even if you have linker relaxation on then doesn't it still need it
<geist> gp register stuff is mostly for referencing data, global registers, etc. AFAICT the relaxation is the linker will simply use GP as a base if the target label is within the offset range of it
<geist> as opposed to storing the full address (for non pic) or using the PC to compute t
<Xav101> so how would I turn off the relaxation so it doesn't need the reg but still can relax jumps?
<geist> s/global registers/global variables
<geist> i think if you simply dont put in the __global_pointer$ label in your linker script the linker will simply never emit any code
<geist> but can still relax other stuff
<Xav101> ok
<geist> simply never emit any code to use GP that is. the mechanism is quite simple and the linker doesn't really know much
<geist> but i'm not too familiar with the other relaxations other than GP referencing, jrtc27 can probably answer better
<xentrac> Xav101: hey, that's wonderful, congratulations!
<xentrac> is there a way you can publish your CPU design so other factorio players can try running it?
<Xav101> yeah probably when I've got this all done and maybe debugged it a bit
<xentrac> historically speaking RAM was a huge problem for a long time
Xav101 has quit [Ping timeout: 252 seconds]
<xentrac> from about 01945 to about 01955 (and up to 01965 in cost-sensitive applications) people used delay lines, magnetic drums, and Williams tubes, so they could have thousands of bits of RAM without thousands of separate physical devices to store the bits in. I haven't played Factorio so I don't know if there's a similar thing you can do in it
nun has quit [Quit: ZNC - http://znc.in]
freakazoid343 has joined #riscv
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
nun has joined #riscv
freakazoid333 has quit [Ping timeout: 250 seconds]
riff-IRC has quit [Read error: Connection reset by peer]
riff-IRC has joined #riscv
jacklsw has quit [Quit: Back to the real world]
s0ph0s has quit [Ping timeout: 248 seconds]
s0ph0s has joined #riscv
cwebber has joined #riscv
s0ph0s has quit [Ping timeout: 240 seconds]
mahmutov has quit [Ping timeout: 240 seconds]
s0ph0s has joined #riscv
s0ph0s has quit [Ping timeout: 250 seconds]
compscipunk has quit [Quit: WeeChat 3.2]
jacklsw has joined #riscv
Xav101 has joined #riscv
<Xav101> @xentrac yeah there sort of is? There's some weird stuff you can do but you'll lose speed, and halfword and byte stores are already bad enough with my current design so I'm not going to deal with that just yet.
freakazoid12345 has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
freakazoid343 has quit [Ping timeout: 250 seconds]
s0ph0s has joined #riscv
Xav101 has quit [Ping timeout: 240 seconds]
riff-IRC has quit [Remote host closed the connection]
riff-IRC has joined #riscv
frost has joined #riscv
BOKALDO has joined #riscv
riff-IRC has quit [Remote host closed the connection]
jacklsw has joined #riscv
winterflaw has joined #riscv
riff-IRC has joined #riscv
jjido has joined #riscv
hendursa1 has joined #riscv
hendursaga has quit [Ping timeout: 276 seconds]
valentin has joined #riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
jacklsw has quit [Quit: Back to the real world]
jamtorus has joined #riscv
gordonDrogon has quit [Ping timeout: 252 seconds]
gordonDrogon has joined #riscv
jellydonut has quit [Ping timeout: 252 seconds]
jacklsw has joined #riscv
jamtorus is now known as jellydonut
Andre_H has joined #riscv
Andre_H has quit [Ping timeout: 252 seconds]
jjido has joined #riscv
jjido has quit [Client Quit]
peeps[zen] has quit [Remote host closed the connection]
peeps[zen] has joined #riscv
hendursa1 has quit [Remote host closed the connection]
hendursa1 has joined #riscv
rneese has quit [Remote host closed the connection]
Andre_H has joined #riscv
Andre_H has quit [Ping timeout: 248 seconds]
frost has quit [Quit: Connection closed]
jwillikers has joined #riscv
Xav101 has joined #riscv
Xav101 has quit [Ping timeout: 250 seconds]
jjido has joined #riscv
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #riscv
BOKALDO has quit [Quit: Leaving]
Andre_H has joined #riscv
Andre_H has quit [Remote host closed the connection]
jacklsw has quit [Quit: Back to the real life]
<stefanct> jimwilson: thanks, that's a bit hidden (not mention in the getting started or reference manual. it's very odd though that they are not included but 4 screws + 4 washers (half of which are completely useless AFAICT)
<stefanct> i "fixed" it with some m3 screws and two nuts
<stefanct> (but then recognized - despite the m.2 slot keying - the sata lines are not connected and there is no sata controller in the soc ;)
BOKALDO has joined #riscv
<mps> anyone runinng riscv64 in qemu VM with u-boot as boot loader
crest has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<mps> I can boot it with -kernel parameter with kernel out of VM image fine, but would like to use u-boot
<mps> when I run with u-boot I have next error msg 'Unhandled exception: Load access fault'
<mps> full boot log is here
crest has joined #riscv
<jrtc27> stefanct: I blame the fact that there's no way to key an M.2 slot for only NVMe
<jrtc27> you can key for only SATA but not the other way round :(
<jrtc27> well, even then B-keying includes PCIe x2
<jrtc27> it's all a bit sad
<jrtc27> mps: you haven't provided a log, and yes I have done that just fine
<mps> jrtc27: ah, sorry
<mps> jrtc27: here it is https://tpaste.us/xnjW
<jrtc27> looks like your kernel tried to dereference a null pointer very early in boot
<mps> jrtc27: the same kernel boots fine with -kernel parameter, that is what wonders me
<jrtc27> if you use u-boot it'll be loaded to a different address and jumped to via a different protocol
<mps> yes
<jrtc27> so which bit of the early boot code gets used is different
<jrtc27> this is the part of the boot process that is likely to differ between -kernel and u-boot extlinux
<mps> I think so. had a hope someone was hit by this and have solution
<jrtc27> my guess is u-boot is passing a null device tree
<mps> btw, I created short script to make alpine linux VM and boot it, https://arvanta.net/alpine/install-alpine-riscv64-qemu/
<jrtc27> delete the fdtdir line from your extlinux config
* jrtc27 mutters something more about exlinux needing to die and people finally fixing Linux to use EFI like a proper computer
<mps> jrtc27: ah, interesting. will try this fix
<mps> and, does riscv can be booted with uefi
<mps> uh, can the riscv be booted with uefi
<jrtc27> u-boot supports it, and freebsd supports and uses it, but linux is stuck not using it; I think the kernel itself does, but grub does not
<jrtc27> it continues to annoy me that linux is doing stupid things like this..
<jrtc27> gives a crap experience for people like you, and encourages bad practices
<mps> <rant> I'm not sure which one is worse, u-boot or grub </rant>
<jrtc27> at least if you use the same thing as other proper architectures use then you get consistent look, feel, functionality and reliability
<mps> yes, I agree
<jrtc27> because if you want people to take you seriously when you say riscv can be used as a pc architecture you'd better make sure it acts like one
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Xav101 has joined #riscv
<Xav101> in a linker script, after you use AT, how would you reset the VMA to the LMA?
jjido has joined #riscv
<jrtc27> either you have the two backwards or you're confused
<jrtc27> VMAs are the thing you normally control, and LMAs are the things you can override to not be the same as the VMAs
<jrtc27> I don't know what you're trying to do, but I suspect that you want to have multiple memory regions
compscipunk has joined #riscv
TMM_ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM_ has joined #riscv
<Xav101> @jrtc27 I'm trying to do a thing where the data section is placed in ROM but is loaded into RAM. To define the start and end points for where to copy the data into RAM from I was going to define some symbols using the location counter and then la them so I know where to start/stop
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #riscv
<jrtc27> IMO you want a section with your data whose VMA is in RAM and LMA is in ROM, with start and end symbols
<jrtc27> then add a single symbol that is the address of the start of the data in ROM
<jrtc27> you then have all the information you need, and that's most compatible with ELFs
<Xav101> how do you know the end?
<jrtc27> rom_start + (real_ram_end - real_ram_start)
<Xav101> ok
Xav101 has quit [Ping timeout: 240 seconds]
Xav101 has joined #riscv
freakazoid343 has joined #riscv
freakazoid12345 has quit [Ping timeout: 250 seconds]
hendursaga has quit [Remote host closed the connection]
hendursaga has joined #riscv
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Xav101 has quit [Quit: Leaving]
jacklsw has joined #riscv
Andre_H has joined #riscv
GenTooMan has quit [Ping timeout: 250 seconds]
GenTooMan has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
vagrantc has joined #riscv
mahmutov has joined #riscv
jjido has joined #riscv
bgamari has quit [Quit: ZNC 1.8.1 - https://znc.in]
bgamari has joined #riscv
mps has left #riscv [#riscv]
Andre_H has quit [Quit: Leaving.]
Andre_H has joined #riscv
freakazoid343 has quit [Read error: Connection reset by peer]
freakazoid333 has joined #riscv
freakazoid333 has quit [Read error: Connection reset by peer]
freakazoid333 has joined #riscv
BOKALDO has quit [Quit: Leaving]
solrize has joined #riscv
Andre_H has quit [Quit: Leaving.]
<jrtc27> so they bought MIPS to make CPUs, failed, sold MIPS, MIPS stopped being MIPS and started making RISC-V cores and now Imagination are making RISC-V cores too
<jrtc27> what a mess
<jrtc27> I wonder if they'll be adopting RISC-V for their GPUs (presumably they have controllers on there like the ones nvidia talk(ed) about replacing with RISC-V microcontrollers?)
<jrtc27> presumably not so interested in replacing their actual GPU ISAs
<dh`> at least it's riscv and not say m88k or other bologna
<sorear> return of m88k would be... interesting
zjason` has joined #riscv
zjason has quit [Ping timeout: 240 seconds]
<dh`> afaicr there was nothing particularly wrong with it other than 80s microarchitecture
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #riscv
rektide has quit [Quit: leaving]
wgrant has quit [Ping timeout: 252 seconds]
rektide has joined #riscv
rektide has quit [Quit: leaving]
rektide has joined #riscv
valentin has quit [Quit: Leaving]
wgrant has joined #riscv
jwillikers has quit [Remote host closed the connection]
mahmutov has quit [Ping timeout: 240 seconds]
winterflaw has quit [Ping timeout: 276 seconds]