| --- Log opened Thu May 01 00:00:29 2014 | ||
| stekern | _franck_: the pastie from or1200-generic shows that or1200-generic *doesn't* work, no? | 05:55 |
|---|---|---|
| stekern | bah, my clipboard didn't take your paste, so I pasted my old pastie in to the browser... | 05:56 |
| stekern | yes, that seems like it's working like it should, and almost match what I saw on hardware with or1200. On hw, it didn't go to 20 after 'next' on 22, but got 'stuck' on 22 | 05:57 |
| stekern | yeah, it's odd, when I try to enable mor1kx in Jose's branch the vpi server doesn't get enabled at all | 06:33 |
| stekern | I can't see how that would depend on the MOR1KX `define | 06:33 |
| _franck_ | I'm trying to make jtag_vpi to work also | 06:33 |
| _franck_ | yes weird, the jtag_vpi.v tasks gets stuck at some point | 06:34 |
| _franck_ | (0.00 ns) Task reset_tap | 06:34 |
| _franck_ | then nothing | 06:34 |
| stekern | with mor1kx? | 06:48 |
| _franck_ | yes, with icarus | 06:49 |
| stekern | mmm, that sounds like what's happening here too | 06:49 |
| _franck_ | but I just figured out I can't start a simu from the unmodified mor1kx-generic :( | 06:49 |
| stekern | hmm, why? | 06:50 |
| _franck_ | I loads the program then it get stuck, the vcd is empty | 06:50 |
| _franck_ | need to find out | 06:50 |
| stekern | ohh.. that could perhaps be related then | 06:50 |
| stekern | I did try running icarus against it at some point at least, so it has worked | 06:51 |
| _franck_ | at least I can make it work with verilator | 06:56 |
| _franck_ | with icarus, it doesn't say "VCD dump started (0)" | 06:57 |
| _franck_ | need to go, bye | 06:58 |
| stekern | ok, I'll take a look at that... | 06:58 |
| stekern | I think I'll try to make Jose's branch to work with verilator instead | 06:59 |
| stekern | hmm, something is not working right with export_files in verilator section | 07:05 |
| stekern | ah.. it's a bug in build_SysC | 07:27 |
| stekern | _franck_: I get this when I try to use your or1200-generic patch: | 08:02 |
| stekern | Error: Couldn't read the CPU state | 08:02 |
| stekern | from openocd | 08:02 |
| stekern | _franck_: what was your test program and what did you compile it with? | 08:22 |
| stekern | I can't of course run the one I did for the hw, because libgloss tries to access memory with xxxxx | 08:23 |
| stekern | let's fix that | 09:18 |
| _franck_ | stekern: I took your test program and changed 0x9700000 to 0x90000000 | 10:03 |
| Findeton | so | 10:06 |
| Findeton | I'm trying to build the newlib toolchain again | 10:06 |
| Findeton | I'm following http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 | 10:07 |
| Findeton | but when I try to compile it it says something like | 10:07 |
| Findeton | sysinfo.c:(.text+0x3f6): undefined reference to `yylex' | 10:07 |
| _franck_ | stekern: just to be sure: ./src/openocd -f ./tcl/interface/jtag_vpi.cfg -c "set TAP_TYPE MOHOR" -f ./tcl/board/or1k_generic.cfg -s ./tcl | 10:08 |
| Findeton | here is the whole output http://pastebin.com/JGpU5W3e | 10:09 |
| stekern | _franck_: (test program) what did you compile it with? | 10:18 |
| stekern | and yes, that's the command line I'm using | 10:18 |
| stekern | and it works with Jose's de0_nano_sim | 10:18 |
| stekern | Findeton: do you have bison/flex installed? | 10:19 |
| _franck_ | stekern: or1k-elf-gcc -O0 -g -o test_dbg test_dbg.c | 10:20 |
| Findeton | stekern: shit | 10:21 |
| Findeton | I thought I had it, but I didn't have flex | 10:21 |
| Findeton | bison I do have | 10:21 |
| Findeton | btw I am creating a script to download build and install all the openrisc tools from zero for a debian/ubuntu environment | 10:22 |
| Findeton | so that I don't have to do everything thrice :p | 10:22 |
| Findeton | a lazy programmer is a good programmer | 10:23 |
| stekern | true that | 10:25 |
| blueCmd | Findeton: you might want to make it a Makefile | 10:27 |
| blueCmd | since it has built-in support for skipping already done steps | 10:27 |
| blueCmd | feel free to borrow / steal stuff from https://github.com/bluecmd/or1k-devel/blob/master/Makefile | 10:28 |
| Findeton | thanks for the info blueCmd | 10:28 |
| blueCmd | That makefile will do everything if you do "make root" - but it will not download the sources for or1k-src/or1k-linux/or1k-gcc and or1k-glibc | 10:29 |
| blueCmd | but it will download stuff like ncurses and zsh | 10:29 |
| blueCmd | or rather, https://github.com/bluecmd/or1k-devel/blob/master/tools/Makefile will | 10:29 |
| Findeton | interesting, I'll look into it | 10:31 |
| blueCmd | Findeton: there is also a project in #debian-bootstrap called 'rebootstrap' that builds everything and outputs a couple of debs | 10:32 |
| blueCmd | it doesn't work for or1k yet because we're not upstreamed fully though | 10:32 |
| Findeton | that's ironic because my idea is to remove bootstrapping from openrisc haha | 10:33 |
| Findeton | xD | 10:33 |
| blueCmd | what do you mean? | 10:33 |
| Findeton | I mean, my ideal thing would be to have an assembler developed in assembly code | 10:34 |
| Findeton | openrisc assembly code I mean | 10:34 |
| blueCmd | And build everything from that? | 10:34 |
| blueCmd | Like small-as -> binutils -> gcc ... ? | 10:35 |
| Findeton | and from that, a set of higher and higher compilers all the way to llvm ir, C and finally gcc | 10:35 |
| blueCmd | right | 10:35 |
| Findeton | yeah, but you know, without bootstrapping | 10:35 |
| Findeton | :p | 10:35 |
| blueCmd | well that's what bootstrapping is, no? | 10:35 |
| blueCmd | bootstrapping = building stuff in stages from nothing | 10:35 |
| Findeton | well, only the assembler would be bootstrapped | 10:36 |
| blueCmd | at least to me | 10:36 |
| blueCmd | you're talking about cross compiled? | 10:36 |
| Findeton | no, bootstrapping is to build the tools from other machine :p | 10:36 |
| blueCmd | no, that's cross compilation | 10:36 |
| Findeton | what I mean is that | 10:36 |
| Findeton | for example gcc is developed in C/C++ (depending on the version) | 10:37 |
| blueCmd | right. makes much more sense then :) | 10:37 |
| blueCmd | you want a fully natively compiled system | 10:37 |
| Findeton | yeah, from scratch | 10:37 |
| Findeton | from the metal, as they say | 10:37 |
| blueCmd | (or as far as you can get) | 10:37 |
| blueCmd | "small-as" or whatever you want to call it would still need to be cross-compiled (or be compiled by a non-pure native system) | 10:38 |
| Findeton | or by hand | 10:38 |
| Findeton | an assembler developed with assembly code... its cross compilation can be checked manually | 10:38 |
| Findeton | it could be compiled by hand if you have a lot of free time, but it would suffice to check random parts of the compilation I think :p | 10:40 |
| blueCmd | well if you do it by hand you're the cross compiler | 10:42 |
| blueCmd | This sounds like it would have been someones thesis | 10:46 |
| blueCmd | so maybe you can find this small assembler somewhere and figure out exactly how much it needs to be able to do | 10:47 |
| Findeton | yeah but you need way more than just an assembler | 10:48 |
| Findeton | you need to get to compile C natively | 10:48 |
| stekern | _franck_: (or1k-elf-) how can that work in icarus without a fixed libgloss? | 10:49 |
| Findeton | I think a good way is to create a C compiler developed in llvm ir code, and a llvm ir to assemly code in asssembly code | 10:49 |
| Findeton | and just to bother the founders of llvm, i'll do it free software, not open source :p | 10:50 |
| blueCmd | well you would need a C library for that as well then | 10:50 |
| Findeton | whatever it takes! it's just for fun, I have time | 10:51 |
| Findeton | I know it's a lot of work, I'm doing it step by step, I don't really care if I finish it actually | 10:52 |
| _franck_ | stekern: you tell me. I didn't look at the vcd output, just connected with gdb set breakpoints, jump at 0x100 then run then test then it works for me | 11:03 |
| stekern | just for fun, could you give me the .elf? | 11:04 |
| blueCmd | stekern: I forgot how to build or1ksim for 32 bit and I'm too lazy to scourge | 11:04 |
| blueCmd | do you know it off-hand? | 11:05 |
| stekern | because, the problem is, the board mem start symbol ends up in bss and is referenced before bss is cleared | 11:05 |
| stekern | why do you need a 32-bit or1ksim? | 11:05 |
| _franck_ | stekern: https://www.dropbox.com/s/b6jebgvngejasp9/test_dbg | 11:06 |
| blueCmd | stekern: because I get a shitload of <invalid> | 11:06 |
| stekern | blueCmd: doesn't this fix it for you? https://github.com/openrisc/or1ksim/commit/5bc5f0e903efe2b42dfa31b6b2d31260a3baa5a6 | 11:11 |
| stekern | _franck_: ok, for some reason, _board_mem_base hasn't ended up in .bss | 11:22 |
| stekern | but it does in mine | 11:22 |
| stekern | aaaanyway.... | 11:23 |
| _franck_ | (mor1kx-generic with icarus) if I comment mor1kx in orpsoc_top.v, the simulation runs... | 11:32 |
| stekern | _franck_: can confirm that mor1kx-generic fails here too in icarus | 11:32 |
| stekern | how do you mean 'comment' | 11:33 |
| stekern | ah, I understand | 11:33 |
| _franck_ | I mean remove | 11:33 |
| stekern | yes, there is something in mor1kx, that's clear | 11:33 |
| stekern | and it has to be a recent commit, since it *has* worked | 11:33 |
| stekern | let me find a rev that works and bisect this | 11:33 |
| _franck_ | hmu, don't know if fusesoc's github provider supports specific revision when fetching the core | 11:35 |
| _franck_ | *hum | 11:35 |
| _franck_ | ah, some cleanup to do, for github provider, the capi doc says "branch" and in cores it is "version" | 11:37 |
| stekern | yes, and version can be about anything that you can 'checkout' | 11:43 |
| stekern | but I have mor1kx as a local provider, at least when I'm doing dev on it | 11:44 |
| stekern | https://github.com/openrisc/mor1kx/commit/9e5a414e35cee893d46d4a7442f2b80e32619b82 | 11:48 |
| stekern | it's that one | 11:48 |
| stekern | it's probably better to run vcd recording with icarus than verilator when manually doing things with gdb | 12:04 |
| stekern | the vcd might grow rather big with verilator | 12:05 |
| stekern | I've got a capture of 'next' failure with mor1kx now at least | 12:07 |
| stekern | stupid delay slots... | 12:21 |
| stekern | it's mofo pain keeping track of them when stepping | 12:21 |
| stekern | +a | 12:22 |
| stekern | I think this problem is two-folded | 12:50 |
| stekern | 1) the bug I'm fixing now, where a stall at a jump insn would not follow the jump | 12:51 |
| stekern | 2) it looks like gdb really is "going into the function" when doing next | 12:51 |
| _franck_ | stekern: that could help: | 13:10 |
| _franck_ | https://github.com/fjullien/or1k-src/commit/8b7a003ffa4a7f9e55bc1ffd8ff87cf5e4ca9497#diff-fec1eded1311c718d58f468abbbf9666R595 | 13:10 |
| _franck_ | I have two commits here I never applied: | 13:11 |
| _franck_ | https://github.com/fjullien/or1k-src/commits/or1k | 13:11 |
| stekern | ok, I'll try those, just found another corner case to fix in mor1kx | 13:13 |
| stekern | what do you 'set remotetimeout' to? | 13:24 |
| blueCmd | stekern: oh, I haven't merged those | 13:35 |
| blueCmd | the timestamp confused me | 13:35 |
| blueCmd | thanks | 13:38 |
| jeremybennett | stekern: Now back in circulation. juliusb is by far the more recent and active maintainer of newlib. I only did the trivial teaching version he used as a starting point. Quite happy for someone else to take over maintaining. | 13:46 |
| stekern | jeremybennett: that's what I suspected | 13:51 |
| stekern | I think I've got all single step issues ironed out in mor1kx now, I can step the test program without problems several iterations at least, something I couldn't before | 13:57 |
| stekern | this 'next' problem is definitely a gdb issue. what looked like "working" with or1200 is actually or1200 failing, it doesn't execute the functions, it just skips it | 14:53 |
| stekern | (I know, because my test code sets the leds in the functions, but nothing change when nexting over them with or1200) | 14:54 |
| stekern | let's try your patches now _franck_ | 14:57 |
| stekern | or32-elf-gdb works differently btw: http://pastie.org/9130960 | 15:02 |
| stekern | is that how it's suppose to work? | 15:03 |
| stekern | _franck_: looking closer at your patch, I don't think that will make a difference for this issue | 15:06 |
| stekern | it'll only make a difference if setting a bp in a delay slot, right? | 15:07 |
| stekern | hmm, wonder how all this works together with or1ksim | 15:12 |
| Findeton | make[2]: *** No rule to make target `install'. Stop. | 15:25 |
| Findeton | make[1]: *** [install-target-libstdc++-v3] Error 2 | 15:25 |
| Findeton | what could be the source of that errorr while compiling the first set of tools, binutils etc (for Newlib toolchain) | 15:26 |
| stekern | ...with or1ksim 'next' just works fine, so has to be something that gdb expects that mor1kx doesn't do... | 15:29 |
| stekern | Findeton: 'first set of tools'? | 15:30 |
| stekern | Findeton: you can use this script (curtesy to ams) to build the or1k-elf toolchain: http://pastie.org/9131013 | 15:32 |
| Findeton | yeah I mean, the newlib toolchain | 15:32 |
| Findeton | I first build binutils etc then gcc then newlib and gdb | 15:34 |
| stekern | right | 15:35 |
| stekern | at what stage does that error come? | 15:35 |
| stekern | note to self - or1ksim: http://pastie.org/9131025 | 15:38 |
| stekern | note to self - mor1kx: http://pastie.org/9131034 | 15:41 |
| stekern | *could* of course be openocd or adbg that doesn't return something gdb expects too | 15:41 |
| stekern | _franck_, jeremybennett: what are those Ack that are present in the or1ksim log, but missing in the mor1kx log? | 15:49 |
| stekern | and... what does that T05 mean? | 16:00 |
| _franck_ | jeremybennett will know better than me. When you are using openocd, add "-d 3" to see what gdb is doing | 16:03 |
| stekern | ok, will do... | 16:04 |
| stekern | at least I've deschiffered this to be 'read all regs': Sending packet: $g#67 | 16:04 |
| _franck_ | ah a 'g' packet I know that ;) | 16:06 |
| _franck_ | https://sourceware.org/gdb/onlinedocs/gdb/Packets.html | 16:06 |
| stekern | yeah, I found that (and jeremy's appnote), but haven't found what the responses are (yet) | 16:08 |
| _franck_ | https://sourceware.org/gdb/onlinedocs/gdb/Stop-Reply-Packets.html#Stop-Reply-Packets | 16:09 |
| _franck_ | T05 target stopped, because of a trap signal | 16:10 |
| stekern | ah, T05 and S05 are equivalent | 16:12 |
| stekern | ok, so that's all good | 16:12 |
| stekern | I guess it's the gpr's that makes gdb unhappy | 16:12 |
| jeremybennett | stekern: Sounds like you've found out. T is a generalization of the S stop packet for use with threads | 16:13 |
| stekern | jeremybennett: yes, thanks | 16:20 |
| stekern | but what's the #73 for in s#73? | 16:21 |
| stekern | and #67 in g#67? | 16:21 |
| _franck_ | $packet-data#checksum | 16:23 |
| stekern | ah, ok | 16:23 |
| stekern | thanks | 16:23 |
| stekern | let's hack in some spr access to the gprs then... | 16:26 |
| Findeton | stekern: it's the first stage | 17:05 |
| Findeton | first make line on from http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 | 17:06 |
| stekern | Findeton: why are you building libstdc++ in that stage? | 17:07 |
| Findeton | uhm that is a good question | 17:07 |
| Findeton | something is off | 17:10 |
| stekern | ok, next seems to work now when gdb can read the gprs | 17:13 |
| stekern | n | 17:14 |
| stekern | oops | 17:14 |
| stekern | ...at least almost work | 17:36 |
| Findeton | btw who is the one that has been working lately to do a multicore openrisc? | 17:57 |
| Findeton | I saw someone on the list but i don't know his nick | 17:57 |
| stekern | Findeton: wallento | 18:10 |
| Findeton | oh | 18:10 |
| Findeton | and does it work? | 18:10 |
| Findeton | can we already use a multicore openrisc? :p | 18:10 |
| stekern | haha! scratch that 'almost', 'next' works *perfectly* with mor1kx now! I had accidently built a de0_nano image for or1200 instead of mor1kx... duh... | 18:12 |
| blueCmd | Findeton: what do you mean use? | 18:12 |
| Findeton | I mean install it in a fpga and I don't know, run linux on it | 18:13 |
| stekern | yes - no | 18:13 |
| stekern | or, sure you can run linux on it, on one of it's cores | 18:13 |
| stekern | the openrisc linux port doesn't have SMP support (yet) | 18:14 |
| stekern | and cache coherency is missing | 18:17 |
| stekern | at least in the published version | 18:19 |
| Findeton | stekern | 18:53 |
| stekern | that's me | 18:54 |
| Findeton | so there are some missing things but the hardware works | 18:54 |
| Findeton | the missing part is on the software side | 18:54 |
| stekern | cache coherency is a hw thing | 18:54 |
| Findeton | ah | 18:54 |
| Findeton | I was hoping it wasn't lol | 18:54 |
| Findeton | man this takes a lot to compile | 18:55 |
| stekern | basically, you need to keep each core's local cache coherent with what the other cores write to main mem | 18:55 |
| stekern | (or their local caches, depending on your cache write strategy) | 18:56 |
| blueCmd | snoop! | 18:56 |
| stekern | you said it dog! | 18:56 |
| blueCmd | and that concludes what i know of SMP | 18:56 |
| blueCmd | also, I fixed destructor in glibc | 18:56 |
| blueCmd | \o/ | 18:56 |
| stekern | where did you find the nail to put in that coffin? | 18:57 |
| blueCmd | I'm recompiling my full testsuite to make sure I don't have any regressions and still need to verify I didn't break it with static, but the gist is: | 18:58 |
| blueCmd | dl-start.S is responsible of calling _start in the dynamically linked program and pass the fini function to it somehow | 18:58 |
| blueCmd | it does that by setting r9 (copied from uClibc) | 18:58 |
| stekern | mmm, right | 18:59 |
| stekern | or... wait, r9? | 18:59 |
| blueCmd | I don't know what uClibc does, but glibc requires it to be registered via atexit since __libc_start_main goes like: { call_main(); exit(); } so it will never return | 18:59 |
| blueCmd | yes | 18:59 |
| blueCmd | it does a jr and not a jalr | 18:59 |
| blueCmd | so anyway, _start gets called with the fini address in r9, but didn't pass it along to the registerer that handles atexit registration for fini-functions | 19:00 |
| stekern | ok | 19:01 |
| blueCmd | so. well, now it does | 19:02 |
| blueCmd | and it appears to work | 19:02 |
| stekern | in uClibc, all that is handled in the generic __uClibc_main | 19:03 |
| blueCmd | stekern: but is it web-scale? | 19:03 |
| blueCmd | or agile? or modular? | 19:03 |
| stekern | (and _fini is not passed to _start in r9) | 19:03 |
| blueCmd | clearly you need abstractions for your factory abstractions | 19:03 |
| blueCmd | which glibc has | 19:03 |
| stekern | you've must copy-pasted that from somewhere else ;) | 19:03 |
| blueCmd | haha | 19:04 |
| blueCmd | I don't think so | 19:04 |
| stekern | and stop speaking like a phb ;) | 19:04 |
| blueCmd | the comment said "uClibc does this, let's mimic it" | 19:04 |
| stekern | ah, well... look for yourself: https://github.com/openrisc/uClibc-or1k/blob/master/libc/sysdeps/linux/or1k/crt1.S#L69 | 19:05 |
| blueCmd | https://github.com/skristiansson/uClibc-or1k/commit/a3282fcae696990a8a897001276c28390b3e9477 | 19:05 |
| blueCmd | that is the problem in glibc | 19:05 |
| stekern | ah, ok I see | 19:05 |
| stekern | that's an 8 though, you know ;) | 19:06 |
| stekern | and it's not passed *to* _start, but *from* | 19:07 |
| blueCmd | stekern: well, the change is to change that to l.ori r8, r9, 0 | 19:08 |
| blueCmd | the fix is to change* | 19:08 |
| blueCmd | stekern: https://github.com/openrisc/uClibc-or1k/blob/master/ldso/ldso/or1k/dl-startup.h#L68 | 19:09 |
| stekern | ah, why didn't you say so ;) | 19:09 |
| blueCmd | you're totally not passing it in r9 | 19:09 |
| stekern | ok, you're right, but I'm not using it for anything ;) | 19:11 |
| blueCmd | :D | 19:11 |
| blueCmd | which is kind of weird | 19:11 |
| blueCmd | but if it works | 19:11 |
| stekern | what's _dl_fini suppose to do? | 19:11 |
| blueCmd | call all _fini of shared objects loaded | 19:12 |
| blueCmd | like the _fini of the program I guess | 19:12 |
| blueCmd | it's _super_ hard to follow stuff like that in glibc since it is renamed all the time | 19:13 |
| blueCmd | with aliases | 19:14 |
| blueCmd | or voodoo | 19:14 |
| stekern | heh | 19:16 |
| blueCmd | fingers crossed that this works and libkrb5 will build with this | 19:28 |
| blueCmd | hopefully that will unlock a sizeable chunk of those 4500 packages that are locked at the moment pending dependnecies | 19:28 |
| stekern | ok... time to find out why icarus doesn't like multiway caches... | 19:35 |
| stekern | https://github.com/openrisc/mor1kx/commit/9e5a414e35cee893d46d4a7442f2b80e32619b82#diff-07e05d8a4db9264f06ddd82de6d136c5R233 | 19:45 |
| stekern | ^ icarus killer | 19:45 |
| blueCmd | We clearly need more Stefans | 20:00 |
| stekern | that and people with JB as initials | 20:11 |
| mor1kx | [mor1kx] skristiansson pushed 3 new commits to master: https://github.com/openrisc/mor1kx/compare/933f942e2e70...cbdd7abf528b | 20:24 |
| mor1kx | mor1kx/master 14f2aa1 Stefan Kristiansson: cache: use per-block unique for-loop index variables... | 20:24 |
| mor1kx | mor1kx/master 6e6d8ce Stefan Kristiansson: cappuccino/ctrl: set npc to pc_ctrl_i on trap stall... | 20:24 |
| mor1kx | mor1kx/master cbdd7ab Stefan Kristiansson: cappuccino: add support to read gpr via spr... | 20:24 |
| stekern | there we go | 20:26 |
| stekern | icarus is once again at a safe distance from the sun | 20:27 |
| juliusb | I don't get it, what about that didn't icarus like? | 20:28 |
| stekern | an integer (w) that is used in more than one block | 20:29 |
| stekern | https://github.com/openrisc/mor1kx/commit/14f2aa18ec07c08f7efc5ef9ce98d180547c0669 | 20:30 |
| stekern | there's probably more to it, since it *could* handle w1 and w2 having the same name, but I choose to rename those too for consistency | 20:31 |
| juliusb | hmm, yeah odd. was it plain crashing during compile or doing strange things at run time? | 20:32 |
| stekern | it does nothing, just sits in an endless loop not simulating anything | 20:34 |
| juliusb | oh I love those ones | 20:34 |
| stekern | I guess it might be because it's in the sensitivity list of two always(*) | 20:34 |
| stekern | and being set in both | 20:34 |
| stekern | and icarus somehow can't figure out that it shouldn't use for-loop index variables like that | 20:35 |
| juliusb | good spot | 20:37 |
| stekern | ah, well, I just bruteforced the changes in the commit that I bruteforced the regression to with git bisect ;) | 20:38 |
| stekern | but cappuccinos single stepping is solid now | 20:39 |
| stekern | and you can even read gprs from gdb ;) | 20:39 |
| stekern | write, not so much, yet... | 20:40 |
| juliusb | solid stepping is a good thing | 20:40 |
| juliusb | haha | 20:40 |
| juliusb | write's bust? | 20:40 |
| stekern | it's not implemented, that's all | 20:41 |
| stekern | and I'm not so sure the way I added read support will stick | 20:41 |
| stekern | I added a third read port to RF, which means a third RAM... (or 32x32 flops) | 20:42 |
| stekern | it's conditional on the debug_unit at least ;) | 20:42 |
| juliusb | ah right | 20:42 |
| juliusb | why third RAM? | 20:42 |
| stekern | because, each read port will be instantiated as a seperate RAM | 20:43 |
| stekern | but, doing it like that was the easiest, and will interfere the least with pipeline logic | 20:44 |
| juliusb | 3 read ports? | 20:44 |
| juliusb | 2 for execute, 1 for earlier in pipeline? | 20:44 |
| stekern | yes, port a, port b and port spr | 20:44 |
| juliusb | oh... you are mapping SPRs to BRAM now? | 20:44 |
| stekern | no, just to read the gprs | 20:45 |
| juliusb | oh right yep I see | 20:45 |
| stekern | https://github.com/openrisc/mor1kx/commit/cbdd7abf528bed632c6bb9eec56f49d4cd5932a7 | 20:45 |
| juliusb | that always was a pain getting the GPR to be read for the SPR accesses | 20:45 |
| stekern | you could just use one of the ports (b for instance) but then you have to mux the address | 20:45 |
| stekern | even if you just do it while stalled, it's scary | 20:46 |
| juliusb | the other implementations (and I guess cappuccino previously) | 20:46 |
| juliusb | ... used to do it like that right? | 20:46 |
| stekern | no, gpr read via spr have never been supported | 20:46 |
| juliusb | ha ok yes, that rings a bell :) | 20:47 |
| juliusb | sorry, I was mistakenly thinking something else to do with mt/fsprs needed data from the GPRs to do their thing | 20:48 |
| juliusb | been out of the game too long :-/ | 20:48 |
| stekern | the _idea_ was probably that it would work like that when it got implemented, since the spr data output was mapped to the data out port from port b of the rf | 20:48 |
| stekern | ah, well, you quickly forget... didn't you see how blueCmd lectured me about stuff *I've* done in uClibc a couple of lines up? =) | 20:49 |
| juliusb | haha, clearly happens to the best of us ;) | 20:51 |
| juliusb | i'm looking forward to playing with some OR stuff over the next month while I prepare for chiphack | 20:52 |
| juliusb | there's some impressive stuff gone on, I've noticed while lurking on the lists | 20:53 |
| juliusb | i like all this upstreaming action | 20:54 |
| stekern | yes, it would be nice if we could get gcc sorted out too | 20:57 |
| blueCmd | stekern: :) | 20:57 |
| juliusb | I've half a mind to get a multicore demo going for chiphack actually | 20:59 |
| juliusb | will evaluate the state of the stuff this weekend | 20:59 |
| stekern | I think it should be relatively easy to get wallento's demo running in hw | 21:02 |
| stekern | the only caveat is that it's not using the uart to output stuff, but l.nop 4 | 21:04 |
| blueCmd | I'm going to debconf as it looks now, and I might give a presentation there | 21:12 |
| stekern | cool | 21:12 |
| blueCmd | if we get multicore up and running in linux until then.. that would be soo awesome | 21:12 |
| blueCmd | I might be eating this up later: sounds be possible, how hard can it be? :) | 21:13 |
| stekern | august 23, plenty of time | 21:13 |
| olofk | blueCmd: XCVR cores? | 21:46 |
| stekern | oh... poor olofk, you've got *some* backlogs to read if you're there now ;) | 21:47 |
| olofk | stekern: I just flipped over to thursday, and I'm barely awake now | 21:55 |
| olofk | What have I told you about not talking when I'm away? :) | 21:55 |
| stekern | sorry... | 21:56 |
| blueCmd | olofk: tranceivers and other things | 22:00 |
| blueCmd | stekern: hah, that's what I thought as well when I read it :) | 22:01 |
| olofk | blueCmd: I don't have a problem with non-free cores other than that they can be a pain to use and maintain | 22:10 |
| olofk | But I suspect you're talking about things like coregen or megawizard | 22:10 |
| blueCmd | yes, but good | 22:10 |
| blueCmd | yep | 22:10 |
| blueCmd | "yes, but good" => "yes, but that aligns what I want to do" | 22:10 |
| blueCmd | with what I want to do* | 22:10 |
| olofk | coregen is no big problem. I know what to do there | 22:10 |
| blueCmd | "words - how do they work?" | 22:11 |
| olofk | But I haven't figured out how to generate a core from a config file with megawizard | 22:11 |
| stekern | dunno, I never figured that out | 22:11 |
| olofk | Got to sleep now unfortunately. The back log nearly killed me | 22:11 |
| stekern | the words, I mean, megawizard shouldn't be hard | 22:12 |
| blueCmd | *puh* I first thought one of my build bots had been hacked | 22:33 |
| blueCmd | it turned out that it was building 'aircrack-ng' and running the test suite | 22:34 |
| blueCmd | the multiple 'aircrack-ng' processes that was running against a password.lst on a wpa file looked _Very_ suspicious | 22:34 |
| stekern | haha | 22:38 |
| blueCmd | krb5 unlocked 100 packages | 22:40 |
| blueCmd | postgresql-9.3 was one of them, and that will unlock a lot of packages (like apache) | 22:40 |
| stekern | apache, nice | 22:41 |
| blueCmd | you already have nginx if you want to play with a webserver | 22:41 |
| stekern | how about lighttpd? | 22:41 |
| blueCmd | lighttpd build-depends on missing: | 22:41 |
| blueCmd | - or1k:libmysqlclient-dev | 22:41 |
| stekern | ah, ok | 22:42 |
| blueCmd | how's that for light? | 22:42 |
| stekern | heh | 22:42 |
| stekern | I guess you *could* build it without that ;) | 22:42 |
| blueCmd | that's not the debian way! | 22:42 |
| blueCmd | build with EVERYTHING | 22:42 |
| stekern | like you *can* build scummvm without qt | 22:43 |
| stekern | and without jackd2 | 22:43 |
| blueCmd | oh, I can probably fix mysql | 22:43 |
| blueCmd | it build-depends on libaio | 22:43 |
| blueCmd | and it appears to only need a hint of which endian-ness (like sooo many other packages) | 22:43 |
| --- Log closed Fri May 02 00:00:30 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!