crabbedhaloablut has quit [Ping timeout: 268 seconds]
loki_val has joined #riscv
dramforever_ has joined #riscv
dramforever__ has quit [Read error: Connection reset by peer]
pabs3 has joined #riscv
pabs3 has quit [Remote host closed the connection]
pabs3 has joined #riscv
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
Maylay has quit [Ping timeout: 268 seconds]
Maylay has joined #riscv
pabs3 has joined #riscv
Trifton has joined #riscv
Maylay has quit [Ping timeout: 240 seconds]
gdd1 has quit [Ping timeout: 240 seconds]
gdd1 has joined #riscv
dramforever__ has joined #riscv
dramforever_ has quit [Ping timeout: 240 seconds]
oaken-so1rce is now known as oaken-source
Maylay has joined #riscv
dramforever_ has joined #riscv
dramforever__ has quit [Ping timeout: 268 seconds]
dramforever__ has joined #riscv
BootLayer has joined #riscv
dramforever_ has quit [Ping timeout: 240 seconds]
vagrantc has joined #riscv
Maylay has quit [Ping timeout: 268 seconds]
Maylay has joined #riscv
loki_val has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
Maylay has quit [Ping timeout: 240 seconds]
vagrantc has quit [Quit: leaving]
gorgonical2 has joined #riscv
<gorgonical2>
I'm booting a custom kernel on the unmatched and the board hangs after my first byte written to the uart. OpenSBI comes up with u-boot and prints to the console just fine. Are there any obvious gotchas to be aware of?
<gorgonical2>
I'm even trying directly to duplicate writes to the port, a la: sw t1, (\port) just repeated. But always after the first one it hangs
<muurkha>
congratulations! unfortunately I don't know enough to help
<gorgonical2>
I've just noticed the sbi spec has a console ecall interface I could use, but I'd like to know if I *must* use it if present and what could be wrong with this implementation. This all works in qemu, by the way
JTL1 is now known as JTL
GenTooMan has quit [Ping timeout: 255 seconds]
Maylay has joined #riscv
<dh`>
if it's a uart you probably need to wait until it's ready for the next character
<dh`>
that or it's interrupting you and your interrupts don't work
<gorgonical2>
I considered that I might need to fully wait for xmit but I didn't have time today to test that. I'll have to check that tomorrow. But the routine *does* have an xmit wait in there. It is entirely possible interrupts aren't working, too
<smaeul>
using the SBI console is entirely optional, though it is extremely convenient
<gorgonical2>
I mean, the interrupts aren't working at that point so definitely if it's trying then that would break
<dh`>
unless you have masked the interrupt or told the uart not to generate one, it probably is
<gorgonical2>
Perhaps. I am not reconfiguring it when we come in from opensbi. I know qemu's uart is very permissive in comparison to real hardware
<gorgonical2>
Oh. The opensbi code runs it with interrupts disabled
<dramforever__>
OpenSBI uses a polling implementation for the sbi_console functions for all uart drivers, AFAIK, so i don't think interrupts matter in this context
<dramforever__>
But I guess you do end up sharing the same UART peripheral with OpenSBI, so if you reconfigure it the OpenSBI drivers might not work
dramforever__ is now known as dramforever
<gorgonical2>
My kernel in general assumes a simple, working uart and just goes with that. I think for the actual hardware and to avoid this collision I am going to convert to the sbi provided console, but I'm motivated to understand this problem anyway
<gorgonical2>
By polling you mean checking the full bit on the tx/rx registers?
<dramforever>
yes
<gorgonical2>
I have a similar implementation, though I can't remember just now if it's actually right: beqz vs bnez
cronos has quit [Ping timeout: 268 seconds]
<gorgonical2>
It could potentially be backward. Though I would expect if it's backward I should see no b ytes written and not just one
<dramforever>
There's a JTAG on the Unmatched board, so perhaps try using that?
<dramforever>
It's going to be much easier than electronics telepathy over IRC
<gorgonical2>
Yeah. I'll try a few things and hopefully they will magically resolve. Then I'll try the jtag when that doesn't work
<gorgonical2>
Have to maybe delegate the problem to a lazy Friday, though. Can't spend like three days hacking on jtag stuff when there's a solution to hand
<gorgonical2>
When I looked at that I suspected there could be some caching behavior at play. Even with the fence insns opensbi uses it doesn't help
<gorgonical2>
I know the unmatched has a cache erratum but that should only be on ifetch and shouldn't crop up here
<dramforever>
Not sure why you wouldn't use JTAG at this point though
<gorgonical2>
I was gonna say something about time constraints, but I'm not convinced I won't need the jtag again in the future so you're probably right
<dramforever>
Yeah I'm just not convinced that 'I have time constraints so I don't want GDB', but of course just do whatever you're feeling comfortable with
<gorgonical2>
Yep lol. When I remembered jtag is basically gdb for hardware you convinced me
<dramforever>
It's *literally* gdb for hardware :P
<gorgonical2>
I've never used jtag stuff before which meant in the past when I did kernel stuff for arm I did it the hard way
<gorgonical2>
I am not always the smartest
<dramforever>
Well that's the thing, you'd need to get openocd, set up udev rules or do some chmod thing, mess around with the config, get it to halt and resume properly etc
<dramforever>
So if something ends up not working it easily takes up all your time
<gorgonical2>
If you write to the uart when the txfifo is full does it cause an exception?
<gorgonical2>
In other words, can I just infinite loop writing some byte?
<gorgonical2>
The manual says the write will be ignored. Also that the txfifo is 8 entries, so I should be able to get away with some writes first
Maylay has quit [Ping timeout: 268 seconds]
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #riscv
ZipCPU has quit [Ping timeout: 244 seconds]
ZipCPU has joined #riscv
cronos has joined #riscv
wingsorc has quit [Quit: Leaving]
<palmer>
gorgonical: if the clock is changing during your UART writes then you might be getting bitten by this <https://github.com/sifive/sifive-blocks/pull/90>, there's a workaround for it in Linux but IIRC it's not called out in the docs