| --- Log opened Thu Aug 25 00:00:41 2016 | ||
| ZipCPU | wallento: I've built the or1k-elf-gcc compiler, binutils, and newlib according to the instructions, but when I try to build a file I keep getting: | 08:44 |
|---|---|---|
| ZipCPU | undefind symbols: _start, strcmp, malloc, and exit. Any thoughts? | 08:45 |
| wallento | ZipCPU: This looks like newlib is not linked | 09:34 |
| wallento | can you put the problem with some output to the mailing list? | 09:34 |
| ZipCPU | Sure ... but where's the mailing list at these days? Now that opencores is ... slowly vanishing ... | 09:38 |
| ZipCPU | Or is that where you'd like me to post, the opencores forum? | 09:39 |
| shorne | ZipCPU: the list is pretty active right now | 09:54 |
| shorne | openrisc@lists.librecores.org | 09:55 |
| ZipCPU | Aahh !!!! That's what I needed. Thanks, shorne! | 09:55 |
| shorne | no problem | 09:58 |
| ZipCPU | Do you think building binutils with --disable-newlib would have anything to do with it? | 10:25 |
| ZipCPU | Nope. That's not the problem. | 10:38 |
| ssvb | oh, nice, there is a mailing list! | 10:41 |
| * ssvb has seen some other old defunct mailing list somewhere | 10:42 | |
| -!- heroux_ is now known as heroux | 11:14 | |
| ZipCPU | Is anyone else working with an Arty? | 15:34 |
| olofk | ssvb: We have had plenty of mailing lists for OpenRISC. At one point we had two competing, because if disagreements in the project. What a mess that was | 17:54 |
| olofk | SMDhome1: Did you get any further with the verilator stuff. Haven't been able to reach my pc for a while | 17:54 |
| olofk | ZipCPU: Did you get everything compiled and isntalled? | 17:55 |
| olofk | And regarding the somewhat miniscule amount of I/O in the mor1kx-generic system, this is a pure simulation system, and the UART output will be written directly to stdout from the UART core | 17:56 |
| olofk | That's done here https://github.com/olofk/uart16550/blob/master/rtl/verilog/uart_transmitter.v#L274 | 17:57 |
| ZipCPU | olofk: Welcome back! SMD has been helping me get going, but I'm still having problems getting fusesoc to properly compile the mor1kx-generic simulation. | 17:57 |
| ZipCPU | Oh --- and I did find a bug for you to fix ;) | 17:57 |
| olofk | Great :) | 17:57 |
| ZipCPU | The mor1kx-generic fusesoc core listing still requires the avalon bus file, a file that was removed ... | 17:58 |
| olofk | ah, right. I'll fix that | 17:58 |
| ZipCPU | So, yes, I can compile now. Everyone who commented on the list was correct--I was just the clueless one. | 17:58 |
| ZipCPU | I ... just can't build (via fusesoc/verilator) a working mor1kx-generic simulator. | 17:58 |
| ZipCPU | Yeah--here's the missing file: mor1kx_bus_if_avalon.v. Removing this from the core listing, and I get one step further. | 17:59 |
| olofk | Yep. The system seems to work fine with icarus and modelsim now | 18:01 |
| ZipCPU | Not Verilator? | 18:01 |
| olofk | Yes, verilator works too | 18:02 |
| olofk | But! | 18:02 |
| olofk | There is an ancient problem with the verilator backend for mor1kx-generic | 18:03 |
| ZipCPU | What's that? | 18:03 |
| olofk | SMDhome1, ZipCPU: You need to specify absolute path to the elf file you want to load | 18:03 |
| ZipCPU | If it's the UART, I can fix that. I'm getting all kinds of other problems. | 18:03 |
| ZipCPU | Ok, but that's not the bug I'm getting. | 18:04 |
| olofk | Also, there might be another problem. A while ago verilator changed how the classes are defined | 18:04 |
| olofk | I can't remember if I converted to the new way | 18:05 |
| ZipCPU | I'm getting a bug in wb_common.v, line 17, saying that $error is "only allowed under an assertion." | 18:05 |
| ZipCPU | And a warning on the orpsoc_top.v, line 46, that "Signal definition not found, creating implicitly: tdo_padoe_o" | 18:05 |
| ZipCPU | I mean, a lot of these I could fix, but ... who would I submit a fix to? | 18:06 |
| olofk | Oh... I see now that I have a local change that replaces $error with $display | 18:06 |
| ZipCPU | For example, the $error line could be wrapped in `ifndef VERILATOR preprocessor directives, as an example. | 18:07 |
| olofk | Yeah, but I actually think $error is wrong altogether. I think that's a system verilog thing | 18:07 |
| ZipCPU | But ... what about the undefined wire in orpsoc_top.v, "tdo_padoe_o" on line 46? | 18:07 |
| olofk | And I don't want to introduce a single stupid line that breaks compatibility for sims that can't handle sv :) | 18:08 |
| ZipCPU | Sure ... so I can patch, but not "fix" ... got it. Are you the maintainer I should submit that to? | 18:09 |
| ZipCPU | (Once I start getting list-serve e-mails, I'll probably submit some of these ...) | 18:09 |
| olofk | I'd love to get both patches and bug reports | 18:09 |
| ZipCPU | <Grin> I personally love it when bug reports come with suggested patches, myself ... ;) | 18:10 |
| olofk | ok, I replaced error with display now and pushed | 18:11 |
| olofk | I had that locallly since god knows when | 18:11 |
| olofk | Now to padoe | 18:11 |
| olofk | We could just make that connection empty. It's not used for anything | 18:11 |
| olofk | I'll do that right away | 18:12 |
| ZipCPU | How do I force fusesoc to go back and reload from the repository, to pick up your change? | 18:12 |
| olofk | ohh.... I lied | 18:12 |
| olofk | I said that I changed to the new Verilator style for classes | 18:12 |
| olofk | That turned out to also be something I have locally but never pushed | 18:13 |
| olofk | ZipCPU, SMDhome1: If you're having trouble with mor1kx-generic and a reasonably new verilator, try this patch http://9ea4cb9c3ed0f7c7.paste.se/ | 18:15 |
| olofk | hmm.. I found another local change here | 18:15 |
| ZipCPU | Actually, SMDhome1 wasn't having Verilator problems, which I found strange. I was having them. He had a newer version of Verilator, making me wonder if I needed to upgrade. | 18:15 |
| olofk | This one https://www.dropbox.com/s/yzs86jv4c6lui0z/hello_uart.elf?dl=0 works for me in icarus, modelsim and verilator | 18:17 |
| olofk | If you want a reference elf | 18:17 |
| ZipCPU | Any suggested way of forcing fusesoc to go back and re-read its cores from the repository? | 18:18 |
| olofk | It should always do that | 18:20 |
| olofk | Unless you run with --keep | 18:21 |
| olofk | SMDhome1: I think I might know what's wrong! | 18:21 |
| olofk | There are two common ways to do putc | 18:21 |
| olofk | The normal way is to push a byte through the UART | 18:21 |
| olofk | And the other way, is a faster way that is only used for simulations. It works by putting your byte in register R3 and the call l.nop 0x3 | 18:22 |
| olofk | The thing is that there isn't any code in the verilog that does the print | 18:23 |
| olofk | Instead we have a monitor in the testbench that checks each instruction to see if there was a l.nop 0x3, and if so prints the byte | 18:24 |
| olofk | Looking at the verilator testbench there isn't anything that looks for this instruction, so the bytes are never printed | 18:25 |
| olofk | Two solutions | 18:25 |
| olofk | Which option to use (uart or l.nop 0x3) is decided by which board-specific routines that are called by newlib | 18:25 |
| olofk | By default, the routines for the or1ksim libgloss target are used, which uses nops | 18:26 |
| olofk | so... | 18:26 |
| olofk | either... | 18:26 |
| olofk | 1. Compile with -mde0_nano (any board would probably work. They're all in newlib/libgloss/or1k/boards) | 18:27 |
| olofk | or... | 18:27 |
| olofk | 2. Add the code to check for nops in tb.cpp | 18:27 |
| olofk | I could have sworn that was already present in tb.cpp :/ | 18:28 |
| ZipCPU | or ... 3. Add in the uart simulator that I was mentioning, that turns a UART into a functioning UART port, only forwarding it over TCP. | 18:28 |
| olofk | Yes. True | 18:28 |
| ZipCPU | If you'd like, I *could* package it as a separate core ... | 18:28 |
| olofk | I'd love that. Been wanting a core like that for several years, but never gotten around to implement it | 18:29 |
| olofk | We do that for JTAG already | 18:29 |
| ZipCPU | If you don't mind, I'll throw my Verilog UART code in as well--since the two share the same setup definition. | 18:30 |
| olofk | Up to you | 18:30 |
| ZipCPU | Consider it done, but expect it to take a couple of days. | 18:30 |
| olofk | I'm happy to help and review the core file | 18:30 |
| olofk | Awesome! | 18:30 |
| olofk | Oh well. That's it for me. Time to sleep | 18:32 |
| olofk | Booked a flight to Bologna now too | 18:32 |
| ZipCPU | But ... but .... but ... | 18:32 |
| ZipCPU | fusesoc still hasn't picked up the updated wb_common.v file ... ??? | 18:32 |
| olofk | The one I pushed? | 18:33 |
| ZipCPU | The one I thought you pushed ... are we talking about the same file? | 18:33 |
| olofk | Try fusesoc update | 18:33 |
| olofk | Ah.. now I understand what you mean | 18:33 |
| olofk | I thought you asked if fusesoc reloads the cores from disk on every run, but you were asking if it checked for newer versions of the orpsoc-cores library | 18:34 |
| olofk | To which the answers are yes and no :) | 18:34 |
| ZipCPU | Okay. Now we're communicating then. I'm good then--off to bed with you. ;) | 18:34 |
| olofk | Cool. Speak soon | 18:35 |
| ZipCPU | olofk: When you wake up, what does this mean: "WARN: plusargs section is deprecated and will not be parsed by FuseSoC. Please migrate to parameters in" (lots of files) | 18:38 |
| --- Log closed Fri Aug 26 00:00:42 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!