IRC logs for #openrisc Monday, 2014-07-07

--- Log opened Mon Jul 07 00:00:08 2014
daliasstekern, any test results? :)03:08
daliasstekern, i take it r10 is the thread-pointer register for the or1k abi?03:14
stekerndalias: not yet, I was busy with other stuff in my TODO pipeline yesterday03:29
daliasno problem03:30
stekernyes, r10 is the thread-pointer register03:30
daliasah r11 is return value. that's what was confusing me :)03:30
daliasyour thread asm commits look right then, from a non-or1k-expert perspective anyway03:31
stekernyup, abi is: r1=sp, r2=fp, r3-r8=arg, r9=lr, r10=tp, r11 (and r12)=return values, r16=GOT pointer03:32
dalias*nod* i found the docs now03:41
stekerngreat, thanks for taking a look at it03:42
daliasbtw is the stuff about variadic arguments never being in registers still true?03:42
daliasfun :)03:43
stekernit sucks03:43
daliasit's more efficient, but hell when idiots call variadic functions without prototypes03:43
dalias(e.g. most hello world programs)03:43
stekernwe've had a couple of discussions about maybe changing it, but breaking the ABI isn't all that fun ;)03:44
daliasare stack slots left for the args that were passed in registers, like mips abi?03:44
daliasthat's really ugly and inefficient (and error-prone when writing asm by hand), but it would allow you to solve the variadic problem cleanly03:45
stekernwe had some problems with gcc calling variadic functions with different prototypes03:45
stekernno, the stack slots start at the beginning of the stack03:46
stekernthat came out weird03:47
daliasso calling a function with <7 args has no requirement for the caller to do anything with the stack?03:47
stekernI mean, we don't reserve stack slots for the reg args03:47
daliasif you did it the mips way, gcc could just store the arguments both on the stack AND in registers when the prototype was missing03:48
stekernyeah, I know. but if we'd change it, I'd rather just change it to treat variadic functions like normal functions.03:49
stekernI don't like that reserve stack slots for regs ABI, I've been dabbling with another open source cpu that does that (eco32) and I found it annoying.03:51
daliasoh of course03:51
daliasthe mips way is idiotic and defeats the purpose of pass-by-register03:51
daliasbecause you still have to do nasty stack manipulations to make a call03:51
daliasi just meant if it were already that way, you could work around the problem without changing the ABI03:52
stekernah, yeah03:53
daliasbtw i wouldn't bother changing it. x86_64 already has subtle breakage if you call variadic functions as non-variadic03:53
daliasthey require %al to have the # of sse arg registers used03:53
daliasand if %al contains junk, the callee will jump to random addresses due to the way the prologue code works.....03:54
daliasgcc always zeros %al when you call a function with no prototype at all03:54
daliasbut we've found broken code (iirc in glib) that called variadic functions (open) via a non-variadic function pointer03:54
daliasand of course this broke horribly03:55
daliasso imo such code just needs to be caught and fixed03:55
stekernmmm, I think we've pretty much decided to not change it, and instead go on a crusade to find offenders03:55
stekerndalias: gcc used to do that to...03:55
daliasdo what?03:55
daliascalling variadic functions via non-variadic function pointers?03:56
stekernah, didn't read what you wrote properly. not exactly that but almost.03:56
stekerngcc defined the function as void func(int, ...){} in one file and then declared it as void func(int, int, int); in another03:58
stekernbut, that's fixed now03:58
daliasyeah that's basically the same03:59
stekernthere's other projects out there with bugs like that (directfb iirc)03:59
daliaswell like i said they're very dangerous on x86_6403:59
daliasso they need to be fixed03:59
daliason x86_64, gcc really generates variadic prologue that jumps to a negative offset based on scaling %al04:00
daliasso if the caller does not know it's variadic, %al contains junk and you jump to random code that happens to be before the start of the function04:01
daliasthis should probably be considered a security bug in gcc04:01
daliasbecause they could easily avoid it by applying a single AND instruction to %al to bound its range04:01
daliasdoes the musl port have all of the port files now, and just need checking/testing?04:16
daliasor are there still missing things?04:16
stekerndalias: I think so, unless I missed something05:01
stekernthere's still the inefficient setjmp implementation05:02
daliasif some basic testing shows it working, i think we can commit upstream and do further work in the main tree05:11
stekernsounds good to m05:13
daliasbtw i have in mind some 'gratuitous' renamings of some files that i kinda want to do, which affect ports. not sure whether to do these before or after committing or1k.05:18
daliasthings like clone.[cs] -> __clone.[cs], syscall.[cs] -> __syscall.[cs], etc.05:18
dalias(part of the goal being consistency; the other part being avoiding having multiple files with the same name in libc.a which makes debugging confusing05:18
stekerndalias: makes sense, syncing that out of tree wouldn't be very painful though, so do as you feel fit05:59
maxpalnHi - hope you are all well!!08:43
maxpalnSome good news - I have the ORSOC working on our latest silicon - ECP5 :-)08:43
maxpalnand or factory seems to be taking significant interest in promoting the solution too :-)08:43
maxpalnHowever, in more serious news - I have a problem trying to run or32-elf-sim on a Linux kernel I have built08:44
maxpalnI am getting a 'KERNEL: Bus error (SIGBUS) 0xbc058004' error08:44
maxpalnI suspect this is something to do with the settings in my dts file (I have gone back and reused a known good .config file to build the kernel but I am still getting the error)08:45
maxpalnDoes anyone have a bit of knowledge about the Linux boot process to point me in the right direction for my debug...08:46
maxpalnI'll share a link to the linux boot log ... just a second.08:46
maxpalnHere it is08:48
maxpalnAnd in case it is helpful, here is the dts file08:49
stekernwb maxpaln08:55
stekernlong time no see, and good news08:56
stekernit's trying to access some device that you don't have in your SoC (well, virtual SoC, since it's or1ksim)08:58
maxpalnit is a long time - I've been debugging our new silicon with the customer I am developing the ORSOC solution for08:58
maxpalnit is has been a long 3 months!!08:58
stekernorPsoc, orsoc is still a company ;)08:59
maxpalnthanks for your tip - so, without knowing too much about the linux boot process08:59
maxpalnAh, well pointed out!08:59
stekernmy guess is the spi stuff, IIRC there's no spi emulation in or1ksim08:59
maxpalnActually, that is a good point - I had noticed the references to both (orsoc and ORPSOC) and had never really put two and two together09:00
maxpalnSO I should look at the SPI Stuff in the DTS file?09:00
stekerntry to just comment it out and see if the kernel boots then09:00
maxpalnok, good tip09:00
maxpalnnope, that's not it09:17
maxpalnout of interest, I am assuming or1ksim is using the DTS file at arch/openrisc/boot/dts/or1ksim.dts - is that correct?09:17
maxpalnif not I've been editing the wrong file09:18
maxpalnhmmm, this is confusing09:19
maxpalnI went to back to what I thought was a working .config and .dts file - but the crash still occurs09:19
stekernit depends on your config, and since you are (most likely) using a builtin dts, you need to recompile the kernel after you change things in the .dts09:20
maxpalnaha - there you go!09:20
maxpalnback to school again09:20
maxpalnso, change the dts, recompile Linux, then sim09:20
maxpalngo it09:20
ysionneau10:43 < maxpaln> Some good news - I have the ORSOC working on our latest silicon - ECP5 :-) < you made an ASIC out of openrisc core?09:25
stekernysionneau: it's a Lattice FPGA09:25
ysionneauah no I got it, you work for lattice ?09:25
maxpalnYes, that's correct09:26
ysionneauand you just tested orpsoc on the latest fpga silicon09:26
ysionneauok :)09:26
maxpalnyes, although there was a fair bit of work involved in getting the DDR3 memory controller to work09:26
ysionneaumaxpaln: is there still development on LatticeMico32 CPU at lattice?09:26
ysionneaujust out of curiosity09:26
maxpalnyes, although mainly maintenance rather than active development09:31
maxpalnit is still part of many of our solutions -09:31
maxpalnwhen we need a processor the Mico32 is the one we use - but the roadmap, which did include things like multi-cores, broader feature set etc. has been scaled back09:32
ysionneauah too bad09:33
maxpalnwell, the processor is very stable and was developed to a very useable level09:33
maxpalnBut the direction for this sort of area is very much up in the air at the moment09:33
maxpalnThe SOC devices from Altera and Xilinx are interesting - but customer feedback is mixed.09:34
blueCmdI'm going to build a wb-slave <-> wb-master bridge over 8 pins to carry wishbone over to another FPGA09:34
blueCmdwill I have a bad time?09:34
maxpalnHow will you be getting from one FPGA to another - ribbon cable or on the PCB? The phase relationship on the clocks between the two FPGAs will need to be managed, it will also vary over PVT09:39
maxpalnmeanwhile, on my linux problem - I am still getting the crash,09:40
maxpalnAs a sanity check I went back to what I believe to be a known good pair of DTS file and .config - but the crash still occurs09:40
maxpalnso I am wondering what other variables exist that I have somehow broken09:41
maxpalnthe ork1sim command line includes a reference to a .cfg fileL09:42
maxpalnor32-elf-sim -f arch/openrisc/or1ksim.cfg vmlinux09:42
blueCmdmaxpaln: ribbon cable if I can get that to work09:42
maxpalnI don't remember creating (or editing) this file - and it is dated from December of last year09:42
maxpalncould there be something out of date or somehow incompatible here?09:43
blueCmdor32-elf-sim is a weird name09:43
maxpalnreally? I found it in the docs somewhere09:43
blueCmdmaybe that is how it's supposed to be named, but it's always just 'sim' for me09:43
maxpalnah, maybe you have an alias09:43
blueCmdno, it's in /usr/loca/bin/sim09:44
blueCmd./configure on or1ksim repository will net you a 'sim' binary09:44
stekernblueCmd: you can configure or1ksim with a --target option09:44
blueCmdstekern: ah09:44
maxpalnyeah, this definitely worked before so I don't think I have anything misconfigured09:45
maxpalnbut I take your point09:45
blueCmdwhat is the crash?09:46
stekernmaxpaln: can you show your 'known-to-be-good' .dts09:46
maxpalnblueCmd: the latest one is here:09:47
maxpalnthe latest dts I am using is here:09:47
blueCmdmaxpaln: actually I'm thinking of using a lattice FPGA to my wb issues. my scenario is that I have an FPGA board with only 8 GPIOs. I need to extend it to include sdcard, ethernet and RTC, and possibly more. So I'm thinking of having a ribbon cable to a lattice FPGA and let it be a 'wb expander'09:47
maxpalndts file
blueCmdmaxpaln: check the memory size in or1ksim.cfg I would say09:48
stekernbut you still have the spi and flash stuff in there09:48
stekernremove everything below the enet0 node09:49
maxpalnblueCmd: The ribbon cable won't be a problem per-se but between the FPGA IOs, the PCB trace, the connectors and the cable itself you'll want to keep the clock rate pretty low - in the order of single figure MHz is a good plan to start with.09:49
maxpalnAh, yes - I removed the SPI stuff, tested it and saw the fail, then reverted to the 'known good one'09:50
maxpalnlet me remove the SPI stuff again and rerun09:50
maxpalnblueCmd: that is assuming you will be sending the clock as one of the 8 wires09:51
maxpalnstekern: - yes, that is it! :-)09:52
maxpalnso, let me now try the 'new' dts without the SPI09:52
blueCmdmaxpaln: right, I'm thinking of sending a single ended clock yes.09:54
maxpalnblueCmd: OK, so getting the bus will be bi-directional but only the master will send the clock. If that is right the biggest delay will be when the Slave sends data backl to the master, the clock used by the Slave will be phase shifted from the Master, then the data arriving at the Master will be phase shifted from the Slave. This combined phase shift or delay will be your biggest factor in09:57
maxpalndetermining throughput09:57
maxpaln(and probably your biggest headache in terms of getting a reliable interface)09:59
blueCmdmaxpaln: what if I made a small board with an FPGA that plugged straight on the pin header and then used a real XCVR to transfer the data over a sata cable or something? would that be significantly better?10:01
blueCmdprobably going to go with the ribbon first, but I'm trying to figure out my alternatives10:01
maxpalnwell, the signal quality is only part of the issue - and slowing the clock would probably negate those effects. A pure PCB based solution would help here - it would allow you to get to higher data rates.10:02
maxpalnbut I would say you need to give consideration to what is essentially the PHY layer of the interface10:03
maxpalnThere are not many source synchronous bi-directional busses - probably for the above reason.10:03
stekernsb0: how do I generate the misoc timing report?10:03
maxpalnIt would be more common for the Transmit device to send a clock with the data - in your case you only have one clock master, and the clock relationship between the slave and master will be unknown.10:04
blueCmdmaxpaln: I can make it MISO/MOSI style if that helps me increase the clock rate, but then I'm down to 3 pins in each direction10:05
stekernor rather, can I get it to generate it, or do I have to run that Xilinx tool (whatever its name was now again) manually?10:05
stekerntrce I think10:05
maxpalnyeah, I was thinking about that - 3-pins either direction is dull, but easier.10:05
maxpalnwhat about making the whole bus bi-directional10:06
maxpalnthat way both slave and master can send the clock10:06
blueCmdstekern: in vivado you do 'check_timing' and/or 'report_timing_summary'10:06
blueCmdmaybe grep for that in the code10:06
blueCmdmaxpaln: hm, interesting10:07
maxpalnblueCmd: it would be usual in this sort of scenario to either send the data centre aligned to the clock, or send it edge aligned as normal and in the receiving device clock the data in on the opporite (probably falling) edge of the clock. This would give you half a clock cycle of margin to allow for the ribbon cable or PCB delays.10:12
blueCmdmaxpaln: so why cant I just clock twice as fast for the same effect? signal quality?10:17
blueCmdbasically what you're proposing is DDR right?10:18
maxpalnNot really - you are clocking at a single data rate10:18
maxpalnthink of it the other way around, you clock the data out on the riding edge of the clock - so the data gets sent aligned to the rising edge of the clock10:19
maxpalnIn the receiving device you also clock the data on the rising edge of the clock10:19
maxpalnIn this scenario, there is virtually no margin for the receiving device10:20
maxpalnthe data transition will occur virtually simultaneously to the clock edge10:20
maxpalnsetup and hold times will almost certainly be violated10:21
maxpalnthis can readily be solved by clocking the data into the device on the falling edge10:21
maxpalnnow you have half a clock cycle of margin to meet setup and hold times10:21
maxpalnyou can then clock the data on the rising edge of the second register inside the receiving device - you would need to add a half clock cycle constraint to this path to ensure timing is met10:22
maxpalnconversely, you can send the data sligned to the centre of the clock - then the receiving device can carry on as normal and use the rising edge of the clock to latch the incoming data.10:23
maxpalnthis sort of thing is at least part art and not 100% science10:24
maxpalnyou can calculate the clock to out of the transmit device (and FPGA tool will tell you this in the timing report) and the input setup of the receiving device.10:25
maxpalnthis will give you part of the delay - but the time to get across everything in between depends on a lot of factors.10:25
maxpalnOne to send your way now: the or1ksim of the new dts without SPI works fine10:34
maxpalnI have loaded this into HW to try and get some UART output during the Linux boot -10:35
maxpalnbut the boot fails - I get epcr asserted during the instruction read process10:35
maxpalnthe wierd thing is that I don't get a correspending wishbone err signal asserted at the same tim4e10:35
maxpalnso I am not sure what it causing the exception10:36
maxpalnany thoughts on how to debug?10:36
maxpalnas a bit of background, I have a simple 'Hello World' program that sends data out over the UART to my PC10:36
maxpalnthis works fine - so I know the processor is working, or at least ib this simple test it works10:37
maxpalnand the UART successfully sends data10:37
maxpalnwhen I boot from Linux I am using the embedded logic analyser to monitor the EPCR signal and the wisbone error signals at the top level -10:37
maxpalnoh, hang-on might have a clue10:38
maxpalnafter the exception it jumps to address 0xA0010:38
maxpalnaha - this is a I-TLB Miss10:39
maxpaln[My run of progress might have stalled]10:40
stekernitlb misses are fairly normal ;)10:41
ysionneauitlb miss raise an exception? I thought there was a hardware page-tree walker :o10:41
maxpalnah, ok :-)10:41
* ysionneau should one day read the openrisc manual10:41
maxpaln:-) I am reading it now10:41
stekernysionneau: it's optional10:42
ysionneauah ok10:42
maxpalnso, in my case: the assertion of the EPCR for the ITLB miss10:42
stekernand or1200 (which maxpaln is using, right?) doesn't have a hw tlb refiller even10:42
maxpalnis this a terminal thing?10:43
stekernand the default mor1kx setup has it disabled too10:43
ysionneauah or1200 right10:43
maxpalnYes, OR1200 for my - I guess what I'd like to know is whether this would prevent Linux from booting10:43
maxpalnor is the cause elsewhere10:43
stekernand there is no support for hw tlb refill in vanilla openrisc Linux10:44
stekernmaxpaln: it wouldn't, you're problem is most likely somewhere else10:44
maxpalnok, thanks - although I feel I amback looking for the needle again :-010:45
maxpalnone question, how does the or1ksim process know about the HW configuration of the processor - i.e. what capabilities exist in the actual Verilog of the processor?10:45
stekernit doesn't10:46
maxpalnah, ok10:46
stekernyou have to configure it manually (with the or1ksim.cfg file)10:46
maxpalnaha - ok10:46
maxpalnso maybe I'll check my or1ksim.cfg to ensure it matches HW - maybe there is a clue there10:47
blueCmdmaxpaln: thanks for the explaination, makes sense.10:53
maxpalnblueCmd: No probs!10:55
maxpalnOk, I have my confused hat on now -11:09
maxpalnI am trigger on a memory instruction bus read from address 0x100 - my assumption is this should happen once when the ROM bootloader jumps there after loading from SPI11:10
maxpalnBut I am seeing this event happen every 5 seconds or so11:11
maxpalnI am guessing that somewhere during the Linux boot sequence the processor somehow manages to get reset and start loading from address 0x10011:12
maxpalnI don't get any UART output so the kernel didn't get that far...11:13
maxpalnI don't get any wishbone error signals asserted (I am also looking for this event in the ILA)11:14
mor1kx[mor1kx] skristiansson pushed 1 new commit to master:
mor1kxmor1kx/master fe350a8 Stefan Kristiansson: alu: add alternative non-stall "PIPELINED" mul impementation...11:14
stekern^ gives about a 4% boost in coremark benchmarks (1.86 vs 1.79 coremark/MHz)11:15
ysionneaunice :)11:16
stekern+ it takes less resources11:16
stekerncon: timing goes down the drain a bit :(11:16
stekernhave to take a closer look at that later, maybe it's solvable11:17
maxpalnok, need to think about this one - it appears that when the ROM causes the processor jump to address 0x100 (after loading from SPI Flash into RAM) the processor just starts loading the data from SPI into RAM again. It is as if the instructions at RAM address 0x100 now contain the ROM bootloader code. Very odd!!11:30
ysionneaumaybe a cache issue?11:31
ysionneautry invalidating the I cache before jumping to RAM?11:31
maxpalnwhat's the best way to do that?11:32
maxpalnsounds plausible though - the last time I had Linux running was when I was using my old DDR3 controller which (due to some very dodgy wishbone coding) didn't support wrap-bursts. In turn this required me to disable the cache's.11:34
maxpalnSo I have never had Linux running with Cache's enabled.11:34
maxpalnI wouldn't know how to invalidate the cache though - bit of a newbie...11:35
ysionneauI don't know much about openrisc sorry that was just a "try this maybe" advice :)11:35
maxpaln:-) fair enough11:35
ysionneaubut from the description you are giving it sounded like an I-cache issue11:35
maxpalnfair enough11:35
ysionneaumaybe have a look at 9.2.7 Instruction Cache Block Invalidate11:36
maxpaln:-) - I was looking through the docs and had got to 8.2.x ... good spot...11:36
stekerneasier is probably to just disable cache before jumping to RAM11:37
stekernon reset it should be disabled too11:38
ysionneauthere is no instruction to flush all the cache?11:38
stekernand Linux invalidates the caches before turning them on11:38
ysionneauyou need to loop and invalidate line by line?11:38
maxpalnhow do you disable the cache dynamically like that?11:39
stekernI rather have that then (only) a flush all11:39
stekernand flush all is more expensive in terms of hw11:39
maxpalnaha, its a bit in the supervision register11:39
ysionneaustekern: sure you need a FSM for that :/11:40
stekernyup, and if you lack more precise invalidating/flush, it's a performance killer11:41
ysionneaufor DMA and stuff like that yes11:44
chan1hello, I hope somebody could briefly consider what's wrong with my compling uClibc and give me an advice.13:00
chan1I am following (Building by Hand! part) and have error during 'Compile uClibc'13:00
chan1I configured for or32 and defconfig and ran make with PREFIX=${SYSROOT} but it gives me an error below13:00
chan1  CC libpthread/linuxthreads.old/attr.o13:00
chan1In file included from libpthread/linuxthreads.old/internals.h:30:0,13:00
chan1                 from libpthread/linuxthreads.old/attr.c:26:13:00
chan1./libpthread/linuxthreads.old/sysdeps/or32/pt-machine.h: In function 'testandset':13:00
chan1./libpthread/linuxthreads.old/sysdeps/or32/pt-machine.h:41:8: error: '__NR_or1k_atomic' undeclared (first use in this function)13:00
chan1./libpthread/linuxthreads.old/sysdeps/or32/pt-machine.h:41:8: note: each undeclared identifier is reported only once for each function it appears in13:00
chan1In file included from libpthread/linuxthreads.old/../linuxthreads.old_db/proc_service.h:20:0,13:00
chan1                 from libpthread/linuxthreads.old/../linuxthreads.old_db/thread_dbP.h:9,13:00
chan1                 from libpthread/linuxthreads.old/internals.h:32,13:00
chan1                 from libpthread/linuxthreads.old/attr.c:26:13:00
maxpalnok, more clues13:08
maxpalnit seems that during the boot from RAM the processor jumps back to the ROM code13:09
maxpalnThe sequence transitions as expected: Reset to ROM address, load from SPI Flash to RAM, jump to address 0x100 and boot processor,13:10
maxpalnhowever, after about 10th of the Linux code the process jumps back to the ROM13:11
maxpalnit coincides with an exception that EPCR reports at address 0xC0004B1413:12
maxpalnsomething strange is happening here....13:18
stekernchan1: I don't know what's causing your issue, but you might want to consider using the more up-to-date or1k- toolchain13:22
maxpalnstekern: agreed - in fact once I am able to deliver a working Linux build to my customer I will be making it a priority to get up to date with the latest stable build of everything.13:22
maxpalnHaving come so far (and frankly so close) on the current versions, I am hoping it won't be too difficult to get something running.13:23
maxpalnbut as always, the final step is the hardest...13:23
stekernmaxpaln: I wasn't speaking to you ;)13:26
maxpalnstekern: ah, I missed that - although your advice is still valid :-)13:27
stekernyup, but out of place for your current issue =P13:27
maxpalnok, in general terms, is there any reason (other than a reset) for the processor to jump back to the boot address in the ROM code?13:29
stekernmaxpaln: what is at 0xc0004b1413:29
maxpalnI am looking but not seeing one13:29
maxpalnnothing! I don't have any peripherals at 0xC.....13:29
maxpalnI thought that might be a reserved address for cache or something13:29
sb0stekern, manually with trce13:35
maxpalnOk, I have just noticed that after the exception the Instruction address jumps to 0xF0000B0013:36
maxpalnLooking at the ROM code it uses a narrow address bus so it just sees 0x0013:38
maxpalnbut the real question is why the exception causes a jump to an address at 0xF....13:38
maxpalnif this was meant to be 0x00000B00 then this would be a Range exception -13:39
maxpalnbut the questoin about 0xF... still stands13:39
stekernis the EPH bit set?13:40
stekernsb0: ok, I figured that when I couldn't find any trace of it in the source13:41
maxpalnHmmm, I aren't capturing the Supervision Register right now - I'll need to add it to the ILA13:42
maxpalnah, I see your thinking though13:43
maxpaln(he says catching up with RTFM'ing :-) )13:43
maxpalnI will start a new FPGA build to capture the supervision register - (any clues where I might find it)13:44
stekernin or1200? no idea13:44
maxpalnyeah, just searching there now - I'll find it soon nough13:45
maxpalnIn case I need to find it again int he future: or1200_sprs.v13:48
maxpalnwell, that has confirmed that EPH is set- in fact it gets set just before EPCR changes to 0xC0004B14.14:26
maxpalnHere is a screen grab of the EPCR and SR bits from the logic analyser14:29
maxpalnSo I have somehow triggered a range exception - that has in turn set the EPH bit!14:30
maxpalnI should go to Las Vegas - I've managed to get a full set!14:37
maxpalnEvery bit of SR is set at the point of the EPCR changing - although DSX adn OV are only asserted for what appears to be 1 or two clock cycles.14:39
maxpalnSo I have some sort of range exception but while processing the exception the EPH flag causes the processor to execute ROM code instead of the actual exception code.14:40
maxpaln[really confused now]14:40
blueCmdmaxpaln: having a look at the board it looks like I can group at least 6 of the 8 pins in 3 pcs of diff pairs15:23
blueCmdwould that help?15:24
maxpalnDifferential pairs would help avoid additive noise to the signals as they transition through the ribbon cable or PCB. But I think this isn't going to be your main concern -15:25
maxpalnonce you can cleanly latch the data into the receiving device you'll be in safe territory15:25
maxpalnFor example, in the Lattice SW (IPexpress) you can create an IO interface that will provide you with an edge aligned or centre aligned clock/data relationship. I suspect the other FPGA tools provide the same. This makes your life easier since you don't need to design the interface yourself - but it has the disadvantage of being device specific...15:27
blueCmdmaxpaln: what is it called for lattice?15:33
maxpalnthe tool? IPexpress - you can find it from the Tools menu within Diamond or from the Accessories subfolder on the Start Menu15:33
blueCmdmaxpaln: nah, the construct15:35
maxpalnthe construct?15:39
blueCmdfor clock centered alignment15:39
blueCmdi.e how would you do it for lattice?15:39
maxpalnah, you need to create it within the IPexpress tool - you specify the parameters of the interface (bus width, frequency, IO standard etc.)15:40
maxpalnit generates you a VHDL or Verilog module that you instantiate in your design.15:40
maxpalnWhen you select SDR from the Architecture_Modules/IO folder you can choose 'clock inversion' to use the opposite edge of the system clock.15:41
stekernmaxpaln: I think you have a wild write to SR at 0xc0004b14 (or the instruction before that), my guess is that the reason you get the range exception is that the OV bit is getting set.15:43
stekernby that wild write I mean15:44
maxpalnHmmm - I was just reading through the exception model to familiarise myself with it15:44
maxpalnSo, I am assuming address 0xC... is the cache or some other internal CPU feature, since I don't have an explicit peripheral at that address.15:45
maxpalnweirdly, immediately prior to the exception the CPU is accessing the memory data bus not the exception bus15:46
maxpalnbut assuming your hunch is right (and I think you have a 100% hit rate so far - so it's a good assumption)15:47
maxpalnI am still not sure how to fix this - if fix is the right word15:47
maxpalnOk, so the overflow flag is a fairly regular occurence - or at least shouldn't be fatal.15:52
maxpalnbut why EPH gets set is a mystery...15:52
blueCmdmaxpaln: Bidirection diff. clk, 2x bidirectional DDR, master/slave select pin controlled by master, high impedance on not-active side.15:53
blueCmdwould that work?15:54
stekernmaxpaln: 0xc... is a virtual address15:54
stekernLinux uses that for the kernel15:54
blueCmd(sorry for picking your brains on this, I'm quite facinated about this :P)15:54
maxpalnstekern: ah, ok15:54
maxpalnblueCmd: no worries at all15:54
stekernmaxpaln: EPH is getting set by that wild write15:54
maxpalnby *wild* do you mean wrong15:55
stekernyou have to backtrack why garbage is getting written to it15:55
stekernyes, wrong ;)15:55
maxpalnah, ok15:55
maxpalnback in the room15:55
maxpalnblueCmd: I was thinking that a select pin would be a useful - it would allow the master to terminate a transaction if the Slave managed to get locked up too.15:56
maxpalnblueCmd: I am not sure you need a differential clock, it could be useful but it depends on what data rate you plan on trying to achieve. DDR on the data IO will help a lot if you only have 2 data bits (can't you increaase this - I only count 5 pins in your description). But remember it reduces your timing margin significantly15:59
stekernmaxpaln: to look up what 0xc000b14 does, you can disas vmlinux and look search for that address15:59
maxpalnsecurely latching the data from one device to the other is your primary challenge - technically, it's not difficult. But if you get ambitious with the data rates the setup and hold margins get really difficult to meet16:00
maxpalnstekern: good suggestion16:03
blueCmdmaxpaln: system clock is 80 MHz, I want to transfer control command (read/write & byte select 3 bits?), address (worst case 32 bits), and data (worst case 32 bits). I mean, using 1 MHz that will take some time.16:03
blueCmdso if I can get up to 2 digit MHz that would be awesome16:03
maxpalnblueCmd: 2 digit MHz won't be an issue - 100 MHz DDR is probably your theoretical limit for something handcrafted like this16:04
maxpalnI would expect you to be able to get to double figures MHz through a ribbon cable.16:04
blueCmdcool! even single ended?16:04
maxpalnBut running slowly to prove comms and cranking up the data rate is the way forward16:05
maxpalnyeah, single ended is fine for signals that slow16:05
blueCmdyes, ofc. But I don't want to settle on a path "everybody" knows will only do 1 MHz16:05
blueCmdbut yes, I can try do this without diff pairs and see where it get's me and take it from there.16:06
maxpalnyou can help by setting the IO standard to something like LVCMOS1V2 - a smaller swing will help in various ways. But the eval boards you are using will probably dictate the IO voltage unless they (kindly) provide jumpers to select IO voltaage.16:06
blueCmdyes, the lines have 3.3V pullup16:06
maxpalnOK, but even 3V3 is fine at several 10s of MHz.16:07
maxpalnWe do have customers running 32-bit busses at 3V3 150 MHz but it starts to have lots of noise issues16:07
maxpalnwe have an SSO tool to help debug - but at your data rates you'll be fine.16:07
maxpalnI would start at something like 5 MHz - establish a working baseline then up the speed.16:08
maxpalnI would expect you to get something like 20 or even 40 Mhz fine.16:08
blueCmdha, I'm super-excited - long time ago I felt like this! thanks :)16:08
blueCmdlong time since I felt like this*16:08
blueCmdNow I just need my ribbon cable to arrive from china16:09
maxpalnkeep the ribbon cable short too - that will help16:09
blueCmdI can set up nice models and simulate this16:09
blueCmdI bought this one:
maxpalnOK, if you're having problems one of those connectors should be moveable to reduce the length16:13
blueCmdI have some physical placement constraints as well16:14
blueCmdso I cannot make it super-short16:15
maxpalnSeveral inches is fine -16:15
maxpalnYou'll probaby be ok with the cable as it is - when things stop working as you increase the clock rate you can try reducing the cable length a bit. But your hard disk works on ribbon cable like this (although the IDE controller standard probably went through several iterations to get to that level of robustness :-) )16:17
blueCmdhah yes16:17
maxpalnstekern: objdump on the vmlin binary at address c0004b14:16:18
maxpalnc0004b14:c0 00 18 11 l.mtspr r0,r3,0x1116:18
maxpalnso Hex 11 is OR'ed with GPR3 and written to GPR016:19
maxpalnit is part of a section called <arch_local_irq_restore>16:19
maxpalnthe dump is here in case you feel like extending your charity a little further (I seriously don't know if I could debug this without your help - many thanks indeed!)16:23
maxpalnok, well my time on this has come to an end today - I am out at a customer tomorrow so I will be back on it on wednesday!16:33
maxpalnSince this is an IRQ related thing, I am womdering if there is something odd about (a) the interrupt setup in the HW or (b) the interrupt setup in the Linux Kernel16:33
maxpalnor maybe some conflict between the two16:34
maxpalnor maybe none of the above!!!16:34
daliasstekern, how hard is it to get a working or1k toolchain and emulator environment set up? i'm wondering in case anyone on our side is willing to do some testing (either now, or ongoing regression testing later)20:21
stekerndalias: I'm probably biased =) but not very hard20:37
stekernI've had some problems building a toolchain against musl though, I haven't investigated further but I had to disable libquadmath in the second gcc stage to get it to build20:40
stekerndalias: when you anyway are around, I'm getting this error in libc-test: fcntl.c:29: error: 'O_TTY_INIT' undeclared (first use in this function)20:42
stekernanyway, to get a working toolchain, upstream binutils can be used and our gcc port is here:
stekernon the emulator side, there's openrisc support in qemu and also a custom functional simulator21:06
stekernI'm a bit vague, since I'm not sure what kind of simulator environment you are looking after21:07
daliasstekern, yes some of the libc-test FAILs are to be expected21:19
daliasthey're open issues in musl and/or the compiler21:20
daliasre: building toolchain i mainly meant to ask: are patches to the official gcc and binutils needed or do they have upstream or1k support?21:20
stekernright, so vanilla binutils from binutils-gdb git should be fine, but our gcc is not upstream21:24
stekerndalias: this is what I got when I ran libc-test in a chrooted environment with qemu-user:
daliasstekern, qemu-user is going to fail most of the thread tests22:23
olofkAh crap.  I missed maxpaln. If he comes back , could someone invite him to orconf. I've been meaning to do that, but haven't got any contact information22:26
daliasstekern, that looks like just the build part22:26
daliasnot the runtime part22:26
olofkblueCmd: You might have some luck looking at I know that they have done some work on sending wishbone busses across different FPGAs22:27
olofkThere's even a linux driver for external wishbone busses. I think Alessandro Rubini did that for the CERN guys, but I don't know exactly what it does22:28
olofkMight be some kind of wishbone over USB actually22:29
olofkAnyway. Got to sleep now22:29
olofkstekern: Very happy to see your fusesoc pull request. I'll take a look at it tomorrow22:30
blueCmdolofk: ah, something like that is what I would need I guess, but my needs are much simpler and I don't have the luxury of high speed serdes23:12
--- Log closed Tue Jul 08 00:00:09 2014

Generated by 2.15.2 by Marius Gedminas - find it at!