| --- Log opened Thu Aug 29 00:00:32 2013 | ||
| hansfbaier | Is there a memory map available for the OR1200? | 01:32 |
|---|---|---|
| hansfbaier | I read the arch manual tonight, but couldn't find one | 01:32 |
| hansfbaier | I am thinking about writing a memory checker | 01:33 |
| hansfbaier | ie that writes sdram from start to end | 01:33 |
| hansfbaier | but it looks like - at least - I'd have to begin at 0x1000... | 01:33 |
| hansfbaier | because below there are the exception handlers. | 01:34 |
| stekern | hansfbaier: or1200 define the memory map, but orpsoc does | 03:32 |
| stekern | best place to look is in the <board>/rtl/verilog/include/orpsoc-params.v | 03:33 |
| stekern | olofk: what happens when you set WB_PORTS=1? | 03:34 |
| stekern | and bursts on what side, wb or sdram? on wb side, no. on sdram side, yes. | 03:35 |
| stekern | I bet it complains about this row when WB_PORTS=1: temp[WB_PORTS-1:0] = {temp[0],temp[WB_PORTS-1:1]}; | 03:39 |
| stekern | the whole arbiter could of course be put in a generate statement if WB_PORTS=! | 03:39 |
| stekern | *1 | 03:40 |
| hansfbaier | stekern: I calculated this morning 16MB RAM => maximum address = 0xffffff | 04:02 |
| hansfbaier | stekern: when barebox hangs for instance | 04:03 |
| hansfbaier | it is way above that | 04:03 |
| hansfbaier | stekern: is this virtual mem? I read gdb uses physical addresses only | 04:03 |
| hansfbaier | (gdb) nexti | 04:05 |
| hansfbaier | 0x00fc04b01978{ | 04:05 |
| hansfbaier | ah this looks good | 04:06 |
| hansfbaier | but the weird thing is: symptoms are the same: It just hangs on one addr or oscillates between two adjacent | 04:07 |
| hansfbaier | stekern: You mean WB_PORTS in orpsoc_top? | 04:11 |
| hansfbaier | there two in wb_sdram_ctrl and the arbiter... | 04:11 |
| hansfbaier | Ahh | 04:12 |
| hansfbaier | the one in top is param to the sdram controller | 04:12 |
| hansfbaier | That's what you mean probably | 04:12 |
| hansfbaier | stekern: sorry | 04:13 |
| hansfbaier | read you wrong were talking to olofk... | 04:13 |
| stekern | heh, yeah, that was for olofk | 04:42 |
| stekern | gdb only reads physical addresses, but the PC can of course be virtual when you break | 04:43 |
| stekern | hansfbaier: but in barebox, the mmu isn't used | 04:43 |
| stekern | so if you're PC is > than your RAM, then I would say that something is wrong | 04:45 |
| stekern | the only exception is that we sometimes have a boot ROM in the 0xf0000000 area, but if you load via gdb, that shouldn't be used | 04:46 |
| hansfbaier | stekern: Another n00b question: _franck_'s LED blinker accesses the GPIO at 0x91 | 04:55 |
| hansfbaier | but he loads it into r3 like this: 0x91000000 | 04:56 |
| hansfbaier | it works | 04:56 |
| hansfbaier | but I wonder why | 04:56 |
| hansfbaier | is this because of or1ks big endianness | 04:56 |
| hansfbaier | ? | 04:56 |
| stekern | yes, the peripherals are mapped into the > 0x90000000 space | 04:56 |
| hansfbaier | stekern: where exactly does this mapping occur? | 04:57 |
| hansfbaier | in the -define.v | 04:57 |
| hansfbaier | there is only something like gpio-address = 8'h91 | 04:57 |
| stekern | ah, no, you've misread the code, he accesses them at 0x91000000 | 04:57 |
| hansfbaier | l.movhi r3,0x9100 | 04:58 |
| hansfbaier | l.addi r4,r0,0xff | 04:58 |
| hansfbaier | l.sb 0x0(r3),r4 | 04:58 |
| hansfbaier | stekern: Yes I wonder how the address gets there | 04:58 |
| stekern | yes, 0x91000000 | 04:58 |
| hansfbaier | parameter gpio0_wb_adr = 8'h91; | 04:58 |
| hansfbaier | shouldn't that be 0x000000091 | 04:59 |
| hansfbaier | (wrong number of zeros0 | 04:59 |
| hansfbaier | ) | 04:59 |
| stekern | ah, but in the code where the arbitration happens, only the upper bits are compared | 04:59 |
| hansfbaier | is that in arbiter? | 05:00 |
| hansfbaier | let me grep the rtl again | 05:02 |
| hansfbaier | ... | 05:02 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/boards/altera/de0_nano/rtl/verilog/arbiter/arbiter_dbus.v#n376 | 05:05 |
| hansfbaier | ah | 05:11 |
| hansfbaier | assign wb_slave_sel[1] = wbm_adr_o[`WB_ARB_ADDR_MATCH_SEL] == slave1_adr; | 05:11 |
| hansfbaier | stekern: the line before: wbm_adr_o[31:28] | 05:14 |
| hansfbaier | should'nt that use `WB_ARB_ADDR_MATCH_SEL also? | 05:14 |
| hansfbaier | ah no only 4 bit | 05:14 |
| hansfbaier | `WB_ARB_ADDR_MATCH_SEL is 8 bit | 05:14 |
| hansfbaier | IIRC | 05:14 |
| hansfbaier | stekern: now I get it, thanks | 05:15 |
| hansfbaier | stekern: _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 them | 05:22 |
| hansfbaier | when I delete all breakpoints and cont they blink | 05:22 |
| hansfbaier | when I single step over a gpio write | 05:23 |
| hansfbaier | nothing happens too | 05:23 |
| hansfbaier | breakpoints are at bl1 and bl2 | 05:24 |
| stekern | yeah, 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 repo | 05:24 |
| hansfbaier | stekern: ah ok | 05:25 |
| * hansfbaier gets the toolchain blues.... | 05:55 | |
| hansfbaier | stekern: As I understand correctly the toolchain I have https://github.com/kevinmehall/openrisc-tools-build.git | 05:56 |
| hansfbaier | builds binaries for or1k-linux uClibc | 05:56 |
| hansfbaier | If I want to build bare metal with the C compiler, Do i need to compile a new toolchain for newlib? | 05:57 |
| hansfbaier | stekern: ah got it | 06:13 |
| hansfbaier | yes | 06:13 |
| stekern | you need or32-elf for that (or or1k-elf) | 06:14 |
| hansfbaier | stekern: when I compile barebox and/or vmlinux with or32-linux-.... | 06:16 |
| hansfbaier | stekern: ist that wrong??? | 06:16 |
| hansfbaier | stekern: Should those be compiled with or32-elf??? | 06:16 |
| stekern | barebox and linux can be built with either | 06:17 |
| hansfbaier | stekern: One big difficulty with the OpenRisc project is that the source code repos and the documentation are not very well organized. | 06:17 |
| stekern | or or1k-elf (but not with or1k-linux-* as it currently stands) | 06:17 |
| hansfbaier | stekern: that can be a pretty confusing maze for a beginner | 06:18 |
| stekern | yes | 06:18 |
| hansfbaier | stekern: I really appreciated kevins tutorial that made so much sense | 06:18 |
| hansfbaier | stekern: but it's quite difficult to go on from there | 06:19 |
| stekern | well known problem... | 06:19 |
| hansfbaier | :) | 06:20 |
| stekern | but for the toolchains there is a "simple" answer: the old stable toolchain is in opencores svn, all current toolchain development happens under: https://github.com/openrisc | 06:21 |
| _franck_ | we should also provides binary toolchains | 06:22 |
| stekern | all "official" documentaion for the project is under http://opencores.org/or1k/OR1K:Community_Portal | 06:22 |
| stekern | _franck_: I agree | 06:22 |
| stekern | especially now, with the 4.8.1 branched out | 06:23 |
| stekern | any volunteers for that? =) | 06:24 |
| _franck_ | ... | 06:25 |
| _franck_ | ...I would say you ;) | 06:29 |
| stekern | I said volunteers, but yeah, I guess it could be me... ;) | 06:30 |
| hansfbaier | stekern: So what is jonas repo good for, linux port? | 06:39 |
| hansfbaier | or rather: what is the relationship of git.openrisc.net and the repo on github.com/openrisc | 06:41 |
| hansfbaier | s/of/between | 06:41 |
| stekern | ok, this is a long story, I'll try to summarize it... | 06:42 |
| stekern | in the beginning, there was opencores svn. then developers asked for git support, when that didn't happen, jonas set up openrisc.net for Linux and uclibc | 06:43 |
| stekern | later, 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 |
| stekern | as more developers have jumped on-board the project, there was a trend that most of them just created their own git repos on github | 06:45 |
| stekern | so we decided to create the openrisc github organisation to bring those under a common roof | 06:46 |
| stekern | Linux and u-boot have been upstreamed, so their actual "official" repos are their upstream counterparts | 06:47 |
| stekern | now, 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 |
| hansfbaier | stekern: upstream = github? | 06:50 |
| stekern | but ideally, people *should* be able to just use the upstream versions of those, that's at least the idea | 06:50 |
| hansfbaier | ok | 06:50 |
| stekern | no, upstream = kernel.org and git.denx.de | 06:51 |
| stekern | i.e. the same place you would go to get your kernel for your desktop =) | 06:53 |
| hansfbaier | aah the linux kernel upstream | 07:13 |
| hansfbaier | stekern: Ah I get it | 07:14 |
| hansfbaier | stekern: http://pastebin.com/raw.php?i=XUVfDw0T | 08:17 |
| hansfbaier | stekern: I have something weird here | 08:18 |
| hansfbaier | l.sfltu r5, r10 | 08:18 |
| hansfbaier | l.bf loop | 08:18 |
| hansfbaier | r5 = 0x201 | 08:18 |
| hansfbaier | r10=0x1000000 | 08:18 |
| hansfbaier | but the l.bf does not jump | 08:19 |
| hansfbaier | no idea why | 08:19 |
| hansfbaier | am I getting something wrong here? | 08:19 |
| hansfbaier | _franck_: any idea? | 08:23 |
| hansfbaier | Now it gets even weirder: | 08:28 |
| hansfbaier | I changed l.bf to l.bnf | 08:29 |
| hansfbaier | And it does not jump too. | 08:30 |
| hansfbaier | Hardware bug? | 08:30 |
| hansfbaier | or gdb bug? | 08:30 |
| hansfbaier | But when I just cont and set a breakpoint to end: | 08:30 |
| hansfbaier | then I land there with r5 =0x201 | 08:30 |
| hansfbaier | super weird | 08:30 |
| _franck_ | delay slot | 08:32 |
| _franck_ | put nop after branch instructions | 08:32 |
| hansfbaier | _franck_: aaahhh | 08:35 |
| hansfbaier | understand | 08:35 |
| hansfbaier | _franck_: What is the purpose of the delay slot? Technical necessity? Or on purpose? | 08:36 |
| _franck_ | it keeps the pipeline busy | 08:40 |
| _franck_ | while branching | 08:40 |
| hansfbaier | _franck_: now I put 5 l.nop after the branch | 08:41 |
| hansfbaier | and the flag is set in sr | 08:42 |
| frubbl | _franck_: I inserted 5 l.nop and the flag was set but no branch happened.... | 09:06 |
| frubbl | Blackout here.... that's Indonesia... | 09:07 |
| frubbl | On my phone I have a different Nick | 09:07 |
| _franck_ | are you using stepi ? | 09:08 |
| frubbl | Yes at the time | 09:08 |
| _franck_ | not sure in works with your gdb/openocd/RTL combination | 09:08 |
| _franck_ | s/in/it | 09:09 |
| frubbl | Can't try now. Blackout | 09:09 |
| _franck_ | ok | 09:09 |
| frubbl | Stepi on the gpio did not work on the led blinker | 09:10 |
| _franck_ | try to update this function in openocd: https://github.com/fjullien/openOCD/blob/auto_tdesc/src/target/openrisc/or1k.c#L619 | 09:15 |
| _franck_ | I did not push this to the openrisc github yet | 09:16 |
| frubbl | Thanks will try | 09:17 |
| olofk | stekern: Yes, removing the arbiter for WB_PORTS=1 crossed my mind too | 10:03 |
| olofk | My 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 read | 10:04 |
| olofk | I'm trying to find the code where address is increased, but searching for a variable named a isn't all that fun :) | 10:07 |
| stekern | olofk: ah, but it isn't increased | 10:11 |
| stekern | that's not how the bursts work on the sdram side | 10:12 |
| stekern | you give the start address and then read out data according to the burstlen | 10:12 |
| stekern | so you're searching for a needle in a haystack without a needle ;) | 10:15 |
| olofk | But it looks like it's repeating the same data over and over | 10:16 |
| olofk | hmm.. 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 etc | 10:16 |
| stekern | olofk: yeah, that's not gonna work... | 10:17 |
| stekern | https://github.com/skristiansson/wb_sdram_ctrl/blob/master/rtl/verilog/wb_port.v#L370 | 10:17 |
| stekern | I've never claimed that this core is perfect (at least not yet) ;) | 10:18 |
| olofk | hmm.. so it will only work with burst of a specific length? | 10:18 |
| stekern | the sdram_ctrl.v should work with any length, but the wb side expects burst length of 8 | 10:19 |
| stekern | *should*, I haven't really tested anything else than 1 | 10:19 |
| olofk | ahh.. ok. Is this core more or less targeted against cache refills? | 10:20 |
| stekern | mno | 10:20 |
| olofk | Because I guess it won't work for ethernet | 10:20 |
| stekern | it works perfectly for ethernet | 10:20 |
| stekern | but, the wb side has it owns buffers that are 8 32-bits long | 10:20 |
| stekern | so 2*16*8 | 10:21 |
| stekern | s/owns/own | 10:21 |
| olofk | is 8 the BURST_LENGTH here, or is that unrelated? | 10:21 |
| stekern | so it burst into those, thus the "hardcoded" burstlength of 8 | 10:21 |
| stekern | yes | 10:22 |
| olofk | yes what? :) | 10:22 |
| stekern | 8 is the BURST_LENGTH | 10:22 |
| stekern | and the limitation that it *has* to be 8 is in wb_port.v | 10:23 |
| stekern | on the line I pasted | 10:23 |
| olofk | ah.. ok | 10:24 |
| olofk | But how does that work with ethernet? Isn't the whole frame transmitted in one burst? | 10:24 |
| stekern | "no" | 10:25 |
| stekern | but that isn't interesting what ethernet do on the wb side | 10:25 |
| olofk | Then I probably still don't understand | 10:25 |
| stekern | the 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 |
| olofk | yep | 10:26 |
| stekern | ethernet use one of the fixed length ones, right? | 10:26 |
| olofk | No clue. I should ask the maintainer of ethmac... oh wait, that's me :) | 10:27 |
| stekern | =) | 10:27 |
| stekern | it doesn't matter anyway, because the wb bursts are completely unrelated to the sdram bursts | 10:27 |
| stekern | the way the conroller works is that when a wb access occurs on some address, wb_port fetches 8*32 bits into an internal cache | 10:28 |
| olofk | So I should be able to send wishbone burst with any length then? | 10:28 |
| stekern | and then the wb side read out of that cache/buffer | 10:29 |
| olofk | Makes sense. That's probably what I expected | 10:29 |
| stekern | so, how that cache get filled, that's something that the wb side of things doesn't care about | 10:29 |
| stekern | when it is filled, it can burst happily out of it | 10: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 |
| stekern | +possible | 10:31 |
| hansfbaier | _franck_: | 10:31 |
| hansfbaier | ./configure --enable-usb_blaster_libftdi --enable-adv_debug_sys --enable-altera_vjtag --enable-maintainer-mode --disable-usb_blaster_ftd2xx | 10: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 -MF | 10:31 |
| hansfbaier | libtool: 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 usb | 10:31 |
| hansfbaier | usb_blaster/ublast_access_ftd2xx.c:32:20: fatal error: ftd2xx.h: No such file or directory | 10:31 |
| hansfbaier | weird | 10:31 |
| olofk | Ok, 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 port | 10:31 |
| stekern | and if the cache is not filled, the wb side just have to wait for it to be filled | 10:32 |
| stekern | wb bursts doesn't have to complete in a single cycle | 10:32 |
| stekern | olofk: ok, that sounds weird | 10:32 |
| stekern | I've got to run now, but if you have something more concrete for me to look at, I can do that in the evening | 10:33 |
| hansfbaier | _franck_: build seems broken | 10:38 |
| hansfbaier | _franck_: ah just updated the function you told me, seems to build | 10:44 |
| hansfbaier | _franck_: that did the trick! GREAT! Thanks! | 11:29 |
| hansfbaier | _franck_: My memory tester | 11:29 |
| hansfbaier | also uncovered the same problems | 11:29 |
| _franck_ | the openocd reference is here now: http://openocd.zylin.com/#/c/1547/ | 11:29 |
| hansfbaier | _franck_: What does that mean, reference in what sense? | 11:30 |
| _franck_ | hansfbaier: great ! | 11:30 |
| hansfbaier | _franck_: But my little memory test program | 11:30 |
| _franck_ | means the more up-to-date | 11:30 |
| hansfbaier | uncovers the same problem | 11:30 |
| _franck_ | other repo will become obsolete | 11:30 |
| hansfbaier | _franck_: is that upstream? | 11:31 |
| _franck_ | almost | 11:31 |
| * hansfbaier is totally confused about the gazillion different openOCD-git repos | 11:31 | |
| _franck_ | openocd use gerrit (kind of a patch tracker) | 11:31 |
| hansfbaier | _franck_: led blinker also working fine now | 11:31 |
| _franck_ | hansfbaier: yes I know and I'm sorry for that. But I'm working on it | 11:32 |
| _franck_ | openocd is *almost* upstream | 11:33 |
| hansfbaier | _franck_: 0x400108:0xff0xff0xff0xff0xff0xff0xff0xff | 11:46 |
| hansfbaier | 0x400110:0xff0xff0xff0xff0xff0xff0xff0xff | 11:46 |
| hansfbaier | 0x400118:0xff0xff0xff0xff0xff0xff0xff0xff | 11:46 |
| hansfbaier | 0x400120:0xff0x050x000x000x8c0x850x000x00 | 11:46 |
| hansfbaier | ... | 11:46 |
| hansfbaier | The interesting thing the memory checker always crashes at 0x400121, | 11:47 |
| hansfbaier | that means it lands somehow at 0x00000704 | 11:47 |
| hansfbaier | (no idea how) | 11:47 |
| hansfbaier | maybe sdram is broken somehow round that address | 11:48 |
| hansfbaier | stekern: ^ | 11:48 |
| hansfbaier | Here is the current version: http://pastebin.com/qpfB1ngt | 11:49 |
| _franck_ | your memory checker crashes while testing address 0x400121 ? | 12:02 |
| stekern | hansfbaier: I can try running that on my de0 nano in the evening | 12:11 |
| hansfbaier | stekern: Thanks a lot | 12:12 |
| stekern | just as a sanity check | 12:12 |
| hansfbaier | stekern: I can paste the original source | 12:12 |
| hansfbaier | http://pastebin.com/QdSyyeSR | 12:13 |
| hansfbaier | inconsistent whitespace, sorry | 12:13 |
| hansfbaier | _franck_: | 12:15 |
| hansfbaier | Yes, reproducibly | 12:15 |
| hansfbaier | _franck_: symptoms are the same as vmlinux and barebox | 12:16 |
| hansfbaier | just hangs somewhere stuck there | 12:16 |
| hansfbaier | pretty weird | 12:16 |
| hansfbaier | any debugging ideas | 12:16 |
| hansfbaier | stekern: I tried signaltap | 12:16 |
| _franck_ | may be that 0x400121 overlaps 0x000121 somehow | 12:17 |
| _franck_ | with gdb try to write something at 0x400121 and read 0x121 to see if it changes | 12:18 |
| hansfbaier | _franck_: ah good idea | 12:18 |
| hansfbaier | _franck_: BINGO | 12:24 |
| hansfbaier | (gdb) set {unsigned char}0x400122 = 0xff | 12:24 |
| hansfbaier | (gdb) set {unsigned char}0x400123 = 0xff | 12:24 |
| hansfbaier | (gdb) set {unsigned char}0x400124 = 0xff | 12:24 |
| hansfbaier | (gdb) x 0x400121 | 12:24 |
| hansfbaier | 0x400121:0xffffffff | 12:24 |
| hansfbaier | (gdb) x 0x000121 | 12:24 |
| hansfbaier | 0x121 <loop+1>:0xffffffff | 12:24 |
| hansfbaier | (gdb) x 0x400121 | 12:24 |
| hansfbaier | 0x400121:0xffffffff | 12:24 |
| hansfbaier | (gdb) x 0x121 | 12:24 |
| hansfbaier | 0x121 <loop+1>:0xffffffff | 12:24 |
| hansfbaier | _franck_: awesome | 12: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 VCC | 12: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 so | 12:31 |
| ysionneau | or a buggy tlb entry? | 12:31 |
| olofk | I had this problem on one of my boards. Had to remove some solder that was stuck between two of the memory address pins | 12:36 |
| hansfbaier | _franck_: was fun to write the memory checker though | 12:37 |
| hansfbaier | my first or1200k program in assembler | 12:38 |
| hansfbaier | good learning experience | 12:38 |
| _franck_ | now you've passed the openrisc test ;) You can continue.... | 12:44 |
| stekern | ;) | 12:45 |
| _franck_ | and You didn't give up | 12:46 |
| stekern | yes, that's the real test, we're all kind of stubborn people | 12:47 |
| stekern | hansfbaier: could you paste the parameters you feed the sdram controller? | 12:47 |
| stekern | and I'll check the backlog for your memory model and that there's no assumptions that isn't true for that chip | 12:49 |
| hansfbaier | stekern: http://pastebin.com/AGPATP6a | 12:49 |
| hansfbaier | from orpsoc_top | 12:50 |
| hansfbaier | .v | 12:50 |
| hansfbaier | stekern: let me look | 12:50 |
| hansfbaier | H57V1262GTR | 12:51 |
| hansfbaier | row width is 12, isn't it? | 12:52 |
| hansfbaier | instead of 13 | 12:52 |
| hansfbaier | I thought I had already set sdram parameters somewhere | 12:53 |
| hansfbaier | http://www.skhynix.com/inc/pdfDownload.jsp?path=/datasheet/pdf/consumer/H57V1262GTR_Series(Rev.1.0).pdf | 12:55 |
| hansfbaier | stekern: ^ you probably got that already | 12:56 |
| hansfbaier | My model is the -75C | 12:57 |
| hansfbaier | Wait, but no, the chip has 13 address lines | 13:01 |
| hansfbaier | I think I get it: | 13:07 |
| hansfbaier | In the datasheet | 13:07 |
| hansfbaier | it says PIN 36 = NC | 13:07 |
| hansfbaier | but in the schematic of my sdram board | 13:07 |
| hansfbaier | it says A12 | 13:07 |
| hansfbaier | so the pin is a dummy actually | 13:08 |
| hansfbaier | so 12 would be the right row width | 13:08 |
| hansfbaier | chinese boards | 13:08 |
| hansfbaier | this one was so nice and cheap | 13:08 |
| hansfbaier | and mostly worked well | 13:08 |
| hansfbaier | except where it was a learning experience | 13:09 |
| hansfbaier | _franck_: stekern: looks like bingo | 13:22 |
| hansfbaier | now i am already at | 13:22 |
| hansfbaier | 0xc40d93 | 13:23 |
| hansfbaier | and still looping | 13:23 |
| hansfbaier | the memchecker reported an error at 0x91000000 | 13:24 |
| stekern | yeah, your row width should be 12 (as you already figured out) | 13:24 |
| hansfbaier | stekern: I was tricked by the scematic and the tcl file of the manufacturer of the sdram board | 13:25 |
| _franck_ | because AFAIR you forget a delay slot afet l.j | 13:25 |
| hansfbaier | they wired up 13 | 13:25 |
| hansfbaier | but the chip has only 12 | 13:25 |
| hansfbaier | maybe they used the same board for different types of chips | 13:25 |
| stekern | yeah, maybe they weren't sure what part they'd fit when they draw the schematics | 13:25 |
| hansfbaier | (they sell 2 different mem boards) | 13:25 |
| stekern | but I have to admit, I easily get confused by the row, bank and col count too ;) | 13:26 |
| stekern | and especially since address line 10 has that special meaning, it confuses things even more | 13:27 |
| hansfbaier | aaaaaaaaaaaaaaahhhhhhhhh | 13:27 |
| _franck_ | hansfbaier: before you jump to end, you execute l.sb 0(r3),r8 | 13:27 |
| hansfbaier | the 0x91000000 | 13:28 |
| hansfbaier | isn't that the gpio controller | 13:28 |
| _franck_ | it is | 13:28 |
| _franck_ | :) | 13:28 |
| hansfbaier | _franck_: yes you're right | 13:28 |
| hansfbaier | so it means it works | 13:28 |
| * hansfbaier virtually jumps around dancing for joy | 13:28 | |
| stekern | =) | 13:30 |
| _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 |
| olofk | I usually refer to this one to explain what we're all about http://www.eeweb.com/rtz/moment-of-truth | 13:30 |
| hansfbaier | _franck_: looks like watchpoints aren't implemented yet in openocd | 13:30 |
| _franck_ | no, they are not implemented either in RTL | 13:31 |
| hansfbaier | ah I see | 13:31 |
| hansfbaier | I thought because it's in the spec | 13:32 |
| hansfbaier | ok good to know | 13:32 |
| * _franck_ is not that sure about watchpoint | 13:32 | |
| hansfbaier | olofk: hehe | 13:32 |
| hansfbaier | there are a bunch of registers for watchpoints | 13:32 |
| hansfbaier | IIRC | 13:32 |
| hansfbaier | _franck_: but wait | 13:34 |
| hansfbaier | a moment of doubt: | 13:35 |
| stekern | only sw breakpoints are supported, there are some hw breakpoints patches for an older version of or1200, but they were never merged for some reason | 13:35 |
| stekern | only sw breakpoints in mor1kx too | 13:35 |
| _franck_ | that's what I thought | 13:35 |
| hansfbaier | The program should not ever come as far as 0x91000000 | 13:35 |
| hansfbaier | it should stop at 0x100000 | 13:36 |
| hansfbaier | which id didn't | 13:36 |
| hansfbaier | weird again | 13:36 |
| hansfbaier | s/id/it/ | 13:36 |
| stekern | it's because of the missing delay slot nop, no? | 13:39 |
| stekern | you've got 0x91000000 in r3 | 13:40 |
| stekern | when you jump to end | 13:40 |
| hansfbaier | stekern: does l.j need a l.nop too? | 13:46 |
| stekern | yes, all jumps (except l.rfe) has a delay slot | 13:48 |
| olofk | Looking for hotels in Cambridge now. Anyone booked anything yet? | 13:52 |
| hansfbaier | stekern: thanks, good to know | 13:53 |
| hansfbaier | ok now time for a linux kernel boot | 13:54 |
| * hansfbaier has to reboot first | 13:54 | |
| hansfbaier | usb stack confused | 13:55 |
| hansfbaier | PL2303 does not want to be recognize | 13:55 |
| hansfbaier | d | 13:55 |
| hansfbaier | init started: BusyBox v1.19.0.git (2011-02-16 08:10:12 CET) | 14:08 |
| hansfbaier | Configuring loopback device | 14:08 |
| hansfbaier | Please press Enter to activate this console. | 14:08 |
| hansfbaier | ifconfig: SIOCSIFADDR: No such device | 14:08 |
| hansfbaier | # | 14:08 |
| hansfbaier | # | 14:08 |
| hansfbaier | WOOT! | 14:08 |
| hansfbaier | _franck_: stekern: THANK YOU | 14:09 |
| hansfbaier | Finally | 14:09 |
| hansfbaier | I have a complete open source system | 14:10 |
| hansfbaier | anyone ported X yet ;) | 14:10 |
| hansfbaier | would be a drag though | 14:11 |
| _franck_ | great to hear | 14:11 |
| hansfbaier | OpenRISC w/ linux the ideal learning environment | 14:12 |
| hansfbaier | I can build my own hardware and write my own linux drivers for it | 14:12 |
| _franck_ | always a great news when we have new contributors | 14:12 |
| hansfbaier | I have to catch up a bit with my paid work now | 14:12 |
| hansfbaier | was playing around more than full time for 2 days | 14:13 |
| hansfbaier | _franck_: will try barebox now | 14:13 |
| stekern | olofk: still not yet, yell if you find something good | 14:14 |
| stekern | I'll do the same | 14:15 |
| stekern | hansfbaier: poke53282 have tested compiling and running X, but there's a bug somewhere | 14:16 |
| hansfbaier | stekern: really, that was a joke actually, but wow! | 14:16 |
| stekern | he got xeyes running at least ;) | 14:17 |
| hansfbaier | stekern: wow that's pretty good already | 14:20 |
| stekern | hansfbaier: where are you working? | 14:23 |
| hansfbaier | _franck_: barebox runs too | 14:24 |
| hansfbaier | stekern: I am freelance | 14:25 |
| hansfbaier | stekern: but my main customer is a small german company building embedded trance hardware | 14:25 |
| hansfbaier | stekern: pretty cool stuff | 14:25 |
| hansfbaier | just joined them a couple of weeks ago | 14:25 |
| hansfbaier | www.gliwa.com | 14:25 |
| _franck_ | trance ? | 14:26 |
| hansfbaier | _franck_: :) | 14:26 |
| stekern | ah, that explain how you can "set aside" two days to play with openrisc =) | 14:26 |
| stekern | yeah, I was about to ask the same, trance? | 14:26 |
| _franck_ | looking at the german website I guess it's *trace* | 14:27 |
| hansfbaier | ah yes, trace, sorry | 14:27 |
| hansfbaier | pretty cool stuff | 14:27 |
| _franck_ | and you are doing software ? | 14:27 |
| hansfbaier | a customer found in a day the problem they were debugging for months | 14:28 |
| olofk | or timing analysis? ;) | 14:28 |
| hansfbaier | stekern: Yes, software | 14:28 |
| hansfbaier | embedded too | 14:28 |
| hansfbaier | LPC1769 | 14:28 |
| hansfbaier | I am still pretty new to the embedded world | 14:28 |
| hansfbaier | That's why I am playing so hard | 14:28 |
| hansfbaier | still need to learn so much | 14:28 |
| _franck_ | I've always wanted to work as a freelancer... | 14:29 |
| hansfbaier | I was writing enterprise java stuff for years now | 14:29 |
| hansfbaier | and got so fed up and bored with it I needed something else | 14:29 |
| hansfbaier | And then i got all excited about hardware and electronics | 14:29 |
| hansfbaier | blinking LEDs :) | 14:30 |
| _franck_ | yes, it's much better than printing "Hello, World !" | 14:30 |
| _franck_ | :) | 14:30 |
| hansfbaier | There's a sd card controller in orpsoc IIRC, right? | 14:31 |
| hansfbaier | Now I can try re-enable the cpu caches | 14:31 |
| hansfbaier | the nice thing about my chinese board is, that I can use exactly the same base board and expansion modules | 14:37 |
| hansfbaier | for my Altera EP4CE10 as well as my Xilinx XC3S500E | 14:37 |
| hansfbaier | the FPGA module is exchangeable | 14:37 |
| hansfbaier | apart from the price | 14:38 |
| stekern | do they have any larger fpgas? | 14:38 |
| stekern | and I'm also a bit surprised it didn't make it pass 50mhz with or1200 | 14:39 |
| hansfbaier | stekern: unfortunately not | 14:40 |
| stekern | but maybe it's just so packed | 14:40 |
| hansfbaier | stekern: I ordered the Adapteva parallela | 14:40 |
| hansfbaier | great value for $199 | 14:40 |
| stekern | me too | 14:40 |
| hansfbaier | got the Zynq x20 | 14:40 |
| hansfbaier | about 75k LUT IIRC | 14:41 |
| hansfbaier | great value for money | 14:41 |
| hansfbaier | that's 7.5x larger than my EP4cE10 | 14:41 |
| hansfbaier | stekern: Only the connectors are a PITB | 14:42 |
| stekern | would be interesting what kind of fmax you'd get with mor1kx on that board | 14:42 |
| stekern | your ep4 board I mean | 14:43 |
| hansfbaier | stekern: does openOCD work with Xilinx boards | 14:43 |
| hansfbaier | stekern: Is mor1kx faster? | 14:43 |
| stekern | yes, and especially the version in my working tree | 14:44 |
| stekern | and openocd at least work with xilinx if you use an external jtag connection | 14:44 |
| hansfbaier | stekern: so configure some of the outputs as jtag | 14:45 |
| hansfbaier | stekern: but with which JTAG interface? | 14:45 |
| hansfbaier | The altera blaster? | 14:45 |
| hansfbaier | or something like a J-Link? | 14:45 |
| hansfbaier | stekern: is the mor1kx drop-in compatible, | 14:46 |
| stekern | those el cheapo arm jtag debuggers from e.g. olimex should work | 14:46 |
| hansfbaier | or do I need to wire it up | 14:47 |
| _franck_ | I'm using an Olimex ARM-USB-TINY | 14:47 |
| stekern | yes, it's drop in compatible | 14:47 |
| hansfbaier | stekern: what would be the best repo to clone? | 14:48 |
| stekern | since you're using my de0 nano as base it's just a matter of comment OR1200 and uncomment MOR1KX in the config file | 14:49 |
| stekern | and copy the sources from github.com/openrisc/mor1kx | 14:49 |
| hansfbaier | stekern: Do you think we should commit the Waveshare board into the tree? | 14:50 |
| hansfbaier | now that it is running? | 14:50 |
| hansfbaier | will need some more work though | 14:51 |
| hansfbaier | renames etc.. | 14:51 |
| stekern | yeah, sure | 14:52 |
| hansfbaier | stekern: OK, I try to do the rename and get everything ready, that it is comparable to the de0_nano board | 14:52 |
| hansfbaier | s/I/I'll/ | 14:53 |
| stekern | while you're at it, you can change that VERSATILE_SDRAM define, that's something i newer seem to get around to do... | 14:58 |
| stekern | never | 14:58 |
| stekern | to WB_SDRAM_CTRL or something | 15:01 |
| stekern | _franck_: I have one of those too, but I never actually tested it with openrisc, just heard that they should work | 15:07 |
| stekern | good to get it confirmed from a trusted source ;) | 15:07 |
| hansfbaier | stekern: You have a waveshare-board too | 15:10 |
| hansfbaier | ? | 15:10 |
| hansfbaier | or Olimex | 15:10 |
| stekern | no, an ARM-USB-TINY | 15:10 |
| hansfbaier | _franck_: Will the ARM-USB-TINY-H work too? | 15:20 |
| stekern | I can't see why that wouldn't work | 15:24 |
| _franck_ | yes should work: https://github.com/fjullien/openOCD/blob/auto_tdesc/tcl/interface/ftdi/olimex-arm-usb-tiny-h.cfg | 15:30 |
| _franck_ | well, may me I have an ARM-USB-OCD, can't remember | 15:32 |
| hansfbaier | _franck_: Ah disabling caches was important too | 15:34 |
| hansfbaier | enabled them | 15:34 |
| hansfbaier | now it hangs in busybox | 15:35 |
| stekern | wonder what's the problem now | 15:54 |
| ams | stekern: lack of beer or coffee. | 16:14 |
| hansfbaier | good night | 16:16 |
| hansfbaier | thanks a lot | 16:16 |
| hansfbaier | got to sleep | 16:16 |
| hansfbaier | next project would be hooking up an enc28j60 into the spi | 16:17 |
| hansfbaier | and linux | 16:17 |
| hansfbaier | byq | 16:17 |
| hansfbaier | bye | 16:17 |
| stekern | I wonder what I should do with the lsu error tests, they are going to fail since I can never exactly handle store errors as before | 18:07 |
| stekern | since there will be registers written back etc while the store is being processed | 18:08 |
| stekern | I 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 anyway | 18:09 |
| stekern | s/games/game | 18:09 |
| olofk | stekern: Not sure if I really understood each other earlier regarding the burst stuff, but it works now | 18:10 |
| olofk | If I set BURST_LENGTH=8 | 18:10 |
| stekern | olofk: schizo, eh? you and you not understanding each others, not sure I can help you there | 18:12 |
| olofk | LOL | 18:13 |
| stekern | but, BURST_LENGTH has to be 8, due to current limitations in wb_port.v ;) | 18:13 |
| olofk | Now that's a fucking confusing parameter | 18:13 |
| stekern | yeah, sorry about that :( | 18:13 |
| olofk | No worries. Even Hitler made mistakes | 18:14 |
| stekern | the idea is/was of course that the limitation shouldn't exist in wb_port.v | 18:14 |
| olofk | It breaks on wishbone bursts with length > 4, but that might be my test bench logic | 18:15 |
| stekern | should work with that, I've used burst length > 4 | 18:15 |
| stekern | maybe I remove the BURST_LENGTH parameter from the top level, until wb_port.v is fixed ;) | 18:16 |
| olofk | Hmm. it wasn't related to wb burst length. | 18:24 |
| stekern | what is it related to? | 18:32 |
| olofk | Not sure yet, but I'm getting wrong data back on some reads | 18:38 |
| olofk | Where's the internal cache? | 18:40 |
| stekern | in wb_port.v | 18:47 |
| olofk | Hmmm... am I supposed to cut off an LSB of wb_adr? | 18:52 |
| stekern | hmm, no, they are expected to be 31:0 at least on the external interface | 18:55 |
| olofk | It looks like the cache isn't updated properly | 19:05 |
| olofk | I'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 back | 19:06 |
| stekern | maybe you've found a bug! ;) | 19:07 |
| stekern | because when I'm reading the code I see a corner case that is not covered | 19:07 |
| stekern | no, actually I think it is covered | 19:13 |
| stekern | I thought that there might still be data in the write fifo when the read is done, but the writes have higher priority than the reads | 19:14 |
| stekern | done == started | 19:15 |
| stekern | there 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 raised | 19:17 |
| stekern | but otoh, there should be a 2 clock cycle latency for the read to propagate into the sdram domain as well | 19:17 |
| stekern | but 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 |
| stekern | this makes me wonder a thing about wb burst writes, do they really have to be in any particular order? | 19:24 |
| olofk | stekern: I'm not sure it's strictly burst-related. Want my VCD+ | 19:25 |
| olofk | s/+/? | 19:25 |
| olofk | _franck_: No. There are some improvements to be made in that area | 19:25 |
| stekern | basically, they could be treated as pipelined writes, since why do you need to know the next address? | 19:25 |
| stekern | olofk: yeah, sure send it over | 19:26 |
| olofk | _franck_: But I'm sending stdout/stderr to log files in the build/core/sim-$simulator directory | 19:26 |
| _franck_ | ok | 19:27 |
| olofk | stekern: Address is only valid on the first transaction in a burst. All other addresses are calculated from cti/bte | 19:28 |
| stekern | olofk: no | 19:28 |
| stekern | the master has to provide the address on all accesses | 19:28 |
| olofk | Are you really sure about that? | 19:29 |
| stekern | yes | 19:29 |
| olofk | That's just stupid | 19:29 |
| stekern | because otherwise you wouldn't be backward compatible | 19:29 |
| olofk | That's true | 19:29 |
| olofk | (not stupid) | 19:29 |
| olofk | https://www.dropbox.com/s/umvaoznnpif32bd/testlog.vcd | 19:30 |
| olofk | The reads and writes are very close to each other, so you might be on to something there | 19:32 |
| olofk | It's getting interesting after 29980 ns | 19:33 |
| stekern | umm, why are there lots of 'z' on the wb lines? | 19:34 |
| stekern | (completely unrelated to the problem though) | 19:35 |
| _franck_ | olofk: FYI http://pastebin.com/SMvDyHam , I need to clean build/de1/* to run the simulation again | 19:36 |
| olofk | stekern: I wanted to only have one master writing data, and I couldn't set WB_PORTS=! | 19:36 |
| olofk | s/!/1 | 19:36 |
| olofk | So only the last of the three ports are connected | 19:37 |
| stekern | heh, yeah, I guessed that | 19:37 |
| olofk | _franck_: @(posedge wb_clk_i); | 19:38 |
| olofk | fuck | 19:38 |
| olofk | _franck_: Try /usr/local/bin/python3.3 bin/orpsoc.in sim --force de1 | 19:38 |
| stekern | that's a pretty frantic fuck, I'd say | 19:38 |
| olofk | LOL | 19:38 |
| olofk | But I guess it depends on your f_max :) | 19:39 |
| stekern | true | 19:39 |
| olofk | I tried to put some extra cycles between each access, but it didn't help | 19:40 |
| stekern | it's the read from 0x2608 that's wrong, right? | 19:44 |
| stekern | the write burst looks a bit odd though, but apart from that, the 0x2608 read still looks wrong | 19:45 |
| stekern | well, maybe it doesn't look odd, what did cti='010' mean? | 19:47 |
| olofk | repeat (20) @(posedge wb_clk_i); | 19:47 |
| olofk | Grr.. | 19:47 |
| olofk | We can use wb_sdram_ctrl_tb.masters[2].wb_master0.transaction to keep track of which transaction we're talking about | 19:48 |
| stekern | 42 | 19:49 |
| stekern | 0x42 | 19:50 |
| olofk | cti=010 is incrementing burst cycle according to the spec | 19:50 |
| stekern | ok, then it's nothing odd to only have three accesses in the burst | 19:51 |
| stekern | or no... I probably meant bte then | 19:51 |
| olofk | Yes, the data returned in 0x44 is a combination of the writes from 0x42 and 0x43 | 19:51 |
| olofk | bte=010? It's only two bits | 19:52 |
| stekern | no, bte=11 | 19:52 |
| stekern | I'm mixing up bte and cti | 19:53 |
| stekern | but 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 read | 19:54 |
| stekern | ...no, the read comes later than that... | 19:54 |
| stekern | I 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 |
| olofk | I separated the writes and reads with ~20 cycles, so I don't think they are too close | 19:57 |
| olofk | _franck_: You can add icarus_options in your .core file. You should be able to set -D<define> there | 19:57 |
| _franck_ | ok thanks | 19:58 |
| olofk | Sorry... iverilog_options is the name | 19:58 |
| olofk | In the [icarus] section | 19:58 |
| olofk | There is a similar for modelsim. | 19:58 |
| * _franck_ should read capi.txt :) | 19:59 | |
| * olofk should update capi.txt | 19:59 | |
| olofk | asciidoc -b xhtml11 capi.txt makes it a bit more readable | 20:00 |
| olofk | stekern: bte=11 should be a 16-beat wrap | 20:01 |
| stekern | yup, I opened the spec here too | 20:02 |
| stekern | ending them prematurely is of course ok, they just initially looked odd | 20:02 |
| olofk | You want an updated VCD with more space between the transactions? | 20:03 |
| stekern | but the read I thought was wrong was actually a write... | 20:03 |
| stekern | ...so now I can't see anything wrong anymore... | 20:04 |
| stekern | which transaction was the faulty one? | 20:04 |
| olofk | The read back from 0x44 | 20:05 |
| olofk | I'm writing 0x0684410D, 0x2EBAB55D, 9917C432 | 20:05 |
| stekern | ah, that was too far out on the right ;) | 20:06 |
| olofk | I'm getting back 0x0684410D, 0x4DBC9B9B, 6BD921D7 | 20:06 |
| olofk | The last two values are from transactions 0x42 and 0x43. | 20:06 |
| olofk | ...which is why I'm guessing that the caches are the culprit here | 20:07 |
| stekern | yeah, that's a good guess, the read in 0x44 doesn't even go out on the sdram bus to fetch those values | 20:13 |
| olofk | Here's a version that separates the accesses https://www.dropbox.com/s/1q4frvhm341gv2i/testlog2.vcd | 20:15 |
| stekern | try this patch: http://pastie.org/8281310 | 20:24 |
| _franck_ | who's going to change its name: astebin.com/2gbPn7m6 ? | 20:24 |
| stekern | heh... yeah, verilog namespaces are a pain... | 20:26 |
| olofk | stekern: Nope, sorry. Didn't help :( | 20:28 |
| stekern | huh, 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-arbiter | 20:29 |
| stekern | olofk: oh wait... I see why | 20:29 |
| stekern | heeelp, why is pastebin playing videos?? | 20:31 |
| stekern | olofk: this *has* to work: http://pastie.org/8281336 | 20:34 |
| _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 me | 20:38 |
| olofk | stekern: That helped a little. Only the last word is wrong now | 20:40 |
| stekern | hmm, can I see the vcd of that? | 20:43 |
| olofk | testlog2.vcd is updated | 20: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 |
| stekern | yeah, I know what's wrong | 20:49 |
| stekern | patch coming up in a few | 20:49 |
| stekern | olofk: http://pastie.org/8281424 | 20:53 |
| olofk | It works with a single master now | 21:05 |
| olofk | But when I enable an additional master, something is still wrong | 21:06 |
| olofk | But that could definitely be in my test bench | 21:06 |
| _franck_ | I need to sleep, bye | 21:08 |
| olofk | good night | 21:08 |
| stekern | _franck_: you got some closure at least =) | 21:08 |
| stekern | night | 21:08 |
| stekern | olofk: is it burst writes that is the trouble there too? | 21:09 |
| olofk | Yes, but all my writes are burst, even if length is 1 | 21:09 |
| stekern | as you might guess, I haven't ever used those | 21:09 |
| olofk | But I'm pretty confident that this is in my transactor | 21:10 |
| stekern | ah, but cti=111 doesn't count | 21:10 |
| stekern | but nice job catching that write burst bug, my beer debt is growing | 21:11 |
| olofk | Oh no. I'm in debt to you for fixing it. I'm just glad that my fancy wishbone BFM has gotten som real-world use | 21:12 |
| olofk | And the last problem was in my TB | 21:12 |
| olofk | ...or... | 21:13 |
| olofk | Oh well. This is it for tonight | 21:13 |
| stekern | I see that that patch is still not perfect | 21:14 |
| olofk | The same goes for my test bench | 21:14 |
| stekern | ...or is it | 21:14 |
| olofk | :) | 21:15 |
| olofk | Good night | 21:15 |
| stekern | maybe it's time for bed ;) | 21:15 |
| stekern | night | 21:15 |
| stekern | ah, 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 that | 21:19 |
| stekern | non-burst accesses I mean | 21:21 |
| knz | yop | 21:21 |
| knz | just wondering what the "l." instruction mnemonic prefix is about | 21:23 |
| hansfbaier | stekern: do you ever sleep :) | 21:30 |
| hansfbaier | stekern: question: | 21:31 |
| hansfbaier | 0x00000184 <loop+96>:l.nop 0x0 | 21:31 |
| hansfbaier | 0x00000188 <loop+100>:l.nop 0x0 | 21:31 |
| hansfbaier | => 0x0000018c <loop+104>:l.j 0x6 | 21:31 |
| hansfbaier | 0x00000190 <loop+108>:l.nop 0x0 | 21:31 |
| hansfbaier | 0x00000194 <loop+112>:l.nop 0x0 | 21:31 |
| hansfbaier | 0x00000198 <memerr+0>:l.sb 0x0(r3),r6 | 21:31 |
| hansfbaier | End of assembler dump. | 21:31 |
| hansfbaier | (gdb) nexti | 21:31 |
| hansfbaier | 0x00000190 in loop () | 21:31 |
| hansfbaier | 3: $r5 = 16777216 | 21:31 |
| hansfbaier | stekern: I wonder why the l.j is not executed..... | 21:31 |
| hansfbaier | that's very weird | 21:31 |
| hansfbaier | now it got executed | 21:32 |
| hansfbaier | ok, never mind | 21:32 |
| hansfbaier | I think I know why. | 21:46 |
| hansfbaier | the weird effect that pc jumps to nowhere and gets stuck there happens when there is an access to an illegal address | 21:46 |
| hansfbaier | when I erroneously did an l.sh to 0x91000001 instead of l.sb I got there in the next instruction | 21:47 |
| poke53282 | Hi 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: http://simulationcorner.net/opencore4/X11.png | 21:47 |
| hansfbaier | poke5328: very cool | 21:48 |
| hansfbaier | that would already be pretty plenty if it were stable | 21:49 |
| hansfbaier | tried it on the binary simulator? | 21:49 |
| hansfbaier | or hardware? | 21:49 |
| poke53282 | I 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 |
| poke53282 | In an emulator. | 21:49 |
| poke53282 | http://s-macke.github.com/jor1k/ | 21:49 |
| poke53282 | This one | 21:49 |
| hansfbaier | Yes | 21:49 |
| hansfbaier | maybe it is also a problem in the simulator | 21:50 |
| poke53282 | I had the same crashes in or1ksim | 21:50 |
| hansfbaier | ah ok | 21:50 |
| poke53282 | You don't need a framebuffer to test. | 21:50 |
| poke53282 | virtual Xserver is fine. | 21:51 |
| hansfbaier | poke53282: good to know | 21:51 |
| hansfbaier | but X is off limits for me now | 21:51 |
| hansfbaier | there's still so much other stuff to get running | 21:51 |
| hansfbaier | want to make SPI Ethernet work in linux | 21:51 |
| poke53282 | You can find the script to compile everything here: https://github.com/s-macke/jor1k-toolchain-builder | 21:52 |
| poke53282 | Ok | 21:52 |
| poke53282 | It is only a matter of time when it will work. Just one bug left. | 21:53 |
| poke53282 | But you can try scummvm :) | 21:53 |
| --- Log closed Fri Aug 30 00:00:33 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
