| --- Log opened Tue Jul 22 00:00:30 2014 | ||
| stekern | is ghdl still 'the shit' if you want a open source vhdl simulator? | 03:40 |
|---|---|---|
| jeremy_bennett | blueCmd: stekern: You should be basing your patch for upstream on the top of mainline branch. | 06:59 |
| jeremy_bennett | BTW are you changing anything generic, or is it purely an OR1K specific patch? | 07:00 |
| stekern | jeremy_bennett: there are no generic changes in our tree, only or1k specific ones | 07:01 |
| jeremy_bennett | stekern: That makes life a lot simpler. | 07:03 |
| jeremy_bennett | You should make sure you can report good regression test results for OR1K. Ideally no failures. If there is anything not supported it should be marked to return UNREPORTED, or possibly XFAIL | 07:07 |
| jeremy_bennett | stekern: Don't know about GHDL. I've never come across anyone who has actually used it. I get the impression of a project that is incomplete and languishing a bit | 07:08 |
| stekern | yeah, support for later revisions of VHDL seems very lacking... | 07:09 |
| stekern | it worked for a simple design I tested it with now, but I doubt it's useful for more complex stuff | 07:09 |
| stekern | but the question wasn't actually about ghdl, the question was if there are alternatives? | 07:10 |
| jeremy_bennett | stekern: The answer to that question is "no". There has been a project to put VHDL into Verilator, but it also languishes, and at a very early stage. | 08:41 |
| jeremy_bennett | The problem is that VHDL seems to be reducing in popularity, and so the motivation to support it is also dropping. | 08:41 |
| blueCmd | jeremy_bennett: for the tests that will be hard since we do not have any single fully working libc | 09:00 |
| blueCmd | but we can be as close as possible | 09:00 |
| stekern | I should probably test running it against musl | 09:16 |
| stekern | I could combine it with running it against multicore too | 09:18 |
| stekern | the only problem is that I don't have a board with networking anymore :( | 09:18 |
| stekern | I need to build that mac<->mac adapter | 09:19 |
| stekern | which is dead simple, but still some effort is needed... | 09:19 |
| blueCmd | stekern: give me a script that builds musl and I'll mod my cloud testing and run it through qemu | 09:22 |
| blueCmd | hah, I need to change qemu to use real atomics I think, hopefully that will solve the random segfaults/timeouts | 09:24 |
| maxpaln | ok, new approach today - I ran around in circles yesterday trying to track down the problem. The biggest issue is that the problem appears to occur in the middle of the recursive call to schedule() within kernel/sched/core.c - it's making triggering on the correct iteration difficult to manage. In addition, I found that the debug printk's affect how far through the code we get - which after | 09:27 |
| maxpaln | thinking about it overnight I have concluded that problem must manifest itself in some interaction between the instructions executed by printk and the rest of the code. | 09:27 |
| maxpaln | I can see that schedule_preempt_disabled() is entered and an l.jal to schedule() occurs but the return call never happens. | 09:27 |
| maxpaln | Looking through the processor manual I am trying to understand a little of how the memory is arranged - | 09:28 |
| maxpaln | Section 16.2.2 says of the Stack Frame: "In addition to registers, each function has a frame on the run-time stack." | 09:28 |
| maxpaln | So I am wondering if somewhere along the line I am getting a write to an incorrect area of memory - tracking it down is proving frustratingly complex though.... | 09:29 |
| maxpaln | [just sharing my thoughts - it seems to help :-)] | 09:29 |
| stekern | blueCmd: http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-07-20.log.html#t22:36 | 09:32 |
| stekern | or in a shorter form: | 09:34 |
| stekern | git clone git://github.com/skristiansson/musl-cross.git | 09:34 |
| stekern | ./build.sh | 09:34 |
| stekern | maxpaln: feel free to continue sharing thoughts, I do that all the time too ;) | 09:37 |
| stekern | I can give you a hint about the code you are debugging, schedule() does exactly that, schedule. | 09:40 |
| stekern | which means that the context will be switched inside that function | 09:40 |
| maxpaln | stekern: THAT's IT! If only I had that information yesterday :-P | 09:41 |
| maxpaln | ah, sorry- I jumped in with my sarcasm too early | 09:41 |
| maxpaln | [blushes] | 09:41 |
| stekern | =P | 09:42 |
| maxpaln | Yeah, I am currently wondering if the return pointer to the original schedule_preempt_disable() is corrupted | 09:43 |
| maxpaln | I am crossing my fingers the corruption happens somewhere near the start or the end - the recursion happens some 180+ times - tracking things through that is tricky to say the least!! | 09:43 |
| blueCmd | stekern: thanks, I wanted the shorter form | 09:49 |
| blueCmd | not the blog-post disquised as an email ;) | 09:50 |
| stekern | maxpaln: where is that recursive call? | 09:50 |
| maxpaln | hmmm, trying to trace it through the source code now | 09:53 |
| maxpaln | I can see it happening in the execution of the assembler - but now you've asked I guess it is possible that it isn't supposed to be recursive and that is where the problem lies... | 09:54 |
| maxpaln | let me see if I can trace it | 09:54 |
| -!- Netsplit *.net <-> *.split quits: ysionneau, ams, blueCmd, arokux, rjo | 09:54 | |
| -!- Netsplit over, joins: ysionneau, arokux, rjo | 09:55 | |
| maxpaln | Ok, I am backing away from the idea of a recursive call - it doesn't pan out in the assembler. There is a repeated call though - from within kthreadd() | 10:34 |
| maxpaln | I haven't traced the entry point for this function yet - but I have been tracing the calls to schedule() and several of them originate from within kthreadd() | 10:35 |
| maxpaln | Hmmm, back chasing my tail again.... | 10:39 |
| maxpaln | Ok, different approach - schedule() unconditionally calls __schedule() which has only one l.j r9 call - so I triggered on that and tracked all the places that this function returns to. | 11:59 |
| maxpaln | They are here: | 11:59 |
| maxpaln | http://pastie.org/private/csgkvcnjnrb8wt3c8y0oa | 11:59 |
| maxpaln | There are a lot of timeouts but I am not sure if this is indicative of another issue or just likely to happen for a limited HW profile. | 12:00 |
| maxpaln | In any case, the final return is to do_work_pending() - I am going to look closer here. | 12:00 |
| maxpaln | finally a break - do_work_pending is called only once!! | 12:03 |
| maxpaln | :-) | 12:03 |
| jeremy_bennett | blueCmd: It will be hard to persuade the GCC community to accept a port without some credible regression test results. For GCC 4.5.1 we ran both ELF and uClibc tests against Or1ksim and the ELF tests also against a Verilator model | 12:07 |
| jeremy_bennett | The speed of the model is not important - the tests are dominated by the time to compile. | 12:08 |
| jeremy_bennett | For bare metal (ELF) a minimal newlib is sufficient. For Linux, you must have a reasonable libc, or you wouldn't be able to build Linux. | 12:08 |
| blueCmd | jeremy_bennett: we have ~200 failures for the GCC test suite | 12:22 |
| maxpaln | I am found the vicinity of the problem - but the symptoms are confusing me | 12:22 |
| blueCmd | jeremy_bennett: for uclibc I think this was 85 for 4.5.1 | 12:23 |
| maxpaln | __schedule() returns to do_work_pending(), which returns via l.jr r9 to _work_pending(), then immediately onto _restore_all() | 12:26 |
| maxpaln | via l.bf | 12:26 |
| maxpaln | _restore_all appears to be proceeding on plan - then whilst starting to reload the registers from memory, EPCR changes to a seemingly random value. | 12:28 |
| maxpaln | _restore_all is at c000622c | 12:29 |
| maxpaln | EPCR changes to 0x001048a8 | 12:29 |
| maxpaln | execution of the code continues until the end of _restore_all() when l.rfe takes us to _ret_from_exception() | 12:31 |
| maxpaln | this is where things get confusing | 12:32 |
| maxpaln | the first instruction of _ret_from_exception() isn't executed (although it is fetched from memory) instead PC jumps to 0xA04 | 12:33 |
| maxpaln | when executing 0xA0C an attempt is made to read the databus from address 0x7fed3e80 | 12:34 |
| maxpaln | which is where everything hangs | 12:35 |
| maxpaln | nothing physical is at address 0x70000000 | 12:35 |
| maxpaln | I am confused by several things: EPCR getting assign 0x001048a8, the jump straight to 0xA04 instead of 0xA00, and the attempted read from the non-existent address 0x7fed3e80 | 12:36 |
| maxpaln | Interestingly, 0x001048a8 is within __jffs2_flush_wbuf() | 12:37 |
| maxpaln | and the last output from the boot process is: | 12:37 |
| maxpaln | devtmpfs: initialized | 12:38 |
| maxpaln | Switched to clocksource openrisc_timer | 12:38 |
| maxpaln | jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc. | 12:38 |
| maxpaln | But I can't see any execution of this code for at least several hundred instructions before EPCR gets asserted. | 12:39 |
| maxpaln | 0x7fed3e80 appears to originate via the penultimate instruction in _restore_all(): | 12:42 |
| maxpaln | 0x7fed3e80 | 12:42 |
| maxpaln | ooops, copy paste issue- here is the final instruction: | 12:42 |
| maxpaln | c00062c8:84 21 00 04 l.lwz r1,0x4(r1) | 12:42 |
| maxpaln | by tracking the registers I can see r1 retrieved as 0xc1219ef0 but written as 0x7fed3e80 | 12:44 |
| maxpaln | There is no memory access to retreive this value so it must be in cache somewhere! | 12:44 |
| maxpaln | I'll try triggering on 0x01219ef4 to see if this shows up anything interesting | 12:45 |
| maxpaln | [typing to yourself is strangely therapeutic!] | 12:46 |
| blueCmd | maxpaln: stekern and I do it all the time | 12:53 |
| maxpaln | :-) | 13:07 |
| stekern | maxpaln: EPCR is loaded from pt_regs in _restore_all | 13:07 |
| stekern | i.e., it is restored from memory and written to EPCR with an l.mtspr | 13:08 |
| maxpaln | aha - ok, that makes sense | 13:09 |
| maxpaln | at the point where EPCR gets set, this instruction is being executed: | 13:09 |
| maxpaln | c000624c:c0 00 18 40 l.mtspr r0,r3,0x40 | 13:09 |
| stekern | exactly, that will write EPCR with the value in r3 | 13:10 |
| maxpaln | Ok, so that explains EPCR | 13:10 |
| stekern | so, that value *should* be the value that was saved to the stack on exception entry | 13:10 |
| maxpaln | ok, well it makes sense I suppose - it is in the __jffs2_flush_wbuf() function which is the last thing that appears to be executed during Linux boot | 13:11 |
| stekern | as for the 'strange' addresses, those look like userspace addresses | 13:11 |
| stekern | especially the 0x7fed3e80 stackpointer value | 13:12 |
| maxpaln | well, I just traced all accesses to address 0x01219ef4 (the one that returned the 0x7... value | 13:12 |
| stekern | so, you should start poking around in your busybox elf for those | 13:12 |
| maxpaln | whoah - 'busybox elf' | 13:13 |
| maxpaln | I haven't come across that term before | 13:13 |
| stekern | arch/openrisc/support/initramfs/bin/busybox | 13:13 |
| maxpaln | Ah, I see - | 13:13 |
| maxpaln | I wouldn't have gotten there, but that makes sense | 13:14 |
| maxpaln | what isn't clear - is why an OR1200 Data Bus access to that address 0x7.... just hangs | 13:14 |
| maxpaln | well, actually - I say that but I can't confirm it hangs indefinitely, it definitely sits there with or1200 data bus stb asserted for several hundred clock cycles. | 13:16 |
| stekern | is that 0x7fed3e80 let out on the bus? | 13:21 |
| stekern | if so, then that's certainly not right | 13:21 |
| maxpaln | yes, the OR1200 data bus address is 0x7fed3e80 with or1200 STB asserted | 13:22 |
| maxpaln | I had just come to the same conclusion | 13:23 |
| maxpaln | Also, at the same point, the instruction bus cycles through 0xA04, 0xA08 and eventually hangs on 0xA0c | 13:24 |
| maxpaln | but these addresses make no sense - here's the assembler: | 13:24 |
| maxpaln | c0000a00:00 06 ed f0 l.j c01bc1c0 <boot_itlb_miss_handler> | 13:24 |
| maxpaln | c0000a04:15 00 00 00 l.nop 0x0 | 13:24 |
| maxpaln | ... | 13:24 |
| maxpaln | c0000b00:d4 00 f8 84 l.sw 0x84(r0),r31 | 13:24 |
| maxpaln | c0000b04:d4 00 50 7c l.sw 0x7c(r0),r10 | 13:24 |
| maxpaln | so, after a day and a half I can confirm that something has gone wrong :-) | 13:25 |
| maxpaln | I'm a bit stuck for where to go now [puzzled look] | 13:26 |
| ysionneau | off-topic, each time I look at your nickname I think about "max payne" | 13:28 |
| mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/bca908d059f9...17afdf2250c5 | 13:28 |
| mor1kx | mor1kx/master e117375 Stefan Kristiansson: cfgrs: whitespace cleanup and switch to verilog2001 module declaration | 13:28 |
| mor1kx | mor1kx/master 17afdf2 Stefan Kristiansson: add support for shadow register files... | 13:28 |
| maxpaln | ysionneau: that is not a coincidence | 13:29 |
| stekern | off-topic*2 Remedy have their office next to where I work | 13:29 |
| maxpaln | I gained the tag after a very drunk night playing some multiplayer game at a friends house - I wanted to give myself the nick name maxpayne but could only type maxpaln - it kinda stuck... | 13:29 |
| stekern | haha, that's one of the best 'how I got my nick' stories I've heard | 13:30 |
| ysionneau | nice :) | 13:31 |
| maxpaln | :-) | 13:31 |
| maxpaln | ok, any clues about how to progress - I am guessing something should be translating the virtual 0x7FED... address to a physical location | 13:35 |
| maxpaln | I think I need a break - back in 10 mins! | 13:36 |
| imphil | Announcement: the OpTiMSoC guys created a new FIFO-based communication library to encapsulate the communication between a FPGA and a host PC. It's essentially refactored and reworked code from OpTiMSoC, in the hope to make it useful for others as well. See https://github.com/TUM-LIS/glip for code & documentation. | 13:42 |
| blueCmd | after a few hours of dissecting, I found the commit that breaks ncurses, visit the bug associated with the request and find that this bug was filed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61832 | 13:43 |
| blueCmd | "r212638 breaks building ncurses" | 13:43 |
| blueCmd | so yeah, might be a point to look at bugzilla first | 13:43 |
| maxpaln | right - back in room | 13:50 |
| stekern | blueCmd: haha, been there done that... | 13:50 |
| maxpaln | so having traced all accesses to address 0x01219ef4 - there is an initial write of 0x0 in mem_set(), a write of 0x7FED3ed0 in start_thread(), a read of the same value within _syscall_resume_userspace() then 13 writes of various values and finally a read from within _ret_from_exception() | 13:54 |
| maxpaln | Given that this address is appearing on the bus I am not sure it is worth diving into the contents of the busybox binary - apart from to see what was attempting to be accessed I guess, | 13:57 |
| maxpaln | although it is not clear how to translate the virtual address to an offset in the busybox hex dump. | 13:57 |
| stekern | maxpaln: the translation should be 1:1 | 14:02 |
| stekern | i.e. the values in the hexdump is the virtual addresses (just like for the kernel) | 14:03 |
| maxpaln | Hmm, that is what I was expecting - but the address range in the busybox is 0x0 to 0x13699c | 14:04 |
| maxpaln | it doesn't get anywhere near as high as 0x7FED3ED0 | 14:04 |
| stekern | could of course that they are bogus | 14:05 |
| stekern | +be | 14:05 |
| stekern | it was just a guess from my side, 0x7FED3ED0 looked like it could be a stackpointer | 14:11 |
| maxpaln | oh, hang-on - looking through the linux dump - there is a similar notation to the busybox dump. It is for the disassembly of sections: | 14:15 |
| maxpaln | Disassembly of section .comment: | 14:16 |
| maxpaln | 00000000 <.comment>: | 14:16 |
| maxpaln | 0:47 43 43 3a l.jr r8 | 14:16 |
| maxpaln | 4:20 28 4f 70 .word 0x20284f70 | 14:16 |
| maxpaln | 8:65 6e 52 49 .word 0x656e5249 | 14:16 |
| maxpaln | c:53 43 20 33 .word 0x53432033 | 14:16 |
| maxpaln | So where is the offset for the start of the .comment section stored - I am guessing that the address in the busybox represents an offset from a base address | 14:17 |
| maxpaln | but maybe you are right - maybe it isn't in the user space... | 14:19 |
| stekern | let's rewind to one thing you said "instead PC jumps to 0xA04" | 14:21 |
| maxpaln | ok, yep | 14:23 |
| maxpaln | just retrieving the trace | 14:23 |
| stekern | imphil: nice, will have to take a closer look at that | 14:24 |
| maxpaln | ok, so the PC loads the start of _ret_from_exception() at 0x62d0 | 14:25 |
| maxpaln | then the PC sequence is: 0x62d0, 0xA04, 0xA08, 0xA0C | 14:25 |
| stekern | ok, you want to catch the exception that you are returning from there | 14:26 |
| maxpaln | ok - EPCR says this is at 0x1048a8 inside the jjfs2 function. | 14:27 |
| maxpaln | I#ll try and capture that. | 14:27 |
| stekern | isn't EPCR 0xa04? | 14:27 |
| maxpaln | sorry, confused us all - no, OR1200 Inst Bus address is 0xA04 | 14:28 |
| stekern | isn't 0x62d0 a l.rfe? | 14:28 |
| maxpaln | nope, that's the instruction before - here is the section of the assembler: | 14:29 |
| maxpaln | c00062c4:87 e1 00 7c l.lwz r31,0x7c(r1) | 14:29 |
| maxpaln | c00062c8:84 21 00 04 l.lwz r1,0x4(r1) | 14:29 |
| maxpaln | c00062cc:24 00 00 00 l.rfe | 14:29 |
| maxpaln | c00062d0 <_ret_from_exception>: | 14:29 |
| maxpaln | c00062d0:84 81 00 00 l.lwz r4,0x0(r1) | 14:29 |
| maxpaln | c00062d4:a4 64 00 01 l.andi r3,r4,0x1 | 14:29 |
| stekern | ok, but c00062d0 is never executed then (unless or1200 is buggy) | 14:30 |
| stekern | and epcr is 0xa04 | 14:30 |
| stekern | so, you want to find if you've got an exception at 0xa04 somewhere | 14:30 |
| stekern | and if that's an userspace address or kernel address | 14:30 |
| stekern | you should see that from SR and ESR | 14:31 |
| maxpaln | ok - but one point to push onto the stack is that at 0x62d0, r1=0x7FED3E80 - so the execution of that instruction would tally up with the assertion of the OR1200 data asserting STB with the address set to 0x7FED3E80 (with the crucial point that the address should have been translated from virtual to physical memory space) | 14:32 |
| jtdesousa | is it possible to use openocd with the Atlys port , or is that stil to be done? | 14:32 |
| maxpaln | but we can come back to that - I'll try and track down exception at 0xA04 | 14:32 |
| stekern | jtdesousa: that is possible | 14:33 |
| maxpaln | well, EPCR never holds the value 0xA04 | 14:34 |
| jtdesousa | thanks | 14:34 |
| stekern | ok, let's step back a bit. When the l.rfe at c00062cc is executed, what does epcr contain at that moment? | 14:35 |
| jtdesousa | is there a wiki with how I shall configure openocd before compiling it to use the Xilinx JTAG I/F ? | 14:36 |
| jtdesousa | or some document | 14:36 |
| maxpaln | just getting the trace back... | 14:38 |
| maxpaln | ok, | 14:39 |
| _franck_ | jtdesousa: http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-03-24.log.html | 14:39 |
| maxpaln | when the l.rfe is executed at c00062cc - EPCR=0x001048a8 | 14:40 |
| stekern | oh, ok... that's actually what you said before, I was just ignoring the facts | 14:41 |
| jtdesousa | _frank_: thanks | 14:42 |
| stekern | that seems all strange | 14:42 |
| stekern | l.rfe should jump to the address in EPCR, and 0x001048a8 can't in any way translate to 0xa04 | 14:43 |
| maxpaln | Agreed | 14:43 |
| stekern | so that must mean that at the same time the l.rfe is executed, there is a tlb miss | 14:43 |
| stekern | and then or1200 bugs out and increases PC by 4 or something like that | 14:44 |
| maxpaln | hmmm, maybe | 14:45 |
| stekern | what's epcr when you hit 0xa04? | 14:47 |
| maxpaln | still 0x001048a8 | 14:47 |
| stekern | just to make sure, it's 0x001048a8 at c00062c8 too, right? | 14:48 |
| maxpaln | yeah, it's been that value for a while | 14:48 |
| maxpaln | since 0x624c | 14:49 |
| maxpaln | or c0000624c | 14:49 |
| maxpaln | s/0000/000/ | 14:49 |
| stekern | right | 14:50 |
| maxpaln | after executing the l.rfe the instruction bus fetches the next four instructions as 0x62d0-0x62dc | 14:52 |
| maxpaln | then where the execution of 0xA00 should be, the OR1200 address appears as 0x62d0 | 14:52 |
| maxpaln | probably triggering the erroneous address value on the data bus address | 14:52 |
| stekern | yeah, sounds plausible | 14:53 |
| maxpaln | so somewhere in all that is a problem that prevented 0xA00 from being executed correctly. | 14:53 |
| stekern | yes, that's certainly a bug. but then there's also the question if 0x001048a8 is a valid address in the first place. | 14:54 |
| maxpaln | well, 0x001048a8 is within __jffs2_flush_wbuf - this is definitely plausible | 14:54 |
| stekern | no, that should be a virtual address | 14:54 |
| maxpaln | ah, really...... | 14:55 |
| maxpaln | is there a map of the virtual addresses somewhere? | 14:57 |
| stekern | what do you mean? | 14:58 |
| maxpaln | well, it would be good to look up the virtual address 0x001048a8 | 14:59 |
| stekern | I can answer 'yes, in the pagetables' | 14:59 |
| stekern | but not sure if I understood your question | 14:59 |
| maxpaln | OK, I wanted to look at the instruction at address 0x001048a8 but I am not sure what binary to find it in | 15:00 |
| stekern | it's either in busybox or the kernel | 15:00 |
| maxpaln | ah, ok | 15:00 |
| stekern | so, most likely not a valid address | 15:01 |
| maxpaln | it could be a busybox address: | 15:01 |
| maxpaln | 1048a4:e0 85 20 00 l.add r4,r5,r4 | 15:01 |
| maxpaln | 1048a8:d4 04 20 0c l.sw 0xc(r4),r4 | 15:01 |
| maxpaln | 1048ac:13 ff ff f9 l.bf 0x104890 | 15:01 |
| stekern | ah, ok. I thought you said that address didn't exist in busybox, but perhaps that was another address | 15:01 |
| maxpaln | ah, I meant the 0x7FED.... address | 15:02 |
| maxpaln | 0x7FED3E80 is definitely not in the busybox | 15:02 |
| stekern | yeah, but that looks like a stack address | 15:02 |
| maxpaln | which one? | 15:03 |
| stekern | 0x7FED3E80 | 15:03 |
| maxpaln | ok - I'll take your lead on that one :-) | 15:03 |
| stekern | so, if we assume that 0x1048a8 is a legal address, then the or1200 bug seems to be the cause | 15:05 |
| maxpaln | ok | 15:05 |
| stekern | it's easy to fix, switch over to mor1kx ;) | 15:05 |
| maxpaln | :-) - I will absolutely be doing that as soon as I have this working - I'd prefer to get a linux kernel booting first. | 15:05 |
| maxpaln | This particular piece of work is for a customer in Denmark. Once I have it working I am switching to more general project to get the latest ORPSOC code running on our silicon. The lessons learned here will obviously help a lot - but I am expecting a bit of work to get the latest code running (I might be wrong) and I am currently on the critical path for this customer project! | 15:07 |
| maxpaln | So rather than abandon everything I've learned on the OR1200 code I'd much prefer to get a Linux kernel booting. SO I have a couple of thoughts: | 15:08 |
| stekern | yeah, I get your standpoint. that said, mor1kx is drop-inable in your current SoC, so you could get away with pretty small changes | 15:09 |
| blueCmd | is there any reason not to use mor1kx? | 15:10 |
| blueCmd | is or1200 VHDL? | 15:10 |
| maxpaln | I guess my main concern is effort to get it in place. | 15:10 |
| maxpaln | if it really is drop-inable (nice word play :-) ) then I guess it should be pretty straight forward. | 15:11 |
| blueCmd | my experience says that the module interface is the same, so it's only a matter of instansiating it and setting the paramaters to reasonable values | 15:11 |
| maxpaln | ok, and the two are compatible with the OR32 tool flow I am using? | 15:12 |
| stekern | maxpaln: you can take a look here for a top module that can be switched between or1200 and mor1kx: https://github.com/openrisc/orpsoc-cores/blob/master/systems/de0_nano/rtl/verilog/orpsoc_top.v#L333 | 15:12 |
| stekern | (or1200 is instantiated just above that) | 15:13 |
| stekern | yes, you can run the same software | 15:13 |
| maxpaln | ok, that looks straight forward from the initial look - | 15:15 |
| maxpaln | My heart is sinking a little though - I feel like I was just a few hours from having a working build. | 15:15 |
| maxpaln | experience tells me things are never as easy as they seem :-) | 15:16 |
| stekern | maybe you still are ;) | 15:17 |
| maxpaln | on the plus side, my memory controller appears to be holding up very well :-) | 15:17 |
| maxpaln | So what's the easiest way to obtain the latest stable mor1kx? | 15:18 |
| stekern | but, while I don't care so much on a personal level, it would of course be good to get that or1200 bug fixed... | 15:18 |
| stekern | https://github.com/openrisc/mor1kx | 15:18 |
| maxpaln | well, I have some time today - I am happy to continue to investigate if you like | 15:18 |
| maxpaln | I won't be starting anything with the mor1kx until tomorrow - that sort of thing requires a fresh mind! | 15:19 |
| maxpaln | but guidance would definitely be needed - I wouldn't know where to start] | 15:22 |
| maxpaln | :-) | 15:22 |
| stekern | yeah, that's a bit of the problem, we don't really have anybody that is an expert on the or1200... so you're kind of on your own | 15:24 |
| stekern | but given the bug, poking around the rfe and exception handling code would probably be a good starter | 15:25 |
| stekern | especially looking for what would happen if an rfe and an exception happens at the same time | 15:26 |
| maxpaln | ah, ok - I see. Well, I'll have a look and see if anything jumps out at me | 15:27 |
| stekern | writing a small test case might help too, just turn on the immu in esr and rfe in an exception handler, that should cause a similar case as you're seeing | 15:28 |
| fnunes__ | Hi all, I'm trying to connect openocd to a Digilent Atlys board. I configured openocd like this: http://pastebin.com/y8zwZinM .Then issued make and all went ok. Then executing openocd like this: http://pastebin.com/i2r4ZUW4 . | 15:51 |
| stekern | so what does your ./tcl/interface/orsoc-jtag.cfg have at line 7? | 15:56 |
| stekern | this is what mine looks like: http://pastie.org/9412462 | 15:57 |
| fnunes__ | I just copied https://github.com/openrisc/openOCD/blob/master/tcl/interface/orsoc-jtag.cfg and then tried to change the interface to ftdi, but again more errors. I'll try yours. Thanks. | 15:58 |
| jtdesousa | stekern: to configure openocd is it enough like this: ./configure --enable-ftdi --enable-maintainer-mode | 16:05 |
| stekern | think so | 16:06 |
| stekern | my config.log says: ./configure --enable-ftdi --enable-usb_blaster_libftdi --enable-jtag_vpi --enable-maintainer-mode --no-create --no-recursion | 16:06 |
| fnunes__ | stekern: Recompiling openocd with those flags now. Thanks. | 16:11 |
| rah | https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_avalon_bridge/verilog/avalon_to_wb_bridge.v | 16:22 |
| rah | how come the avalon-to-wb bridge is simple compared to the reverse? | 16:23 |
| rah | s/simple/so simple/ | 16:24 |
| blueCmd | rah: 17:23 < rah> how come the avalon-to-wb bridge is simple compared to the reverse? | 16:24 |
| blueCmd | sorry | 16:24 |
| blueCmd | rah: https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_avalon_bridge/verilog/wb_to_avalon_bridge.v#L89 | 16:25 |
| rah | blueCmd: I don't understand that sentence :-) | 16:26 |
| imphil | stekern, we also have a jtag backend in the works, but that will take a bit more polishing before it's ready to be committed | 16:27 |
| blueCmd | rah: it's the whole block there that describes it | 16:28 |
| blueCmd | and it's not complicated, it simply delays the stream so that it can find out which burst mode to use | 16:28 |
| stekern | imphil: cool, I'd like to hook that up to my this thingy: https://github.com/skristiansson/diila | 16:31 |
| stekern | (among other use-cases) | 16:32 |
| -!- fnunes__ is now known as fnunes_ | 16:34 | |
| fnunes_ | stekern: The error now is: hastebin.com/hikagowufe.md . lsusb: http://pastebin.com/vU10DEA1 , orsoc-jtag-tmp.cfg: http://pastebin.com/fazUBLkw , my_or1k_generic.cfg: http://pastebin.com/jLybK4wh . | 16:36 |
| stekern | hastebin, for your quick pastes | 16:38 |
| stekern | fnunes_: the first link got screwed up ;) | 16:39 |
| fnunes_ | stekern: Sorry for that. http://hastebin.com/hikagowufe.md | 16:48 |
| stekern | haha, ok so it was right, I thought the hastebin was a typo | 16:48 |
| stekern | tried to run it as root? | 16:49 |
| fnunes_ | Nop, trying now. | 16:49 |
| fnunes_ | Same thing | 16:50 |
| stekern | your lsusb doesn't show any ftdi device though | 16:51 |
| fnunes_ | I installed digilent.adept.utilities_2.1.1-i686 and the driver for UART port (xr21v141x-lnx2.6.18-3.4.pak). All from the Atlys board page at digilentinc.com. Maybe I should other ? | 16:55 |
| fnunes_ | use | 16:55 |
| stekern | to make clear, I have only used openocd together with the atlys board by using an external jtag adapter | 16:56 |
| sb0 | hey | 16:56 |
| sb0 | any new mor1kx optimizations lately? my FPGA is full... | 16:56 |
| fnunes_ | stekern: I don't have that. | 16:57 |
| blueCmd | sb0: xD | 16:57 |
| stekern | sb0: the PIPELINE multiplier shaves a couple of luts and flops, but it kills timing :/ | 16:58 |
| fnunes_ | stekern: Maybe thats the only way. I have only seem setups online with that or the Xilinx adapter. | 16:58 |
| stekern | sb0: I think it shouldn't need to though, but I have been busy with other stuff, so I haven't got to fully investigate it | 16:59 |
| stekern | fnunes_: yeah, I don't know... it would be cool if the digilent interface could be used. unfortunately, my atlys board has broke down, so your on your own there. | 17:00 |
| stekern | sb0: this is what I'm speaking about: https://github.com/openrisc/mor1kx/commit/fe350a8b3d5acfd2a3e55320ae55d970b000619c | 17:01 |
| sb0 | "generating multiply overflows becomes cumbersome and has therefore been omitted." << you mean the overflow exception? | 17:04 |
| sb0 | btw, lm32 already has such a multiplier mechanism, right? | 17:04 |
| stekern | yes, overflow exception | 17:06 |
| stekern | and yes, I think lm32 has that kind of multiplier mechanism | 17:06 |
| sb0 | ...does anyone use overflow exceptions? | 17:07 |
| sb0 | it's an interesting feature though... | 17:08 |
| stekern | not that I know of | 17:08 |
| sb0 | oh, and shadow register files... interesting :) | 17:11 |
| stekern | yes, we'll need them for multicore | 17:11 |
| sb0 | multicore? why? | 17:12 |
| sb0 | what I can think of is low-overhead context switches and threads ... | 17:12 |
| sb0 | ok. fpga is not totally full. 94%. so it'll still work for now *g* | 17:13 |
| fnunes_ | stekern: Is it possible that openocd comunicates through the UART port ? | 17:13 |
| stekern | yes, that's their original purpose. the fast context switches are not completely supported in mor1kx yet though, but with the shadow register file it's a step in the direction of fully implementing them | 17:13 |
| sb0 | is the register file in BRAMß | 17:14 |
| sb0 | ? | 17:14 |
| stekern | for multicore, on exception entry we need scratch regs to obtain the kernel stack pointer, the problem is that there's no scratch regs defined in our ABI | 17:15 |
| stekern | so, the kernel have resorted to a hack where the regs are saved to addresses below 0x100, but that of course only works in the unicore case | 17:16 |
| stekern | (and it's ugly, so we'd like to get rid of that anyway) | 17:16 |
| blueCmd | unicorn case | 17:17 |
| stekern | so, instead we'll use the shadow register file (which can be accessed with SPRs) as a scratch reg area | 17:17 |
| stekern | the benefit is that this is all within what the spec already defines | 17:18 |
| stekern | sb0: yes, it's in BRAM, so shadow regs are pretty low cost on FPGA targets | 17:18 |
| stekern | you can of course force it into flops, but by default it's in bram | 17:19 |
| sb0 | good. | 17:19 |
| sb0 | that multiplier does remove a bit of bloat. 94% -> 88% ... | 17:38 |
| sb0 | still routing... and the timing score looks bad though... | 17:38 |
| dalias | stekern, below 0x100? so kernel still has page 0 mapped? :( | 17:55 |
| dalias | i'm pretty sure that escalates trivial kernel bugs into full kernelspace code execution bugs | 17:56 |
| stekern | dalias: no, it's with the mmu turned off | 18:03 |
| dalias | ah | 18:03 |
| blueCmd | stekern: do you know if the part where 'l.swa' is cancelled if another (non-atomic) store instruction is executed is common in other arches? | 19:46 |
| stekern | umm, doesn't it have to be? | 19:49 |
| stekern | it's of course only stores to the same location that breaks the link | 19:50 |
| dalias | i don't think non-atomic loads/stores affect ll/sc link on other archs | 19:59 |
| dalias | but i'm not 100% sure | 19:59 |
| blueCmd | stekern: I don't think it has to be, if you can say that you're only protected against other l.swa | 20:02 |
| blueCmd | what dalias said | 20:02 |
| blueCmd | that's what I get from reading the qemu code for alpha and microblaze anyway | 20:02 |
| blueCmd | sorry, alpha and arm | 20:03 |
| blueCmd | arm might support it, it's hard to see what cases actually clear it - but alpha I'm pretty sure doesn't support non-atomic "poison" | 20:04 |
| stekern | hmm, to get to that other store, you'd have to do a context switch. so it's perhaps redundant. But the same would be valid for another l.swa then too, wouldn't it? | 20:05 |
| stekern | or are you speaking across multiple cores here? | 20:06 |
| blueCmd | stekern: I'm not speaking of it in practice - just what the arch says | 20:07 |
| stekern | yes, but what the arch says about within a single core or in the multicore case then? ;) | 20:08 |
| blueCmd | it can be a tad bit expensive to implement a compare on every store in qemu | 20:09 |
| blueCmd | stekern: the alpha or or1k? | 20:09 |
| stekern | or1k | 20:09 |
| blueCmd | not sure | 20:10 |
| blueCmd | I mean, it says it uses bus snooping so that every single store to that memory violates it | 20:10 |
| blueCmd | so it's crystal clear that stores should poison the lock | 20:11 |
| blueCmd | which is very nice, but might be expensive to emulate | 20:11 |
| stekern | mmm, but maybe it's ok to cut some corners in qemu... | 20:18 |
| dalias | are you talking about stores from another core? | 20:20 |
| blueCmd | dalias: stores in general | 20:20 |
| dalias | to the locked address, or to any address? | 20:20 |
| blueCmd | dalias: locked address | 20:21 |
| blueCmd | I'm considering using cpu_watchpoint_insert | 20:21 |
| blueCmd | but that might make it harder to implement gdb support later if we want that | 20:22 |
| dalias | for qemu? | 20:22 |
| dalias | can't qemu tell that, unless an interrupt happens, there will be no accesses between the ll and sc? | 20:23 |
| dalias | just by looking at the code it's dynrec'ing | 20:23 |
| blueCmd | dalias: well, sure - but for the case when we have multiple cores that doesn't work | 20:24 |
| dalias | qemu does not emulate multicore does it? | 20:24 |
| blueCmd | It doesn't? | 20:25 |
| blueCmd | I'm pretty sure it does | 20:25 |
| dalias | iirc not. it's really hard to do so | 20:25 |
| blueCmd | -smp [cpus=]n[,maxcpus=cpus][,cores=cores][,threads=threads][,sockets=sockets] set the number of CPUs to 'n' [default=1] | 20:25 |
| dalias | but does it use real threads on the host to implement them? | 20:26 |
| dalias | maybe so | 20:26 |
| blueCmd | Ah | 20:26 |
| blueCmd | QEMU provides "-smp" option, but those virtual cpus are scheduled in | 20:26 |
| blueCmd | round-robin fashion. In other words, it's not real parallelism. I don't | 20:26 |
| blueCmd | know if there is any difference with kvm enabled. | 20:26 |
| dalias | *nod* | 20:26 |
| dalias | that makes it pretty trivial | 20:26 |
| blueCmd | Yep | 20:26 |
| stekern | I get a flashback of me asking these question the other day ;) | 20:26 |
| stekern | +s | 20:26 |
| blueCmd | stekern: pff | 20:26 |
| blueCmd | stekern: one person questioning this is nothing, two then I start to research ;) | 20:27 |
| stekern | =P | 20:27 |
| dalias | without a lot of assumptions about the host's memory architecture and whatnot i don't think there's a clean way to actually emulate smp with multiple threads | 20:27 |
| blueCmd | right. so what Alpha does is that it actually loads the value and checks if the value is unchanged as well | 20:28 |
| blueCmd | I'm not sure if that is a hack or if the spec actually does that | 20:28 |
| blueCmd | but it might be a compromise | 20:28 |
| stekern | the qemu implementation you mean? | 20:29 |
| dalias | i don't think checking if the value is unchanges is a valid check | 20:29 |
| blueCmd | yes | 20:29 |
| dalias | it's subject to ABA | 20:29 |
| stekern | yeah, me neither | 20:29 |
| blueCmd | no, but if it _has_ changed we know that another store was executed | 20:30 |
| blueCmd | it's a hack for us, sure - but it might be nice to lock down the errors | 20:30 |
| blueCmd | and it's pretty cheap | 20:30 |
| stekern | olofk: just a heads-up, I've pushed a couple of small cleanups to orpsoc-cores: https://github.com/openrisc/orpsoc-cores/commits/master | 20:40 |
| stekern | well, that's for anyone that's interested, not just olofk | 20:41 |
| dalias | this is one reason a real CAS instruction is preferable :) | 20:41 |
| stekern | it's just not very nice implementation wise in a RISC-core | 20:44 |
| blueCmd | stekern: you will not believe this, but it seems to work better with real atomics | 20:54 |
| blueCmd | or whatever, "semi-fake" | 20:55 |
| stekern | I believe! | 20:57 |
| stekern | do you have a gif for that proclamation? | 20:57 |
| blueCmd | stekern: haha you know me too well | 20:58 |
| blueCmd | I actually resisted, but if you crave it | 20:58 |
| blueCmd | https://www.youtube.com/watch?v=hAAlDoAtV7Y | 20:58 |
| stekern | =P | 21:01 |
| stekern | blueCmd: http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=f2eb7035e0600a839b997999ffee6d0e19c533c6 | 21:02 |
| blueCmd | stekern: <3 | 21:02 |
| stekern | typos in Kconfig... | 21:03 |
| blueCmd | stekern: please please do a typo and write 'on a unicorn system' | 21:03 |
| blueCmd | also, I think it's 'on a unicorn system *or* unsure' | 21:03 |
| blueCmd | I hate these guys: NETDEV WATCHDOG: eth0 (ethoc): transmit queue 0 timed out | 21:04 |
| blueCmd | and then my network dies | 21:04 |
| stekern | well, the intent is *and*, but the description sucks (even without typos) | 21:04 |
| blueCmd | oh right | 21:05 |
| blueCmd | because if you're unsure about everything then you might be on multicore | 21:05 |
| stekern | if you are on a unicorn system and sure that you have the shadow file, you'll benefit from enabling that option | 21:05 |
| stekern | multicorn | 21:06 |
| stekern | popcorn | 21:06 |
| blueCmd | 'Run Harry, run!' | 21:07 |
| blueCmd | oh, it jumped back to life (ethoc that is) | 21:07 |
| blueCmd | 64 bytes from 192.168.1.1: seq=12 ttl=64 time=1698.349 ms | 21:07 |
| blueCmd | heh | 21:07 |
| blueCmd | stekern: https://github.com/bluecmd/or1k-qemu/commit/440cca2249eead49896d7b2ba425d6e83339a694 | 21:08 |
| blueCmd | see my nice #ifdef there? | 21:10 |
| blueCmd | It's there because my system doesn't boot with that enabled ;) | 21:11 |
| stekern | hmm, why? | 21:12 |
| blueCmd | I don't know, maybe my load is wrong in qemu | 21:14 |
| stekern | we want shadowed register file in qemu too | 21:24 |
| stekern | you can cheat and just make that area read/writeable spr | 21:24 |
| stekern | *over spr | 21:25 |
| stekern | amazing, I think I actually am done with everything I wanted to finish off today | 21:30 |
| stekern | next on my todo list is to pull out the atomic insn related patches from my smp branch and see if I can attract Jonas attention with them... | 21:33 |
| olofk | stekern: Thanks for cleaning up that uart mess. I never got around to do that | 21:48 |
| --- Log closed Wed Jul 23 00:00:31 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!