IRC logs for #openrisc Thursday, 2014-05-01

--- 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
stekernbah, my clipboard didn't take your paste, so I pasted my old pastie in to the browser...05:56
stekernyes, 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 2205:57
stekernyeah, it's odd, when I try to enable mor1kx in Jose's branch the vpi server doesn't get enabled at all06:33
stekernI can't see how that would depend on the MOR1KX `define06:33
_franck_I'm trying to make jtag_vpi to work also06:33
_franck_yes weird, the jtag_vpi.v tasks gets stuck at some point06:34
_franck_(0.00 ns) Task reset_tap06:34
_franck_then nothing06:34
stekernwith mor1kx?06:48
_franck_yes, with icarus06:49
stekernmmm, that sounds like what's happening here too06:49
_franck_but I just figured out I can't start a simu from the unmodified mor1kx-generic :(06:49
stekernhmm, why?06:50
_franck_I loads the program then it get stuck, the vcd is empty06:50
_franck_need to find out06:50
stekernohh.. that could perhaps be related then06:50
stekernI did try running icarus against it at some point at least, so it has worked06:51
_franck_at least I can make it work with verilator06:56
_franck_with icarus, it doesn't say "VCD dump started (0)"06:57
_franck_need to go, bye06:58
stekernok, I'll take a look at that...06:58
stekernI think I'll try to make Jose's branch to work with verilator instead06:59
stekernhmm, something is not working right with export_files in verilator section07:05
stekernah.. it's a bug in build_SysC07:27
stekern_franck_: I get this when I try to use your or1200-generic patch:08:02
stekernError: Couldn't read the CPU state08:02
stekernfrom openocd08:02
stekern_franck_: what was your test program and what did you compile it with?08:22
stekernI can't of course run the one I did for the hw, because libgloss tries to access memory with xxxxx08:23
stekernlet's fix that09:18
_franck_stekern: I took your test program and changed 0x9700000 to 0x9000000010:03
FindetonI'm trying to build the newlib toolchain again10:06
FindetonI'm following
Findetonbut when I try to compile it it says something like10:07
Findetonsysinfo.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 ./tcl10:08
Findetonhere is the whole output
stekern_franck_: (test program) what did you compile it with?10:18
stekernand yes, that's the command line I'm using10:18
stekernand it works with Jose's de0_nano_sim10:18
stekernFindeton: do you have bison/flex installed?10:19
_franck_stekern: or1k-elf-gcc -O0 -g -o test_dbg test_dbg.c10:20
Findetonstekern: shit10:21
FindetonI thought I had it, but I didn't have flex10:21
Findetonbison I do have10:21
Findetonbtw I am creating a script to download build and install all the openrisc tools from zero for a debian/ubuntu environment10:22
Findetonso that I don't have to do everything thrice :p10:22
Findetona lazy programmer is a good programmer10:23
stekerntrue that10:25
blueCmdFindeton: you might want to make it a Makefile10:27
blueCmdsince it has built-in support for skipping already done steps10:27
blueCmdfeel free to borrow / steal stuff from
Findetonthanks for the info blueCmd10:28
blueCmdThat 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-glibc10:29
blueCmdbut it will download stuff like ncurses and zsh10:29
blueCmdor rather, will10:29
Findetoninteresting, I'll look into it10:31
blueCmdFindeton: there is also a project in #debian-bootstrap called 'rebootstrap' that builds everything and outputs a couple of debs10:32
blueCmdit doesn't work for or1k yet because we're not upstreamed fully though10:32
Findetonthat's ironic because my idea is to remove bootstrapping from openrisc haha10:33
blueCmdwhat do you mean?10:33
FindetonI mean, my ideal thing would be to have an assembler developed in assembly code10:34
Findetonopenrisc assembly code I mean10:34
blueCmdAnd build everything from that?10:34
blueCmdLike small-as -> binutils -> gcc ... ?10:35
Findetonand from that, a set of higher and higher compilers all the way to llvm ir, C and finally gcc10:35
Findetonyeah, but you know, without bootstrapping10:35
blueCmdwell that's what bootstrapping is, no?10:35
blueCmdbootstrapping = building stuff in stages from nothing10:35
Findetonwell, only the assembler would be bootstrapped10:36
blueCmdat least to me10:36
blueCmdyou're talking about cross compiled?10:36
Findetonno, bootstrapping is to build the tools from other machine :p10:36
blueCmdno, that's cross compilation10:36
Findetonwhat I mean is that10:36
Findetonfor example gcc is developed in C/C++ (depending on the version)10:37
blueCmdright. makes much more sense then :)10:37
blueCmdyou want a fully natively compiled system10:37
Findetonyeah, from scratch10:37
Findetonfrom the metal, as they say10: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
Findetonor by hand10:38
Findetonan assembler developed with assembly code... its cross compilation can be checked manually10:38
Findetonit 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 :p10:40
blueCmdwell if you do it by hand you're the cross compiler10:42
blueCmdThis sounds like it would have been someones thesis10:46
blueCmdso maybe you can find this small assembler somewhere and figure out exactly how much it needs to be able to do10:47
Findetonyeah but you need way more than just an assembler10:48
Findetonyou need to get to compile C natively10:48
stekern_franck_: (or1k-elf-) how can that work in icarus without a fixed libgloss?10:49
FindetonI think a good way is to create a C compiler developed in llvm ir code, and a llvm ir to assemly code in asssembly code10:49
Findetonand just to bother the founders of llvm, i'll do it free software, not open source :p10:50
blueCmdwell you would need a C library for that as well then10:50
Findetonwhatever it takes! it's just for fun, I have time10:51
FindetonI know it's a lot of work, I'm doing it step by step, I don't really care if I finish it actually10: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 me11:03
stekernjust for fun, could you give me the .elf?11:04
blueCmdstekern: I forgot how to build or1ksim for 32 bit and I'm too lazy to scourge11:04
blueCmddo you know it off-hand?11:05
stekernbecause, the problem is, the board mem start symbol ends up in bss and is referenced before bss is cleared11:05
stekernwhy do you need a 32-bit or1ksim?11:05
blueCmdstekern: because I get a shitload of <invalid>11:06
stekernblueCmd: doesn't this fix it for you?
stekern_franck_: ok, for some reason, _board_mem_base hasn't ended up in .bss11:22
stekernbut it does in mine11:22
_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 icarus11:32
stekernhow do you mean 'comment'11:33
stekernah, I understand11:33
_franck_I mean remove11:33
stekernyes, there is something in mor1kx, that's clear11:33
stekernand it has to be a recent commit, since it *has* worked11:33
stekernlet me find a rev that works and bisect this11:33
_franck_hmu, don't know if fusesoc's github provider supports specific revision when fetching the core11:35
_franck_ah, some cleanup to do, for github provider, the capi doc says "branch" and in cores it is "version"11:37
stekernyes, and version can be about anything that you can 'checkout'11:43
stekernbut I have mor1kx as a local provider, at least when I'm doing dev on it11:44
stekernit's that one11:48
stekernit's probably better to run vcd recording with icarus than verilator when manually doing things with gdb12:04
stekernthe vcd might grow rather big with verilator12:05
stekernI've got a capture of 'next' failure with mor1kx now at least12:07
stekernstupid delay slots...12:21
stekernit's mofo pain keeping track of them when stepping12:21
stekernI think this problem is two-folded12:50
stekern1) the bug I'm fixing now, where a stall at a jump insn would not follow the jump12:51
stekern2) it looks like gdb really is "going into the function" when doing next12:51
_franck_stekern: that could help:13:10
_franck_I have two commits here I never applied:13:11
stekernok, I'll try those, just found another corner case to fix in mor1kx13:13
stekernwhat do you 'set remotetimeout' to?13:24
blueCmdstekern: oh, I haven't merged those13:35
blueCmdthe timestamp confused me13:35
jeremybennettstekern: 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
stekernjeremybennett: that's what I suspected13:51
stekernI 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 before13:57
stekernthis '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 it14: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
stekernlet's try your patches now _franck_14:57
stekernor32-elf-gdb works differently btw:
stekernis 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 issue15:06
stekernit'll only make a difference if setting a bp in a delay slot, right?15:07
stekernhmm, wonder how all this works together with or1ksim15:12
Findetonmake[2]: *** No rule to make target `install'.  Stop.15:25
Findetonmake[1]: *** [install-target-libstdc++-v3] Error 215:25
Findetonwhat 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
stekernFindeton: 'first set of tools'?15:30
stekernFindeton: you can use this script (curtesy to ams) to build the or1k-elf toolchain:
Findetonyeah I mean, the newlib toolchain15:32
FindetonI first build binutils etc then gcc then newlib and gdb15:34
stekernat what stage does that error come?15:35
stekernnote to self - or1ksim:
stekernnote to self - mor1kx:
stekern*could* of course be openocd or adbg that doesn't return something gdb expects too15:41
stekern_franck_, jeremybennett: what are those Ack that are present in the or1ksim log, but missing in the mor1kx log?15:49
stekernand... 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 doing16:03
stekernok, will do...16:04
stekernat least I've deschiffered this to be 'read all regs': Sending packet: $g#6716:04
_franck_ah a 'g' packet I know that ;)16:06
stekernyeah, I found that (and jeremy's appnote), but haven't found what the responses are (yet)16:08
_franck_T05 target stopped, because of a trap signal16:10
stekernah, T05 and S05 are equivalent16:12
stekernok, so that's all good16:12
stekernI guess it's the gpr's that makes gdb unhappy16:12
jeremybennettstekern: Sounds like you've found out. T is a generalization of the S stop packet for use with threads16:13
stekernjeremybennett: yes, thanks16:20
stekernbut what's the #73 for in s#73?16:21
stekernand #67 in g#67?16:21
_franck_ $packet-data#checksum16:23
stekernah, ok16:23
stekernlet's hack in some spr access to the gprs then...16:26
Findetonstekern: it's the first stage17:05
Findetonfirst make line on from
stekernFindeton: why are you building libstdc++ in that stage?17:07
Findetonuhm that is a good question17:07
Findetonsomething is off17:10
stekernok, next seems to work now when gdb can read the gprs17:13
stekernoops17:14 least almost work17:36
Findetonbtw who is the one that has been working lately to do a multicore openrisc?17:57
FindetonI saw someone on the list but i don't know his nick17:57
stekernFindeton: wallento18:10
Findetonand does it work?18:10
Findetoncan we already use a multicore openrisc? :p18:10
stekernhaha! 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
blueCmdFindeton: what do you mean use?18:12
FindetonI mean install it in a fpga and  I don't know, run linux on it18:13
stekernyes - no18:13
stekernor, sure you can run linux on it, on one of it's cores18:13
stekernthe openrisc linux port doesn't have SMP support (yet)18:14
stekernand cache coherency is missing18:17
stekernat least in the published version18:19
stekernthat's me18:54
Findetonso there are some missing things but the hardware works18:54
Findetonthe missing part is on the software side18:54
stekerncache coherency is a hw thing18:54
FindetonI was hoping it wasn't lol18:54
Findetonman this takes a lot to compile18:55
stekernbasically, you need to keep each core's local cache coherent with what the other cores write to main mem18:55
stekern(or their local caches, depending on your cache write strategy)18:56
stekernyou said it dog!18:56
blueCmdand that concludes what i know of SMP18:56
blueCmdalso, I fixed destructor in glibc18:56
stekernwhere did you find the nail to put in that coffin?18:57
blueCmdI'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
blueCmddl-start.S is responsible of calling _start in the dynamically linked program and pass the fini function to it somehow18:58
blueCmdit does that by setting r9 (copied from uClibc)18:58
stekernmmm, right18:59
stekernor... wait, r9?18:59
blueCmdI 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 return18:59
blueCmdit does a jr and not a jalr18:59
blueCmdso 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-functions19:00
blueCmdso. well, now it does19:02
blueCmdand it appears to work19:02
stekernin uClibc, all that is handled in the generic __uClibc_main19:03
blueCmdstekern: but is it web-scale?19:03
blueCmdor agile? or modular?19:03
stekern(and _fini is not passed to _start in r9)19:03
blueCmdclearly you need abstractions for your factory abstractions19:03
blueCmdwhich glibc has19:03
stekernyou've must copy-pasted that from somewhere else ;)19:03
blueCmdI don't think so19:04
stekernand stop speaking like a phb ;)19:04
blueCmdthe comment said "uClibc does this, let's mimic it"19:04
stekernah, well... look for yourself:
blueCmdthat is the problem in glibc19:05
stekernah, ok I see19:05
stekernthat's an 8 though, you know ;)19:06
stekernand it's not passed *to* _start, but *from*19:07
blueCmdstekern: well, the change is to change that to l.ori r8, r9, 019:08
blueCmdthe fix is to change*19:08
stekernah, why didn't you say so ;)19:09
blueCmdyou're totally not passing it in r919:09
stekernok, you're right, but I'm not using it for anything ;)19:11
blueCmdwhich is kind of weird19:11
blueCmdbut if it works19:11
stekernwhat's _dl_fini suppose to do?19:11
blueCmdcall all _fini of shared objects loaded19:12
blueCmdlike the _fini of the program I guess19:12
blueCmdit's _super_ hard to follow stuff like that in glibc since it is renamed all the time19:13
blueCmdwith aliases19:14
blueCmdor voodoo19:14
blueCmdfingers crossed that this works and libkrb5 will build with this19:28
blueCmdhopefully that will unlock a sizeable chunk of those 4500 packages that are locked at the moment pending dependnecies19:28
stekernok... time to find out why icarus doesn't like multiway caches...19:35
stekern^ icarus killer19:45
blueCmdWe clearly need more Stefans20:00
stekernthat and people with JB as initials20:11
mor1kx[mor1kx] skristiansson pushed 3 new commits to master:
mor1kxmor1kx/master 14f2aa1 Stefan Kristiansson: cache: use per-block unique for-loop index variables...20:24
mor1kxmor1kx/master 6e6d8ce Stefan Kristiansson: cappuccino/ctrl: set npc to pc_ctrl_i on trap stall...20:24
mor1kxmor1kx/master cbdd7ab Stefan Kristiansson: cappuccino: add support to read gpr via spr...20:24
stekernthere we go20:26
stekernicarus is once again at a safe distance from the sun20:27
juliusbI don't get it, what about that didn't icarus like?20:28
stekernan integer (w) that is used in more than one block20:29
stekernthere's probably more to it, since it *could* handle w1 and w2 having the same name, but I choose to rename those too for consistency20:31
juliusbhmm, yeah odd. was it plain crashing during compile or doing strange things at run time?20:32
stekernit does nothing, just sits in an endless loop not simulating anything20:34
juliusboh I love those ones20:34
stekernI guess it might be because it's in the sensitivity list of two always(*)20:34
stekernand being set in both20:34
stekernand icarus somehow can't figure out that it shouldn't use for-loop index variables like that20:35
juliusbgood spot20:37
stekernah, well, I just bruteforced the changes in the commit that I bruteforced the regression to with git bisect ;)20:38
stekernbut cappuccinos single stepping is solid now20:39
stekernand you can even read gprs from gdb ;)20:39
stekernwrite, not so much, yet...20:40
juliusbsolid stepping is a good thing20:40
juliusbwrite's bust?20:40
stekernit's not implemented, that's all20:41
stekernand I'm not so sure the way I added read support will stick20:41
stekernI added a third read port to RF, which means a third RAM... (or 32x32 flops)20:42
stekernit's conditional on the debug_unit at least ;)20:42
juliusbah right20:42
juliusbwhy third RAM?20:42
stekernbecause, each read port will be instantiated as a seperate RAM20:43
stekernbut, doing it like that was the easiest, and will interfere the least with pipeline logic20:44
juliusb3 read ports?20:44
juliusb2 for execute, 1 for earlier in pipeline?20:44
stekernyes, port a, port b and port spr20:44
juliusboh... you are mapping SPRs to BRAM now?20:44
stekernno, just to read the gprs20:45
juliusboh right yep I see20:45
juliusbthat always was a pain getting the GPR to be read for the SPR accesses20:45
stekernyou could just use one of the ports (b for instance) but then you have to mux the address20:45
stekerneven if you just do it while stalled, it's scary20:46
juliusbthe other implementations (and I guess cappuccino previously)20:46
juliusb... used to do it like that right?20:46
stekernno, gpr read via spr have never been supported20:46
juliusbha ok yes, that rings a bell :)20:47
juliusbsorry, I was mistakenly thinking something else to do with mt/fsprs needed data from the GPRs to do their thing20:48
juliusbbeen out of the game too long :-/20:48
stekernthe _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 rf20:48
stekernah, 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
juliusbhaha, clearly happens to the best of us ;)20:51
juliusbi'm looking forward to playing with some OR stuff over the next month while I prepare for chiphack20:52
juliusbthere's some impressive stuff gone on, I've noticed while lurking on the lists20:53
juliusbi like all this upstreaming action20:54
stekernyes, it would be nice if we could get gcc sorted out too20:57
blueCmdstekern: :)20:57
juliusbI've half a mind to get a multicore demo going for chiphack actually20:59
juliusbwill evaluate the state of the stuff this weekend20:59
stekernI think it should be relatively easy to get wallento's demo running in hw21:02
stekernthe only caveat is that it's not using the uart to output stuff, but l.nop 421:04
blueCmdI'm going to debconf as it looks now, and I might give a presentation there21:12
blueCmdif we get multicore up and running in linux until then.. that would be soo awesome21:12
blueCmdI might be eating this up later: sounds be possible, how hard can it be? :)21:13
stekernaugust 23, plenty of time21:13
olofkblueCmd: XCVR cores?21:46
stekernoh... poor olofk, you've got *some* backlogs to read if you're there now ;)21:47
olofkstekern: I just flipped over to thursday, and I'm barely awake now21:55
olofkWhat have I told you about not talking when I'm away? :)21:55
blueCmdolofk: tranceivers and other things22:00
blueCmdstekern: hah, that's what I thought as well when I read it :)22:01
olofkblueCmd: I don't have a problem with non-free cores other than that they can be a pain to use and maintain22:10
olofkBut I suspect you're talking about things like coregen or megawizard22:10
blueCmdyes, but good22:10
blueCmd"yes, but good" => "yes, but that aligns what I want to do"22:10
blueCmdwith what I want to do*22:10
olofkcoregen is no big problem. I know what to do there22:10
blueCmd"words - how do they work?"22:11
olofkBut I haven't figured out how to generate a core from a config file with megawizard22:11
stekerndunno, I never figured that out22:11
olofkGot to sleep now unfortunately. The back log nearly killed me22:11
stekernthe words, I mean, megawizard shouldn't be hard22:12
blueCmd*puh* I first thought one of my build bots had been hacked22:33
blueCmdit turned out that it was building 'aircrack-ng' and running the test suite22:34
blueCmdthe multiple 'aircrack-ng' processes that was running against a password.lst on a wpa file looked _Very_ suspicious22:34
blueCmdkrb5 unlocked 100 packages22:40
blueCmdpostgresql-9.3 was one of them, and that will unlock a lot of packages (like apache)22:40
stekernapache, nice22:41
blueCmdyou already have nginx if you want to play with a webserver22:41
stekernhow about lighttpd?22:41
blueCmdlighttpd build-depends on missing:22:41
blueCmd- or1k:libmysqlclient-dev22:41
stekernah, ok22:42
blueCmdhow's that for light?22:42
stekernI guess you *could* build it without that ;)22:42
blueCmdthat's not the debian way!22:42
blueCmdbuild with EVERYTHING22:42
stekernlike you *can* build scummvm without qt22:43
stekernand without jackd222:43
blueCmdoh, I can probably fix mysql22:43
blueCmdit build-depends on libaio22:43
blueCmdand 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 2.15.2 by Marius Gedminas - find it at!