--- Log opened Fri Feb 20 00:00:49 2015 | ||
mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/fee34915756a1feb5beceff1fba50f6ee3f2b10f | 03:22 |
---|---|---|
mor1kx | mor1kx/master fee3491 Stefan Kristiansson: cappuccino: add support for l.msync... | 03:22 |
olofk | When I woke up today I realized just how great a serial bootloader would be | 06:36 |
olofk | stekern: I see that mor1kx support msync now :) | 06:36 |
olofk | poke53281: Hopefully, I should just be able to put links or lynx in my initramfs and run it, right? | 06:50 |
wallento | stekern: nice one the msync! | 08:04 |
poke53281 | olofk: Almost, you need musl as well. And probably ncurses | 09:03 |
poke53281 | And openssl I guess. | 09:03 |
poke53281 | static binaries are so ancient :) | 09:04 |
stekern | olofk: yup, interrupt handler has finished, back to adding vm support to the lk or1k port ;) | 09:15 |
Me1234_ | olofk: 0xb0000000:00010000 | 12:34 |
olofk | Me1234_: I'm not entirely sure what you just wrote :) | 12:37 |
Me1234_ | olofk: output of command x 0xb0000000 in GDB. 0xb0000000 is the SPI core address. | 12:44 |
poke53281 | http://2.bp.blogspot.com/_I182g1bK2Yw/TIwlCNFT9aI/AAAAAAAABPM/idRUu9vvJjg/s1600/WTF.GIF | 12:45 |
poke53281 | reminds me of the mysterion message of starflight, which turns out to be a phone number of one of the developers. :) | 12:45 |
Me1234_ | olofk: I am trying to connect old SPI core to ORPSOCv3 | 12:45 |
Me1234_ | olofk: Is this config in wb_intercon.conf ok? | 12:51 |
Me1234_ | [slave spi0] | 12:51 |
Me1234_ | datawidth=8 | 12:51 |
Me1234_ | offset=0xb0000000 | 12:51 |
Me1234_ | size=8 | 12:51 |
olofk | Me1234_: And 0xb0000000 is where it's mapped in orpsocv2? | 12:52 |
Me1234_ | olofk: I have checked, it is same for ORPSoCv2 and ORPSoCv3 | 12:57 |
olofk | cool. And your wb_intercon.conf looks good. Did you regenerate the verilog files? | 12:59 |
olofk | But since you can read the registers at 0xb0000000 I guess that it should be ok. Otherwise you would get an error | 13:00 |
Me1234_ | olofk: It is not my wb_intercon. | 13:01 |
Me1234_ | olofk: I only wanted to ask if everything is ok with size | 13:02 |
Me1234_ | olofk : It is a default orpsocv3 wb_intercon.conf | 13:02 |
Me1234_ | olofk: If I read out of ram and peripherals, for example | 13:09 |
Me1234_ | (gdb) x 0x2000001 | 13:09 |
Me1234_ | 0x2000001: 0x48484848 | 13:09 |
Me1234_ | olofk: No errors occur?! | 13:09 |
Me1234_ | olofk: And read value is non-zero. Is it wb_intercon bug? | 13:10 |
Me1234_ | olofk: After restart it is | 13:16 |
Me1234_ | (gdb) x 0x2000001 | 13:16 |
Me1234_ | 0x2000001: 0x00000000 | 13:16 |
olofk | hmm... | 13:20 |
olofk | If this was an access from the CPU you would get both alignment exception and bus error I guess | 13:21 |
olofk | Don't think it's a bug in wb_intercon.conf, but I'm not sure how the debug interface handles errors | 13:22 |
olofk | Can you for example write something to address 0x0 and read it back after you have tried to access 0x2000001 | 13:22 |
Me1234_ | olofk: Am I writing to memory the right way? set {char}0x00000000 = 42 | 13:56 |
Me1234_ | olofk: I set 0x0 to 42, try to read from 0x2000001, read 0x0 and get 42. | 13:59 |
juliusb | olofk: hey man, not sure if you've mentioned this already, but are you planning on getting a Google summer of code program in this year at all for FuseSoC or something related to it? | 14:13 |
olofk | juliusb: Actually, Alex approached me with some FuseSoC ideas from the lowRISC side | 14:14 |
olofk | I would love to have some OpenRISC projects, but I don't want to run it alone | 14:15 |
juliusb | deadline is today right? | 14:16 |
juliusb | for organisations at least | 14:16 |
juliusb | what were you thinking on the OR front? | 14:16 |
olofk | juliusb: We got this from last year opencores.org/or1k/OR1K:FutureWork | 14:23 |
olofk | Updated it slightly a few weeks ago | 14:23 |
olofk | Actually, I see that VDSO is on the list. That one's done now | 14:24 |
Hesham | olofk: According to the web-page, Linux is not the only OS that's running on OpenRISC. Last year GSoC project [1] provided an RTEMS port that works on or1ksim. | 14:56 |
Hesham | [1] https://devel.rtems.org/wiki/Projects/GSoC/OpenRISC | 14:56 |
Me1234_ | Does newlib have sleep function? Or usleep? | 15:03 |
Me1234_ | 15:04 | |
Me1234_ | Or do I need to use the timer? | 15:05 |
wallento | Hesham: I started putting it on the new website | 15:17 |
wallento | Are you planning to wrap up your tutorial? | 15:18 |
wallento | https://openrisc.github.io/software.html#RTEMS | 15:18 |
Hesham | wallento: Which website? | 15:18 |
wallento | I will complete the information on the cross compiler and kernel | 15:18 |
Hesham | Ah thanks, I have some blog posts | 15:19 |
wallento | and there is also a release build of the toolchain: http://lis.ei.tum.de/pub-download/openrisc-builds/or1k-rtems/ | 15:19 |
wallento | I also comitted a patch to rsb recently that changes binutils to upstream 2.25 | 15:19 |
wallento | I also got RTEMS to build (only a slight change to your blog: bsp is or1ksim and not or1k_or1ksim) | 15:20 |
Hesham | Great | 15:20 |
wallento | but I cannot run it on the de0_nano system, some UART issue it seems | 15:20 |
wallento | this is where I was last monday and did not find time until now unfortunately | 15:20 |
Hesham | I didn't reach the FPGA implementation part | 15:20 |
wallento | Its maybe just a different BSP | 15:20 |
wallento | but I will have a look at it next week | 15:21 |
Hesham | I actually tried hard to get OpenRISC on my Atlys board but couldn't | 15:21 |
Hesham | Something relates to DDR2 IIRC | 15:21 |
Hesham | But great work wallento, would you need some help writing a tutorial for how to run RTEMS on or1ksim? | 15:22 |
Hesham | I intended to write one, but I got busy | 15:22 |
wallento | Hesham: That would be nice | 15:54 |
wallento | I also started some stuff, but did not finalize it. It's straight forward from your blog posts, but with some slioght changes aber upstream | 15:55 |
Hesham | OK, I'll try to write some simple blog posts and tell you then | 15:59 |
Hesham | Have you managed to run OpenRISC on de0_nano? Baremetal? | 15:59 |
olofk | Has anyone had problem with ethmac under Linux? I'm getting a lot of dribble nibble, packet dropped and wrong CRC messages in Linux | 16:41 |
olofk | aha. Seems like maxpaln had this problem a while ago. Probably need to force it to not use 1gbps | 16:57 |
olofk | Ahh.. I was hoping for a slightly better solution :( http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-01-02.log.html#t16:25 | 17:27 |
Me1234 | Is slave selects register in simple_spi (default ORPSoCv3) b0000000 + 4 | 20:41 |
olofk | Me1234: Looks like it. There's an interesting thing to note here though | 20:57 |
olofk | The upstream simple_spi core doesn't have a slave select register. This is patched locally in orpsoc-cores | 20:58 |
olofk | It could be worth checking that the patch applied correctly. You're using de0_nano, right? | 20:59 |
Me1234 | olofk: So to select the EPCS64 I need to write 1 ro b0000004 | 20:59 |
Me1234 | olofk: Yes, I use de0_nano | 20:59 |
olofk | I guess so. To be honest, I haven't really looked at simple_spi | 21:00 |
olofk | To be sure that the patch applied, could you check in build/de0_nano/src/simple_spi/simple_spi_top.v and make sure that there is a output called ss_o | 21:00 |
Me1234 | olofk: There is ss_o | 21:03 |
olofk | ok, then we can probably rule that out | 21:04 |
Me1234 | My current test program, that does NOT work:Leds show 10100000 and uart outputs the same. http://pastie.org/9967070 | 21:06 |
Me1234 | olofk: . | 21:06 |
olofk | Me1234: Make sure to declare the pointers as volatile | 21:10 |
olofk | It would be interesting to run that program in a simulator as well | 21:11 |
olofk | Might want to remove the printf's for that though | 21:11 |
olofk | Do you have Icarus installed? | 21:11 |
olofk | and gtkwave | 21:11 |
Me1234 | I think I have, and if I do not I can install it via apt (I use ubuntu) | 21:12 |
Me1234 | olofk: I did not figure out how to run the sim last time I tried it | 21:12 |
olofk | cool. Then you should be able to run "fusesoc sim --force de0_nano --vcd --elf-load=<path to your elf file> --timeout=<some value. Try 10000 or something to begin with> | 21:13 |
Me1234 | olofk: quite hard using pastie, blocked by provider. Need to connect VPN every time. | 21:15 |
olofk | That's annoying | 21:16 |
Me1234 | olofk: Fusesoc ends with error: http://pastie.org/9967110 | 21:16 |
Me1234 | olofk: it is not verilator | 21:17 |
olofk | Ah crap. I have probably fixed that locally. Recognize the error | 21:17 |
Me1234 | olofk: ERROR: Failed to compile Icarus Simulation model | 21:17 |
Me1234 | olofk : Icarus | 21:17 |
olofk | There are some weird syntax errors in the i2c controller. | 21:18 |
Me1234 | olofk: I did not have Icarus installed also. Thought it is verilator | 21:19 |
olofk | ok, this will require some blind hacking. I don't have the right tools on this computer, so I can't test it myself | 21:21 |
olofk | Edit ~/.cache/fusesoc/i2c/i2c_master_byte_ctrl.v | 21:21 |
Me1234 | olofk: It seems that opencores SVN is down. Not opencores.org in general, only svn. | 21:22 |
Me1234 | I created a backup copy of ~/.cache/fusesoc, so I have the files | 21:22 |
olofk | Change "input my_addr" to "input [6:0] my_addr" | 21:22 |
olofk | That's good | 21:22 |
olofk | Hopefully that change will be enough to run the simulation | 21:24 |
olofk | :( | 21:25 |
Me1234 | olofk: connecting VPN caused IRC to disconnect | 21:25 |
Me1234 | olofk: usesoc output now: http://pastie.org/9967138 | 21:26 |
olofk | Me1234: God, that must be annoying | 21:26 |
olofk | Ah good. Almost there | 21:26 |
olofk | I think that your version of libelf is too old | 21:26 |
olofk | Can't remember if it's called libelf or elfutils in ubuntu | 21:26 |
olofk | Which ubuntu version are you using? | 21:27 |
Me1234 | olofk: libelf-dev is not installed | 21:27 |
Me1234 | 14.04 | 21:27 |
olofk | Could be that easy. Try to install that | 21:27 |
olofk | And you can ignore all the warnings that say "(null):0: tgt-vvp warning: V0.9 may give incorrect results when casting an unsigned value greater than 63 bits to a real value." | 21:28 |
olofk | They are harmless icarus warnings, but they are impossible to disable. Very annoying | 21:28 |
olofk | Can you check the version of libelf in /usr/lib | 21:29 |
Me1234 | Now the results here, after installing libelf-dev: http://pastie.org/9967151 | 21:29 |
olofk | Perfect! It works now | 21:30 |
olofk | So now you should have a file called build/de0_nano/sim-icarus/testlog.vcd | 21:30 |
olofk | This can be viewed with gtkwave | 21:30 |
olofk | I'm not sure how long simulation time you captured, so you will most likely have to increase --timeout to something larger and rerun the simulation | 21:31 |
Me1234 | olofk: I have it, GTKWAVE shows it. | 21:31 |
olofk | Just leave gtkwave open and press Ctrl+R to reload the waveform after rerunning simulations | 21:31 |
olofk | cool. Are you familiar with waveform debugging? | 21:32 |
Me1234 | olofk: No | 21:32 |
olofk | Well, you've come to the right place to learn :) | 21:33 |
olofk | It's probably the most used tool for HDL guys | 21:33 |
olofk | Anyway.. | 21:33 |
olofk | In the treeview to the left, navigate down to orpsoc_top/mor1kx/mor1kx_cpu/mor1kx_cpu_cappucino/ | 21:35 |
olofk | (not completely sure about the naming here) | 21:35 |
olofk | Hopefully you will find a signal called traceport_exec_pc_o in the bottom left list | 21:36 |
Me1234 | olofk: Simulation error again : | 21:37 |
Me1234 | Compiling /srv1/srv/o/syn/build/de0_nano/src/elf-loader/elf-loader.c... | 21:37 |
Me1234 | Compiling /srv1/srv/o/syn/build/de0_nano/src/elf-loader/vpi_wrapper.c... | 21:37 |
Me1234 | /usr/bin/iverilog-vpi: 1 file(s) failed to compile. | 21:37 |
Me1234 | ERROR: Failed to build simulation model | 21:37 |
Me1234 | ERROR: Failed to compile VPI library elf-loader | 21:37 |
olofk | huh.. | 21:37 |
olofk | But it worked just before? | 21:37 |
olofk | See if you can find any errors in build/de0_nano/sim-icarus/vpi_wrapper.log | 21:38 |
olofk | hmm.. or elf-loader.log perhaps | 21:39 |
Me1234 | olofk: No such file | 21:40 |
olofk | hmm | 21:40 |
olofk | What files do you have in that directory? | 21:41 |
Me1234 | olofk: elf-loader.log icarus.scr vpi_wrapper.o | 21:42 |
Me1234 | olofk: elf-loader.log contents: | 21:43 |
Me1234 | /srv1/srv/o/syn/build/de0_nano/src/elf-loader/elf-loader.c:26:18: fatal error: gelf.h: No such file or directory | 21:43 |
Me1234 | #include <gelf.h> | 21:43 |
Me1234 | ^ | 21:43 |
Me1234 | compilation terminated. | 21:43 |
olofk | Aha. Did you install libelf-dev? | 21:44 |
Me1234 | olofk: Yes, then I installed libelfg0-dev, I think it replaced libelf-dev. | 21:44 |
olofk | ah yes. I remember being confused about which package to use in ubuntu | 21:46 |
olofk | Try the other one | 21:46 |
olofk | And check if /usr/include/gelf.h exists | 21:46 |
Me1234 | olofk: Sim works again | 21:46 |
olofk | cool | 21:47 |
olofk | So what we're trying to do is to follow the PC and look at the bus accesses to see what's going on | 21:47 |
olofk | See if you can locate the PC according to the instructions I pasted some minutes ago | 21:48 |
olofk | I could probably help out a bit if you send me the vcd file, but it's near bedtime here, so I won't be able to look at it today | 21:54 |
olofk | Got to go now. | 22:08 |
--- Log closed Sat Feb 21 00:00:50 2015 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!