IRC logs for #openrisc Sunday, 2014-09-21

--- Log opened Sun Sep 21 00:00:02 2014
poke53282stekern: Do you know if l.trap should be handled like l.sys?01:06
poke53282With the pc I mean. Should it point to the next instruction?01:06
poke53282At the moment I guess not01:08
poke53282according to or1ksim I am right01:38
poke53282at some point the pc in the pt_regs structure in 5h3 k34n3l is added by 4. I don't know where this happens and why.04:47
poke53282s/5h3 k34n3l/the kernel/04:48
poke53282This value should be identical to the epcr spr.04:49
sb0_stekern, do GCC's __builtin_setjmp and __builtin_longjmp work for or1k?05:20
sb0_and should we use those in misoc instead of the asm implementation?05:20
stekernsb0_: I don't think we implement those05:43
sb0_hmm... and should I expect to work?05:44
sb0_"The buffer format and the overall functioning of [] is compatible with the GCC __builtin_setjmp implementation allowing code built with the clang and GCC to interoperate" ...and I actually need similar interoperability05:47
poke53282stekern: Is there a reason for the last line?05:50
poke53282regs->pc += 405:50
stekernpoke53282: that sounds like a signal problem05:50
stekernoh.. that I don't know05:50
sb0_that's why people love ARM... and starting the 31337th open softcore won't address this issue05:52
sb0_well, I'll have a look at it05:52
poke53282is there a chance to see the history of this line in git05:52
stekernsb0_: I was answering to poke5328205:52
stekernsb0_: if you don't use __builtin_setjmp, then there's of course no difference between how llvm and gcc use setjmp/longjmp05:53
poke53282git log will do it05:53
sb0_it says that is compatible with __builtin_setjmp. doesn't say anything about custom asm implementations...05:54
stekernwell, maybe builtin_setjmp is generic then?05:56
stekerngrepping gcc, it seems only alpha, mips and pa do something special about it05:58
stekernpoke53282: git blame works fairly well05:59
poke53282Yes, I have found it. Nothing interesting. First commit from jonibo05:59
stekernpoke53282: seems like a bug to me06:00
poke53282well, I think this for returning from a a l.trap function. If you don't add 4, you will end up in a infinite loop.06:01
poke53282of course the delayed insruction is not considered here.06:01
poke53282So it's wrong anyhow.06:02
stekernwell, you should end up in an infinite loop06:02
stekernif the l.trap is still there06:02
poke53282Ok, then it's a bug.06:03
stekern...but I don't know what the kernel expects with the trap06:05
poke53282well, it's send the signal for the program. That's all.06:07
poke53282unfortunately ltrace expects a single step debugging option. I won't implement in hardware.06:10
poke53282So, the other option is to implement it in software.06:10
poke53282Considering all the jumps and delayed instructions.06:11
stekernsb0_: looks like that's generic stuff, and that it works on or1k. I tested this:
poke53282This is already 50% of the cpu emulator06:11
stekernpoke53282: oh, I think there was some single stepping code by juliusb in the kernel long ago, but jonas scraped that before upstreaming06:12
sb0_yup, I'm looking at "void test(void *b) {__builtin_setjmp(b); }" and disassembling it06:12
sb0_so far the asm code looks ok, but it is *not* compatible with the Embecosm implementation06:13
stekernno, but from the little I read about __builtin_setjmp/longjmp, I wouldn't expect it to be compatible with any libc setjmp/longjmp06:14
poke53282Hmm, would be good to find this code.06:14
poke53282Anyhow. ltrace works finally. Just two patches for the kernel, one for jor1k and two hundred code lines for ltrace.06:15
poke53282And one full day :)06:15
poke53282do you implement l.trap?06:15
stekernin mor1kx?06:15
stekernyes, that's how software breakpoints are used06:15
sb0_why does the Embecosm *jmp save/restore all registers anyway?06:16
sb0_well, most06:16
stekernsb0_: for no good reason06:16
stekernthis is enough:
sb0_already a lot, no? the __builtin_*jmp deals with fewer than that06:18
stekernmaybe __builtin_*jmp utilises information about the reg usage in the context setjmp is called from?06:19
stekernthe one that I pasted saves all the callee-saved registers06:21
sb0_according to the llvm doc: "The single parameter is a pointer to a five word buffer in which the calling context is saved. The front end places the frame pointer in the first word, and the target implementation of this intrinsic should place the destination address for a in the second word. The following three words are available for use in a target-specific manner."06:22
sb0_and I've seen elsewhere in GCC mailing lists that the __builtin_*jmp also expect a five-word buffer06:22
stekernyes, that's what I read too06:22
stekernwe just have to make a test-case that uses up all the callee-saved regs and see what the __builtin_*jmps do with that ;)06:23
stekernI mean, a test-case that clobbers the callee-saved regs06:24
poke53282looks like, this is what I need. Today implemented a few of those features which were missing.06:36
poke53282I bookmark this patch06:36
poke53282I would also say, those patches are necessary for a native gdb06:45
stekernhmmm, I have a fun thing happening in the kernel now... void f0(void) { printk("f0\n"; } void f1(void) { printk("f1\n"); f0(); } only prints 'f1'06:54
stekernthis is the actual code:
stekerndisasm gives:07:09
stekernc0323688:       15 00 00 22     l.nop 0x2207:09
stekernc032368c:       15 00 00 23     l.nop 0x2307:09
stekernmust be another dma_request_slave_channel_reason() that get used07:10
stekernmaybe some CONFIG knob that is needed for it to get compiled in07:10
stekerninstead of some stub version07:11
poke53282Is the whole code removed?07:13
poke53282or only the function in between. I think this is what you mean.07:14
poke53282Yes, looks like you have stub function there.07:14
poke53282I have decided to build a tiny sound card driver from scratch. One which sends the buffer and size to a register and the rest is done outside.07:21
poke53282Otherwise I don't think that I can solve the issues I have07:22
stekernwhat are the issues you are having?07:23
poke53282I choosed one driver which had pio as an option.07:23
poke53282But I guess this was never really tested.07:23
poke53282And I would need 1000 interrupts per second07:24
poke53282So, the this didn't work.07:24
poke53282But while trying to correct I issues I learned enough to understand everything important.07:25
poke53282So I will take the driver and remove everything unimportant.07:27
poke53282My main problem is the timing07:27
poke53282and the communicating with the different components.07:27
poke53282good sound emulating is always difficult.07:28
poke53282and if I have my own driver with my own parameters will help a lot.07:29
poke53282mount /dev/bed /home/bed; && mv -f poke /home/bed && sleep 2880007:36
sb0stekern, how can one ensure that the mor1kx store buffer is empty?10:22
sb0I've seen weird behaviour when dynamically loaded code, that mysteriously disappeared when CRCing the code before executing it. I suspect the store buffer might have something to do with that...10:23
stekernsb0: l.msync *should* ensure that, but I haven't fixed that yet. You can do a dummy load to achieve the same result though10:51
sb0to any address?10:53
PaulfraOSAADoes anybody know what happend to opencores?13:39
PaulfraOSAADid they get a ceice and decist from sony or something?13:39
sb0unsurprisingly enough, setjmp/longjmp are buggy16:15
sb0let's try the musl stuff ...16:16
PaulfraOSAAWhat is the verilog equivalent to open? I need some signals to not be attached16:45
stekernPaulfraOSAA: just ()16:46
PaulfraOSAAok, thanks. I tried it, but it still failed. Turns out i set the inputs to open too _doh_16:47
PaulfraOSAAYAY! It synthesizes :) I've added a module to an or1k core :D16:56
PaulfraOSAANow to make it output stuff16:56
stekernsb0: in what way buggy (and in what way will ARM not be, if all is generic stuff anyway?)17:07
PaulfraOSAAAdded lots of stuff to please read and comment if you have a mo' next up is doing assembly and debugging17:11
poke53282Ok, I created a reposotory with my changes to ltrace. . When I have solved two or three problems, I can give the patches to the author of ltrace.19:22
olofkstekern: I think I misunderstood you regarding the wb_intercon stuff19:49
olofkBut that looks fine with me19:51
olofkIf I have understood things right, wb_intercon.conf would still decide the maximum number of cores19:53
stekernolofk: yes, the max num of cores is still determined from wb_intercon.conf20:16
stekernpoke53282: cool!20:17
olofkstekern: I say go for it then.20:40
--- Log closed Mon Sep 22 00:00:04 2014

Generated by 2.15.2 by Marius Gedminas - find it at!