IRC logs for #openrisc Monday, 2013-09-02

--- Log opened Mon Sep 02 00:00:38 2013
hansfbaierWhile slides / videos be available from the meeting?01:40
hansfbaierslides would be great01:40
stekernhansfbaier: at the very least the slides04:42
stekernwe had video recordings last year04:42
hansfbaierstekern: great04:44
hansfbaierstekern: I looked a little into the Interrupt problem with the ENC28J6004:45
hansfbaierstekern: it doesn't seem to be a problem of the driver, rather the kernel interrupt handling code04:45
hansfbaierstekern: SPI communication to the enc28j60 works well04:45
hansfbaierstekern: But when that IRQ goes low(-active)04:46
hansfbaierstekern: then the kernel loops in interrupt handling code including functions in arch/openrisc/irq*04:46
hansfbaierstekern: 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 kernel04:47
hansfbaierstekern: in arch/openrisc/kernel/irq.c there is a comment that for OR1200 there has to be writt04:48
hansfbaier/* There are two oddities with the OR1200 PIC implementation:04:49
hansfbaier * i)  LEVEL-triggered interrupts are latched and need to be cleared04: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 spec04:49
hansfbaier */04:49
hansfbaieris this still valid, maybe I need to look at the RTL code04:49
hansfbaiermaybe the RTL code has been fixed to conform to the spec, but the kernel was not updated.04:50
hansfbaierBut then the serial interrupts should not work either, should they?04:50
stekernyes, the or1200 pic is odd04:51
hansfbaierstekern: Why not fix it?04:51
hansfbaierstekern: if it is against the spec?04:51
hansfbaierstekern: is there a lot of code depending on it?04:51
stekern(as an answer to if it's still valid)04:51
stekernyou just said the reason, you'd (potentially) break it for users that have started to rely on it04:52
stekernin mor1kx, you can configure it to be level, edge or or1200 compatible04:53
stekernbut the kernel interrupt code should be pretty solid I think04:53
stekernso let me step back and read what you wrote a couple of lines above ;)04:54
hansfbaierstekern: what would be a good way to debug this?04:54
hansfbaierstekern: What would be a good function call trace tool? prink? But that's a lot of work.04:54
hansfbaierstekern: somehow I need to know why the kernel locks up in interrupt handling code04:55
stekerndoesn't the enc28j60 driver write the registers in the interrupt handler?04:55
stekernI love printk debuging... but that's me04:55
hansfbaierBTW, wouldn't it be better to update the spec then?04:56
stekernno, the spec is fine04:56
stekernit probably should be fixed in or1200 and made configurable04:57
stekernit goes under the "patches welcome" parole =)04:58
stekernah, I see04:58
stekernhmm, so you *need* edge triggered interrupts for that to work04:59
stekernbecause that wouldn't work with a level triggered interrupt, not even without the or1200 oddities05:01
hansfbaierstekern: the second paste is the irq_work routine05:01
stekernyeah, I got that, but it's not so interesting, since the problem already shows in the first apste05:02
hansfbaierstekern: But isn't x86 supposed to have level triggered IRQs? (I thought that's what I read in wikipedia)05:02
hansfbaierstekern: but it said there in fact that PCI requires level triggered ints, not the x8605:03
stekernon what archs have that driver been used? are there any indications of that anywhere?05:04
hansfbaier Author: Claudio Lanconelli <>05:04
hansfbaier * based on enc28j60.c written by David Anders for 2.4 kernel version05:04
hansfbaier2.4 might imply x8605:04
stekernhmm, why?05:05
hansfbaierstekern: (wild guess) because it's a rather early version, not many archs around at the time???? But I am possibly wrong05:05
stekernbut most gpio controllers have the option to be configured as edge triggered05:05
hansfbaiersome guys used it with the RPi :
stekernI think we should actually have those EINTs going through the gpio core, and then that should turn the edge interrupts into level interrupts05:07
hansfbaierstekern: How long has the interrupt line be active to be recognized, one clock cycle?05:15
stekernquick 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_handler05:16
hansfbaierstekern: ah ok05:16
hansfbaierstekern: thanks05:16
hansfbaierstekern: I can figure that out05:17
stekernI don't think the kernel fiddle with the mask bits anywhere else (at least not more than once), but let me check that05:18
hansfbaiermtspr(SPR_PICSR, mfspr(SPR_PICSR) & ~(1UL << data->hwirq));05:18
stekernyes, exactly05:19
stekernerrr, no not at all05:20
stekernmtspr(SPR_PICMR, mfspr(SPR_PICMR) & ~(1UL << data->hwirq))05:20
hansfbaierstekern: yes, of course use PICMR05:21
stekernthere's actually a or1k_pic_mask_ack that clears the irq in sr and mask it05:24
stekernthat's linked to irq_mask_ack, not sure when that is used though05:25
hansfbaierstekern: Yes, but it's static05:25
stekernyes, but the pointer to it is passed to linux irq system05:26
stekernhansfbaier: 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 now05:27
hansfbaierstekern: saw it in the list. Thanks! SPI seems to work pretty well even now.05:28
stekernit'd be great if you could try that out, to get some more test coverage on it05:29
hansfbaierstekern: ok I'll pull05:29
stekernand yes, the spi driver worked fine before, it was more of a matter of its surroundings changing a bit since jonas initially wrote it05:37
hansfbaierstekern: Now I did this:05:40
hansfbaier    mtspr(SPR_PICMR, mfspr(SPR_PICMR) & ~(1UL << irq));05:40
hansfbaierand a printk there05:40
hansfbaierbut I still get the same interrupt storm:05:41
hansfbaierENC28J60 got interrupt no 2505:41
hansfbaierENC28J60 got interrupt no 2505:41
hansfbaierENC28J60 got interrupt no 2505:41
hansfbaierthe mtspr does not seem to work05:42
hansfbaierPIC.PICMR = SPR9_0 = 33555463 (0x2000407)05:42
stekern... or then the kernel unmask it somewhere05:42
hansfbaierstekern: yes it's set there hmmm05:43
hansfbaierstekern: 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
hansfbaierhmm that can't be all05:46
hansfbaiermaybe some asm05:46
stekernah, handle_level_irq() mask before calling the interript handler and unmask after05:50
stekernbut logically, that would mean that irq 25 should be masked in your enc28j60 interrupt handler, isn't that the case?05:56
stekerndoesn't change our problem, but I'm just curious06:03
hansfbaierstekern: Yes, it's masked06:04
stekernso let's change our quick and dirty fix to a little less dirty one, but in the rtl this time06:04
hansfbaier    if (mfspr(SPR_PICMR) & (1UL << irq))06:04
hansfbaier    {06:04
hansfbaier        printk("not masked\n");06:04
hansfbaier    }06:04
hansfbaierdidn't show up06:04
stekerngood, then all makes sense!06:04
hansfbaierstekern: to you ;)06:06
stekerndo something like that and connect eint25_edge to the irq input of the cpu06:07
stekernI think holding the irq line high for one clock cycle should be enough, if not, then prolong it ;)06:08
stekernhansfbaier: thanks for education me a bit in Linux irq handling code by bringing interesting problems ;)06:15
hansfbaierstekern: You are welcome :)06:23
hansfbaierstekern: I'll have to thank you....06:24
hansfbaierstekern: 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
hansfbaierlooks like I've messed something up06:26
hansfbaierstekern: stupid me06:27
hansfbaierswitched to branch master06:27
hansfbaierto pull your changes06:27
hansfbaierstekern: But you didn't change RTL, did you?06:27
hansfbaierOnly linux?06:27
stekernumm, I haven't pushed anything to my orpsocv2 repo in 2 weeks06:28
hansfbaierstekern: Ah06:28
hansfbaierstekern: so it was to linux06:29
stekernso i guess that qualifies as "didn't change RTL" =)06:29
hansfbaierI did this06:29
hansfbaierlets synth06:30
stekernoh, that's not right06:30
stekern~ and ! means the same thing for 1-bit signals06:30
stekernah, actually, maybe it's right06:31
hansfbaierstekern: Yes, but it's low active06:31
stekernbut the code is certainly confusing like that =)06:31
stekern <= that's a bit easier to read06:35
stekernrename the eint25_edge signal to eint25_nedge for bonus points06:37
hansfbaierwill do, but previous should work, shouldn't it?06:39
hansfbaierI'll try it first06:39
stekernyes, it should work06:41
hansfbaierstekern: which branch do I have to merge from?06:47
hansfbaierno that's a tag06:47
hansfbaiermaster has a lot of changes06:48
hansfbaiercompared to mine.06:48
hansfbaierI think I just download the two files and update them to my branch06:48
hansfbaierbefore giving me a headache06:48
stekernah, yeah, do that ;)06:49
stekernthe build tools you are using use commit 065bba63d70b6de4f56c75f5e3a89ac2a5d0b01f06:51
stekernso you probably want to pull from master eventually (but not in the middle of debugging this enc thing)06:52
hansfbaierstekern: hmmm got an SPI related kernel crash after copying in the new spi controller07:03
hansfbaierreverted patch, works again07:06
hansfbaierconnected network cable: no interrupt storm :)07:07
hansfbaierBut: device not found07:07
hansfbaierwait a minute...07:07
hansfbaieroh my....07:07
hansfbaierI messed something up07:07
stekernhmm, interesting, but let's not draw too much conclusions from you "backporting" it into your old tree07:12
stekernif that happens later with jonas master, then I'd be more concerned07:13
-!- enghong_ is now known as enghong07:18
hansfbaierWeird I messed something up.07:41
hansfbaierMy I2C realtime clock is gone07:41
hansfbaierand the enc28j60 does not show up07:41
hansfbaiermmc/SPI works07:41
hansfbaierreboot time07:41
hansfbaierstekern: # enc28j60: intLINK(1)08:28
hansfbaierenc28j60: enc28j60_check_link_status() PHSTAT1: 1804, PHSTAT2: 042008:28
hansfbaiernet eth0: link up - Half duplex08:28
hansfbaierstekern: but:08:31
hansfbaierstekern: ping crashes08:31
hansfbaierbut it tries to send a packet08:31
hansfbaierstekern: some progress08:32
hansfbaierejc28j60 driver is marked experimental08:32
hansfbaierBut the Link up means the Link up Interrupt was processed well08:36
hansfbaierstekern: enc28j60: enc28j60_irq_work_handler() exit08:38
hansfbaierstekern: looks like IRQ handling works08:38
hansfbaiersomehow ...08:38
stekernthat's good08:39
stekerncould of course be a chance that interrupts are being missed and stuff like that, or something completely different08:41
stekernI think our "quick and not so dirty" hack should be pretty fine08:41
olofkI've been thinking about writing an external interrupt controller that can be hooked up to a wishbone bus08:42
olofkAnd only have a single IRQ line into or1k08:42
olofkHow much extra work would that generate? I guess a driver would be required08:44
stekernolofk: we should make a new gpio core with irq support08:44
olofkThat makes sense08:44
olofkI read a rant on the CERN open hardware mailing list where a guy proposed that interrupts should be proper wishbone accesses. I quite liked that08:45
olofkLike MSI for PCI08:45
stekernI kind of get what that means, but elaborate08:46
stekernwhat does it mean that "interrupts should be proper wishbone accesses"?08:46
olofkInstead of raising an interrupt line, you implement a master interface that sends a wb write to an interrupt controlelr08:47
olofkIt's probably not very good for small systems, but it's quite nice for larger ones08:47
olofkThat mean that you can send a lot more information about the interrupt, they can be pipelined and routed easier08:48
olofkAnd you can run it off-chip without adding new pins if you already have an off-chip wishbone transport08:49
olofkNo... the last isn't necessarily true08:49
hansfbaierstekern: receiving seems to work08:52
hansfbaierstekern: but tx gives timeouts08:53
hansfbaierstekern: well08:53
hansfbaierstekern: enough for today. Thanks!08:53
stekernhansfbaier: you have to save some fun for tomorrow to, right? =)08:53
olofkOnly RX can be quite useful. NSA uses that all the time08:54
stekernolofk: 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
olofkYep. Still need one IRQ08:55
hansfbaierstekern: Yes, got to work again08:57
hansfbaiertoo much play last week ....08:57
stekernolofk: so, basically you want the PIC that we have now, but with an wishbone interface instead of an SPR interface08:58
olofkI haven't looked at the PIC to be honest08:58
stekernwell, there's that difference that all peripherals should be wb masters08:59
olofkBut I guess having an external one makes it easier to do crazy modifications, or drop it to save logic08:59
olofk(that's how MicroBlaze does it)09:00
stekernnios II too, I think09:00
olofkBut with regular IRQ lines09:00
stekernthey have some external interrupt controller09:00
olofkMight be something to consider for or2k. Might save a few pages in the spec09:01
stekernI don't see why you couldn't do that as it is today09:01
stekernit wouldn't even need any software changes09:02
olofkFor an external PIC?09:02
stekernyes, for whato you described09:03
olofkLunch time now.09:03
olofkLatch that though ;)09:03
stekernsure ;)09:03
stekernperipheral 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
stekernyou'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 bus09:08
hansfbaierolofk: Only RX with 10BaseT-HalfDuplex won't be terrible useful to the NSA ;)09:26
jeremybennettstekern: Just seen mor1kx v1.0 is now tagged.09:27
stekernjeremybennett: yup, the first of (hopefully) many great mor1kx releases ;)09:28
olofkhansfbaier: Ah.. true :)09:30
_franck_olofk: don't you think we should remove wb_utils from orpsoc-cores ?09:32
olofk_franck_: Absolutely09:32
_franck_you don't want to start to duplicate things like we used to do :)09:32
olofkstekern: I guess you're right. Still would be nice to remove it from the spec to trim it down a bit09: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
jeremybennettI see we have 9 people registered at ORCONF 2013 already.09:37
olofkI'm almost done with my intercon generator now, so once that is in place, I'll remove wb_utils09:38
olofkNo.. I'll remove wb_utils first.09:38
stekernI think that's more than we had for orconf2012 by this time09:38
olofkI'm setting up a linux VM now. What would be the smallest distribution for running icarus?09:45
hansfbaierolofk: Arch Linux :)09:46
olofkGood idea09:46
hansfbaierolofk: or debian minimal09:47
olofkAlso good idea09:47
olofkDoes arch have a package list somewhere? Want to get a feeling for how many eda tools there are available09:48
olofkLooks good09:50
knzmy de0 is shipped :)11:22
_franck_this is awesome: !!12:37
knz_franck_: nice :)12:57
stekernI get "this wbepage is not available"12:57
_franck_stekern: me too now...13:03
_franck_it's back13:05
olofkThat's a cool page13:24
olofkstekern: You should use it for the GPIO files in the kernel :)13:24
stekernI can't even reach it13:25
stekernah, now I can13:25
stekernyeah, it is cool ;)13:27
_franck_I wanted this to draw something about the bus interconnection on my de1 orpsoc ;)13:31
olofkIsn't there any non-volatile memory on de0-nano?13:48
olofkOr is it? There's some conflicting information on the terasic site13:49
stekernyes, there is 8MB of spi flash14:10
stekernso you can easily fit the fpga configuration, u-boot, dts and kernel in there14:12
stekernand a small rootfs14:13
olofkBut does it run Crysis?14:13
knzolofk: :)14:15
knzolofk: probably a 1 pixel rendering of a very small crysis scene :)14:15
stekernthat's after my gaming period, so it's irrelevant ;)14:50
knzhi all15:21
knzI understand there's some mainstream support in linux for openrisc now15:21
knzfrom 3.6 or 3.7 or something, right?15:21
knzthe question I have is: how is it possible that linux has mainstream support for openrisc, but binutils/gcc not yet?15:22
knzusually linux does not integrate support for a targt which is not yet integrated in the rest of the gnu toolchain15:22
_franck_stekern: Am I wrong here : ?15:31
stekern_franck_: I'll check when I'm on a device where I can paste from irc15:34
_franck_it's in your sdram controller, wb_port.v15: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 think15:35
stekernyes, that's a clear typo, good catch15:40
olofkknz: 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 accepted16:52
olofkI have also been told that the port that Jonas did was really well-written. That probably helped too16:53
olofkstekern: Might have hit a new bug in wb_sdram_ctrl16:58
stekernolofk: excellent! tell me about it17:03
olofkI can tell you with a VCD. Haven't analyzed it myself yet17:04
stekernactually, 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 tree17:05
stekernthat's least what I got from some mailing list mails I saw back then17:06
stekernother ports Arnd had his eyes on were the lm32 port (the one maintained by the milkymist community)17:07
stekerngoogle will probably find those mails if someone is interested ;)17:07
stekernolofk: bring it on, but there will be a couple of hours latency before I have time to look at it17:08
olofkI'll take a look at it too. Would feel good to find it myself17:10
stekernI'll keep quiet if I happen to see the problem then ;)17:34
stekernany pointers where it fails?17:34
stekern_franck_: the wb_bufram_addr was a typo, the others you changed in your patch was correct17:48
olofkstekern: 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
olofkHow 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 be18:01
olofkI'm interested in the XML stuff and differences in general from the old port18: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
olofkI liked your barebox presentation last year, but we can as well talk about GDB over a beer if you prefer that18:03
_franck_I'll try to summarize what I've done and see how it looks18:04
juliusbI'd definitely like a gdb update, with or without beer :)18:05
olofkThat would be great18:05
olofkLooking forward to see Cambridge too. I've never been to Massachusetts before18:06
olofkToo bad it's such a long flight18:06
juliusb!! :P18:07
juliusbYou're talking about ORCONF olofk ?18:07
juliusbYou missed the ", England" part of the location for the conference18:08
juliusbyou'll have to just teleconf with us from Boston, then18:08
olofkJust fax me regular updates, and I'll be fine18:09
juliusbspeaking of MA in the USA, i'm preparing my slides for OHS201318:10
juliusbthey want them by tomorrow18:10
juliusbonly just starting :-/18:10
juliusbit's only a 6 minute talk thoguh18:10
olofkThat must be the hard part, to distill it down so much18:10
juliusbI thought i'd give a 1 slide introduction to VLSI and then jump straight to the workings of the mor1kx core...18:11
olofkI still think it's kind of silly of them to only offer so short slots18:11
juliusbi'll copy-paste portions of a netlist onto a slide18:11
juliusbmaybe 4,5 slides of that18:12
juliusbI hope I won't be going too deep too fast18:12
juliusb(short talk) ah I don't mind really18:12
juliusbmean less work for me to do18:12
olofkAhh.. there's a FIFO for writes, and a RAM (cache) for reads, right?18:16
olofkIt appears as read_done is asserted before the data is read from the SDRAM18:30
stekernolofk why did you quit on me, just when I got loose from the other minor project I'm involved in, kitchen renovation19:44
--- Log closed Tue Sep 03 00:00:39 2013

Generated by 2.15.2 by Marius Gedminas - find it at!