--- Log opened Tue Nov 01 00:00:22 2016 | ||
promach | how do I use https://github.com/olofk/fusesoc/blob/master/fusesoc/build/icestorm.py to compile mor1kx and DMA together ? | 04:55 |
---|---|---|
SMDwrk | promach: what have you already tried? | 05:09 |
SMDwrk | vidya: hi, do you have any success with verilated run? | 05:09 |
promach | SMDwrk: actually now, I am using Zedboard, having much problem with AXI DMA module. | 05:51 |
promach | I am considering the possibility of using mor1kx and DMA | 05:52 |
promach | need to go now | 05:52 |
vidya | SMDwrk: I'm still stuck at that error | 06:43 |
SMDwrk | vidya: how do you compile your binary? | 06:43 |
SMDwrk | I'm still working on getting data from uart | 06:43 |
vidya | SMDwrk: I tried simulating with icarus also but no luck some other error pops up | 06:44 |
SMDwrk | what kind of error? | 06:44 |
vidya | or1k-linux-musl-gcc hello.c -o hello.elf | 06:44 |
vidya | I use this command for compiling | 06:45 |
SMDwrk | Try or1k-elf toolchain | 06:45 |
vidya | When using this :fusesoc sim --sim=icarus wb_sdram_ctr , the toolchain works, but when fusesoc sim --sim=icarus mor1kx-generic --vcd --elf-load=/home/vidya/or1k/csaw_esc_2016/tools/c_codes/hello.elf | 06:46 |
vidya | I get this error::0: assert: netlist.cc:605: failed assertion 0 Aborted (core dumped) ERROR: Failed to build simulation model ERROR: Failed to compile Icarus Simulation model | 06:47 |
vidya | I will try using or1k-elf | 06:47 |
SMDwrk | Do you have any logs for that assert? | 06:47 |
vidya | Sorry I mean simulation works | 06:48 |
vidya | Making jtag_vpi-r2.vpi from jtag_vpi.o... Array too big [4294967295:0]:0: assert: netlist.cc:605: failed assertion 0, Before this it just compiles elf , jtag | 06:49 |
vidya | SMDwrk: Verilator worked with or1k-elf-gcc, Thanks a lot. But why is it so? which one is the latest? | 06:59 |
olofk_ | vidya: The or1k-elf and or1k-linux-musl toolchains have different purposes | 07:02 |
olofk_ | You often need both | 07:02 |
vidya | Is it so that or1k-elf is used to compile for simulation and or1k-linux- is used for running the code on linux? | 07:04 |
ZipCPU|Laptop | SMDwrk: Have you made any more progress on that UART? | 07:05 |
ZipCPU|Laptop | Can you see the UART output line toggling (yet)? | 07:05 |
ZipCPU|Laptop | If you can get it at least that far, I can get you the rest of the way. | 07:05 |
SMDwrk | ZipCPU|Laptop: sure, i see tx pad differs through time and it looks like some uart signals, but I didn't have time to make your uartsim to capture that correctly, that's why I still don't have any output to the stdout | 07:06 |
ZipCPU|Laptop | Two next steps: 1) Make sure you are using the uartsim.cpp from the wbuart32 repository. There was a bug that was fixed after sending the UART your way. | 07:08 |
ZipCPU|Laptop | 2) Transmit an "A" or some other similar signal with transitions one bit period apart. Count the clocks between transitions, and make sure the baud rate is set up properly. | 07:08 |
ZipCPU|Laptop | There's a "setup" line when calling the UART, where you need to give it the number of clocks between transitions. | 07:09 |
ZipCPU|Laptop | Remember, these are clock ticks. There is one clock tick for every time the clock has a high value and a low value, even though the simulation goes through the loop two times. | 07:09 |
ZipCPU|Laptop | The reason for the updated uartsim is that my internal state machine counting was off by one tick. | 07:10 |
ZipCPU|Laptop | Simulation found that bug, and so it's been fixed. Without updating, you should be able to run at a large number of ticks per baud interval. | 07:10 |
ZipCPU|Laptop | Oh ... one other thing to keep in mind, just a sad fact of life today: The uartsim baud rate is not changed when you adjust the baud rate within your code. | 07:11 |
ZipCPU|Laptop | The baud rate you set in your code must match that of the uartsim, or ... you'll have some of the standard baud mismatch problems. | 07:12 |
SMDwrk | I hope to try this today | 07:15 |
-!- Thomas_ is now known as Guest83875 | 10:29 | |
N0xsys | Hi there! | 12:56 |
N0xsys | I have a little question about OpenOCD | 12:56 |
N0xsys | In the OpenOCD terminal, you can use the 'reg' command to print the list of the registers and their values | 12:57 |
N0xsys | But how can I say in my Verilog code that one particular register should be visible by the OpenOCD reg command ? | 12:59 |
wallento | stekern: I am updating the lk port, okay? Some important changes in the code base that stop or1k from building | 13:02 |
RelaxAtion | hello all | 15:17 |
ZipCPU | Hello. | 15:20 |
kc5tja | Greetings. | 15:20 |
ZipCPU | Salutations. | 15:20 |
RelaxAtion | I am havong some difficulties on implementing interruptions on an OpenRisc core and i hope to find some help in here | 15:21 |
RelaxAtion | having* | 15:21 |
RelaxAtion | i already put UPR[PICP] at 1 to enable programmable interruption then i put the PICMR register at 0x00000000 because i don't want unmasked interruptions | 15:25 |
RelaxAtion | then i put my PICSR register at 0x00000003 because i want 3 programmable interruptions ut now i don't know what to write on my verilog file to work with the interruptions | 15:27 |
RelaxAtion | i don't know if i am clear enough sorry | 15:27 |
ZipCPU | Well, here's the best help I can offer: Don't leave the forum. | 15:27 |
ZipCPU | Many of those who understand the OR1K architecture the best respond within 24-hours. | 15:28 |
ZipCPU | If you must leave the forum, then check the logs at http://juliusbaxter.net/openrisc-irc. | 15:28 |
RelaxAtion | ah ah ok i'll let my IRC client open all night then ! | 15:28 |
ZipCPU | Exactly! (Especially since I don't know the answer to your question ...:) | 15:28 |
RelaxAtion | in fact my question is more a verilog issue than an openrisc issue i think | 15:29 |
olofk_ | RelaxAtion: What are you using on the software side? or1k-elf (aka the newlib toolchain)? Or do you run for example Linux? | 15:33 |
olofk_ | And what will you use to trigger the interrupt? An external signal from a peripheral controller, or something else? | 15:34 |
RelaxAtion | i run for an example linux and the interrupt should be triggered by an signal emit when a condition is reached | 15:35 |
olofk_ | If you run Linux it will likely be a lot more complicated | 15:36 |
olofk_ | Not sure how interrupts work at all in Linux to be honest | 15:37 |
olofk_ | You would probably need to write a kernel driver | 15:37 |
olofk_ | Unless you're talking about software interrupts, but I'm not sure how that work either | 15:39 |
olofk_ | I should probably have learned this by now after spending five years of my life on this stupid CPU :) | 15:39 |
ZipCPU | \o/ ! | 15:43 |
olofk_ | mafm: I heard you talked to the Software Freedom Conservancy at debconf :) | 15:49 |
RelaxAtion | ok i discussed with my colleagues and apparently we are working with or1k-elf :) | 15:50 |
olofk_ | RelaxAtion: ok. That will make it simpler | 15:51 |
olofk_ | But what is the source of the interrupt? You say when a condition is reached. Do you mean in some verilog code outside of the CPU, or a condition in some software running on the CPU? | 15:52 |
RelaxAtion | tge | 15:57 |
RelaxAtion | misspress soryr | 15:57 |
RelaxAtion | so we have an altera card, with a cyclone 4 on it | 15:57 |
RelaxAtion | and there is some verilog code running on it | 15:58 |
olofk_ | So far so good :) | 16:00 |
olofk_ | I got to run for a while now, but please explain a bit more and I'll try to help when I get the time | 16:01 |
olofk_ | Also look at this. It might be what you need http://openrisc.io/newlib/docs/html/group__or1k__interrupts.html | 16:01 |
RelaxAtion | i am preparing my words, see you :) | 16:01 |
olofk_ | Perfect! :) | 16:01 |
RelaxAtion | so, we detect a jal, we read the adress in the R9 register, we put it on a pile, then when we detect a jr we check the last adress stocked in the pile and the current adress in R9, if their is a difference the interrupt is trigger | 17:06 |
ZipCPU | RelaxAtion: Are you doing this in simulation, or in hardware? | 17:21 |
ZipCPU | And ... what do you mean by "put it on a pile"? | 17:21 |
RelaxAtion | it is made for hardware | 17:22 |
RelaxAtion | and we create a pile where we stock the adress that's why i said put it on a pile :) | 17:22 |
olofk_ | RelaxAtion: Ah cool. So you have a hardware stack that runs in parallel to the regular stack, and you detect mismatches. | 17:25 |
olofk_ | How big is your pile? | 17:26 |
olofk_ | I've seen small CPU that only have a hw stack, like 8 entries, never using both sw and hw | 17:27 |
RelaxAtion | yes that is the point, we have to develop a defense for FPGA :) our pile isn't that big, less than 30 slots i think, i don't rememeber sorry :/ | 17:28 |
olofk_ | ok, cool. So then I guess your hw stack (or pile) will generate the interrupt, right? | 17:28 |
RelaxAtion | when the mismatch is detect the interrupt is supposed to be generate but we are struggling on how to create this part | 17:30 |
olofk_ | Have you seen in simulations that the interrupt signal is being sent? Is it connected to one of the bits in the irq port on the CPU? | 17:31 |
olofk_ | Which CPU by the way? or1200 or mor1kx. | 17:32 |
olofk_ | I hope mor1kx, because we really want people to move away from or1200 :) | 17:32 |
RelaxAtion | we work on mor1kx don't worry ;) | 17:33 |
RelaxAtion | we are in cappucino on it | 17:33 |
olofk_ | And FuseSoC to build the system? | 17:33 |
RelaxAtion | oh yes fusesoc | 17:33 |
olofk_ | You got top grades, then! :) | 17:34 |
RelaxAtion | non because the interrupt signal isn't created yet, that's where i am struggling | 17:34 |
RelaxAtion | no* | 17:34 |
RelaxAtion | ah ah nice then :) | 17:34 |
olofk_ | ok, so you don't have an interrupt signal yet? Did I understand that correctly? Or do you have one, but can't make the CPU see it? | 17:35 |
olofk_ | I'm talking about a interrupt wire to the CPU here | 17:36 |
RelaxAtion | we don't have an interrupt signal yet | 17:37 |
RelaxAtion | it is still only a dream ahah | 17:37 |
olofk_ | I would recommend starting with that actually. It will make it much easier to see that the software works | 17:39 |
olofk_ | But say that you have a interrupt wire connected to bit 14 in the irq_i vector of mor1kx | 17:40 |
olofk_ | You would then add an interrupt handler with or1k_interrupt_handler_add to register the function to be run when the interrupt triggers | 17:41 |
olofk_ | You would then run or1k_interrupt_enable to enable interrupts in general | 17:41 |
olofk_ | And or1k_interrupt_enable to enable your specific irq line | 17:42 |
olofk_ | oh, the first one should be or1k_interrupts_enable, not or1k_interrupt_enable | 17:42 |
olofk_ | Is this for csaw esc btw? | 17:46 |
RelaxAtion | thank you ! i'll try to implement this tommorrow morning ! yes you guessed right :) | 17:47 |
olofk_ | Good luck. It looks like a cool challenge | 17:48 |
RelaxAtion | it is a really nice experience, but it is really tough, we have to discover and implement a defense in a whole new system in 2 months :) | 17:50 |
RelaxAtion | when you add your classes and others projects you don't have a life anymore ahah ! | 17:51 |
olofk_ | Haha. I was just thinking it would be nice to go back to school for a while to have some time to do other projects :) | 17:52 |
-!- olofk_ is now known as olofk | 17:52 | |
RelaxAtion | well it's my last year but i can still exchange plaes with you ;) | 17:55 |
RelaxAtion | anyway thanks for your help, i'll come agin when this work ! :) good night all | 18:03 |
olofk | Welcome back | 18:09 |
mafm1 | olofk: where did you hear that? I didn't even attend last Debconf | 18:38 |
olofk | mafm1: Hmm... who could that have been then? I talked to a guy at the GSoC mentor summit about our gcc situation and he said he talked to someone at debconf about the same issue a few weeks ago | 18:51 |
olofk | I asked if it was you, and he said yes. He must have mixed up the names then, but still, I wonder who it was then | 18:51 |
mafm1 | olofk: gsoc mentor for Debian, or other projects? | 18:57 |
mafm1 | maybe I did in last Debconf, a year ago :) | 19:01 |
olofk | mafm1: No, his name was Bradley Kuhn (I think) and he was from the Software Freedom Conservancy | 19:06 |
olofk | Time to sleep. Good night | 19:07 |
mafm1 | olofk: ah, right, maybe it was another person, because I think that I never spoke to him... although I would have liked to | 19:07 |
mafm1 | olofk: nite :) | 19:07 |
kc5tja | https://hackaday.io/project/10035-kestrel-computer-project/log/48452-data-sheet-documentation-available | 19:55 |
--- Log closed Wed Nov 02 00:00:24 2016 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!