| --- Log opened Wed May 28 00:00:08 2014 | ||
| olofk | blueCmd: I'm starting to notice the lack of test suites | 04:13 |
|---|---|---|
| olofk | I'm not following you on the gui stuff. If you want a GUI editor you could use GTK or QT or something I guess | 04:14 |
| stekern | I'm taking a wild guess here, and he mixed up gui stuff with top level generation | 05:27 |
| stekern | to which you spoke about cactus | 05:27 |
| stekern | kactus | 05:28 |
| stekern | or whatever that's called | 05:28 |
| stekern | I still have prejudices about IP-XACT... | 05:31 |
| stekern | for a number of reasons: | 05:31 |
| stekern | 1) xml | 05:31 |
| stekern | 2) it has the name IP in it's name, that can't be good | 05:32 |
| stekern | 3) the biggest argument I've heard for it is that "it's used in the industry" | 05:33 |
| stekern | so is a lot of crap, that's not a reason to adopt it... | 05:34 |
| stekern | but, as I said, *prejudices* | 05:34 |
| stekern | that 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 |
| stekern | hmm, seems like there's only VHDL support in kactus2 | 05:54 |
| stekern | heh, and it removed all my .v files too when I removed the HW component I had created | 05:55 |
| stekern | BAM! In your face Mr Heisenbug! | 06:26 |
| stekern | IOW, 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 seing | 06:28 |
| stekern | dual-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 |
| wallento | stekern: IP is a rather less offensive in academia. I think it may have this background: black boxes with interfaces that you can simply plug together | 07:01 |
| stekern | yeah, I know that the name IP has became a synonym to 'module' or 'core' in the HW world. | 07:04 |
| stekern | it's still wrong ;) | 07:05 |
| wallento | ack | 07:07 |
| 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 layer | 07:10 |
| stekern | wallento: but let's go back to more interesting things, I've got this snoop related patch going on | 07:16 |
| wallento | okay, regarding the store buffer? | 07:17 |
| stekern | yes | 07:17 |
| wallento | i still have this cache patch lying around | 07:17 |
| wallento | i will hopefully be able to be sure about it today | 07:17 |
| wallento | ;) | 07:17 |
| stekern | the gist of it is that you can't just check for snoop accesses breaking the atomic_reserve at the beginning of the store buffer | 07:18 |
| wallento | the store buffer is a pretty nasty thing regarding snooping | 07:19 |
| stekern | you have to wait for the l.swa to propagate through it and *then* check that the atomic_reserve haven't been broken | 07:19 |
| wallento | that is the same as waiting that the store buffer is empty? | 07:19 |
| stekern | basically, yes | 07:20 |
| stekern | but you of course have to give the l.swa a bit of special care when it comes out of the store-buffer | 07:21 |
| wallento | can't you "just" wait for the store buffer to drain and then bypass it for swa? | 07:21 |
| olofk | stekern: Yes, I agree. IP-Xact is an overengineered design-by-committee standard | 07:22 |
| kyrre_ | good morning | 07:22 |
| stekern | you could, but I think that would create even more edge-cases | 07:22 |
| olofk | But at least it's a wheel, so I don't need to invent a new one | 07:22 |
| olofk | stekern, 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 project | 07:24 |
| stekern | ...and I don't see a huge advantage of doing that | 07:25 |
| olofk | Some, 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 file | 07:25 |
| olofk | Kactus 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 Icarus | 07:26 |
| olofk | But in the long run, I would probably prefer a det | 07:26 |
| olofk | dedicated top-level editor | 07:26 |
| wallento | speaking of the store buffer, at the moment I cannot deactivate it, right? | 07:29 |
| stekern | no | 07:30 |
| stekern | but I was thinking about that yesterday, for the cache-coherency snooping, I don't see the problem with it | 07:31 |
| stekern | ...maybe I need to walk the dog to see it, but perhaps you can help me by explaining ;9 | 07:34 |
| wallento | no, its more a general thing, the only feature you can't switch off :) | 07:34 |
| wallento | and for playing around with the coherency I intended to deactivate it divide and conquer style | 07:35 |
| stekern | ah, yes. that's a bit of a nuisance, I agree | 07:36 |
| _franck__ | stekern: I think you could: | 07:51 |
| _franck__ | halt | 07:51 |
| _franck__ | or1200.cpu arp_reset assert 0 | 07:51 |
| _franck__ | do what you want here | 07:52 |
| _franck__ | or1200.cpu arp_reset deassert 0 | 07:52 |
| _franck__ | resume | 07:52 |
| stekern | nice, that works | 07:56 |
| stekern | just 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 written | 07:57 |
| stekern | what does the last '0' stand for? | 07:58 |
| _franck__ | it's halt/not halt but not sure if it works | 07:59 |
| stekern | ok | 08:03 |
| stekern | general 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 correctly | 08:06 |
| _franck__ | if debug means debug with gdb, I don't know | 08:07 |
| _franck__ | we would need to have two altera_virtual_jtag in the system | 08:09 |
| _franck__ | vever tried this | 08:10 |
| _franck__ | s/vever/never | 08:10 |
| _franck__ | no no no no | 08:11 |
| _franck__ | adv_debug_can access several CPU | 08:11 |
| _franck__ | at least 2 | 08:13 |
| _franck__ | https://github.com/fjullien/openOCD/blob/usb-blaster2/src/target/openrisc/or1k_du_adv.c#L721 | 08:13 |
| _franck__ | so only one tap and some trickery to add in openocd to switch targeted CPU | 08:14 |
| stekern | yes, that's what I thought, that accessing more than one cpu should be handled in adv_debug | 08:19 |
| stekern | personally, just loading the program into RAM and being able to control the CPUs reset lines is about what I need. | 08:22 |
| _franck__ | https://github.com/fjullien/openOCD/blob/usb-blaster2/tcl/target/altera_fpgasoc.cfg#L45 | 08:22 |
| stekern | but I guess others will eventually have more sophisticated needs | 08:23 |
| _franck__ | two diffrent targets with -coreid x -dbgbase yyyyy | 08:23 |
| stekern | being able to poke at sprs would be nic too | 08:23 |
| stekern | ah, 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: https://github.com/fjullien/openOCD/blob/usb-blaster2/src/target/cortex_a.c#L2415 | 08:26 |
| _franck__ | and the select between CPU0 and CPU1 in adv_dbg | 08:26 |
| _franck__ | s/the/then | 08:27 |
| stekern | ok, doesn't sound like terribly much work | 08:27 |
| _franck__ | plus you can connect openocd to verilator ;) | 08:28 |
| blueCmd | stekern: yes! kaktus things was what i meant | 08:54 |
| blueCmd | stekern: gj on heisenbug :) | 08:55 |
| stekern | thanks blueCmd | 09:56 |
| stekern | as a token of appreciation, I'll give you my hideous hack to keep the tick timers in sync... | 10:07 |
| stekern | http://pastie.org/9229539 | 10:07 |
| stekern | complete with debug prints and stuff that actually belong there... | 10:07 |
| stekern | to make clear the device at 0x99000000 is this http://pastie.org/9229548 | 10:09 |
| stekern | I'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 together | 10: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 |
| stekern | I don't get why that would matter | 10:24 |
| stekern | they should just act as interrupt sources that can be programmed with an interval... | 10:25 |
| stekern | that 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 |
| wallento | stekern: https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_dcache.v#L368 | 13:04 |
| wallento | any 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 opencores.org ? | 13:40 |
| stekern | wallento: yes, because going to IDLE would mean one wasted cycle on WRITE->READ transitions | 13:45 |
| stekern | the whole IDLE state is a bit unneeded | 13:45 |
| stekern | both fetch and lsu together with the caches are a bit messy, and have a lot of duplicated logic. | 13:47 |
| stekern | to give you an idea how I'd want them to look like: | 13:48 |
| stekern | https://github.com/skristiansson/eco32f/blob/master/rtl/verilog/eco32f_lsu.v | 13:48 |
| stekern | https://github.com/skristiansson/eco32f/blob/master/rtl/verilog/eco32f_fetch.v | 13:48 |
| stekern | https://github.com/skristiansson/eco32f/blob/master/rtl/verilog/eco32f_cache.v | 13:48 |
| stekern | those are of course missing loads of functionality that mor1kx cappuccino has, but I think that kind of division of fill logic etc makes sense | 13:49 |
| stekern | but it's hard to motivate tearing apart the mor1kx logic, since it pretty much work... | 13:50 |
| stekern | +myself to | 13:50 |
| olofk | stekern: If you decide to tear it apart, I would recommend adding a good unit test for those parts first | 15:36 |
| olofk | Given that you end up with the same interface, you can use that to sanity check the new implementation | 15:37 |
| olofk | Hmm.. I removed the head commit from my local fusesoc tree, and now I can't pull it from github anymore. It just times out | 15:43 |
| olofk | It's a bit similar to when my orpsoc-cores stopped working at the same time as other people started to push patches to it | 15:44 |
| olofk | It's like it refuses to work if my local copy is behind the upstream one | 15:44 |
| olofk | Is 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 unrelated | 16:46 |
| stekern | olofk: yes, that will motivate me! ;) | 16:54 |
| stekern | not that I disagree, rather the opposite... | 16:54 |
| blueCmd | olofk: do you have any grand ideas how you want to do unit tests, or should I just start mocking your classes? (hah) | 16:59 |
| blueCmd | stekern: if you have, could I have pie? | 17:54 |
| stekern | which flavour | 17:56 |
| blueCmd | the non-crashing one | 17:56 |
| blueCmd | and in an ELF form | 17:57 |
| stekern | ah, elf pie | 17:57 |
| stekern | http://oompa.chokladfabriken.org/openrisc/pie-test | 18:01 |
| stekern | blueCmd: ^ | 18:08 |
| blueCmd | thanks | 18:11 |
| blueCmd | stekern: what versions of gcc/binutils did you use to build that? | 18:19 |
| stekern | they might be slightly older... | 18:20 |
| blueCmd | -rwxr-xr-x 1 bluecmd bluecmd 14992 May 26 00:07 pie | 18:20 |
| blueCmd | -rwxr-xr-x 1 bluecmd bluecmd 12667 May 28 20:00 sfk-pie | 18:20 |
| stekern | the ones that were in my debian schroot | 18:20 |
| blueCmd | sfk = you. I was going to write sjk but sfk was what my hand wrote | 18:20 |
| blueCmd | I guess binutils is the one I'm more intersted in | 18:21 |
| stekern | (since I couldn't chroot into my nfs rootfs back then) | 18:21 |
| blueCmd | dpkg-query -l binutils | 18:21 |
| stekern | ii binutils 2.24.51.20140425-1 or1k GNU assembler, linker and binary utilities | 18:22 |
| blueCmd | interesting, the same as me | 18:22 |
| stekern | fantastic, isn't it? that command works over irc too! | 18:22 |
| blueCmd | haha | 18:23 |
| blueCmd | md5sum /usr/bin/ld | 18:23 |
| stekern | bcacf1e893bf1d3273fe64b61b97bed4 /usr/bin/ld | 18:23 |
| blueCmd | oho | 18:23 |
| blueCmd | 3d789f5a5b9e42fb02489d2c8c4a1565 /usr/bin/ld | 18:23 |
| blueCmd | you're using the 'clean' one | 18:24 |
| stekern | jahapp, what's in the dirty ld? | 18:25 |
| blueCmd | fixes for TLS | 18:25 |
| blueCmd | or, a fix | 18:25 |
| stekern | ...and pie breakage ;) | 18:25 |
| blueCmd | also I'm not sure if atomics are in that one | 18:25 |
| blueCmd | nope, doesn't work even with that version | 18:26 |
| stekern | does my version work on your system? | 18:26 |
| blueCmd | yes | 18:26 |
| stekern | ...silly sanity check | 18:26 |
| blueCmd | So my thinking is that it's either binutils, gcc or some library (like in case for mpfr) | 18:27 |
| blueCmd | stekern: sha1sum /usr/bin/gcc-4.8 | 18:27 |
| blueCmd | (it's very important to change hash algorithm) | 18:28 |
| stekern | 50de410e7b15716a399d9cb242d822f9725cb646 /usr/bin/gcc-4.8 | 18:28 |
| blueCmd | 8fe7982c83552642850fee7719905b05955c511d /usr/bin/gcc-4.8 | 18:28 |
| stekern | I've got the same as you in my "new" rootfs | 18:29 |
| blueCmd | sha1sum /var/cache/apt/archives/gcc_4%3a4.8.2-4_or1k.deb | 18:30 |
| stekern | /usr/bin/sha1sum: /var/cache/apt/archives/gcc_4%3a4.8.2-4_or1k.deb: No such file or directory | 18:31 |
| blueCmd | dpkg-query -l gcc-4.8 | 18:31 |
| blueCmd | or rather: | 18:31 |
| blueCmd | sha1sum /var/cache/apt/archives/gcc-4.8_4.8.2-18_or1k.deb | 18:31 |
| stekern | ii gcc-4.8 4.8.2-18 or1k GNU C compiler | 18:31 |
| stekern | sorry, I don't have any gcc ghere | 18:32 |
| blueCmd | hm | 18:32 |
| blueCmd | your gcc is my: /home/bluecmd/debian/gcc-2014-04-23/gcc-4.8_4.8.2-18_or1k.deb | 18:34 |
| blueCmd | and that doesn't work either | 18:35 |
| stekern | so, binutils? | 18:35 |
| blueCmd | well | 18:35 |
| blueCmd | I think I have your version on both | 18:35 |
| blueCmd | sha1sum /usr/bin/gcc-4.8 /usr/bin/ld | 18:35 |
| blueCmd | 50de410e7b15716a399d9cb242d822f9725cb646 /usr/bin/gcc-4.8 | 18:35 |
| blueCmd | 891e85979fa15724c5850c9792805893c2372836 /usr/bin/ld | 18:35 |
| stekern | yes, looks like it | 18:36 |
| blueCmd | might be crtn.o et. al | 18:36 |
| stekern | it's the __init vs _init changes | 18:40 |
| blueCmd | yes, that would be my guess | 18:41 |
| blueCmd | gonna disass! | 18:41 |
| stekern | http://pastie.org/9231700 | 18:42 |
| blueCmd | ah right | 18:42 |
| blueCmd | the reason it doesn't work for me is that the destructors are actually executing :) | 18:42 |
| blueCmd | in your thing that is just skipped | 18:43 |
| stekern | haha... that's true | 18:43 |
| blueCmd | lazy stekern binary | 18:43 |
| stekern | so it's "working" | 18:43 |
| olofk | stekern: 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 |
| olofk | blueCmd: No ideas for FuseSoC unit tests. Feel free to come up with ideas here | 19:00 |
| blueCmd | ah, the old or10 cpu | 19:00 |
| olofk | Stupid regular expressions | 19:00 |
| stekern | rdiez will be happy | 19:01 |
| olofk | or10... was that the cheerful rdiez implementation? | 19:01 |
| olofk | :) | 19:01 |
| olofk | Good times | 19:01 |
| olofk | Yep. Changing my fusesoc repo to https solved that too. So fucking weird | 19:05 |
| olofk | Haven't had any problems with it before | 19:05 |
| olofk | blueCmd: I still a bit reluctant to pull 9cbbe6d as it puts more code in core.py, and it's only a refactoring commit | 19:08 |
| stekern | does anyone have experience with this? http://sdcc.sourceforge.net/ | 19:11 |
| blueCmd | olofk: the refactoring was done to make it easy to implement generation | 19:41 |
| blueCmd | ah, ok that one | 19:41 |
| blueCmd | that's up to you if you still want to use "interfaces" and __init__ files | 19: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 doing | 19:44 |
| blueCmd | stekern: I have used sdcc some 5-8 years in the past | 19:44 |
| stekern | I'm doing some $nightjob things with stm8 at the moment and I saw that it had added support for that target in the latest release | 19:58 |
| stekern | it'd be nice not having to run a win8 virtual machine to compile the program | 20:01 |
| stekern | not sure how you'd program those outside it anyway, and also not sure if I'm interested enough to pursue.. | 20:02 |
| blueCmd | I wrote a bootloader for the CPU i used it for | 20:04 |
| blueCmd | that's how I solved it :P | 20:04 |
| stekern | heh... I'll never going to fit a bootloader to this | 20:08 |
| stekern | not 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 point | 20:10 |
| stekern | 1KB ram | 20:10 |
| stekern | http://www.st.com/web/en/resource/technical/document/datasheet/DM00024550.pdf | 20:10 |
| stekern | 8KB flash | 20:11 |
| stekern | plenty of room | 20:11 |
| blueCmd | http://www.atmel.com/images/doc0265.pdf | 20:15 |
| blueCmd | I think it was that one I used back then | 20:15 |
| stekern | ah, an good old 8051 | 20:22 |
| stekern | -n | 20:22 |
| stekern | I've only programmed those in asm though | 20:24 |
| -!- hno` is now known as hno | 20:29 | |
| -!- hno is now known as Guest1195 | 20:30 | |
| -!- Guest1195 is now known as hno | 20:30 | |
| --- Log closed Thu May 29 00:00:10 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!