IRC logs for #openrisc Monday, 2013-12-23

--- Log opened Mon Dec 23 00:00:21 2013
stekern_franck_: very cool!06:31
_franck_web_"Altera does not authorized user to modify and redistribute the software including the usb blaster II. We are sorry to inform this, I shall set this SR to close pending."09:14
_franck_web_I can't include the usb blaster II firmware blob into the openocd driver :(09:14
_franck_web_may be I could ask openocd user to set a variable pointing to the quartus install dir09:16
stekernSR?09:52
_franck_web_SR = service request09:53
stekernbut anyway, i don't see that as a showstopper for the driver09:54
_franck_web_because I'll redistribute the usb-blaster II binary09:56
stekernyou could either provide instructions how to build it into the driver (or like you said, use the blob from the install dir) or just require the blob to be loaded before uising openocd09:56
_franck_web_http://openocd.zylin.com/#/c/1791/4/src/jtag/drivers/usb_blaster/ezusb_firmware.c09:56
stekernor do an open source version of the ub209:57
_franck_web_yes, I could rewrite it09:57
_franck_web_for now, I won't. May be when I have some time09:58
stekernyeah, I wondered if that was ok when I saw you posting the patch earlier09:58
olofk_franck_web_: Very cool stuff. Got to try it out when I have some spare time12:47
olofkDoes it work on Jolla phones :)12:47
stekernonly if it's an optimistijolla12:58
_franck_web_olofk: since it is all socket based communication and if you can run openocd on our phone you can do or1ksim (on your pc) <--> openocd (phone) <-> jtag_vpi (on your pc)13:10
_franck_web_:)13:10
maxpalnstekern: I have installed or1ksim but I don't have a binary called 'or1ksim' just these three:13:20
maxpalnor32-elf-mprofile  or32-elf-profile  or32-elf-sim13:20
maxpalnCould I have done something wrong during the install for or1ksim?13:21
maxpalnor not set an optin correctly?13:21
_franck_web_you have ./sim13:21
maxpalnwhere?13:21
_franck_web_or if you make install it you'll have or1ksim (aren't you) ?13:21
_franck_web_./sim is in the source dir13:21
maxpalnI did a make install - it created the bin, include, lib and share directories13:22
maxpalninside the bin diretory is the three binaries I described above?13:22
maxpalnodd13:22
maxpalnah, ok let me check the soruce dir13:22
_franck_web_../configure --target=or1k-elf --prefix=/opt/or1ksim13:23
_franck_web_oh sorry you have all you need :) three binaries13:24
_franck_web_or32-elf-sim is what you need13:24
maxpalnah, ok13:24
maxpalnI installed that a few months ago - I did read that some of the binaries had changed13:24
maxpalnwas about to go backi and checkl13:25
maxpalnbut it looks like I am all set13:25
maxpalnI'll run it and see how I get on13:25
maxpalnok looking promising - but its sitting at 'Configuring loopback device'13:26
maxpalndoes that take a while?13:26
stekernmaxpaln: the default configuration starts a "telnet interface" (sorry can't remember the correct term right now)13:27
stekerntry to telnet to localhost:1008413:28
maxpalnah, ok - so I need to connect from another terminal13:28
maxpalnthat didn't work but you've pointed me int he right direction13:28
maxpalnI'll dig around to find the right port13:28
stekernyou can change it to open an xterm in the .cfg file as well13:29
stekernand the port should be there too13:29
stekernhttp://git.openrisc.net/cgit.cgi/jonas/linux/tree/arch/openrisc/or1ksim.cfg#n64213:31
maxpalnperfect - was just getting there, but you saved me a bit of time13:32
maxpalnok, the xterm method works - not sure why i can't telnet in, this may indicate something else is wrong14:14
maxpalnI guess this may make life difficult when deploying the code onto the board14:15
maxpalnok, so I have modified the dts file to mirror the board frequencies, I notice the SPI isn't in the dts- it's the only peripheral that isn't in there (although I only have UART, Memory, SPI and Ethernet) so perhaps Uart, Eth and Mamry are the only ones that are meant to be in there14:20
maxpalnSo if I want to try this on the board is it as simple as running the or32-elf-objcopy to convert it to a binary for the OR1200 then deploying as per any other binary file?14:22
maxpalnI'm about to try that - if it works I'll be happy?14:22
maxpaln:-)14:22
maxpalnhmmm, actually that doesn't make sense - all the commands I've run are for the or1ksim not the HW14:40
maxpalnso the question is how do you build the linux binary for HW not or1ksim?14:41
maxpalnI'll see if I can find this in the docs14:41
_franck_web_the linux binary is the same for or1ksim and HW14:42
maxpalnah, excellent14:43
maxpalnso I was doing the right thing14:43
_franck_web_you need to download your linux binary to your board using your JTAG and gdb (or openocd)14:43
maxpalnactually, I was hoping to be able to get the processor to boot from SPI as this is how I have done it so far14:44
_franck_web_ah ok14:44
maxpalnit seemed to be working then I got a bus error :-(14:44
maxpalnpid_max: default: 32768 minimum: 30114:44
maxpalnKERNEL: Bus error (SIGBUS) 0xc027bfd814:44
maxpalnCPU #: 014:44
maxpaln   PC: 00002000    SR: 00018219    SP: c027bfdc14:44
maxpalnGPR00: 00000000 GPR01: c027bfdc GPR02: c040218c GPR03: c040231c14:44
maxpalnGPR04: 00008479 GPR05: c10021a4 GPR06: 00000001 GPR07: c10021be14:44
maxpalnGPR08: 00000000 GPR09: c02a3ff0 GPR10: c027a000 GPR11: c100218814:44
maxpalnGPR12: 00000f21 GPR13: c10021ac GPR14: c03fa044 GPR15: 00000f2a14:44
maxpalnGPR16: c04340f0 GPR17: 0000000a GPR18: c03fa004 GPR19: fffffffc14:44
maxpalnGPR20: 00000000 GPR21: 00000003 GPR22: 00000000 GPR23: 0000000014:44
maxpalnGPR24: 00000000 GPR25: 00003740 GPR26: 00000000 GPR27: c03fc60c14:44
maxpalnGPR28: 00000000 GPR29: 00004000 GPR30: c029c5f4 GPR31: c03fc60814:44
maxpalnMust be something in the HW setup I'll review - maybe on the memory side14:44
_franck_web_at leat you have some console output....14:45
maxpaln:-) exactly -14:45
maxpalnevery cloud and all that14:45
stekernhmm, yes... it fails when it tries to access something on the stack15:23
maxpalnyeah, eventually the final error is Code:  Bad PC value.15:24
maxpalnThis is straying dangerously close to the limits of my knowledge now...15:25
stekerndon't worry, we're here to help ;)15:26
maxpaln:-) - the safety blanket!15:26
stekernhmm, it looks like the mmu is turned off, but it tries to access a virtual address15:29
stekernand the PC is indeed a bit strange, 0x2000 is the dtlb miss handler15:29
maxpalnok, so maybe the setup of the Linux doesn't match the HW yet - the HW definitely has the MMU enabled15:31
stekernI meant disabled by software15:32
maxpalnah, ok15:32
stekernand mmu is always disabled on exception entry15:32
maxpalnok,15:33
stekernbut, it shouldn't be accessing the stack on PC=0x200015:34
stekernit should access address 0x6415:34
maxpalncomparing the console output witht he or1ksim output - this is the consolve output:15:36
maxpalnconsole output:15:36
maxpalnbootconsole [uart0] enabled15:36
maxpalnPID hash table entries: 128 (order: -4, 512 bytes)15:36
maxpalnDentry cache hash table entries: 4096 (order: 1, 16384 bytes)15:36
maxpalnInode-cache hash table entries: 2048 (order: 0, 8192 bytes)15:36
maxpalnSorting __ex_table...15:36
maxpalnMemory: 28368K/32768K available (2302K kernel code, 112K rwdata, 232K rodata, 1416K init, 79K bss, 4400K reserved)15:36
maxpalnmem_init_done ...........................................15:36
maxpalnNR_IRQS:32 nr_irqs:32 015:36
maxpaln96.00 BogoMIPS (lpj=480000)15:36
maxpalnpid_max: default: 32768 minimum: 30115:36
maxpalnKERNEL: Bus error (SIGBUS) 0xc027bfd815:36
maxpalnand this is hte or1ksim output:15:36
maxpalnbootconsole [uart0] enabled15:37
maxpalnPID hash table entries: 128 (order: -4, 512 bytes)15:37
maxpalnDentry cache hash table entries: 4096 (order: 1, 16384 bytes)15:37
maxpalnInode-cache hash table entries: 2048 (order: 0, 8192 bytes)15:37
maxpalnSorting __ex_table...15:37
maxpalnMemory: 28368K/32768K available (2302K kernel code, 112K rwdata, 232K rodata, 1416K init, 79K bss, 4400K reserved)15:37
maxpalnmem_init_done ...........................................15:37
maxpalnNR_IRQS:32 nr_irqs:32 015:37
maxpaln96.00 BogoMIPS (lpj=480000)15:37
maxpalnpid_max: default: 32768 minimum: 30115:37
maxpalnMount-cache hash table entries: 102415:37
maxpalnI guess that the final step 'Mount-cache..' was where the HW encoutered the exception15:37
stekernmaxpaln: what kind of ILA solutions are available on lattice?15:43
stekernalso, I wonder how well tested the non-burst setup of or1200 is tested...15:46
stekern-tested15:46
maxpalnFunnily enough I have just compiled with the logic analyser15:47
maxpalnwe have a very good one :-)15:47
maxpalnI can see the bus exception occurs on the iwb_err_i output from the or1200 unit15:48
stekerncool, I'm sadly not very familiar with the lattice stuff15:48
maxpalnthat's all good - this is my specialist subject :-)15:49
stekernhmm, ok, so what is the address on the insn bus?15:49
maxpalnhmmm, just realised I compiled the HW with the alanyser looking at the memory bus not the OR1200 bus15:51
maxpalnI'll rebuild with more info on the OR1200 bus15:52
maxpalnany other sigs that will be helpful?15:52
stekernbut the memory bus should be helpful as well, at least if it's a memory access that fail16:03
stekernPC is usually interesting ;)16:04
maxpalnhold-on - I've realised I wasn't caputuring the first error16:05
maxpalnthe first error is actually on the dbus_arbiter16:05
stekernif you can catch the PC before the error (and the PCs leading up to the error), you've got a good start16:06
maxpalnit's the wbm0_err_i output16:06
stekernand that's the dbus?16:06
maxpalnyep16:06
maxpalnso it's a peripheral on the dbus looking at the verilog16:06
stekernand wbm0 is or1200 I guess?16:07
maxpalnwell, the assignments in Verilog look this like:16:07
stekernand the address it tries to access is?16:07
maxpaln   assign wbm0_err_i = wbm_err_i & master_sel[0];16:07
maxpaln   assign wbm_err_i = wbs_err_o_mux_i[0] |16:08
maxpaln      wbs_err_o_mux_i[1] |16:08
maxpaln      wbs_err_o_mux_i[2] | watchdog_err;16:08
maxpaln   assign wbs_err_o_mux_i[0] = wbs0_err_o & wb_slave_sel_r[0];16:08
maxpaln  assign wbs_err_o_mux_i[1] = wbs1_err_o & wb_slave_sel_r[1];16:08
maxpaln   assign wbs_err_o_mux_i[2] = wbs2_err_o & wb_slave_sel_r[2];16:08
stekernyes, I know ;) (the arbiter is nicer in orpsocv3 btw)16:09
maxpalnso I gather that the error originated in one of the dbus slaves16:09
maxpalnor the watchdog16:10
maxpalnthe slaves on teh dbus are the DDR3 memory controller, the ethernet controller and the debug interface16:10
stekernyes, but what we really want to know is the wbm0_adr ;)16:10
maxpaln:-) - ok, let me try and look at the or1200 bus a bnit closer16:11
stekernyou can capture those signals (wbm0_adr)16:11
stekernthat should match the wbm0_err that you already are capturing16:12
maxpalnis there a signal for the PC - or is stored in mem?16:13
maxpalnaha what about or1200/cpu/genpc/pc16:14
maxpalnthat looks promising16:14
stekernthere are a signal for the PC in each staged, it was a long time since I looked in or1200 (I'm more familiar with mor1kx)16:14
stekernbut pick the execute pc to begin with16:14
maxpalnok, so epcr I guess16:14
stekernno, that's exception pc register16:15
maxpalnI just worked that out16:15
stekernI can't remember the name, but ex_pc or something ;)16:15
maxpalnhmmm, I am thinking epcr might be the one16:16
stekernhttp://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/rtl/verilog/or1200/or1200_top.v#n40416:16
maxpalnaha16:17
maxpalngotcha16:17
stekernno, epcr is the register holding the address before an exception (i.e. the address that an exception handler will return to on a l.reti)16:17
maxpalnright - got the ex_pc16:17
maxpalngot the or1200 bus on both data and instruction arbiter modules16:18
maxpalngot the error signals16:18
stekerngreat ;)16:18
maxpalnright give me 20 mins or so to build a new HW image16:23
maxpalnright - so it's a watchdog error!16:53
maxpalnhow odd - haven't even looked at that code before16:53
maxpalnok, might need to dig into this one - a watchdog error is more investigatable16:57
maxpalnprobably something in the memory controller implementation or something16:58
stekernthat means that no slave acked the acceas17:01
maxpalnyeah, I'll see which slave was being pulsed and try and trsack it down17:02
maxpalnshould be simple enough to find the cause of - fixing it might be more difficult17:02
stekernso, what's the adress?17:02
maxpalnwell it was the address bus17:03
maxpalnduh17:03
maxpalndata bus17:03
maxpalnat address C027BFD817:03
maxpalnwhich is an odd address17:04
maxpalnI don't think anything should be at this address17:04
stekernso, that's the issue, it tries to access a virtual address, but the mmu is off17:05
maxpalnthe highest base address is the ethernet at 0x9200000017:05
stekernso, next step is to track what it is doing at the PC that happens17:05
maxpalnthe PC is at 0x200017:06
maxpalnmy buffer isn't big enough to see before that17:07
maxpalnwhen triggering on the error17:07
maxpalnI could trigger on the PC getting to 0x200017:07
maxpalnto see what happened in the lead up17:07
maxpalnI have the results if that is helpful -17:08
maxpalnnope - ignore that, different occurrence of PC = 0x200017:15
maxpalnthat one gets ack'ed17:15
maxpalnand the address is more sensible17:15
maxpalnhmmm, its just occurred to me I should be able to simulate this17:16
maxpalnI'll run it through simulation and see if I get the same result17:16
maxpalnthat will be in interesting test17:16
maxpalnit'll be the morning before it's ready though!17:27
maxpalnI need to go anyway now - back to this tomorrow!17:27
stekernyou could trigger on PC=0x2000 AND wbm0_adr=0xc027bfd818:23
stekernmy guess of what is happening is that you get a tlb miss on 0xc027bfd8, but somehow that data access is propagating out on the bus  after the exception signal have turned off the mmu18:26
stekernand I suspect it could be a bug in the biu when bursts are turned off, since I suspect no-one has used that mode for a very long time18:34
stekernbecause, normally the burst mode can be used even if the slave doesn't support bursts (or a certain burst mode), the slave should then fall back to classic wb accesses.18:35
stekernalso, I'm counting on that you'll read the backlog tomorrow ;)18:35
maxpaln:-) - just checking it now19:01
maxpalnok, so maybe I need to do something about the lack of burst support in the DDR memory19:01
maxpaln:-(19:01
maxpalnnot a super quick fix but it is something I need to do so maybe sooner rather than later will solve other problems19:02
maxpalnthankfully those nice people at Xilinx have already solved this problem so i'll look at how they solve the problem!19:02
stekernumm, where do xilinx have a wb interface?19:09
stekernbut, if you want a "quick test fix", just disable burst support all together in your SDRAM controller19:10
_franck_make19:41
_franck_oups, sorry19:41
stekernI am making, ham in the oven! ;)19:42
_franck_:)19:42
maxpalnthere's a wb interface to the DDR2 controller in the Xilinx Spartan board distribution in orpsocv221:27
maxpalnI presume it made it v321:27
maxpalnI was also wondering if I could disable cache - would that solve it21:27
maxpalnhavent got a chance to look now though21:28
maxpalnwell solve is probably the wrong word - allow me to workaround for a tes fix21:29
stekernmaxpaln: ah, so the nice people you are referring to isn't actually Xilinx people, but the friendly people of the openrisc community ;)21:32
stekernif I were you, I'd start with disabling burst support in the SDRAM controller, if that works, then I'd implement proper wrap-burst support in it21:35
stekernbut yes, you can try to disable caches, that way it will not do any burst accesses21:36
maxpalnaha - ok I see. Well, that's a good strategy. I didn' write our wishbone interface - I'll have a look and see how easy it is to disable the burst access, hopefully quite easy. I'll report back in22:49
maxpalnoh, and of course thank you to the openrisc community for their diligence at implementing the DDr2 controller - it will no doubt prove very helpful when implementing burst support in this design22:50
--- Log closed Tue Dec 24 00:00:22 2013

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!