| --- Log opened Sat Jul 26 00:00:36 2014 | ||
| stekern | blueCmd: can't it just be that the ethoc emulation in qemu is broken? | 07:03 |
|---|---|---|
| stekern | olofk: you sometimes want to be able to write to a full buffer because that means you can ommit the logic that prevents ut | 07:04 |
| stekern | *it | 07:04 |
| stekern | I can't come up with a case where you *actually* want to write to the full buffer though | 07:05 |
| olofk | Yes, I was also thinking that it might be easier on the control logic to allow writes, but otoh this messes up the pointers, so we probably have to do a clear/reset to get back to a known state | 07:27 |
| olofk | And the only extra logic in the fifo would be ram_we = fifo_we & !full | 07:28 |
| stekern | yes, but iirc, that can become a pretty critical path | 07:29 |
| stekern | that's why you have things like almost_full signals, that assert when there are 1-2 slots left | 07:31 |
| olofk | true. Critical path is probably the most valid argument here | 07:31 |
| olofk | But in practice, the user of the FIFO will implement this check anyway | 08:47 |
| blueCmd | stekern: I guess, but I don't understand why some ssh sessions continue working | 09:14 |
| blueCmd | stekern: http://openrisc.debian.net/tmp/gcc-test-jul-25/gcc.fail | 09:18 |
| blueCmd | after a weeks fixing | 09:18 |
| blueCmd | 63 failures where the lockups potentially cause 11 | 09:18 |
| olofk | blueCmd: For the complete gcc suite? | 09:19 |
| blueCmd | olofk: that's just gcc | 09:19 |
| blueCmd | not g++ | 09:20 |
| blueCmd | or ada and stuff | 09:20 |
| olofk | ah ok, but still. Wasn't it like >200 a few days ago? | 09:20 |
| blueCmd | yes | 09:23 |
| olofk | c00l | 09:23 |
| blueCmd | that's why it took a week :P | 09:23 |
| blueCmd | only one failure in gcc though, rest in glibc | 09:23 |
| blueCmd | only one bug was in gcc though, the rest was in glibc* | 09:25 |
| olofk | any news on the gcc contributors btw? | 09:28 |
| blueCmd | olofk: not really, as it stands if we cannot reach Jungsook Yang we might need to rewrite or scrap part of the floating point stuff in gcc, not sure how to do that | 09:30 |
| blueCmd | also I need to get hold of a bsemi.com guy which I apparently need to call | 09:30 |
| blueCmd | I'm going to send out 'Please fill in this form and send it in' things to the developers that has answered on monday | 09:31 |
| olofk | Yeah, it's good to get that done at least. juliusb and I promised a few years ago to go out on a holy crusade to hunt down the last contributors | 09:32 |
| blueCmd | we should find someone that wants to port Java/Haskell/Go to openrisc | 09:48 |
| blueCmd | i can be interested in go and java (in that order) but that will take time until I'll get around to it I think | 09:49 |
| olofk | Has anyone ever come across a program that is developed on windows but is supposed to work on linux, that actually works on linux? | 10:28 |
| ysionneau | you mean portable code? or a binary you run with wine? | 10:41 |
| olofk | ysionneau: Source code that you can compile on linux | 10:42 |
| olofk | The code I'm looking at turns out to be full of Windows assumptions | 10:42 |
| ysionneau | arg | 10:43 |
| ysionneau | I guess Linux or BSD developers are more used to portability concerns | 10:43 |
| olofk | Like looking for include files in d:\projects\whatever | 10:44 |
| ysionneau | ahah | 10:44 |
| ysionneau | is it a student project? :) | 10:44 |
| olofk | And windows-specific types | 10:44 |
| ysionneau | seems like whatever you read saying "it works on linux" is just plain wrong advertisment =) | 10:45 |
| olofk | haha. No, it's actually a commercial project | 10:45 |
| ysionneau | wow | 10:45 |
| olofk | Yes. This doesn't work on linux at all I would say | 10:45 |
| olofk | I give up now | 10:46 |
| stekern | I feel like I'm leaving on the edge of technology, just installed one of these hdmi-cable thingies between my ws and monitor instead of the old trusty VGA-cable | 11:04 |
| stekern | s/leaving/living | 11:05 |
| blueCmd | yes, something is wrong with ethoc I think | 11:05 |
| blueCmd | I just got a lockup and interrupts continued for everything except ethoc | 11:05 |
| blueCmd | which sounds reverse to what I had the other day | 11:06 |
| blueCmd | maybe it's some grander error | 11:06 |
| stekern | hmm, wonder if I really need to implement some phy emulation in my MAC<->MAC bridge | 11:08 |
| stekern | where the emulation would just be the standard mdio regs | 11:09 |
| stekern | changing to hdmi cable actually made more of a difference than I had thought | 11:10 |
| stekern | especially with my bad eyesight, I thought I wouldn't be able to notice much | 11:11 |
| stekern | hansfbaier: sublime is working fine, at least all the features I've implemented. missing are filters. | 11:57 |
| blueCmd | Nick Krause.. | 11:57 |
| blueCmd | He just doesn't stop | 11:58 |
| blueCmd | http://patchwork.linux-mips.org/patch/7258/ | 12:06 |
| blueCmd | *sigh* | 12:06 |
| poke53281 | blueCmd: I have managed to mount the filesystem without errors. So far, nothing unusal. | 15:49 |
| olofk | Does anyone else keep getting old OpenCores forum posts e-mailed? | 18:07 |
| stekern | no, but I don't get any opencores forum posts e-mailed | 18:59 |
| olofk | I'm not sure, but I think they are coming in chronologically. Just got one from Feb 20 2014 now | 19:10 |
| olofk | Nahh.. probably just random. Got one from July 26 now | 19:15 |
| olofk | The best things about verilog is the excellent string and memory handling | 19:54 |
| olofk | hmm.. looks like I can't simulate mor1kx-generic with modelsim | 20:27 |
| stekern | why not? | 20:27 |
| stekern | did I break something? | 20:27 |
| olofk | Haven't analyzed it yet, but it just hangs | 20:27 |
| olofk | Works fine with icarus | 20:27 |
| olofk | Weird. It just stops fetching new instructions after this 188: c1 40 00 00 l.mtspr r0,r0,0x5000 | 20:36 |
| stekern | what's 0x5000? | 20:38 |
| stekern | ttmr | 20:42 |
| olofk | It's the or1200-simple testcase from orpsocv2 | 20:45 |
| olofk | Not sure if it's related, but at the same time, I get an undefined value on du_dat_o from mor1kx | 20:49 |
| olofk | Hmm.. modelsim spits out some warnings. Port size mismatch for rdad_i in rf_cappuccino and this one from mor1kx_pic "Non-positive replication multiplier inside concat. Replication will be ignored." | 20:54 |
| olofk | Never seen the second one before | 20:54 |
| stekern | maybe it sucks and can't understand 0{1'b1} | 20:55 |
| stekern | try setting the OPTION_PIC_NMI_WIDTH parameter to something > 0 | 20:56 |
| stekern | like 2... | 20:56 |
| olofk | That fixed the last pic warning I think | 21:02 |
| olofk | But it looks like there's strange things going on in fetch_cappuccino. Shadow register-related perhaps? | 21:03 |
| stekern | *shrugs* can't imagine that'd be related | 21:04 |
| blueCmd | stekern: did you see the new failure logs for gcc? | 21:05 |
| stekern | try disabling du, and the shadow reg stuff should be disabled | 21:05 |
| stekern | blueCmd: yup | 21:05 |
| olofk | FEATURE_DEBUGUNIT? | 21:05 |
| blueCmd | jeremy_bennett: http://openrisc.debian.net/tmp/gcc-test-jul-25/gcc.fail - might be interesting for you, the torture ones are probably unrelated but the others should be real failures | 21:06 |
| stekern | olofk: yes | 21:10 |
| stekern | I think I'll need a fake phy | 21:11 |
| stekern | isn't there a dummy phy driver in Linux? | 21:11 |
| olofk | stekern: Setting OPTION_NUM_SHADOW_GPR=0 solved it | 21:17 |
| olofk | Looks like some width isn't made dependent on that | 21:18 |
| olofk | decode_rfa_adr_i in mor1k_rf_cappuccino isn't adjusted for number of shadow RFs | 21:24 |
| stekern | yeah, it shouldn't | 21:27 |
| olofk | But it goes straight into rdad_i in rf_ram, which is adjusted for number of RFs | 21:28 |
| stekern | does it still work if you enable the DEBUG_UNIT again | 21:29 |
| olofk | w8 | 21:29 |
| olofk | That means wait, but takes less time to write | 21:29 |
| olofk | Yep. that works | 21:30 |
| stekern | yes, I was lazy there, but decode_rfa_adr_i shouldn't be adjusted, rdad_i should be padded with zeros | 21:30 |
| olofk | That's easy enough to fix then. I'll try that | 21:31 |
| * olofk is warming up to the submodules idea | 21:31 | |
| stekern | can't imagine that modelsim wouldn't do that by default? | 21:31 |
| olofk | Don't really know what it did, but there were a a lot of red lines in the waveform | 21:32 |
| stekern | maybe it 'x' them... | 21:32 |
| olofk | Might do, since there aren't any drivers | 21:33 |
| stekern | annoying f*cking event driven simulators... | 21:33 |
| olofk | :) | 21:34 |
| stekern | if you are fixing it, you might as well put that stuff in the generate that is above the mor1kx_rf_ram instantiations, and call the signals rfa_rdad and rfb_rdad | 21:36 |
| stekern | and then hand over the patch | 21:36 |
| stekern | or.. doesn't have to be in the generate | 21:37 |
| * stekern tired | 21:38 | |
| * stekern go sleep now | 21:38 | |
| olofk | I changed it to .rdad_i({{(RF_ADDR_WIDTH-OPTION_RF_ADDR_WIDTH){1'b0}},decode_rfa_adr_i}), | 21:39 |
| olofk | How's that for readability? :) | 21:39 |
| olofk | Seems to work at least | 21:39 |
| stekern | heh, yes, that's why I want it in a seperate signal ;) | 21:39 |
| olofk | But not for the 0 case. Yeah, a proper fix would be better | 21:40 |
| stekern | 0 case? | 21:40 |
| olofk | RF_NUM_SHADOW_GPR = 0 | 21:40 |
| olofk | {0{1'b0} is one bit wide apparently | 21:40 |
| stekern | yeah, right, it got grumpy about that too... | 21:41 |
| stekern | stupid modelsim | 21:41 |
| blueCmd | stekern: your port to musl, is it feature complete? | 21:42 |
| stekern | apart from fenv, yes | 21:45 |
| blueCmd | cool | 21:52 |
| blueCmd | poke53281: appear to have a lockup in or1ksim now as well | 22:02 |
| olofk | stekern: http://7aa8165da38c4da9.paste.se/ | 22:26 |
| olofk | Tested with modelsim, icarus and verilator with OPTION_RF_NUM_SHADOW_GPR 0 and 1 | 22:29 |
| olofk | Works with 2 as well | 22:29 |
| poke53281 | Hmm, which compiler version do you use? | 22:30 |
| poke53281 | blueCmd: https://lkml.org/lkml/2014/7/24/584 | 22:32 |
| poke53281 | gcc 4.9 seems to be broken for Linux compilation. | 22:33 |
| olofk | poke53281: At least with -Os | 22:37 |
| blueCmd | poke53281: ah right, that might be relevant - I actually read the thread but never thought that it might be related to this :P | 22:41 |
| blueCmd | hm | 22:41 |
| blueCmd | I don't think it is relevant though | 22:41 |
| blueCmd | we don't have red-zone and I'm using 4.10 | 22:42 |
| blueCmd | for or1k | 22:42 |
| olofk | How does reading and writing SPI work from linux userspace? | 23:23 |
| olofk | Is it just presented as a char device? | 23:23 |
| --- Log closed Sun Jul 27 00:00:37 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!