| --- Log opened Mon Sep 02 00:00:38 2013 | ||
| hansfbaier | While slides / videos be available from the meeting? | 01:40 |
|---|---|---|
| hansfbaier | slides would be great | 01:40 |
| stekern | hansfbaier: at the very least the slides | 04:42 |
| stekern | we had video recordings last year | 04:42 |
| hansfbaier | stekern: great | 04:44 |
| hansfbaier | stekern: I looked a little into the Interrupt problem with the ENC28J60 | 04:45 |
| hansfbaier | stekern: it doesn't seem to be a problem of the driver, rather the kernel interrupt handling code | 04:45 |
| hansfbaier | stekern: SPI communication to the enc28j60 works well | 04:45 |
| hansfbaier | stekern: But when that IRQ goes low(-active) | 04:46 |
| hansfbaier | stekern: then the kernel loops in interrupt handling code including functions in arch/openrisc/irq* | 04:46 |
| hansfbaier | stekern: the enc28j60 driver is supposed to write to the devices registers to clear the interrupt, but it can't since it's locked up in the kernel | 04:47 |
| hansfbaier | stekern: in arch/openrisc/kernel/irq.c there is a comment that for OR1200 there has to be writt | 04:48 |
| hansfbaier | /* There are two oddities with the OR1200 PIC implementation: | 04:49 |
| hansfbaier | * i) LEVEL-triggered interrupts are latched and need to be cleared | 04:49 |
| hansfbaier | * ii) the interrupt latch is cleared by writing a 0 to the bit, | 04:49 |
| hansfbaier | * as opposed to a 1 as mandated by the spec | 04:49 |
| hansfbaier | */ | 04:49 |
| hansfbaier | is this still valid, maybe I need to look at the RTL code | 04:49 |
| hansfbaier | maybe the RTL code has been fixed to conform to the spec, but the kernel was not updated. | 04:50 |
| hansfbaier | But then the serial interrupts should not work either, should they? | 04:50 |
| stekern | yes, the or1200 pic is odd | 04:51 |
| hansfbaier | stekern: Why not fix it? | 04:51 |
| hansfbaier | stekern: if it is against the spec? | 04:51 |
| hansfbaier | stekern: is there a lot of code depending on it? | 04:51 |
| stekern | (as an answer to if it's still valid) | 04:51 |
| stekern | you just said the reason, you'd (potentially) break it for users that have started to rely on it | 04:52 |
| stekern | in mor1kx, you can configure it to be level, edge or or1200 compatible | 04:53 |
| stekern | but the kernel interrupt code should be pretty solid I think | 04:53 |
| stekern | so let me step back and read what you wrote a couple of lines above ;) | 04:54 |
| hansfbaier | stekern: what would be a good way to debug this? | 04:54 |
| hansfbaier | stekern: What would be a good function call trace tool? prink? But that's a lot of work. | 04:54 |
| hansfbaier | stekern: somehow I need to know why the kernel locks up in interrupt handling code | 04:55 |
| stekern | doesn't the enc28j60 driver write the registers in the interrupt handler? | 04:55 |
| stekern | I love printk debuging... but that's me | 04:55 |
| hansfbaier | BTW, wouldn't it be better to update the spec then? | 04:56 |
| stekern | no, the spec is fine | 04:56 |
| stekern | it probably should be fixed in or1200 and made configurable | 04:57 |
| stekern | it goes under the "patches welcome" parole =) | 04:58 |
| hansfbaier | http://pastebin.com/wYALY7yD | 04:58 |
| stekern | ah, I see | 04:58 |
| stekern | hmm, so you *need* edge triggered interrupts for that to work | 04:59 |
| hansfbaier | http://pastebin.com/xWNVRBWc | 04:59 |
| stekern | because that wouldn't work with a level triggered interrupt, not even without the or1200 oddities | 05:01 |
| hansfbaier | stekern: the second paste is the irq_work routine | 05:01 |
| hansfbaier | priv->irq_work | 05:01 |
| stekern | yeah, I got that, but it's not so interesting, since the problem already shows in the first apste | 05:02 |
| stekern | *paste | 05:02 |
| hansfbaier | stekern: But isn't x86 supposed to have level triggered IRQs? (I thought that's what I read in wikipedia) | 05:02 |
| hansfbaier | stekern: but it said there in fact that PCI requires level triggered ints, not the x86 | 05:03 |
| stekern | on what archs have that driver been used? are there any indications of that anywhere? | 05:04 |
| hansfbaier | Author: Claudio Lanconelli <lanconelli.claudio@eptar.com> | 05:04 |
| hansfbaier | * based on enc28j60.c written by David Anders for 2.4 kernel version | 05:04 |
| hansfbaier | 2.4 might imply x86 | 05:04 |
| stekern | hmm, why? | 05:05 |
| hansfbaier | stekern: (wild guess) because it's a rather early version, not many archs around at the time???? But I am possibly wrong | 05:05 |
| stekern | but most gpio controllers have the option to be configured as edge triggered | 05:05 |
| hansfbaier | some guys used it with the RPi : http://www.raspberrypi.org/phpBB3/viewtopic.php?f=44&t=18397 | 05:06 |
| stekern | I think we should actually have those EINTs going through the gpio core, and then that should turn the edge interrupts into level interrupts | 05:07 |
| hansfbaier | ah | 05:09 |
| hansfbaier | stekern: How long has the interrupt line be active to be recognized, one clock cycle? | 05:15 |
| stekern | quick and dirty solution for you now, mask out irq 24 in the enc28j60 interrupt handler, and then enable it right after the spi register is written in the work_handler | 05:16 |
| hansfbaier | stekern: ah ok | 05:16 |
| hansfbaier | stekern: thanks | 05:16 |
| hansfbaier | stekern: I can figure that out | 05:17 |
| stekern | I don't think the kernel fiddle with the mask bits anywhere else (at least not more than once), but let me check that | 05:18 |
| hansfbaier | irq.c? | 05:18 |
| hansfbaier | mtspr(SPR_PICSR, mfspr(SPR_PICSR) & ~(1UL << data->hwirq)); | 05:18 |
| stekern | yes, exactly | 05:19 |
| stekern | errr, no not at all | 05:20 |
| stekern | mtspr(SPR_PICMR, mfspr(SPR_PICMR) & ~(1UL << data->hwirq)) | 05:20 |
| hansfbaier | stekern: yes, of course use PICMR | 05:21 |
| stekern | there's actually a or1k_pic_mask_ack that clears the irq in sr and mask it | 05:24 |
| stekern | that's linked to irq_mask_ack, not sure when that is used though | 05:25 |
| hansfbaier | stekern: Yes, but it's static | 05:25 |
| stekern | yes, but the pointer to it is passed to linux irq system | 05:26 |
| stekern | hansfbaier: you'll be happy to know that I finished up the SPI driver cleanup and sent it to the mailing list, and jonas pulled them into his tree now | 05:27 |
| hansfbaier | stekern: saw it in the list. Thanks! SPI seems to work pretty well even now. | 05:28 |
| stekern | it'd be great if you could try that out, to get some more test coverage on it | 05:29 |
| hansfbaier | stekern: ok I'll pull | 05:29 |
| stekern | thanks! | 05:32 |
| stekern | and yes, the spi driver worked fine before, it was more of a matter of its surroundings changing a bit since jonas initially wrote it | 05:37 |
| hansfbaier | stekern: Now I did this: | 05:40 |
| hansfbaier | mtspr(SPR_PICMR, mfspr(SPR_PICMR) & ~(1UL << irq)); | 05:40 |
| hansfbaier | and a printk there | 05:40 |
| hansfbaier | but I still get the same interrupt storm: | 05:41 |
| hansfbaier | ENC28J60 got interrupt no 25 | 05:41 |
| hansfbaier | ENC28J60 got interrupt no 25 | 05:41 |
| hansfbaier | ENC28J60 got interrupt no 25 | 05:41 |
| hansfbaier | ...... | 05:41 |
| hansfbaier | weird | 05:42 |
| hansfbaier | the mtspr does not seem to work | 05:42 |
| hansfbaier | PIC.PICMR = SPR9_0 = 33555463 (0x2000407) | 05:42 |
| stekern | ... or then the kernel unmask it somewhere | 05:42 |
| hansfbaier | stekern: yes it's set there hmmm | 05:43 |
| hansfbaier | stekern: Yes, looks like that. I set it manually with gdb. same result. | 05:45 |
| hansfbaier | $ grep SPR_PICMR $(find . -name \*.c) | 05:46 |
| hansfbaier | ./drivers/net/ethernet/microchip/enc28j60.c: mtspr(SPR_PICMR, mfspr(SPR_PICMR) | (1UL << 25)); | 05:46 |
| hansfbaier | ./drivers/net/ethernet/microchip/enc28j60.c: mtspr(SPR_PICMR, mfspr(SPR_PICMR) & ~(1UL << irq)); | 05:46 |
| hansfbaier | ./arch/openrisc/kernel/irq.c:mtspr(SPR_PICMR, mfspr(SPR_PICMR) & ~(1UL << data->hwirq)); | 05:46 |
| hansfbaier | ./arch/openrisc/kernel/irq.c:mtspr(SPR_PICMR, mfspr(SPR_PICMR) | (1UL << data->hwirq)); | 05:46 |
| hansfbaier | ./arch/openrisc/kernel/irq.c:mtspr(SPR_PICMR, (0UL)); | 05:46 |
| hansfbaier | hmm that can't be all | 05:46 |
| hansfbaier | maybe some asm | 05:46 |
| stekern | ah, handle_level_irq() mask before calling the interript handler and unmask after | 05:50 |
| stekern | but logically, that would mean that irq 25 should be masked in your enc28j60 interrupt handler, isn't that the case? | 05:56 |
| stekern | doesn't change our problem, but I'm just curious | 06:03 |
| hansfbaier | stekern: Yes, it's masked | 06:04 |
| stekern | so let's change our quick and dirty fix to a little less dirty one, but in the rtl this time | 06:04 |
| hansfbaier | if (mfspr(SPR_PICMR) & (1UL << irq)) | 06:04 |
| hansfbaier | { | 06:04 |
| hansfbaier | printk("not masked\n"); | 06:04 |
| hansfbaier | } | 06:04 |
| hansfbaier | didn't show up | 06:04 |
| stekern | good, then all makes sense! | 06:04 |
| hansfbaier | stekern: to you ;) | 06:06 |
| stekern | http://pastie.org/8290418 | 06:07 |
| stekern | do something like that and connect eint25_edge to the irq input of the cpu | 06:07 |
| stekern | I think holding the irq line high for one clock cycle should be enough, if not, then prolong it ;) | 06:08 |
| stekern | hansfbaier: thanks for education me a bit in Linux irq handling code by bringing interesting problems ;) | 06:15 |
| hansfbaier | stekern: You are welcome :) | 06:23 |
| hansfbaier | stekern: I'll have to thank you.... | 06:24 |
| hansfbaier | stekern: but now the design doesn't fit into my FPGA anymore... Can't believe it. That only should be a flip-flop and a couple of gates. | 06:25 |
| hansfbaier | looks like I've messed something up | 06:26 |
| hansfbaier | stekern: stupid me | 06:27 |
| hansfbaier | switched to branch master | 06:27 |
| hansfbaier | to pull your changes | 06:27 |
| hansfbaier | stekern: But you didn't change RTL, did you? | 06:27 |
| hansfbaier | Only linux? | 06:27 |
| stekern | umm, I haven't pushed anything to my orpsocv2 repo in 2 weeks | 06:28 |
| hansfbaier | stekern: Ah | 06:28 |
| hansfbaier | stekern: so it was to linux | 06:29 |
| stekern | so i guess that qualifies as "didn't change RTL" =) | 06:29 |
| hansfbaier | http://lpaste.net/7334792526445936640 | 06:29 |
| hansfbaier | I did this | 06:29 |
| hansfbaier | lets synth | 06:30 |
| stekern | oh, that's not right | 06:30 |
| stekern | ~ and ! means the same thing for 1-bit signals | 06:30 |
| stekern | ah, actually, maybe it's right | 06:31 |
| hansfbaier | stekern: Yes, but it's low active | 06:31 |
| stekern | but the code is certainly confusing like that =) | 06:31 |
| stekern | http://pastie.org/8290462 <= that's a bit easier to read | 06:35 |
| stekern | rename the eint25_edge signal to eint25_nedge for bonus points | 06:37 |
| hansfbaier | will do, but previous should work, shouldn't it? | 06:39 |
| hansfbaier | I'll try it first | 06:39 |
| stekern | yes, it should work | 06:41 |
| hansfbaier | stekern: which branch do I have to merge from? | 06:47 |
| hansfbaier | openrisc-3.4 | 06:47 |
| hansfbaier | no that's a tag | 06:47 |
| hansfbaier | master has a lot of changes | 06:48 |
| hansfbaier | compared to mine. | 06:48 |
| hansfbaier | hmmm. | 06:48 |
| hansfbaier | I think I just download the two files and update them to my branch | 06:48 |
| hansfbaier | before giving me a headache | 06:48 |
| stekern | ah, yeah, do that ;) | 06:49 |
| stekern | the build tools you are using use commit 065bba63d70b6de4f56c75f5e3a89ac2a5d0b01f | 06:51 |
| stekern | so you probably want to pull from master eventually (but not in the middle of debugging this enc thing) | 06:52 |
| hansfbaier | stekern: hmmm got an SPI related kernel crash after copying in the new spi controller | 07:03 |
| hansfbaier | http://lpaste.net/92432 | 07:04 |
| hansfbaier | reverted patch, works again | 07:06 |
| hansfbaier | connected network cable: no interrupt storm :) | 07:07 |
| hansfbaier | But: device not found | 07:07 |
| hansfbaier | wait a minute... | 07:07 |
| hansfbaier | oh my.... | 07:07 |
| hansfbaier | I messed something up | 07:07 |
| stekern | hmm, interesting, but let's not draw too much conclusions from you "backporting" it into your old tree | 07:12 |
| stekern | if that happens later with jonas master, then I'd be more concerned | 07:13 |
| -!- enghong_ is now known as enghong | 07:18 | |
| hansfbaier | Weird I messed something up. | 07:41 |
| hansfbaier | My I2C realtime clock is gone | 07:41 |
| hansfbaier | and the enc28j60 does not show up | 07:41 |
| hansfbaier | mmc/SPI works | 07:41 |
| hansfbaier | weird | 07:41 |
| hansfbaier | reboot time | 07:41 |
| hansfbaier | stekern: # enc28j60: intLINK(1) | 08:28 |
| hansfbaier | enc28j60: enc28j60_check_link_status() PHSTAT1: 1804, PHSTAT2: 0420 | 08:28 |
| hansfbaier | net eth0: link up - Half duplex | 08:28 |
| hansfbaier | w00t! | 08:29 |
| stekern | ! | 08:30 |
| hansfbaier | stekern: but: | 08:31 |
| hansfbaier | http://lpaste.net/92434 | 08:31 |
| hansfbaier | stekern: ping crashes | 08:31 |
| hansfbaier | but it tries to send a packet | 08:31 |
| hansfbaier | stekern: some progress | 08:32 |
| hansfbaier | ejc28j60 driver is marked experimental | 08:32 |
| hansfbaier | so............ | 08:32 |
| hansfbaier | But the Link up means the Link up Interrupt was processed well | 08:36 |
| stekern | yup | 08:36 |
| hansfbaier | stekern: enc28j60: enc28j60_irq_work_handler() exit | 08:38 |
| hansfbaier | stekern: looks like IRQ handling works | 08:38 |
| hansfbaier | somehow ... | 08:38 |
| hansfbaier | :) | 08:38 |
| stekern | that's good | 08:39 |
| hansfbaier | yes | 08:39 |
| stekern | could of course be a chance that interrupts are being missed and stuff like that, or something completely different | 08:41 |
| stekern | I think our "quick and not so dirty" hack should be pretty fine | 08:41 |
| olofk | I've been thinking about writing an external interrupt controller that can be hooked up to a wishbone bus | 08:42 |
| olofk | And only have a single IRQ line into or1k | 08:42 |
| olofk | How much extra work would that generate? I guess a driver would be required | 08:44 |
| stekern | olofk: we should make a new gpio core with irq support | 08:44 |
| olofk | That makes sense | 08:44 |
| olofk | I read a rant on the CERN open hardware mailing list where a guy proposed that interrupts should be proper wishbone accesses. I quite liked that | 08:45 |
| olofk | Like MSI for PCI | 08:45 |
| stekern | I kind of get what that means, but elaborate | 08:46 |
| stekern | what does it mean that "interrupts should be proper wishbone accesses"? | 08:46 |
| olofk | Instead of raising an interrupt line, you implement a master interface that sends a wb write to an interrupt controlelr | 08:47 |
| olofk | It's probably not very good for small systems, but it's quite nice for larger ones | 08:47 |
| olofk | That mean that you can send a lot more information about the interrupt, they can be pipelined and routed easier | 08:48 |
| olofk | And you can run it off-chip without adding new pins if you already have an off-chip wishbone transport | 08:49 |
| olofk | No... the last isn't necessarily true | 08:49 |
| hansfbaier | stekern: receiving seems to work | 08:52 |
| hansfbaier | http://lpaste.net/92436 | 08:52 |
| hansfbaier | stekern: but tx gives timeouts | 08:53 |
| hansfbaier | stekern: well | 08:53 |
| hansfbaier | stekern: enough for today. Thanks! | 08:53 |
| stekern | hansfbaier: you have to save some fun for tomorrow to, right? =) | 08:53 |
| olofk | Only RX can be quite useful. NSA uses that all the time | 08:54 |
| stekern | olofk: yeah, that was sort of what I thought. but that interrupt controller would still be hooked up to an (1) irq line of the cpu, right? | 08:55 |
| olofk | Yep. Still need one IRQ | 08:55 |
| hansfbaier | http://lpaste.net/92437 | 08:56 |
| hansfbaier | stekern: Yes, got to work again | 08:57 |
| hansfbaier | too much play last week .... | 08:57 |
| stekern | ;) | 08:57 |
| stekern | olofk: so, basically you want the PIC that we have now, but with an wishbone interface instead of an SPR interface | 08:58 |
| olofk | I haven't looked at the PIC to be honest | 08:58 |
| stekern | well, there's that difference that all peripherals should be wb masters | 08:59 |
| olofk | But I guess having an external one makes it easier to do crazy modifications, or drop it to save logic | 08:59 |
| olofk | (that's how MicroBlaze does it) | 09:00 |
| stekern | nios II too, I think | 09:00 |
| olofk | But with regular IRQ lines | 09:00 |
| stekern | they have some external interrupt controller | 09:00 |
| olofk | Might be something to consider for or2k. Might save a few pages in the spec | 09:01 |
| stekern | I don't see why you couldn't do that as it is today | 09:01 |
| stekern | it wouldn't even need any software changes | 09:02 |
| olofk | For an external PIC? | 09:02 |
| stekern | yes, for whato you described | 09:03 |
| stekern | -o | 09:03 |
| olofk | Lunch time now. | 09:03 |
| olofk | Latch that though ;) | 09:03 |
| olofk | s/though/thought | 09:03 |
| stekern | sure ;) | 09:03 |
| stekern | peripheral indicates irq by wb write => irq ctrl set irq_line[0] => or1k cpu do exception => or1k cpu write via wb bus to peripheral to clear interrupt => peripheral indicates to irq ctrl that the irq is cleared => irq_ctrl deasserts irq_line[0] | 09:06 |
| stekern | you'll still have the PIC there of course, with 31 lines unused (so optimized away in the synthesis). You can implement a level PIC with pretty much just bypass logic, so the only overhead is the mask reg and SPR bus | 09:08 |
| hansfbaier | olofk: Only RX with 10BaseT-HalfDuplex won't be terrible useful to the NSA ;) | 09:26 |
| jeremybennett | stekern: Just seen mor1kx v1.0 is now tagged. | 09:27 |
| stekern | jeremybennett: yup, the first of (hopefully) many great mor1kx releases ;) | 09:28 |
| olofk | hansfbaier: Ah.. true :) | 09:30 |
| _franck_ | olofk: don't you think we should remove wb_utils from orpsoc-cores ? | 09:32 |
| olofk | _franck_: Absolutely | 09:32 |
| _franck_ | you don't want to start to duplicate things like we used to do :) | 09:32 |
| olofk | stekern: I guess you're right. Still would be nice to remove it from the spec to trim it down a bit | 09:33 |
| olofk | _franck_: Thanks for keeping me on a straight line. It's very tempting just to do a fork of my own stuff :) | 09:33 |
| jeremybennett | I see we have 9 people registered at ORCONF 2013 already. | 09:37 |
| olofk | I'm almost done with my intercon generator now, so once that is in place, I'll remove wb_utils | 09:38 |
| olofk | No.. I'll remove wb_utils first. | 09:38 |
| stekern | I think that's more than we had for orconf2012 by this time | 09:38 |
| olofk | I'm setting up a linux VM now. What would be the smallest distribution for running icarus? | 09:45 |
| hansfbaier | olofk: Arch Linux :) | 09:46 |
| olofk | Good idea | 09:46 |
| hansfbaier | olofk: or debian minimal | 09:47 |
| olofk | Also good idea | 09:47 |
| olofk | Does arch have a package list somewhere? Want to get a feeling for how many eda tools there are available | 09:48 |
| hansfbaier | https://www.archlinux.org/packages/ | 09:49 |
| hansfbaier | https://www.archlinux.org/packages/?sort=&q=verilog | 09:49 |
| olofk | Looks good | 09:50 |
| knz | my de0 is shipped :) | 11:22 |
| _franck_ | this is awesome: http://www.asciiflow.com/#Draw !! | 12:37 |
| knz | _franck_: nice :) | 12:57 |
| stekern | I get "this wbepage is not available" | 12:57 |
| _franck_ | stekern: me too now... | 13:03 |
| _franck_ | it's back | 13:05 |
| olofk | That's a cool page | 13:24 |
| olofk | stekern: You should use it for the GPIO files in the kernel :) | 13:24 |
| stekern | I can't even reach it | 13:25 |
| stekern | ah, now I can | 13:25 |
| stekern | yeah, it is cool ;) | 13:27 |
| _franck_ | I wanted this to draw something about the bus interconnection on my de1 orpsoc ;) | 13:31 |
| olofk | Isn't there any non-volatile memory on de0-nano? | 13:48 |
| olofk | Or is it? There's some conflicting information on the terasic site | 13:49 |
| stekern | yes, there is 8MB of spi flash | 14:10 |
| stekern | so you can easily fit the fpga configuration, u-boot, dts and kernel in there | 14:12 |
| stekern | and a small rootfs | 14:13 |
| olofk | But does it run Crysis? | 14:13 |
| knz | olofk: :) | 14:15 |
| knz | olofk: probably a 1 pixel rendering of a very small crysis scene :) | 14:15 |
| stekern | that's after my gaming period, so it's irrelevant ;) | 14:50 |
| knz | hi all | 15:21 |
| knz | I understand there's some mainstream support in linux for openrisc now | 15:21 |
| knz | from 3.6 or 3.7 or something, right? | 15:21 |
| knz | the question I have is: how is it possible that linux has mainstream support for openrisc, but binutils/gcc not yet? | 15:22 |
| knz | usually linux does not integrate support for a targt which is not yet integrated in the rest of the gnu toolchain | 15:22 |
| _franck_ | stekern: Am I wrong here : https://github.com/fjullien/orpsocv3/commit/f354c169441eadab5aa72e7f1293f3d2772ce625 ? | 15:31 |
| stekern | _franck_: I'll check when I'm on a device where I can paste from irc | 15:34 |
| _franck_ | ok | 15:35 |
| _franck_ | it's in your sdram controller, wb_port.v | 15:35 |
| _franck_ | wire [(1<<BUF_WIDTH)-1:0]wb_bufram_addr; | 15:35 |
| _franck_ | should be wire [BUF_WIDTH-1:0]wb_bufram_addr I think | 15:35 |
| stekern | yes, that's a clear typo, good catch | 15:40 |
| olofk | knz: Yes, you're right. It's supported since 3.2, but I think that there have been traces of OpenRISC in the Linux Kernel much longer than that, so that might be the reason why it was so readily accepted | 16:52 |
| olofk | I have also been told that the port that Jonas did was really well-written. That probably helped too | 16:53 |
| olofk | stekern: Might have hit a new bug in wb_sdram_ctrl | 16:58 |
| stekern | olofk: excellent! tell me about it | 17:03 |
| olofk | I can tell you with a VCD. Haven't analyzed it myself yet | 17:04 |
| stekern | actually, it's since 3.1 and I think Arnd Bergmann encouraged Jonas to upstream it, because it was well-written and heavily used the device tree | 17:05 |
| stekern | that's least what I got from some mailing list mails I saw back then | 17:06 |
| stekern | other ports Arnd had his eyes on were the lm32 port (the one maintained by the milkymist community) | 17:07 |
| stekern | google will probably find those mails if someone is interested ;) | 17:07 |
| stekern | olofk: bring it on, but there will be a couple of hours latency before I have time to look at it | 17:08 |
| olofk | https://www.dropbox.com/s/f75hk25i3zh6128/testlog3.vcd | 17:10 |
| olofk | I'll take a look at it too. Would feel good to find it myself | 17:10 |
| stekern | I'll keep quiet if I happen to see the problem then ;) | 17:34 |
| stekern | any pointers where it fails? | 17:34 |
| stekern | _franck_: the wb_bufram_addr was a typo, the others you changed in your patch was correct | 17:48 |
| olofk | stekern: Master 1, transaction 457 fails. | 17:57 |
| _franck_ | stekern: ok, I changed this without knowing what is was :) At least there was something to fix.... | 18:00 |
| olofk | How does the buffer thingie work? Is it just FIFOs or does it have any cache functionality? | 18:00 |
| olofk | _franck_: Will you be talking a bit about GDB at orconf? | 18:01 |
| _franck_ | well, I don't know, may be | 18:01 |
| olofk | I'm interested in the XML stuff and differences in general from the old port | 18:02 |
| _franck_ | I'm not that confortable in public (at least while speaking english). As you know we (french people) are not the best english speakers in the world ;) | 18:02 |
| olofk | I liked your barebox presentation last year, but we can as well talk about GDB over a beer if you prefer that | 18:03 |
| _franck_ | I'll try to summarize what I've done and see how it looks | 18:04 |
| juliusb | I'd definitely like a gdb update, with or without beer :) | 18:05 |
| olofk | That would be great | 18:05 |
| olofk | Looking forward to see Cambridge too. I've never been to Massachusetts before | 18:06 |
| olofk | Too bad it's such a long flight | 18:06 |
| juliusb | !! :P | 18:07 |
| juliusb | You're talking about ORCONF olofk ? | 18:07 |
| juliusb | You missed the ", England" part of the location for the conference | 18:08 |
| juliusb | you'll have to just teleconf with us from Boston, then | 18:08 |
| olofk | Just fax me regular updates, and I'll be fine | 18:09 |
| juliusb | speaking of MA in the USA, i'm preparing my slides for OHS2013 | 18:10 |
| juliusb | they want them by tomorrow | 18:10 |
| juliusb | only just starting :-/ | 18:10 |
| juliusb | it's only a 6 minute talk thoguh | 18:10 |
| olofk | That must be the hard part, to distill it down so much | 18:10 |
| juliusb | I thought i'd give a 1 slide introduction to VLSI and then jump straight to the workings of the mor1kx core... | 18:11 |
| olofk | I still think it's kind of silly of them to only offer so short slots | 18:11 |
| juliusb | i'll copy-paste portions of a netlist onto a slide | 18:11 |
| juliusb | maybe 4,5 slides of that | 18:12 |
| juliusb | I hope I won't be going too deep too fast | 18:12 |
| juliusb | (short talk) ah I don't mind really | 18:12 |
| juliusb | mean less work for me to do | 18:12 |
| olofk | True | 18:12 |
| olofk | Ahh.. there's a FIFO for writes, and a RAM (cache) for reads, right? | 18:16 |
| olofk | It appears as read_done is asserted before the data is read from the SDRAM | 18:30 |
| stekern | olofk why did you quit on me, just when I got loose from the other minor project I'm involved in, kitchen renovation | 19:44 |
| --- Log closed Tue Sep 03 00:00:39 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!