<Shatur>
Should the CPU reset address point to ROM or SpiFlash?
<_florent_>
Shatur: it will depends what you are trying to do. I'm having trouble understanding what you want to achieve, so as described in the issue, sharing the big picture would help to answer :)
<Shatur>
_florent_: makes sense, answered :)
<Shatur>
in the issue*
<_florent_>
Shatur: ok thanks, just answered. But I don't think the issue is in LiteX, it's probably just some adaptation to do to the Rust example you are using (I'm not familiar with Rust, but pepijndevos[m] the author of the example is here in the channel)
<pepijndevos[m]>
Oh hello
<pepijndevos[m]>
What's going on?
<Shatur>
pepijndevos[m]: hi! I trying to run your Rust example on litex_sim, but have compilation error: section '.text.dummy' will not fit in region 'spiflash': overflowed by 18446744073675997184 bytes
<Shatur>
I regenerated svd.soc and memory.x using litex_sim with the following command: litex_sim --csr-svd=soc.svd --memory-x=memory.x --with-spi-flash
<Shatur>
And just replaced your files with these two from litex_sim.
<pepijndevos[m]>
I've never used litex_sim with Rust. But make sure you use a release build
<pepijndevos[m]>
But also... That's a lot of bytes...
<Shatur>
pepijndevos[m]: Yes, I tried release. I believe it because of incorrect CPU reset location.
<Shatur>
Because if I change _stext = 0x000000; into 0x01000000 it compiles.
<Shatur>
We se so many bytes because it's a negative number. I.e. the offset is incorrect.
<pepijndevos[m]>
Right
<Shatur>
pepijndevos[m]: So there is an issue with memory.x generation for simulator?
<Shatur>
pepijndevos[m]: I tried asking, people rarely use simulator for such things :(
<pepijndevos[m]>
So what's wrong with changing the reset address as florent suggested
<pepijndevos[m]>
Or putting sections in rom
<Shatur>
pepijndevos[m]: I changed it, it compiles. But is this expected? I meant shouldn't litex_sim generation point to the correct location?
<Shatur>
Also after compilation I tried to put the generated image to rom and to sdram. It boots, but there is no output from UART (I assume it should print to console by default via serial2console module which is enabled by default).
<Shatur>
in boots in both variants (from rom rom instead of BIOSN and from sdram with BIOS from rom)
<Shatur>
This is why I not sure if I even did it correctly.
<Shatur>
There is no tutorials on running software on litex_sim, unfortunately.
<Shatur>
Okay, thank you a lot! Your example is very usefull.
<Shatur>
pepijndevos[m]: Last question: what PROVIDE(UART = DefaultHandler); is doing?
<pepijndevos[m]>
I can't remember. I think it might add a dummy interrupt handler or something?
<Shatur>
Will play with it, thanks!
<Shatur>
For some reason I don't see UART output in simulator console, and this is probably why.
DerekKozel[m] has quit [*.net *.split]
DerekKozel[m] has joined #litex
amstan has quit [Ping timeout: 252 seconds]
leons has quit [Ping timeout: 252 seconds]
sajattack[m] has quit [Ping timeout: 252 seconds]
shoragan[m] has quit [Ping timeout: 248 seconds]
pepijndevos[m] has quit [Ping timeout: 240 seconds]
xobs[m] has quit [Ping timeout: 248 seconds]
CarlFK has quit [Ping timeout: 248 seconds]
DerekKozel[m] has quit [Ping timeout: 252 seconds]
a3f has quit [Ping timeout: 264 seconds]
Crofton[m] has quit [Ping timeout: 264 seconds]
jevinskie[m] has quit [Ping timeout: 265 seconds]
rowang077[m] has quit [Ping timeout: 265 seconds]
proppy[m] has quit [Ping timeout: 268 seconds]
johnsel92[m] has quit [Ping timeout: 272 seconds]
mikolajw has quit [Ping timeout: 272 seconds]
a3f has joined #litex
pepijndevos[m] has joined #litex
proppy[m] has joined #litex
johnsel92[m] has joined #litex
xobs[m] has joined #litex
a3f has quit [Quit: Bridge terminating on SIGTERM]
pepijndevos[m] has quit [Quit: Bridge terminating on SIGTERM]
proppy[m] has quit [Quit: Bridge terminating on SIGTERM]
johnsel92[m] has quit [Quit: Bridge terminating on SIGTERM]
xobs[m] has quit [Client Quit]
shoragan[m] has joined #litex
DerekKozel[m] has joined #litex
jevinskie[m] has joined #litex
amstan has joined #litex
Crofton[m] has joined #litex
sajattack[m] has joined #litex
leons has joined #litex
pepijndevos[m] has joined #litex
CarlFK has joined #litex
mikolajw has joined #litex
FabM has quit [Ping timeout: 244 seconds]
proppy[m] has joined #litex
johnsel92[m] has joined #litex
rowang077[m] has joined #litex
a3f has joined #litex
xobs[m] has joined #litex
<Shatur>
Should UART data be output to the litex_sim console? I'm trying to run a simple example where I write "Hello world" to UART but I can't see anything. Is this expected?
Finde_ has joined #litex
Finde has quit [Read error: Connection reset by peer]
<leons>
That depends on whether you loaded the console module, but running vanilla litex_sim should do that
<leons>
Are you sure your printing a line break at the end to flush buffers?
<Shatur>
leons: Yes, I didn't override `--serial`, so it should be loaded. Thank. Then the issue in how I write to UART...
<Shatur>
Yes, I adding a newline, hm...
<leons>
Out of curiosity, what are you trying to run? Custom bare metal or some OS / abstraction layer?
<Shatur>
leons: Custom bare metal. I trying to print "Hello world" to console :)
<leons>
I've spent some significant time building this implementation and ironing out bugs with edge cases, I'd say it's a fairly complex, complete and battle-tested implementation (sent Gigabytes of random, unpredictable data with variable timing & scheduling through that)
<Shatur>
leons: Thanks, will take a look! I just trying to start from something simple, I'm new to hardware / fpga.
<leons>
Shatur: sure, makes sense. While the LiteUART seems rather simple at first, I found the register API to be a little unergonomic when it comes to edge cases. Perhaps the implementation can give you some hints.
<Shatur>
leons: made it work with simple naive implementation, thank you!
<Shatur>
But I think it worth using what you linked. Is it available on crates?
<leons>
Shatur: No, I think it's rather tightly coupled with other parts of the Tock ecosystem, e.g. the register abstraction and UART HIL
<Shatur>
leons: oh, I see. Probably will try to write something simillar using the link you provided as a reference.
<Shatur>
Finally I have something working :) Because before I even wasn't sure if it was loaded correctly.
<leons>
Shatur: I know the feeling. Congrats!
Finde_ is now known as Finde
Finde has quit [Quit: WeeChat 2.3]
Finde has joined #litex
<jevinskie[m]>
trabucayre: I've been thinking about integrating other simulators into litex and was wondering if your generic_toolchain work would touch on that or ease it? I did something a while ago to get LiteX simulations working with cocotb and iverilog but it was kinda hacky. I'd like to get plain iverilog support, then cocotb integration, and maybe finally questa for some perf improvements over iverilog.
<trabucayre>
jevinskie[m]: I haven't currently managed to check verilator.py but code seems have a structure quite equivalent to GenericPlatform so I assume it may possible to do something
<trabucayre>
s/GenericPlatform/GenericToolchain/g
<trabucayre>
I don't know if adding sim aspect in GenericToolchain is the good way due to complexity
david-sawatzke[m has joined #litex
<trabucayre>
maybe a GenericSimToolchain with the same philosophy
<jevinskie[m]>
Ok! Looking back at it it really wasn't bad, looks like it was less than 200 lines for the Toolchain class plus the cocotb<>migen RPyc magic and the pydev magic (needed for debugging under PyCharm, that was infuriating to figure out). https://github.com/jevinskie/litex/blob/jev/main/litex/build/sim/cocotb.py#L132
<jevinskie[m]>
One of the limitations of verilator is lack of support for delayed statements so most vendor provided models won't work.
<trabucayre>
jevinskie[m]: sorry day job meeting :-(
<trabucayre>
your code is not really big so I'm not sure using a generic approach is really relevant
<trabucayre>
For toolchain it's make more sense, and I think to another round of refactoring.
<jevinskie[m]>
No problem!
Shatur has quit [Quit: Konversation terminated!]
lexano has quit [Ping timeout: 264 seconds]
lexano has joined #litex
cr1901_ has joined #litex
cr1901 has quit [Ping timeout: 272 seconds]
nelgau has quit [*.net *.split]
tpb has quit [*.net *.split]
SpaceCoaster has quit [*.net *.split]
indy has quit [*.net *.split]
geertu has quit [*.net *.split]
rektide_ has quit [*.net *.split]
mlaga97 has quit [*.net *.split]
a3f has quit [*.net *.split]
xobs[m] has quit [*.net *.split]
proppy[m] has quit [*.net *.split]
johnsel92[m] has quit [*.net *.split]
rowang077[m] has quit [*.net *.split]
leons has quit [*.net *.split]
DerekKozel[m] has quit [*.net *.split]
pepijndevos[m] has quit [*.net *.split]
mikolajw has quit [*.net *.split]
Crofton[m] has quit [*.net *.split]
amstan has quit [*.net *.split]
jevinskie[m] has quit [*.net *.split]
shoragan[m] has quit [*.net *.split]
CarlFK has quit [*.net *.split]
sajattack[m] has quit [*.net *.split]
toshywoshy has quit [*.net *.split]
Emantor has quit [*.net *.split]
Abhishek_ has quit [*.net *.split]
guan has quit [*.net *.split]
LoveMHz has quit [*.net *.split]
oter has quit [*.net *.split]
zyp has quit [*.net *.split]
Xesxen has quit [*.net *.split]
sorear has quit [*.net *.split]
RaYmAn has quit [*.net *.split]
lambda has quit [*.net *.split]
DoubleJ has quit [*.net *.split]
_franck_ has quit [*.net *.split]
benh has quit [*.net *.split]
tcal has quit [*.net *.split]
xobs[m] has joined #litex
a3f has joined #litex
rowang077[m] has joined #litex
proppy[m] has joined #litex
johnsel92[m] has joined #litex
mikolajw has joined #litex
leons has joined #litex
CarlFK has joined #litex
pepijndevos[m] has joined #litex
Crofton[m] has joined #litex
amstan has joined #litex
jevinskie[m] has joined #litex
sajattack[m] has joined #litex
shoragan[m] has joined #litex
DerekKozel[m] has joined #litex
nelgau has joined #litex
indy has joined #litex
toshywoshy has joined #litex
tpb has joined #litex
SpaceCoaster has joined #litex
Emantor has joined #litex
geertu has joined #litex
rektide_ has joined #litex
Abhishek_ has joined #litex
lambda has joined #litex
guan has joined #litex
sorear has joined #litex
RaYmAn has joined #litex
benh has joined #litex
Xesxen has joined #litex
zyp has joined #litex
oter has joined #litex
DoubleJ has joined #litex
mlaga97 has joined #litex
tcal has joined #litex
LoveMHz has joined #litex
_franck_ has joined #litex
<jevinskie[m]>
Iām not keen on redoing all of the modules in VPI or adding an abstraction layer. Maybe I can emulate the verilator interface with VPI? š¬