IRC logs for #openrisc Thursday, 2013-08-29

--- Log opened Thu Aug 29 00:00:32 2013
hansfbaierIs there a memory map available for the OR1200?01:32
hansfbaierI read the arch manual tonight, but couldn't find one01:32
hansfbaierI am thinking about writing a memory checker01:33
hansfbaierie that writes sdram from start to end01:33
hansfbaierbut it looks like - at least - I'd have to begin at 0x1000...01:33
hansfbaierbecause below there are the exception handlers.01:34
stekernhansfbaier: or1200 define the memory map, but orpsoc does03:32
stekernbest place to look is in the <board>/rtl/verilog/include/orpsoc-params.v03:33
stekernolofk: what happens when you set WB_PORTS=1?03:34
stekernand bursts on what side, wb or sdram? on wb side, no. on sdram side, yes.03:35
stekernI bet it complains about this row when WB_PORTS=1: temp[WB_PORTS-1:0] = {temp[0],temp[WB_PORTS-1:1]};03:39
stekernthe whole arbiter could of course be put in a generate statement if WB_PORTS=!03:39
hansfbaierstekern: I calculated this morning 16MB RAM => maximum address = 0xffffff04:02
hansfbaierstekern: when barebox hangs for instance04:03
hansfbaierit is way above that04:03
hansfbaierstekern: is this virtual mem? I read gdb uses physical addresses only04:03
hansfbaier(gdb) nexti04:05
hansfbaierah this looks good04:06
hansfbaierbut the weird thing is: symptoms are the same: It just hangs on one addr or oscillates between two adjacent04:07
hansfbaierstekern: You mean WB_PORTS in orpsoc_top?04:11
hansfbaierthere two in wb_sdram_ctrl and the arbiter...04:11
hansfbaierthe one in top is param to the sdram controller04:12
hansfbaierThat's what you mean probably04:12
hansfbaierstekern: sorry04:13
hansfbaierread you wrong were talking to olofk...04:13
stekernheh, yeah, that was for olofk04:42
stekerngdb only reads physical addresses, but the PC can of course be virtual when you break04:43
stekernhansfbaier: but in barebox, the mmu isn't used04:43
stekernso if you're PC is > than your RAM, then I would say that something is wrong04:45
stekernthe only exception is that we sometimes have a boot ROM in the 0xf0000000 area, but if you load via gdb, that shouldn't be used04:46
hansfbaierstekern: Another n00b question: _franck_'s LED blinker accesses the GPIO at 0x9104:55
hansfbaierbut he loads it into r3 like this: 0x9100000004:56
hansfbaierit works04:56
hansfbaierbut I wonder why04:56
hansfbaieris this because of or1ks big endianness04:56
stekernyes, the peripherals are mapped into the > 0x90000000 space04:56
hansfbaierstekern: where exactly does this mapping occur?04:57
hansfbaierin the -define.v04:57
hansfbaierthere is only something like gpio-address = 8'h9104:57
stekernah, no, you've misread the code, he accesses them at 0x9100000004:57
hansfbaier  l.movhi r3,0x910004:58
hansfbaier  l.addi r4,r0,0xff04:58
hansfbaier 0x0(r3),r404:58
hansfbaierstekern: Yes I wonder how the address gets there04:58
stekernyes, 0x9100000004:58
hansfbaierparameter gpio0_wb_adr = 8'h91;04:58
hansfbaiershouldn't that be 0x00000009104:59
hansfbaier(wrong number of zeros004:59
stekernah, but in the code where the arbitration happens, only the upper bits are compared04:59
hansfbaieris that in arbiter?05:00
hansfbaierlet me grep the rtl again05:02
hansfbaierassign wb_slave_sel[1] = wbm_adr_o[`WB_ARB_ADDR_MATCH_SEL] == slave1_adr;05:11
hansfbaierstekern: the line before: wbm_adr_o[31:28]05:14
hansfbaiershould'nt that use `WB_ARB_ADDR_MATCH_SEL also?05:14
hansfbaierah no only 4 bit05:14
hansfbaier`WB_ARB_ADDR_MATCH_SEL is 8 bit05:14
hansfbaierstekern: now I get it, thanks05:15
hansfbaierstekern: _franck_: another weird thing is: When I set breakpoints in _franck_'s LED blinker just before the GPIO is written, the LEDs don't change whatsoever, even when I cont between them05:22
hansfbaierwhen I delete all breakpoints and cont they blink05:22
hansfbaierwhen I single step over a gpio write05:23
hansfbaiernothing happens too05:23
hansfbaierbreakpoints are at bl1 and bl205:24
stekernyeah, I think we have some problems with breakpoints, continuing after them and single stepping. _franck_ is our hero there and I think he has presented some fixes in that area that might not have propagated into my repo05:24
hansfbaierstekern: ah ok05:25
* hansfbaier gets the toolchain blues....05:55
hansfbaierstekern: As I understand correctly the toolchain I have
hansfbaierbuilds binaries for or1k-linux uClibc05:56
hansfbaierIf I want to build bare metal with the C compiler, Do i need to compile a new toolchain for newlib?05:57
hansfbaierstekern: ah got it06:13
stekernyou need or32-elf for that (or or1k-elf)06:14
hansfbaierstekern: when I compile barebox and/or vmlinux with or32-linux-....06:16
hansfbaierstekern: ist that wrong???06:16
hansfbaierstekern: Should those be compiled with or32-elf???06:16
stekernbarebox and linux can be built with either06:17
hansfbaierstekern: One big difficulty with the OpenRisc project is that the source code repos and the documentation are not very well organized.06:17
stekernor or1k-elf (but not with or1k-linux-* as it currently stands)06:17
hansfbaierstekern: that can be a pretty confusing maze for a beginner06:18
hansfbaierstekern: I really appreciated kevins tutorial that made so much sense06:18
hansfbaierstekern: but it's quite difficult to go on from there06:19
stekernwell known problem...06:19
stekernbut for the toolchains there is a "simple" answer: the old stable toolchain is in opencores svn, all current toolchain development happens under:
_franck_we should also provides binary toolchains06:22
stekernall "official" documentaion for the project is under
stekern_franck_: I agree06:22
stekernespecially now, with the 4.8.1 branched out06:23
stekernany volunteers for that? =)06:24
_franck_...I would say you ;)06:29
stekernI said volunteers, but yeah, I guess it could be me... ;)06:30
hansfbaierstekern: So what is jonas repo good for, linux port?06:39
hansfbaieror rather: what is the relationship of and the repo on
stekernok, this is a long story, I'll try to summarize it...06:42
stekernin the beginning, there was opencores svn. then developers asked for git support, when that didn't happen, jonas set up for Linux and uclibc06:43
stekernlater, I asked jonas to create a repo for u-boot that I could use for that (and a personal linux repo for my work there)06:43
stekernas more developers have jumped on-board the project, there was a trend that most of them just created their own git repos on github06:45
stekernso we decided to create the openrisc github organisation to bring those under a common roof06:46
stekernLinux and u-boot have been upstreamed, so their actual "official" repos are their upstream counterparts06:47
stekernnow, we have some drivers and other stuff that hasn't been upstreamed (mostly because of lack of time to put them in the shape needed for them to be accepted)06:49
hansfbaierstekern: upstream = github?06:50
stekernbut ideally, people *should* be able to just use the upstream versions of those, that's at least the idea06:50
stekernno, upstream = and git.denx.de06:51
stekerni.e. the same place you would go to get your kernel for your desktop =)06:53
hansfbaieraah the linux kernel upstream07:13
hansfbaierstekern: Ah I get it07:14
hansfbaierstekern: I have something weird here08:18
hansfbaier    l.sfltu r5, r1008:18
hansfbaier    loop08:18
hansfbaierr5 = 0x20108:18
hansfbaierbut the does not jump08:19
hansfbaierno idea why08:19
hansfbaieram I getting something wrong here?08:19
hansfbaier_franck_: any idea?08:23
hansfbaierNow it gets even weirder:08:28
hansfbaierI changed to l.bnf08:29
hansfbaierAnd it does not jump too.08:30
hansfbaierHardware bug?08:30
hansfbaieror gdb bug?08:30
hansfbaierBut when I just cont and set a breakpoint to end:08:30
hansfbaierthen I land there with r5 =0x20108:30
hansfbaiersuper weird08:30
_franck_delay slot08:32
_franck_put nop after branch instructions08:32
hansfbaier_franck_: aaahhh08:35
hansfbaier_franck_: What is the purpose of the delay slot? Technical necessity? Or on purpose?08:36
_franck_it keeps the pipeline busy08:40
_franck_while branching08:40
hansfbaier_franck_: now I put 5 l.nop after the branch08:41
hansfbaierand the flag is set in sr08:42
frubbl_franck_: I inserted 5 l.nop and the flag was set but no branch happened....09:06
frubblBlackout here....  that's Indonesia...09:07
frubblOn my phone I have a different Nick09:07
_franck_are you using stepi ?09:08
frubblYes at the time09:08
_franck_not sure in works with your gdb/openocd/RTL combination09:08
frubblCan't try now.  Blackout09:09
frubblStepi on the gpio did not work on the led blinker09:10
_franck_try to update this function in openocd:
_franck_I did not push this to the openrisc github yet09:16
frubblThanks will try09:17
olofkstekern: Yes, removing the arbiter for WB_PORTS=1 crossed my mind too10:03
olofkMy problem now is that wishbone writes seem to work fine, but when I do a burst read, the sdram address doesn't increase after the first word is read10:04
olofkI'm trying to find the code where address is increased, but searching for a variable named a isn't all that fun :)10:07
stekernolofk: ah, but it isn't increased10:11
stekernthat's not how the bursts work on the sdram side10:12
stekernyou give the start address and then read out data according to the burstlen10:12
stekernso you're searching for a needle in a haystack without a needle ;)10:15
olofkBut it looks like it's repeating the same data over and over10:16
olofkhmm.. could that be because I set the burst length parameter to 1?10:16
hansfbaier_franck_: will clone the whole thing, it complains about missing tdesc.h etc etc10:16
stekernolofk: yeah, that's not gonna work...10:17
stekernI've never claimed that this core is perfect (at least not yet) ;)10:18
olofkhmm.. so it will only work with burst of a specific length?10:18
stekernthe sdram_ctrl.v should work with any length, but the wb side expects burst length of 810:19
stekern*should*, I haven't really tested anything else than 110:19
olofkahh.. ok. Is this core more or less targeted against cache refills?10:20
olofkBecause I guess it won't work for ethernet10:20
stekernit works perfectly for ethernet10:20
stekernbut, the wb side has it owns buffers that are 8 32-bits long10:20
stekernso 2*16*810:21
olofkis 8 the BURST_LENGTH here, or is that unrelated?10:21
stekernso it burst into those, thus the "hardcoded" burstlength of 810:21
olofkyes what? :)10:22
stekern8 is the BURST_LENGTH10:22
stekernand the limitation that it *has* to be 8 is in wb_port.v10:23
stekernon the line I pasted10:23
olofkah.. ok10:24
olofkBut how does that work with ethernet? Isn't the whole frame transmitted in one burst?10:24
stekernbut that isn't interesting what ethernet do on the wb side10:25
olofkThen I probably still don't understand10:25
stekernthe wb bursts are of some length, 4, 8 or 16 (IIRC) or they can be linear and just continue endlessly (until the master decide to stop)10:26
stekernethernet use one of the fixed length ones, right?10:26
olofkNo clue. I should ask the maintainer of ethmac... oh wait, that's me :)10:27
stekernit doesn't matter anyway, because the wb bursts are completely unrelated to the sdram bursts10:27
stekernthe way the conroller works is that when a wb access occurs on some address, wb_port fetches 8*32 bits into an internal cache10:28
olofkSo I should be able to send wishbone burst with any length then?10:28
stekernand then the wb side read out of that cache/buffer10:29
olofkMakes sense. That's probably what I expected10:29
stekernso, how that cache get filled, that's something that the wb side of things doesn't care about10:29
stekernwhen it is filled, it can burst happily out of it10:30
stekern(now, there's some optimisations going on that makes reading out of the cache while the filling is in flight, but let's ignore that right now)10:31
hansfbaier./configure --enable-usb_blaster_libftdi --enable-adv_debug_sys --enable-altera_vjtag --enable-maintainer-mode --disable-usb_blaster_ftd2xx10:31
hansfbaier/bin/bash ../../../libtool  --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../..  -I../../../src -I../../../src -I../../../src/helper -DPKGDATADIR=\"/usr/local/share/openocd\" -DPKGLIBDIR=\"/usr/local/lib/openocd\" -I../../../jimtcl -I../../../jimtcl   -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT ublast_access_ftd2xx.lo -MD -MP -MF10:31
hansfbaierlibtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../src -I../../../src -I../../../src/helper -DPKGDATADIR=\"/usr/local/share/openocd\" -DPKGLIBDIR=\"/usr/local/lib/openocd\" -I../../../jimtcl -I../../../jimtcl -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wshadow -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -MT ublast_access_ftd2xx.lo -MD -MP -MF .deps/ublast_access_ftd2xx.Tpo -c usb10:31
hansfbaierusb_blaster/ublast_access_ftd2xx.c:32:20: fatal error: ftd2xx.h: No such file or directory10:31
olofkOk, so my test writes data to to an address, and I can see the data being written to the SDRAM. But for some reason, I don't get anything back from my wishbone read. Only the first data is fetched over and over, and no wb_ack is sent to the wishbone port10:31
stekernand if the cache is not filled, the wb side just have to wait for it to be filled10:32
stekernwb bursts doesn't have to complete in a single cycle10:32
stekernolofk: ok, that sounds weird10:32
stekernI've got to run now, but if you have something more concrete for me to look at, I can do that in the evening10:33
hansfbaier_franck_: build seems broken10:38
hansfbaier_franck_: ah just updated the function you told me, seems to build10:44
hansfbaier_franck_: that did the trick! GREAT! Thanks!11:29
hansfbaier_franck_: My memory tester11:29
hansfbaieralso uncovered the same problems11:29
_franck_the openocd reference is here now:
hansfbaier_franck_: What does that mean, reference in what sense?11:30
_franck_hansfbaier: great !11:30
hansfbaier_franck_: But my little memory test program11:30
_franck_means the more up-to-date11:30
hansfbaieruncovers the same problem11:30
_franck_other repo will become obsolete11:30
hansfbaier_franck_: is that upstream?11:31
* hansfbaier is totally confused about the gazillion different openOCD-git repos11:31
_franck_openocd use gerrit (kind of a patch tracker)11:31
hansfbaier_franck_: led blinker also working fine now11:31
_franck_hansfbaier: yes I know and I'm sorry for that. But I'm working on it11:32
_franck_openocd is *almost* upstream11:33
hansfbaier_franck_: 0x400108:0xff0xff0xff0xff0xff0xff0xff0xff11:46
hansfbaierThe interesting thing the memory checker always crashes at 0x400121,11:47
hansfbaierthat means it lands somehow at 0x0000070411:47
hansfbaier(no idea how)11:47
hansfbaiermaybe sdram is broken somehow round that address11:48
hansfbaierstekern: ^11:48
hansfbaierHere is the current version:
_franck_your memory checker crashes while testing address 0x400121 ?12:02
stekernhansfbaier: I can try running that on my de0 nano in the evening12:11
hansfbaierstekern: Thanks a lot12:12
stekernjust as a sanity check12:12
hansfbaierstekern: I can paste the original source12:12
hansfbaierinconsistent whitespace, sorry12:13
hansfbaierYes, reproducibly12:15
hansfbaier_franck_: symptoms are the same as vmlinux and barebox12:16
hansfbaierjust hangs somewhere stuck there12:16
hansfbaierpretty weird12:16
hansfbaierany debugging ideas12:16
hansfbaierstekern: I tried signaltap12:16
_franck_may be that 0x400121 overlaps 0x000121 somehow12:17
_franck_with gdb try to write something at 0x400121 and read 0x121 to see if it changes12:18
hansfbaier_franck_: ah good idea12:18
hansfbaier_franck_: BINGO12:24
hansfbaier(gdb)  set {unsigned char}0x400122 = 0xff12:24
hansfbaier(gdb)  set {unsigned char}0x400123 = 0xff12:24
hansfbaier(gdb)  set {unsigned char}0x400124 = 0xff12:24
hansfbaier(gdb) x 0x40012112:24
hansfbaier(gdb) x 0x00012112:24
hansfbaier0x121 <loop+1>:0xffffffff12:24
hansfbaier(gdb) x 0x40012112:24
hansfbaier(gdb) x 0x12112:24
hansfbaier0x121 <loop+1>:0xffffffff12:24
hansfbaier_franck_: awesome12:24
hansfbaier_franck_: you are the man!12:25
hansfbaier_franck_: How did you come to that assumption?12:25
_franck_well I'm not that old but I've seen a lot, I'm an hardware guy so I've seen add line stuck at GND on VCC12:26
_franck_you might have a proble in your RTL or pin assignment (as you've not designed the hw so let's say it's okay)12:27
hansfbaier_franck_: yes, looks like a stuck pin or so12:31
ysionneauor a buggy tlb entry?12:31
olofkI had this problem on one of my boards. Had to remove some solder that was stuck between two of the memory address pins12:36
hansfbaier_franck_: was fun to write the memory checker though12:37
hansfbaiermy first or1200k program in assembler12:38
hansfbaiergood learning experience12:38
_franck_now you've passed the openrisc test ;) You can continue....12:44
_franck_and You didn't give up12:46
stekernyes, that's the real test, we're all kind of stubborn people12:47
stekernhansfbaier: could you paste the parameters you feed the sdram controller?12:47
stekernand I'll check the backlog for your memory model and that there's no assumptions that isn't true for that chip12:49
hansfbaierfrom orpsoc_top12:50
hansfbaierstekern: let me look12:50
hansfbaierrow width is 12, isn't it?12:52
hansfbaierinstead of 1312:52
hansfbaierI thought I had already set sdram parameters somewhere12:53
hansfbaierstekern: ^ you probably got that already12:56
hansfbaierMy model is the -75C12:57
hansfbaierWait, but no, the chip has 13 address lines13:01
hansfbaierI think I get it:13:07
hansfbaierIn the datasheet13:07
hansfbaierit says PIN 36 = NC13:07
hansfbaierbut in the schematic of my sdram board13:07
hansfbaierit says A1213:07
hansfbaierso the pin is a dummy actually13:08
hansfbaierso 12 would be the right row width13:08
hansfbaierchinese boards13:08
hansfbaierthis one was so nice and cheap13:08
hansfbaierand mostly worked well13:08
hansfbaierexcept where it was a learning experience13:09
hansfbaier_franck_: stekern: looks like bingo13:22
hansfbaiernow i am already at13:22
hansfbaierand still looping13:23
hansfbaierthe memchecker reported an error at 0x9100000013:24
stekernyeah, your row width should be 12 (as you already figured out)13:24
hansfbaierstekern: I was tricked by the scematic and the tcl file of the manufacturer of the sdram board13:25
_franck_because AFAIR you forget a delay slot afet l.j13:25
hansfbaierthey wired up 1313:25
hansfbaierbut the chip has only 1213:25
hansfbaiermaybe they used the same board for different types of chips13:25
stekernyeah, maybe they weren't sure what part they'd fit when they draw the schematics13:25
hansfbaier(they sell 2 different mem boards)13:25
stekernbut I have to admit, I easily get confused by the row, bank and col count too ;)13:26
stekernand especially since address line 10 has that special meaning, it confuses things even more13:27
_franck_hansfbaier: before you jump to end, you execute    0(r3),r813:27
hansfbaierthe 0x9100000013:28
hansfbaierisn't that the gpio controller13:28
_franck_it is13:28
hansfbaier_franck_: yes you're right13:28
hansfbaierso it means it works13:28
* hansfbaier virtually jumps around dancing for joy13:28
_franck_hansfbaier: your are at a point we are all looking for :) This small moment of extase, only people like us can understand ;)13:30
olofkI usually refer to this one to explain what we're all about
hansfbaier_franck_: looks like watchpoints aren't implemented yet in openocd13:30
_franck_no, they are not implemented either in RTL13:31
hansfbaierah I see13:31
hansfbaierI thought because it's in the spec13:32
hansfbaierok good to know13:32
* _franck_ is not that sure about watchpoint13:32
hansfbaierolofk: hehe13:32
hansfbaierthere are a bunch of registers for watchpoints13:32
hansfbaier_franck_: but wait13:34
hansfbaiera moment of doubt:13:35
stekernonly sw breakpoints are supported, there are some hw breakpoints patches for an older version of or1200, but they were never merged for some reason13:35
stekernonly sw breakpoints in mor1kx too13:35
_franck_that's what I thought13:35
hansfbaierThe program should not ever come as far as 0x9100000013:35
hansfbaierit should stop at 0x10000013:36
hansfbaierwhich id didn't13:36
hansfbaierweird again13:36
stekernit's because of the missing delay slot nop, no?13:39
stekernyou've got 0x91000000 in r313:40
stekernwhen you jump to end13:40
hansfbaierstekern: does l.j need a l.nop too?13:46
stekernyes, all jumps (except l.rfe) has a delay slot13:48
olofkLooking for hotels in Cambridge now. Anyone booked anything yet?13:52
hansfbaierstekern: thanks, good to know13:53
hansfbaierok now time for a linux kernel boot13:54
* hansfbaier has to reboot first13:54
hansfbaierusb stack confused13:55
hansfbaierPL2303 does not want to be recognize13:55
hansfbaierinit started: BusyBox v1.19.0.git (2011-02-16 08:10:12 CET)14:08
hansfbaierConfiguring loopback device14:08
hansfbaierPlease press Enter to activate this console.14:08
hansfbaierifconfig: SIOCSIFADDR: No such device14:08
hansfbaier_franck_: stekern: THANK YOU14:09
hansfbaierI have a complete open source system14:10
hansfbaieranyone ported X yet ;)14:10
hansfbaierwould be a drag though14:11
_franck_great to hear14:11
hansfbaierOpenRISC w/ linux the ideal learning environment14:12
hansfbaierI can build my own hardware and write my own linux drivers for it14:12
_franck_always a great news when we have new contributors14:12
hansfbaierI have to catch up a bit with my paid work now14:12
hansfbaierwas playing around more than full time for 2 days14:13
hansfbaier_franck_: will try barebox now14:13
stekernolofk: still not yet, yell if you find something good14:14
stekernI'll do the same14:15
stekernhansfbaier: poke53282 have tested compiling and running X, but there's a bug somewhere14:16
hansfbaierstekern: really, that was a joke actually, but wow!14:16
stekernhe got xeyes running at least ;)14:17
hansfbaierstekern: wow that's pretty good already14:20
stekernhansfbaier: where are you working?14:23
hansfbaier_franck_: barebox runs too14:24
hansfbaierstekern: I am freelance14:25
hansfbaierstekern: but my main customer is a small german company building embedded trance hardware14:25
hansfbaierstekern: pretty cool stuff14:25
hansfbaierjust joined them a couple of weeks ago14:25
_franck_trance ?14:26
hansfbaier_franck_: :)14:26
stekernah, that explain how you can "set aside" two days to play with openrisc =)14:26
stekernyeah, I was about to ask the same, trance?14:26
_franck_looking at the german website I guess it's *trace*14:27
hansfbaierah yes, trace, sorry14:27
hansfbaierpretty cool stuff14:27
_franck_and you are doing software ?14:27
hansfbaiera customer found in a day the problem they were debugging for months14:28
olofkor timing analysis? ;)14:28
hansfbaierstekern: Yes, software14:28
hansfbaierembedded too14:28
hansfbaierI am still pretty new to the embedded world14:28
hansfbaierThat's why I am playing so hard14:28
hansfbaierstill need to learn so much14:28
_franck_I've always wanted to work as a freelancer...14:29
hansfbaierI was writing enterprise java stuff for years now14:29
hansfbaierand got so fed up and bored with it I needed something else14:29
hansfbaierAnd then i got all excited about hardware and electronics14:29
hansfbaierblinking LEDs :)14:30
_franck_yes, it's much better than printing "Hello, World !"14:30
hansfbaierThere's a sd card controller in orpsoc IIRC, right?14:31
hansfbaierNow I can try re-enable the cpu caches14:31
hansfbaierthe nice thing about my chinese board is, that I can use exactly the same base board and expansion modules14:37
hansfbaierfor my Altera EP4CE10 as well as my Xilinx XC3S500E14:37
hansfbaierthe FPGA module is exchangeable14:37
hansfbaierapart from the price14:38
stekerndo they have any larger fpgas?14:38
stekernand I'm also a bit surprised it didn't make it pass 50mhz with or120014:39
hansfbaierstekern: unfortunately not14:40
stekernbut maybe it's just so packed14:40
hansfbaierstekern: I ordered the Adapteva parallela14:40
hansfbaiergreat value for $19914:40
stekernme too14:40
hansfbaiergot the Zynq x2014:40
hansfbaierabout 75k LUT IIRC14:41
hansfbaiergreat value for money14:41
hansfbaierthat's 7.5x larger than my EP4cE1014:41
hansfbaierstekern: Only the connectors are a PITB14:42
stekernwould be interesting what kind of fmax you'd get with mor1kx on that board14:42
stekernyour ep4 board I mean14:43
hansfbaierstekern: does openOCD work with Xilinx boards14:43
hansfbaierstekern: Is mor1kx faster?14:43
stekernyes, and especially the version in my working tree14:44
stekernand openocd at least work with xilinx if you use an external jtag connection14:44
hansfbaierstekern: so configure some of the outputs as jtag14:45
hansfbaierstekern: but with which JTAG interface?14:45
hansfbaierThe altera blaster?14:45
hansfbaieror something like a J-Link?14:45
hansfbaierstekern: is the mor1kx drop-in compatible,14:46
stekernthose el cheapo arm jtag debuggers from e.g. olimex should work14:46
hansfbaieror do I need to wire it up14:47
_franck_I'm using an Olimex ARM-USB-TINY14:47
stekernyes, it's drop in compatible14:47
hansfbaierstekern: what would be the best repo to clone?14:48
stekernsince you're using my de0 nano as base it's just a matter of comment OR1200 and uncomment MOR1KX in the config file14:49
stekernand copy the sources from
hansfbaierstekern: Do you think we should commit the Waveshare board into the tree?14:50
hansfbaiernow that it is running?14:50
hansfbaierwill need some more work though14:51
hansfbaierrenames etc..14:51
stekernyeah, sure14:52
hansfbaierstekern: OK, I try to do the rename and get everything ready, that it is comparable to the de0_nano board14:52
stekernwhile you're at it, you can change that VERSATILE_SDRAM define, that's something i newer seem to get around to do...14:58
stekernto WB_SDRAM_CTRL or something15:01
stekern_franck_: I have one of those too, but I never actually tested it with openrisc, just heard that they should work15:07
stekerngood to get it confirmed from a trusted source ;)15:07
hansfbaierstekern: You have a waveshare-board too15:10
hansfbaieror Olimex15:10
stekernno, an ARM-USB-TINY15:10
hansfbaier_franck_: Will the ARM-USB-TINY-H work too?15:20
stekernI can't see why that wouldn't work15:24
_franck_yes should work:
_franck_well, may me I have an ARM-USB-OCD, can't remember15:32
hansfbaier_franck_: Ah disabling caches was important too15:34
hansfbaierenabled them15:34
hansfbaiernow it hangs in busybox15:35
stekernwonder what's the problem now15:54
amsstekern: lack of beer or coffee.16:14
hansfbaiergood night16:16
hansfbaierthanks a lot16:16
hansfbaiergot to sleep16:16
hansfbaiernext project would be hooking up an enc28j60 into the spi16:17
hansfbaierand linux16:17
stekernI wonder what I should do with the lsu error tests, they are going to fail since I can never exactly handle store errors as before18:07
stekernsince there will be registers written back etc while the store is being processed18:08
stekernI think the important thing is that you get the right PC and offending address, all other is not interesting since the games is over once you get a dbus error anyway18:09
olofkstekern: Not sure if I really understood each other earlier regarding the burst stuff, but it works now18:10
olofkIf I set BURST_LENGTH=818:10
stekernolofk: schizo, eh? you and you not understanding each others, not sure I can help you there18:12
stekernbut, BURST_LENGTH has to be 8, due to current limitations in wb_port.v ;)18:13
olofkNow that's a fucking confusing parameter18:13
stekernyeah, sorry about that :(18:13
olofkNo worries. Even Hitler made mistakes18:14
stekernthe idea is/was of course that the limitation shouldn't exist in wb_port.v18:14
olofkIt breaks on wishbone bursts with length > 4, but that might be my test bench logic18:15
stekernshould work with that, I've used burst length > 418:15
stekernmaybe I remove the BURST_LENGTH parameter from the top level, until wb_port.v is fixed ;)18:16
olofkHmm. it wasn't related to wb burst length.18:24
stekernwhat is it related to?18:32
olofkNot sure yet, but I'm getting wrong data back on some reads18:38
olofkWhere's the internal cache?18:40
stekernin wb_port.v18:47
olofkHmmm... am I supposed to cut off an LSB of wb_adr?18:52
stekernhmm, no, they are expected to be 31:0 at least on the external interface18:55
olofkIt looks like the cache isn't updated properly19:05
olofkI'm doing a write and read back on address 0x00002604. Then I'm doing a burst write/read with the same start address, and I'm getting the old data back19:06
stekernmaybe you've found a bug! ;)19:07
stekernbecause when I'm reading the code I see a corner case that is not covered19:07
stekernno, actually I think it is covered19:13
stekernI thought that there might still be data in the write fifo when the read is done, but the writes have higher priority than the reads19:14
stekerndone == started19:15
stekernthere is of course a latency for the empty flag of the fifo, so there might still be a slight possibility that you have a 1-2 clock cycle window there to sneak the read in before that flag is raised19:17
stekernbut otoh, there should be a 2 clock cycle latency for the read to propagate into the sdram domain as well19:17
stekernbut going back to your description of the problem, it's burst writes that doesn't work properly?19:18
_franck_olofk: is there a verbose option for orpsocv3 build or/and sim ?19:24
stekernthis makes me wonder a thing about wb burst writes, do they really have to be in any particular order?19:24
olofkstekern: I'm not sure it's strictly burst-related. Want my VCD+19:25
olofk_franck_: No. There are some improvements to be made in that area19:25
stekernbasically, they could be treated as pipelined writes, since why do you need to know the next address?19:25
stekernolofk: yeah, sure send it over19:26
olofk_franck_: But I'm sending stdout/stderr to log files in the build/core/sim-$simulator directory19:26
olofkstekern: Address is only valid on the first transaction in a burst. All other addresses are calculated from cti/bte19:28
stekernolofk: no19:28
stekernthe master has to provide the address on all accesses19:28
olofkAre you really sure about that?19:29
olofkThat's just stupid19:29
stekernbecause otherwise you wouldn't be backward compatible19:29
olofkThat's true19:29
olofk(not stupid)19:29
olofkThe reads and writes are very close to each other, so you might be on to something there19:32
olofkIt's getting interesting after 29980 ns19:33
stekernumm, why are there lots of 'z' on the wb lines?19:34
stekern(completely unrelated to the problem though)19:35
_franck_olofk: FYI , I need to clean build/de1/* to run the simulation again19:36
olofkstekern: I wanted to only have one master writing data, and I couldn't set WB_PORTS=!19:36
olofkSo only the last of the three ports are connected19:37
stekernheh, yeah, I guessed that19:37
olofk_franck_:  @(posedge wb_clk_i);19:38
olofk_franck_: Try /usr/local/bin/python3.3 bin/ sim --force de119:38
stekernthat's a pretty frantic fuck, I'd say19:38
olofkBut I guess it depends on your f_max :)19:39
olofkI tried to put some extra cycles between each access, but it didn't help19:40
stekernit's the read from 0x2608 that's wrong, right?19:44
stekernthe write burst looks a bit odd though, but apart from that, the 0x2608 read still looks wrong19:45
stekernwell, maybe it doesn't look odd, what did cti='010' mean?19:47
olofk repeat (20) @(posedge wb_clk_i);19:47
olofkWe can use wb_sdram_ctrl_tb.masters[2].wb_master0.transaction to keep track of which transaction we're talking about19:48
olofkcti=010 is incrementing burst cycle according to the spec19:50
stekernok, then it's nothing odd to only have three accesses in the burst19:51
stekernor no... I probably meant bte then19:51
olofkYes, the data returned in 0x44 is a combination of the writes from 0x42 and 0x4319:51
olofkbte=010? It's only two bits19:52
stekernno, bte=1119:52
stekernI'm mixing up bte and cti19:53
stekernbut I think I see the issue, the wrfifo_empty signals go high during one clock cycle for some reason and there you come and sneak in a read19:54, the read comes later than that...19:54
stekernI wonder why the wrfifo_empty acts like that still...19:55
_franck_olofk: I have an orpsoc_top.v with altera primitives. I want to simulate this top but I need defines to replace those primitives during the simulation. How would you do it ?19:55
olofkI separated the writes and reads with ~20 cycles, so I don't think they are too close19:57
olofk_franck_: You can add icarus_options in your .core file. You should be able to set -D<define> there19:57
_franck_ok thanks19:58
olofkSorry... iverilog_options is the name19:58
olofkIn the [icarus] section19:58
olofkThere is a similar for modelsim.19:58
* _franck_ should read capi.txt :)19:59
* olofk should update capi.txt19:59
olofkasciidoc -b xhtml11 capi.txt makes it a bit more readable20:00
olofkstekern: bte=11 should be a 16-beat wrap20:01
stekernyup, I opened the spec here too20:02
stekernending them prematurely is of course ok, they just initially looked odd20:02
olofkYou want an updated VCD with more space between the transactions?20:03
stekernbut the read I thought was wrong was actually a write...20:03 now I can't see anything wrong anymore...20:04
stekernwhich transaction was the faulty one?20:04
olofkThe read back from 0x4420:05
olofkI'm writing 0x0684410D, 0x2EBAB55D, 9917C43220:05
stekernah, that was too far out on the right ;)20:06
olofkI'm getting back 0x0684410D, 0x4DBC9B9B, 6BD921D720:06
olofkThe last two values are from transactions 0x42 and 0x43.20:06
olofk...which is why I'm guessing that the caches are the culprit here20:07
stekernyeah, that's a good guess, the read in 0x44 doesn't even go out on the sdram bus to fetch those values20:13
olofkHere's a version that separates the accesses
stekerntry this patch:
_franck_who's going to change its name: ?20:24
stekernheh... yeah, verilog namespaces are a pain...20:26
olofkstekern: Nope, sorry. Didn't help :(20:28
stekernhuh, weird.. can you give the vcd with that applied?20:29
olofk_franck_: Yeah, I was worried about that one. I'm planning to add a patch to rename the one in verilog-arbiter20:29
stekernolofk: oh wait... I see why20:29
stekernheeelp, why is pastebin playing videos??20:31
stekernolofk: this *has* to work:
_franck_olofk: can a clean more than rm -rf build/ core/ cache/ ?20:36
_franck_oups I shouldn't clean cores...20:38
olofk_franck_: No, you shouldn't :)20:38
_franck_git checkout saves me20:38
olofkstekern: That helped a little. Only the last word is wrong now20:40
stekernhmm, can I see the vcd of that?20:43
olofktestlog2.vcd is updated20:43
_franck_hurry up stekern , I'd like to know the end of this story before I go to bed !20:47
stekern_franck_: sorry ;)20:48
stekernyeah, I know what's wrong20:49
stekernpatch coming up in a few20:49
olofkIt works with a single master now21:05
olofkBut when I enable an additional master, something is still wrong21:06
olofkBut that could definitely be in my test bench21:06
_franck_I need to sleep, bye21:08
olofkgood night21:08
stekern_franck_: you got some closure at least =)21:08
stekernolofk: is it burst writes that is the trouble there too?21:09
olofkYes, but all my writes are burst, even if length is 121:09
stekernas you might guess, I haven't ever used those21:09
olofkBut I'm pretty confident that this is in my transactor21:10
stekernah, but cti=111 doesn't count21:10
stekernbut nice job catching that write burst bug, my beer debt is growing21:11
olofkOh no. I'm in debt to you for fixing it. I'm just glad that my fancy wishbone BFM has gotten som real-world use21:12
olofkAnd the last problem was in my TB21:12
olofkOh well. This is it for tonight21:13
stekernI see that that patch is still not perfect21:14
olofkThe same goes for my test bench21:14
stekern...or is it21:14
olofkGood night21:15
stekernmaybe it's time for bed ;)21:15
stekernah, I think it's ok, it'll just write an extra time in to the buffer for single cycle accesses, but that's no harm in that21:19
stekernnon-burst accesses I mean21:21
knzjust wondering what the "l." instruction mnemonic prefix is about21:23
hansfbaierstekern: do you ever sleep :)21:30
hansfbaierstekern: question:21:31
hansfbaier   0x00000184 <loop+96>:l.nop 0x021:31
hansfbaier   0x00000188 <loop+100>:l.nop 0x021:31
hansfbaier=> 0x0000018c <loop+104>:l.j 0x621:31
hansfbaier   0x00000190 <loop+108>:l.nop 0x021:31
hansfbaier   0x00000194 <loop+112>:l.nop 0x021:31
hansfbaier   0x00000198 <memerr+0> 0x0(r3),r621:31
hansfbaierEnd of assembler dump.21:31
hansfbaier(gdb) nexti21:31
hansfbaier0x00000190 in loop ()21:31
hansfbaier3: $r5 = 1677721621:31
hansfbaierstekern: I wonder why the l.j is not executed.....21:31
hansfbaierthat's very weird21:31
hansfbaiernow it got executed21:32
hansfbaierok, never mind21:32
hansfbaierI think I know why.21:46
hansfbaierthe weird effect that pc jumps to nowhere and gets stuck there happens when there is an access to an illegal address21:46
hansfbaierwhen I erroneously did an to 0x91000001 instead of I got there in the next instruction21:47
poke53282Hi hansfbaier. You have asked about an X server for opencore. I managed to start an X-server yes. But it is extremely unstable. The farthest point I got was this:
hansfbaierpoke5328: very cool21:48
hansfbaierthat would already be pretty plenty if it were stable21:49
hansfbaiertried it on the binary simulator?21:49
hansfbaieror hardware?21:49
poke53282I don't know why. The bug is not really reproducible and depends on debugging options. Spend one or two days on the problem but didn't find the error. At the moment I think it is some bug in the kernel.21:49
poke53282In an emulator.21:49
poke53282This one21:49
hansfbaiermaybe it is also a problem in the simulator21:50
poke53282I had the same crashes in or1ksim21:50
hansfbaierah ok21:50
poke53282You don't need a framebuffer to test.21:50
poke53282virtual Xserver is fine.21:51
hansfbaierpoke53282: good to know21:51
hansfbaierbut X is off limits for me now21:51
hansfbaierthere's still so much other stuff to get running21:51
hansfbaierwant to make SPI Ethernet work in linux21:51
poke53282You can find the script to compile everything here:
poke53282It is only a matter of time when it will work. Just one bug left.21:53
poke53282But you can try scummvm :)21:53
--- Log closed Fri Aug 30 00:00:33 2013

Generated by 2.15.2 by Marius Gedminas - find it at!