IRC logs for #openrisc Thursday, 2016-08-25

--- Log opened Thu Aug 25 00:00:41 2016
ZipCPUwallento: 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
ZipCPUundefind symbols: _start, strcmp, malloc, and exit.  Any thoughts?08:45
wallentoZipCPU: This looks like newlib is not linked09:34
wallentocan you put the problem with some output to the mailing list?09:34
ZipCPUSure ... but where's the mailing list at these days?  Now that opencores is ... slowly vanishing ...09:38
ZipCPUOr is that where you'd like me to post, the opencores forum?09:39
shorneZipCPU: the list is pretty active right now09:54
ZipCPUAahh !!!!   That's what I needed.  Thanks, shorne!09:55
shorneno problem09:58
ZipCPUDo you think building binutils with --disable-newlib would have anything to do with it?10:25
ZipCPUNope.  That's not the problem.10:38
ssvboh, nice, there is a mailing list!10:41
* ssvb has seen some other old defunct mailing list somewhere10:42
-!- heroux_ is now known as heroux11:14
ZipCPUIs anyone else working with an Arty?15:34
olofkssvb: 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 was17:54
olofkSMDhome1: Did you get any further with the verilator stuff. Haven't been able to reach my pc for a while17:54
olofkZipCPU: Did you get everything compiled and isntalled?17:55
olofkAnd 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 core17:56
olofkThat's done here
ZipCPUolofk: 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
ZipCPUOh --- and I did find a bug for you to fix ;)17:57
olofkGreat :)17:57
ZipCPUThe mor1kx-generic fusesoc core listing still requires the avalon bus file, a file that was removed ...17:58
olofkah, right. I'll fix that17:58
ZipCPUSo, yes, I can compile now.  Everyone who commented on the list was correct--I was just the clueless one.17:58
ZipCPUI ... just can't build (via fusesoc/verilator) a working mor1kx-generic simulator.17:58
ZipCPUYeah--here's the missing file: mor1kx_bus_if_avalon.v.  Removing this from the core listing, and I get one step further.17:59
olofkYep. The system seems to work fine with icarus and modelsim now18:01
ZipCPUNot Verilator?18:01
olofkYes, verilator works too18:02
olofkThere is an ancient problem with the verilator backend for mor1kx-generic18:03
ZipCPUWhat's that?18:03
olofkSMDhome1, ZipCPU: You need to specify absolute path to the elf file you want to load18:03
ZipCPUIf it's the UART, I can fix that.  I'm getting all kinds of other problems.18:03
ZipCPUOk, but that's not the bug I'm getting.18:04
olofkAlso, there might be another problem. A while ago verilator changed how the classes are defined18:04
olofkI can't remember if I converted to the new way18:05
ZipCPUI'm getting a bug in wb_common.v, line 17, saying that $error is "only allowed under an assertion."18:05
ZipCPUAnd a warning on the orpsoc_top.v, line 46, that "Signal definition not found, creating implicitly: tdo_padoe_o"18:05
ZipCPUI mean, a lot of these I could fix, but ... who would I submit a fix to?18:06
olofkOh... I see now that I have a local change that replaces $error with $display18:06
ZipCPUFor example, the $error line could be wrapped in `ifndef VERILATOR preprocessor directives, as an example.18:07
olofkYeah, but I actually think $error is wrong altogether. I think that's a system verilog thing18:07
ZipCPUBut ... what about the undefined wire in orpsoc_top.v, "tdo_padoe_o" on line 46?18:07
olofkAnd I don't want to introduce a single stupid line that breaks compatibility for sims that can't handle sv :)18:08
ZipCPUSure ... 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
olofkI'd love to get both patches and bug reports18:09
ZipCPU<Grin>  I personally love it when bug reports come with suggested patches, myself ... ;)18:10
olofkok, I replaced error with display now and pushed18:11
olofkI had that locallly since god knows when18:11
olofkNow to padoe18:11
olofkWe could just make that connection empty. It's not used for anything18:11
olofkI'll do that right away18:12
ZipCPUHow do I force fusesoc to go back and reload from the repository, to pick up your change?18:12
olofkohh.... I lied18:12
olofkI said that I changed to the new Verilator style for classes18:12
olofkThat turned out to also be something I have locally but never pushed18:13
olofkZipCPU, SMDhome1: If you're having trouble with mor1kx-generic and a reasonably new verilator, try this patch
olofkhmm.. I found another local change here18:15
ZipCPUActually, 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
olofkThis one works for me in icarus, modelsim and verilator18:17
olofkIf you want a reference elf18:17
ZipCPUAny suggested way of forcing fusesoc to go back and re-read its cores from the repository?18:18
olofkIt should always do that18:20
olofkUnless you run with --keep18:21
olofkSMDhome1: I think I might know what's wrong!18:21
olofkThere are two common ways to do putc18:21
olofkThe normal way is to push a byte through the UART18:21
olofkAnd 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 0x318:22
olofkThe thing is that there isn't any code in the verilog that does the print18:23
olofkInstead 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 byte18:24
olofkLooking at the verilator testbench there isn't anything that looks for this instruction, so the bytes are never printed18:25
olofkTwo solutions18:25
olofkWhich option to use (uart or l.nop 0x3) is decided by which board-specific routines that are called by newlib18:25
olofkBy default, the routines for the or1ksim libgloss target are used, which uses nops18:26
olofk1. Compile with -mde0_nano (any board would probably work. They're all in newlib/libgloss/or1k/boards)18:27
olofk2. Add the code to check for nops in tb.cpp18:27
olofkI could have sworn that was already present in tb.cpp :/18:28
ZipCPUor ... 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
olofkYes. True18:28
ZipCPUIf you'd like, I *could* package it as a separate core ...18:28
olofkI'd love that. Been wanting a core like that for several years, but never gotten around to implement it18:29
olofkWe do that for JTAG already18:29
ZipCPUIf you don't mind, I'll throw my Verilog UART code in as well--since the two share the same setup definition.18:30
olofkUp to you18:30
ZipCPUConsider it done, but expect it to take a couple of days.18:30
olofkI'm happy to help and review the core file18:30
olofkOh well. That's it for me. Time to sleep18:32
olofkBooked a flight to Bologna now too18:32
ZipCPUBut ... but .... but ...18:32
ZipCPUfusesoc still hasn't picked up the updated wb_common.v file ... ???18:32
olofkThe one I pushed?18:33
ZipCPUThe one I thought you pushed ... are we talking about the same file?18:33
olofkTry fusesoc update18:33
olofkAh.. now I understand what you mean18:33
olofkI 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 library18:34
olofkTo which the answers are yes and no :)18:34
ZipCPUOkay.  Now we're communicating then.  I'm good then--off to bed with you.  ;)18:34
olofkCool. Speak soon18:35
ZipCPUolofk: 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 2.15.2 by Marius Gedminas - find it at!