IRC logs for #openrisc Tuesday, 2014-08-19

--- Log opened Tue Aug 19 00:00:13 2014
poke53281sseitz: I am correcting currently a few errors in the toolchain.03:44
poke53281doing it like written in the readme.03:44
poke53281"make fetchtoolchain" should finally work04:00
-!- stekern_ is now known as stekern05:16
mor1kx[mor1kx] wallento opened pull request #15: Some small changes (master...master)
maxpalnHowdy 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
maxpalnI 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:
mor1kxmor1kx/master 3060ee3 Stefan Wallentowitz: lsu: reset state for write pending...12:34
mor1kxmor1kx/master 6034397 Stefan Wallentowitz: lsu: add missing signal definition...12:34
mor1kxmor1kx/master 64bc9cb Stefan Kristiansson: cappuccino/ctrl: do not copy FO from esr on rfe...12:34
stekernmaxpaln: sounds like a plan =P12:36
maxpalnI 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 changes12:50
maxpalnbut the instructoin bus address continues as-if no exception took place.12:50
maxpalnThe 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
maxpalnis this to be expected?12:51
maxpalnits 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
ysionneaumaybe it's a tlb miss and the hw is updating the tlb by fetching from main memory12:58
maxpalnmaybe, 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 cache13:01
maxpalnwithout 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 executed13:02
stekernmaxpaln: the instruction bus address most certainly does not the reflect the fetched pc when icache is enabled13:04
maxpalnaha, there we go -13:05
stekernI tend to look at pc_execute_o in mor1kx_decode_execute_cappuccino.v13:05
maxpaln:-) perfect13:05
stekernbut 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 imo13:06
maxpalnyeah, I'm trying to gather several sources of info but this is useful one to capture13:07
mor1kx[mor1kx] wallento opened pull request #16: Multicore (multicore...multicore)
ysionneaukeep 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 exception13:09
ysionneauat least AFAIK by looking at OR1200 spec pdf13:09
ysionneau-to tlb+so tlb13:09
maxpalnyep, that is looking better13:35
maxpalnthe reaction to EPCR changes is more as expected now13:36
stekernysionneau: default is still sw tlb refill13:46
ysionneauah ok, sorry about the noise then :)13:46
maxpaln:-) its all good background -13:46
stekernwallento: your multicore pull request made me realize I hadn't pushed my local merge13:53
stekernI'll do a second merge and then pick that 'extra' multicore commit with the change I suggested. does that sounds good?13:54
stekernwallento: done, can you take a look that I got everything right?14:05
mor1kx[mor1kx] skristiansson closed pull request #16: Multicore (multicore...multicore)
maxpalnhmm, 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
maxpalnWARNING - map: i_orpsoc_top/mor1kx0/mor1kx_cpu/cappuccino.mor1kx_cpu/mor1kx_exec15:50
maxpaln     ute_alu/un1_threestagemultiply.mul_result1_add[0:53] : removed the input15:50
maxpaln     signal of SIGNEDCIN pin because it's not legal.15:50
maxpalnthen a bunch of these15:50
maxpalnWARNING - map: i_orpsoc_top/mor1kx0/mor1kx_cpu/cappuccino.mor1kx_cpu/mor1kx_exec15:50
maxpaln     ute_alu/un1_threestagemultiply.mul_result1_add[0:53] : A/B data pipe not15:50
maxpaln     consistent with non-pipelined OPCODEOP0 control.15:50
maxpalnI am wondering if the multipler in the mor1kx hasn't mapped into our architecture very well.15:50
stekernyou can try with the PIPELINED or SERIAL options instead15:54
stekernthe serial will of course be mighty slow...15:55
stekernmaxpaln: 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 indefinetely16:01
stekernyou want to check this register when it's looping in udelay:
stekernif it's not increasing, the delay will never end16:03
maxpalnaha - interesting, I will add it to my logic analyser and recheck16:04
maxpalnBut you're point about an early crash calling panic is a good direction to follow. I'll try triggering on that...16:04
maxpalnaha - 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
stekernI 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 lot16:28
maxpalnI'm gonna mark that Multiplier issue for review though - something definitely isn't right there...16:30
daliasstekern, could you run this test for me on or1k?20:40
daliasprintf("%zu %zu\n", _Alignof(max_align_t), sizeof(max_align_t));20:40
--- Log closed Wed Aug 20 00:00:15 2014

Generated by 2.15.2 by Marius Gedminas - find it at!