IRC logs for #openrisc Wednesday, 2014-05-28

--- Log opened Wed May 28 00:00:08 2014
olofkblueCmd: I'm starting to notice the lack of test suites04:13
olofkI'm not following you on the gui stuff. If you want a GUI editor you could use GTK or QT or something I guess04:14
stekernI'm taking a wild guess here, and he mixed up gui stuff with top level generation05:27
stekernto which you spoke about cactus05:27
stekernor whatever that's called05:28
stekernI still have prejudices about IP-XACT...05:31
stekernfor a number of reasons:05:31
stekern1) xml05:31
stekern2) it has the name IP in it's name, that can't be good05:32
stekern3) the biggest argument I've heard for it is that "it's used in the industry"05:33
stekernso is a lot of crap, that's not a reason to adopt it...05:34
stekernbut, as I said, *prejudices*05:34
stekernthat said, there are of course different levels of adopting. being able to import IP-XACT xmls - good, use that as the only option - probably bad.05:39
stekernhmm, seems like there's only VHDL support in kactus205:54
stekernheh, and it removed all my .v files too when I removed the HW component I had created05:55
stekernBAM! In your face Mr Heisenbug!06:26
stekernIOW, letting l.swa stall the pipeline while the storebuffer drains and *then* check the reservation flag for possible snooped accesses fixes the crashes I've been seing06:28
stekerndual-core have been running stable for 5 mins now on the de0_nano, let's ship this thing ;)06:29
stekern_franck__: I might have asked this before, but is it possible to assert the reset, do something, de-assert the reset in openocd?06:51
wallentostekern: IP is a rather less offensive in academia. I think it may have this background: black boxes with interfaces that you can simply plug together07:01
stekernyeah, I know that the name IP has became a synonym to 'module' or 'core' in the HW world.07:04
stekernit's still wrong ;)07:05
stekern...partly because it insunuates that the black box is black because you need to protect it's contents from viewers, not as an abstraction layer07:10
stekernwallento: but let's go back to more interesting things, I've got this snoop related patch going on07:16
wallentookay, regarding the store buffer?07:17
wallentoi still have this cache patch lying around07:17
wallentoi will hopefully be able to be sure about it today07:17
stekernthe gist of it is that you can't just check for snoop accesses breaking the atomic_reserve at the beginning of the store buffer07:18
wallentothe store buffer is a pretty nasty thing regarding snooping07:19
stekernyou have to wait for the l.swa to propagate through it and *then* check that the atomic_reserve haven't been broken07:19
wallentothat is the same as waiting that the store buffer is empty?07:19
stekernbasically, yes07:20
stekernbut you of course have to give the l.swa a bit of special care when it comes out of the store-buffer07:21
wallentocan't you "just" wait for the store buffer to drain and then bypass it for swa?07:21
olofkstekern: Yes, I agree. IP-Xact is an overengineered design-by-committee standard07:22
kyrre_good morning07:22
stekernyou could, but I think that would create even more edge-cases07:22
olofkBut at least it's a wheel, so I don't need to invent a new one07:22
olofkstekern, blueCmd: My idea of a first step for IP-Xact integration is to put IP-Xact description of the interfaces for the cores. John Eaton has already done a lot of them in his SoCgen project07:24
stekern...and I don't see a huge advantage of doing that07:25
olofkSome, like wb_intercon, will need to be autogenerated on the fly. I have a WIP patch for wb_intercon_gen that spits out an XML file07:25
olofkKactus isn't all that nice to work with, but at least it's open source, and that single top-level VHDL file it generates could be translated to verilog by Icarus07:26
olofkBut in the long run, I would probably prefer a det07:26
olofkdedicated top-level editor07:26
wallentospeaking of the store buffer, at the moment I cannot deactivate it, right?07:29
stekernbut I was thinking about that yesterday, for the cache-coherency snooping, I don't see the problem with it07:31
stekern...maybe I need to walk the dog to see it, but perhaps you can help me by explaining ;907:34
wallentono, its more a general thing, the only feature you can't switch off :)07:34
wallentoand for playing around with the coherency I intended to deactivate it divide and conquer style07:35
stekernah, yes. that's a bit of a nuisance, I agree07:36
_franck__stekern: I think you could:07:51
_franck__or1200.cpu arp_reset assert 007:51
_franck__do what you want here07:52
_franck__or1200.cpu arp_reset deassert 007:52
stekernnice, that works07:56
stekernjust loading the ram and then toggle the reset works most of the time, but it's a bit hazardous letting the cpus running around in the code that is being written07:57
stekernwhat does the last '0' stand for?07:58
_franck__it's halt/not halt but not sure if it works07:59
stekerngeneral question - what and where would need to change to be able to debug several cores?08:04
_franck__well, at first you could chain the two debug taps and see if openocd detects them correctly08:06
_franck__if debug means debug with gdb, I don't know08:07
_franck__we would need to have two altera_virtual_jtag in the system08:09
_franck__vever tried this08:10
_franck__no no no no08:11
_franck__adv_debug_can access several CPU08:11
_franck__at least 208:13
_franck__so only one tap and some trickery to add in openocd to switch targeted CPU08:14
stekernyes, that's what I thought, that accessing more than one cpu should be handled in adv_debug08:19
stekernpersonally, just loading the program into RAM and being able to control the CPUs reset lines is about what I need.08:22
stekernbut I guess others will eventually have more sophisticated needs08:23
_franck__two diffrent targets with -coreid x -dbgbase yyyyy08:23
stekernbeing able to poke at sprs would be nic too08:23
stekernah, ok... can those two be active at the same time?08:24
_franck__i think so. Need to add something like this in or1k.c:
_franck__and the select between CPU0 and CPU1 in adv_dbg08:26
stekernok, doesn't sound like terribly much work08:27
_franck__plus you can connect openocd to verilator ;)08:28
blueCmdstekern: yes! kaktus things was what i meant08:54
blueCmdstekern: gj on heisenbug :)08:55
stekernthanks blueCmd09:56
stekernas a token of appreciation, I'll give you my hideous hack to keep the tick timers in sync...10:07
stekerncomplete with debug prints and stuff that actually belong there...10:07
stekernto make clear the device at 0x99000000 is this
stekernI'll gladly admit that even after digging through the kernel sources, I don't have a completely clear picture how the different clock devices are knit together10:11
stekern...and to explain a bit, I *did* try use that global timer as the clocksource device, but it still caused unhappiness if the clockevent devices wasn't in sync...10:24
stekernI don't get why that would matter10:24
stekernthey should just act as interrupt sources that can be programmed with an interval...10:25
stekernthat should work fine, regardless of if their timer values are the same or not (they are both running at the same tick speed as each other and the clocksource device)10:26
wallentoany particular reason to go to READ and not to idle?13:05
kyrre_Does anyone know if there is a newer version of FreeRTOS for openrisc? newer than the one from SVN at ?13:40
stekernwallento: yes, because going to IDLE would mean one wasted cycle on WRITE->READ transitions13:45
stekernthe whole IDLE state is a bit unneeded13:45
stekernboth fetch and lsu together with the caches are a bit messy, and have a lot of duplicated logic.13:47
stekernto give you an idea how I'd want them to look like:13:48
stekernthose are of course missing loads of functionality that mor1kx cappuccino has, but I think that kind of division of fill logic etc makes sense13:49
stekernbut it's hard to motivate tearing apart the mor1kx logic, since it pretty much work...13:50
stekern+myself to13:50
olofkstekern: If you decide to tear it apart, I would recommend adding a good unit test for those parts first15:36
olofkGiven that you end up with the same interface, you can use that to sanity check the new implementation15:37
olofkHmm.. I removed the head commit from my local fusesoc tree, and now I can't pull it from github anymore. It just times out15:43
olofkIt's a bit similar to when my orpsoc-cores stopped working at the same time as other people started to push patches to it15:44
olofkIt's like it refuses to work if my local copy is behind the upstream one15:44
olofkIs there anything in git that could explain that? For orpsoc-cores it started working when I changed my origin to use https instead of ssh(?)15:45
blueCmd' It just times out' sounds unrelated16:46
stekernolofk: yes, that will motivate me! ;)16:54
stekernnot that I disagree, rather the opposite...16:54
blueCmdolofk: do you have any grand ideas how you want to do unit tests, or should I just start mocking your classes? (hah)16:59
blueCmdstekern: if you have, could I have pie?17:54
stekernwhich flavour17:56
blueCmdthe non-crashing one17:56
blueCmdand in an ELF form17:57
stekernah, elf pie17:57
stekernblueCmd: ^18:08
blueCmdstekern: what versions of gcc/binutils did you use to build that?18:19
stekernthey might be slightly older...18:20
blueCmd-rwxr-xr-x  1 bluecmd bluecmd 14992 May 26 00:07 pie18:20
blueCmd-rwxr-xr-x  1 bluecmd bluecmd 12667 May 28 20:00 sfk-pie18:20
stekernthe ones that were in my debian schroot18:20
blueCmdsfk = you. I was going to write sjk but sfk was what my hand wrote18:20
blueCmdI guess binutils is the one I'm more intersted in18:21
stekern(since I couldn't chroot into my nfs rootfs back then)18:21
blueCmd dpkg-query -l binutils18:21
stekernii  binutils             or1k                GNU assembler, linker and binary utilities18:22
blueCmdinteresting, the same as me18:22
stekernfantastic, isn't it? that command works over irc too!18:22
blueCmdmd5sum /usr/bin/ld18:23
stekernbcacf1e893bf1d3273fe64b61b97bed4  /usr/bin/ld18:23
blueCmd3d789f5a5b9e42fb02489d2c8c4a1565  /usr/bin/ld18:23
blueCmdyou're using the 'clean' one18:24
stekernjahapp, what's in the dirty ld?18:25
blueCmdfixes for TLS18:25
blueCmdor, a fix18:25
stekern...and pie breakage ;)18:25
blueCmdalso I'm not sure if atomics are in that one18:25
blueCmdnope, doesn't work even with that version18:26
stekerndoes my version work on your system?18:26
stekern...silly sanity check18:26
blueCmdSo my thinking is that it's either binutils, gcc or some library (like in case for mpfr)18:27
blueCmdstekern: sha1sum /usr/bin/gcc-4.818:27
blueCmd(it's very important to change hash algorithm)18:28
stekern50de410e7b15716a399d9cb242d822f9725cb646  /usr/bin/gcc-4.818:28
blueCmd8fe7982c83552642850fee7719905b05955c511d  /usr/bin/gcc-4.818:28
stekernI've got the same as you in my "new" rootfs18:29
blueCmdsha1sum /var/cache/apt/archives/gcc_4%3a4.8.2-4_or1k.deb18:30
stekern/usr/bin/sha1sum: /var/cache/apt/archives/gcc_4%3a4.8.2-4_or1k.deb: No such file or directory18:31
blueCmddpkg-query -l gcc-4.818:31
blueCmdor rather:18:31
blueCmdsha1sum /var/cache/apt/archives/gcc-4.8_4.8.2-18_or1k.deb18:31
stekernii  gcc-4.8                      4.8.2-18            or1k                GNU C compiler18:31
stekernsorry, I don't have any gcc ghere18:32
blueCmdyour gcc is my: /home/bluecmd/debian/gcc-2014-04-23/gcc-4.8_4.8.2-18_or1k.deb18:34
blueCmdand that doesn't work either18:35
stekernso, binutils?18:35
blueCmdI think I have your version on both18:35
blueCmdsha1sum /usr/bin/gcc-4.8 /usr/bin/ld18:35
blueCmd50de410e7b15716a399d9cb242d822f9725cb646  /usr/bin/gcc-4.818:35
blueCmd891e85979fa15724c5850c9792805893c2372836  /usr/bin/ld18:35
stekernyes, looks like it18:36
blueCmdmight be crtn.o et. al18:36
stekernit's the __init vs _init changes18:40
blueCmdyes, that would be my guess18:41
blueCmdgonna disass!18:41
blueCmdah right18:42
blueCmdthe reason it doesn't work for me is that the destructors are actually executing :)18:42
blueCmdin your thing that is just skipped18:43
stekernhaha... that's true18:43
blueCmdlazy stekern binary18:43
stekernso it's "working"18:43
olofkstekern: I'll see if I can cook up some module test benches for mor1kx. I've been meaning to do that for [m]or1[kx20]18:59
olofkblueCmd: No ideas for FuseSoC unit tests. Feel free to come up with ideas here19:00
blueCmdah, the old or10 cpu19:00
olofkStupid regular expressions19:00
stekernrdiez will be happy19:01
olofkor10... was that the cheerful rdiez implementation?19:01
olofkGood times19:01
olofkYep. Changing my fusesoc repo to https solved that too. So fucking weird19:05
olofkHaven't had any problems with it before19:05
olofkblueCmd: I still a bit reluctant to pull 9cbbe6d as it puts more code in, and it's only a refactoring commit19:08
stekerndoes anyone have experience with this?
blueCmdolofk: the refactoring was done to make it easy to implement generation19:41
blueCmdah, ok that one19:41
blueCmdthat's up to you if you still want to use "interfaces" and __init__ files19:43
blueCmd"it's only a refactor commit" - that's what I do, it's my speciality and often what I get praised for. reworking and cleaning up APIs and codebases, generally something few people enjoy doing19:44
blueCmdstekern: I have used sdcc some 5-8 years in the past19:44
stekernI'm doing some $nightjob things with stm8 at the moment and I saw that it had added support for that target in the latest release19:58
stekernit'd be nice not having to run a win8 virtual machine to compile the program20:01
stekernnot sure how you'd program those outside it anyway, and also not sure if I'm interested enough to pursue..20:02
blueCmdI wrote a bootloader for the CPU i used it for20:04
blueCmdthat's how I solved it :P20:04
stekernheh... I'll never going to fit a bootloader to this20:08
stekernnot that it wouldn't be *possible*, the mcu is not that small, but the program already takes too much space to make it feasible at this point20:10
stekern1KB ram20:10
stekern8KB flash20:11
stekernplenty of room20:11
blueCmdI think it was that one I used back then20:15
stekernah, an good old 805120:22
stekernI've only programmed those in asm though20:24
-!- hno` is now known as hno20:29
-!- hno is now known as Guest119520:30
-!- Guest1195 is now known as hno20:30
--- Log closed Thu May 29 00:00:10 2014

Generated by 2.15.2 by Marius Gedminas - find it at!