| --- Log opened Tue Aug 19 00:00:13 2014 | ||
| poke53281 | sseitz: I am correcting currently a few errors in the toolchain. | 03:44 |
|---|---|---|
| poke53281 | doing it like written in the readme. | 03:44 |
| poke53281 | "make fetchtoolchain" should finally work | 04:00 |
| poke53281 | jor1k.com/or1k-toolchain.tar.bz2 | 05:00 |
| -!- stekern_ is now known as stekern | 05:16 | |
| mor1kx | [mor1kx] wallento opened pull request #15: Some small changes (master...master) https://github.com/openrisc/mor1kx/pull/15 | 12:12 |
| maxpaln | Howdy All, after a week or so of finishing off another part of this system I am now back on the mor1kx - this time until it works.. :-) | 12:32 |
| maxpaln | I think I'll invest a little time to see if I can readily debug why the current system doesn't boot - it may point to a bug in some common code that might come back and bite me later. If I start to head into a rat hole I'll bail out, switch to fusesoc and restart. | 12:33 |
| mor1kx | [mor1kx] skristiansson pushed 3 new commits to master: https://github.com/openrisc/mor1kx/compare/5090306ec02b...64bc9cb75b05 | 12:34 |
| mor1kx | mor1kx/master 3060ee3 Stefan Wallentowitz: lsu: reset state for write pending... | 12:34 |
| mor1kx | mor1kx/master 6034397 Stefan Wallentowitz: lsu: add missing signal definition... | 12:34 |
| mor1kx | mor1kx/master 64bc9cb Stefan Kristiansson: cappuccino/ctrl: do not copy FO from esr on rfe... | 12:34 |
| stekern | maxpaln: sounds like a plan =P | 12:36 |
| maxpaln | :-) | 12:36 |
| maxpaln | I have a question on the way exceptions are handled - in the OR1200 whenever I saw a change on EPCR I could monitor the Instruction bus output from the OR1200 processor and see it jump to an exception address like, say, 0xA00. This sequence doesn't appear to almost be true in the mor1kx. I have several I-TLB and D-TLB misses that follow the pattern but there are occassions when EPCR changes | 12:50 |
| maxpaln | but the instructoin bus address continues as-if no exception took place. | 12:50 |
| maxpaln | The EPCR changes that don't result in an exception address on the instruction bus appear to be virtual addresses and instead result in a series of data bus accesses to address 0x60 to 0x70 - | 12:51 |
| maxpaln | is this to be expected? | 12:51 |
| maxpaln | its probably worth noting that I am just monitoring the instruction bus address at the top level of the mor1kx - I guess it is possible the mor1kx might not update this if running from cache.... | 12:55 |
| ysionneau | maybe it's a tlb miss and the hw is updating the tlb by fetching from main memory | 12:58 |
| maxpaln | maybe, but I would expect it to jump to 0xA00 first to retreive the I-TLB miss instructions. But maybe this is where mor1kx and OR1200 differ - perhaps mor1kx can run from cache | 13:01 |
| maxpaln | without updating the top level address - on OR1200 I always saw the instruction bus address at the top level reflect the instruction being processed. Maybe I need to be monitoring a different signal to capture the actual address being executed | 13:02 |
| stekern | maxpaln: the instruction bus address most certainly does not the reflect the fetched pc when icache is enabled | 13:04 |
| maxpaln | aha, there we go - | 13:05 |
| stekern | I tend to look at pc_execute_o in mor1kx_decode_execute_cappuccino.v | 13:05 |
| maxpaln | :-) perfect | 13:05 |
| stekern | but the pc from the other stages might be interesting depending on what you're doing. but as a general 'where's the cpu now' that's the best one imo | 13:06 |
| maxpaln | yeah, I'm trying to gather several sources of info but this is useful one to capture | 13:07 |
| mor1kx | [mor1kx] wallento opened pull request #16: Multicore (multicore...multicore) https://github.com/openrisc/mor1kx/pull/16 | 13:08 |
| ysionneau | keep in mind that in OR1200 tlb is sw assisted so tlb miss implies PC to jump to exception but on mor1kx tlb is hw assisted to tlb miss => tlb refill without PC jump to exception | 13:09 |
| ysionneau | at least AFAIK by looking at OR1200 spec pdf | 13:09 |
| ysionneau | -to tlb+so tlb | 13:09 |
| maxpaln | yep, that is looking better | 13:35 |
| maxpaln | the reaction to EPCR changes is more as expected now | 13:36 |
| stekern | ysionneau: default is still sw tlb refill | 13:46 |
| ysionneau | ah ok, sorry about the noise then :) | 13:46 |
| maxpaln | :-) its all good background - | 13:46 |
| stekern | wallento: your multicore pull request made me realize I hadn't pushed my local merge | 13:53 |
| stekern | I'll do a second merge and then pick that 'extra' multicore commit with the change I suggested. does that sounds good? | 13:54 |
| stekern | wallento: done, can you take a look that I got everything right? | 14:05 |
| stekern | https://github.com/openrisc/mor1kx/commits/multicore | 14:05 |
| mor1kx | [mor1kx] skristiansson closed pull request #16: Multicore (multicore...multicore) https://github.com/openrisc/mor1kx/pull/16 | 14:13 |
| maxpaln | hmm, nothing definitive yet - but some clues. After leacing the processor for an arbitrary amount of time (to see where it ends up instead of booting linux as it should) I can see that it appears to be looping through some udelay functions. So far so normal. One of the instructions in here is a l.mul - which is also pretty normal. Except I noticed that our Map report kicks out this warning: | 15:50 |
| maxpaln | WARNING - map: i_orpsoc_top/mor1kx0/mor1kx_cpu/cappuccino.mor1kx_cpu/mor1kx_exec | 15:50 |
| maxpaln | ute_alu/un1_threestagemultiply.mul_result1_add[0:53] : removed the input | 15:50 |
| maxpaln | signal of SIGNEDCIN pin because it's not legal. | 15:50 |
| maxpaln | then a bunch of these | 15:50 |
| maxpaln | WARNING - map: i_orpsoc_top/mor1kx0/mor1kx_cpu/cappuccino.mor1kx_cpu/mor1kx_exec | 15:50 |
| maxpaln | ute_alu/un1_threestagemultiply.mul_result1_add[0:53] : A/B data pipe not | 15:50 |
| maxpaln | consistent with non-pipelined OPCODEOP0 control. | 15:50 |
| maxpaln | I am wondering if the multipler in the mor1kx hasn't mapped into our architecture very well. | 15:50 |
| stekern | hmmm | 15:54 |
| stekern | you can try with the PIPELINED or SERIAL options instead | 15:54 |
| stekern | the serial will of course be mighty slow... | 15:55 |
| stekern | maxpaln: but.. if the kernel crashes very early, it will try to call panic, which in turn call udelay, and if this happens before the timer is started... you'll delay indefinetely | 16:01 |
| stekern | you want to check this register when it's looping in udelay: https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_ticktimer.v#L72 | 16:02 |
| stekern | if it's not increasing, the delay will never end | 16:03 |
| maxpaln | aha - interesting, I will add it to my logic analyser and recheck | 16:04 |
| maxpaln | But you're point about an early crash calling panic is a good direction to follow. I'll try triggering on that... | 16:04 |
| maxpaln | aha - greate tip (my lack of Linux knowledge showing again) - a call to panic() occurs - I'll start tracing it back to see where it starts... | 16:08 |
| stekern | I think it's more my experience in having mor1kx crashing the kernel than actual Linux knowledge that put me on that track ;) | 16:23 |
| maxpaln | :-) well, it was a good tip - I think an hour or so on this tomorrow should have me narrowing it down a lot | 16:28 |
| maxpaln | I'm gonna mark that Multiplier issue for review though - something definitely isn't right there... | 16:30 |
| dalias | stekern, could you run this test for me on or1k? | 20:40 |
| dalias | printf("%zu %zu\n", _Alignof(max_align_t), sizeof(max_align_t)); | 20:40 |
| --- Log closed Wed Aug 20 00:00:15 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!