| --- 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 dir | 09:16 |
| stekern | SR? | 09:52 |
| _franck_web_ | SR = service request | 09:53 |
| stekern | but anyway, i don't see that as a showstopper for the driver | 09:54 |
| _franck_web_ | because I'll redistribute the usb-blaster II binary | 09:56 |
| stekern | you 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 openocd | 09:56 |
| _franck_web_ | http://openocd.zylin.com/#/c/1791/4/src/jtag/drivers/usb_blaster/ezusb_firmware.c | 09:56 |
| stekern | or do an open source version of the ub2 | 09:57 |
| _franck_web_ | yes, I could rewrite it | 09:57 |
| _franck_web_ | for now, I won't. May be when I have some time | 09:58 |
| stekern | yeah, I wondered if that was ok when I saw you posting the patch earlier | 09:58 |
| olofk | _franck_web_: Very cool stuff. Got to try it out when I have some spare time | 12:47 |
| olofk | Does it work on Jolla phones :) | 12:47 |
| stekern | only if it's an optimistijolla | 12: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 |
| maxpaln | stekern: I have installed or1ksim but I don't have a binary called 'or1ksim' just these three: | 13:20 |
| maxpaln | or32-elf-mprofile or32-elf-profile or32-elf-sim | 13:20 |
| maxpaln | Could I have done something wrong during the install for or1ksim? | 13:21 |
| maxpaln | or not set an optin correctly? | 13:21 |
| _franck_web_ | you have ./sim | 13:21 |
| maxpaln | where? | 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 dir | 13:21 |
| maxpaln | I did a make install - it created the bin, include, lib and share directories | 13:22 |
| maxpaln | inside the bin diretory is the three binaries I described above? | 13:22 |
| maxpaln | odd | 13:22 |
| maxpaln | ah, ok let me check the soruce dir | 13:22 |
| _franck_web_ | ../configure --target=or1k-elf --prefix=/opt/or1ksim | 13:23 |
| _franck_web_ | oh sorry you have all you need :) three binaries | 13:24 |
| _franck_web_ | or32-elf-sim is what you need | 13:24 |
| maxpaln | ah, ok | 13:24 |
| maxpaln | I installed that a few months ago - I did read that some of the binaries had changed | 13:24 |
| maxpaln | was about to go backi and checkl | 13:25 |
| maxpaln | but it looks like I am all set | 13:25 |
| maxpaln | I'll run it and see how I get on | 13:25 |
| maxpaln | ok looking promising - but its sitting at 'Configuring loopback device' | 13:26 |
| maxpaln | does that take a while? | 13:26 |
| stekern | maxpaln: the default configuration starts a "telnet interface" (sorry can't remember the correct term right now) | 13:27 |
| stekern | try to telnet to localhost:10084 | 13:28 |
| maxpaln | ah, ok - so I need to connect from another terminal | 13:28 |
| maxpaln | that didn't work but you've pointed me int he right direction | 13:28 |
| maxpaln | I'll dig around to find the right port | 13:28 |
| stekern | you can change it to open an xterm in the .cfg file as well | 13:29 |
| stekern | and the port should be there too | 13:29 |
| stekern | http://git.openrisc.net/cgit.cgi/jonas/linux/tree/arch/openrisc/or1ksim.cfg#n642 | 13:31 |
| maxpaln | perfect - was just getting there, but you saved me a bit of time | 13:32 |
| maxpaln | ok, the xterm method works - not sure why i can't telnet in, this may indicate something else is wrong | 14:14 |
| maxpaln | I guess this may make life difficult when deploying the code onto the board | 14:15 |
| maxpaln | ok, 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 there | 14:20 |
| maxpaln | So 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 |
| maxpaln | I'm about to try that - if it works I'll be happy? | 14:22 |
| maxpaln | :-) | 14:22 |
| maxpaln | hmmm, actually that doesn't make sense - all the commands I've run are for the or1ksim not the HW | 14:40 |
| maxpaln | so the question is how do you build the linux binary for HW not or1ksim? | 14:41 |
| maxpaln | I'll see if I can find this in the docs | 14:41 |
| _franck_web_ | the linux binary is the same for or1ksim and HW | 14:42 |
| maxpaln | ah, excellent | 14:43 |
| maxpaln | so I was doing the right thing | 14:43 |
| _franck_web_ | you need to download your linux binary to your board using your JTAG and gdb (or openocd) | 14:43 |
| maxpaln | actually, I was hoping to be able to get the processor to boot from SPI as this is how I have done it so far | 14:44 |
| _franck_web_ | ah ok | 14:44 |
| maxpaln | it seemed to be working then I got a bus error :-( | 14:44 |
| maxpaln | pid_max: default: 32768 minimum: 301 | 14:44 |
| maxpaln | KERNEL: Bus error (SIGBUS) 0xc027bfd8 | 14:44 |
| maxpaln | CPU #: 0 | 14:44 |
| maxpaln | PC: 00002000 SR: 00018219 SP: c027bfdc | 14:44 |
| maxpaln | GPR00: 00000000 GPR01: c027bfdc GPR02: c040218c GPR03: c040231c | 14:44 |
| maxpaln | GPR04: 00008479 GPR05: c10021a4 GPR06: 00000001 GPR07: c10021be | 14:44 |
| maxpaln | GPR08: 00000000 GPR09: c02a3ff0 GPR10: c027a000 GPR11: c1002188 | 14:44 |
| maxpaln | GPR12: 00000f21 GPR13: c10021ac GPR14: c03fa044 GPR15: 00000f2a | 14:44 |
| maxpaln | GPR16: c04340f0 GPR17: 0000000a GPR18: c03fa004 GPR19: fffffffc | 14:44 |
| maxpaln | GPR20: 00000000 GPR21: 00000003 GPR22: 00000000 GPR23: 00000000 | 14:44 |
| maxpaln | GPR24: 00000000 GPR25: 00003740 GPR26: 00000000 GPR27: c03fc60c | 14:44 |
| maxpaln | GPR28: 00000000 GPR29: 00004000 GPR30: c029c5f4 GPR31: c03fc608 | 14:44 |
| maxpaln | Must be something in the HW setup I'll review - maybe on the memory side | 14:44 |
| _franck_web_ | at leat you have some console output.... | 14:45 |
| maxpaln | :-) exactly - | 14:45 |
| maxpaln | every cloud and all that | 14:45 |
| stekern | hmm, yes... it fails when it tries to access something on the stack | 15:23 |
| maxpaln | yeah, eventually the final error is Code: Bad PC value. | 15:24 |
| maxpaln | This is straying dangerously close to the limits of my knowledge now... | 15:25 |
| stekern | don't worry, we're here to help ;) | 15:26 |
| maxpaln | :-) - the safety blanket! | 15:26 |
| stekern | hmm, it looks like the mmu is turned off, but it tries to access a virtual address | 15:29 |
| stekern | and the PC is indeed a bit strange, 0x2000 is the dtlb miss handler | 15:29 |
| maxpaln | ok, so maybe the setup of the Linux doesn't match the HW yet - the HW definitely has the MMU enabled | 15:31 |
| stekern | I meant disabled by software | 15:32 |
| maxpaln | ah, ok | 15:32 |
| stekern | and mmu is always disabled on exception entry | 15:32 |
| maxpaln | ok, | 15:33 |
| stekern | but, it shouldn't be accessing the stack on PC=0x2000 | 15:34 |
| stekern | it should access address 0x64 | 15:34 |
| maxpaln | comparing the console output witht he or1ksim output - this is the consolve output: | 15:36 |
| maxpaln | console output: | 15:36 |
| maxpaln | bootconsole [uart0] enabled | 15:36 |
| maxpaln | PID hash table entries: 128 (order: -4, 512 bytes) | 15:36 |
| maxpaln | Dentry cache hash table entries: 4096 (order: 1, 16384 bytes) | 15:36 |
| maxpaln | Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) | 15:36 |
| maxpaln | Sorting __ex_table... | 15:36 |
| maxpaln | Memory: 28368K/32768K available (2302K kernel code, 112K rwdata, 232K rodata, 1416K init, 79K bss, 4400K reserved) | 15:36 |
| maxpaln | mem_init_done ........................................... | 15:36 |
| maxpaln | NR_IRQS:32 nr_irqs:32 0 | 15:36 |
| maxpaln | 96.00 BogoMIPS (lpj=480000) | 15:36 |
| maxpaln | pid_max: default: 32768 minimum: 301 | 15:36 |
| maxpaln | KERNEL: Bus error (SIGBUS) 0xc027bfd8 | 15:36 |
| maxpaln | and this is hte or1ksim output: | 15:36 |
| maxpaln | bootconsole [uart0] enabled | 15:37 |
| maxpaln | PID hash table entries: 128 (order: -4, 512 bytes) | 15:37 |
| maxpaln | Dentry cache hash table entries: 4096 (order: 1, 16384 bytes) | 15:37 |
| maxpaln | Inode-cache hash table entries: 2048 (order: 0, 8192 bytes) | 15:37 |
| maxpaln | Sorting __ex_table... | 15:37 |
| maxpaln | Memory: 28368K/32768K available (2302K kernel code, 112K rwdata, 232K rodata, 1416K init, 79K bss, 4400K reserved) | 15:37 |
| maxpaln | mem_init_done ........................................... | 15:37 |
| maxpaln | NR_IRQS:32 nr_irqs:32 0 | 15:37 |
| maxpaln | 96.00 BogoMIPS (lpj=480000) | 15:37 |
| maxpaln | pid_max: default: 32768 minimum: 301 | 15:37 |
| maxpaln | Mount-cache hash table entries: 1024 | 15:37 |
| maxpaln | I guess that the final step 'Mount-cache..' was where the HW encoutered the exception | 15:37 |
| stekern | maxpaln: what kind of ILA solutions are available on lattice? | 15:43 |
| stekern | also, I wonder how well tested the non-burst setup of or1200 is tested... | 15:46 |
| stekern | -tested | 15:46 |
| maxpaln | Funnily enough I have just compiled with the logic analyser | 15:47 |
| maxpaln | we have a very good one :-) | 15:47 |
| maxpaln | I can see the bus exception occurs on the iwb_err_i output from the or1200 unit | 15:48 |
| stekern | cool, I'm sadly not very familiar with the lattice stuff | 15:48 |
| maxpaln | that's all good - this is my specialist subject :-) | 15:49 |
| stekern | hmm, ok, so what is the address on the insn bus? | 15:49 |
| maxpaln | hmmm, just realised I compiled the HW with the alanyser looking at the memory bus not the OR1200 bus | 15:51 |
| maxpaln | I'll rebuild with more info on the OR1200 bus | 15:52 |
| maxpaln | any other sigs that will be helpful? | 15:52 |
| stekern | but the memory bus should be helpful as well, at least if it's a memory access that fail | 16:03 |
| stekern | PC is usually interesting ;) | 16:04 |
| maxpaln | hold-on - I've realised I wasn't caputuring the first error | 16:05 |
| maxpaln | the first error is actually on the dbus_arbiter | 16:05 |
| stekern | if you can catch the PC before the error (and the PCs leading up to the error), you've got a good start | 16:06 |
| maxpaln | it's the wbm0_err_i output | 16:06 |
| stekern | and that's the dbus? | 16:06 |
| maxpaln | yep | 16:06 |
| maxpaln | so it's a peripheral on the dbus looking at the verilog | 16:06 |
| stekern | and wbm0 is or1200 I guess? | 16:07 |
| maxpaln | well, the assignments in Verilog look this like: | 16:07 |
| stekern | and 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 |
| stekern | yes, I know ;) (the arbiter is nicer in orpsocv3 btw) | 16:09 |
| maxpaln | so I gather that the error originated in one of the dbus slaves | 16:09 |
| maxpaln | or the watchdog | 16:10 |
| maxpaln | the slaves on teh dbus are the DDR3 memory controller, the ethernet controller and the debug interface | 16:10 |
| stekern | yes, 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 closer | 16:11 |
| stekern | you can capture those signals (wbm0_adr) | 16:11 |
| stekern | that should match the wbm0_err that you already are capturing | 16:12 |
| maxpaln | is there a signal for the PC - or is stored in mem? | 16:13 |
| maxpaln | aha what about or1200/cpu/genpc/pc | 16:14 |
| maxpaln | that looks promising | 16:14 |
| stekern | there 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 |
| stekern | but pick the execute pc to begin with | 16:14 |
| maxpaln | ok, so epcr I guess | 16:14 |
| stekern | no, that's exception pc register | 16:15 |
| maxpaln | I just worked that out | 16:15 |
| stekern | I can't remember the name, but ex_pc or something ;) | 16:15 |
| maxpaln | hmmm, I am thinking epcr might be the one | 16:16 |
| stekern | http://git.openrisc.net/cgit.cgi/stefan/orpsoc/tree/rtl/verilog/or1200/or1200_top.v#n404 | 16:16 |
| maxpaln | aha | 16:17 |
| maxpaln | gotcha | 16:17 |
| stekern | no, 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 |
| maxpaln | right - got the ex_pc | 16:17 |
| maxpaln | got the or1200 bus on both data and instruction arbiter modules | 16:18 |
| maxpaln | got the error signals | 16:18 |
| stekern | great ;) | 16:18 |
| maxpaln | right give me 20 mins or so to build a new HW image | 16:23 |
| maxpaln | right - so it's a watchdog error! | 16:53 |
| maxpaln | how odd - haven't even looked at that code before | 16:53 |
| maxpaln | ok, might need to dig into this one - a watchdog error is more investigatable | 16:57 |
| maxpaln | probably something in the memory controller implementation or something | 16:58 |
| stekern | that means that no slave acked the acceas | 17:01 |
| maxpaln | yeah, I'll see which slave was being pulsed and try and trsack it down | 17:02 |
| maxpaln | should be simple enough to find the cause of - fixing it might be more difficult | 17:02 |
| stekern | so, what's the adress? | 17:02 |
| maxpaln | well it was the address bus | 17:03 |
| maxpaln | duh | 17:03 |
| maxpaln | data bus | 17:03 |
| maxpaln | at address C027BFD8 | 17:03 |
| maxpaln | which is an odd address | 17:04 |
| maxpaln | I don't think anything should be at this address | 17:04 |
| stekern | so, that's the issue, it tries to access a virtual address, but the mmu is off | 17:05 |
| maxpaln | the highest base address is the ethernet at 0x92000000 | 17:05 |
| stekern | so, next step is to track what it is doing at the PC that happens | 17:05 |
| maxpaln | the PC is at 0x2000 | 17:06 |
| maxpaln | my buffer isn't big enough to see before that | 17:07 |
| maxpaln | when triggering on the error | 17:07 |
| maxpaln | I could trigger on the PC getting to 0x2000 | 17:07 |
| maxpaln | to see what happened in the lead up | 17:07 |
| maxpaln | I have the results if that is helpful - | 17:08 |
| maxpaln | nope - ignore that, different occurrence of PC = 0x2000 | 17:15 |
| maxpaln | that one gets ack'ed | 17:15 |
| maxpaln | and the address is more sensible | 17:15 |
| maxpaln | hmmm, its just occurred to me I should be able to simulate this | 17:16 |
| maxpaln | I'll run it through simulation and see if I get the same result | 17:16 |
| maxpaln | that will be in interesting test | 17:16 |
| maxpaln | it'll be the morning before it's ready though! | 17:27 |
| maxpaln | I need to go anyway now - back to this tomorrow! | 17:27 |
| stekern | you could trigger on PC=0x2000 AND wbm0_adr=0xc027bfd8 | 18:23 |
| stekern | my 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 mmu | 18:26 |
| stekern | and 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 time | 18:34 |
| stekern | because, 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 |
| stekern | also, I'm counting on that you'll read the backlog tomorrow ;) | 18:35 |
| maxpaln | :-) - just checking it now | 19:01 |
| maxpaln | ok, so maybe I need to do something about the lack of burst support in the DDR memory | 19:01 |
| maxpaln | :-( | 19:01 |
| maxpaln | not a super quick fix but it is something I need to do so maybe sooner rather than later will solve other problems | 19:02 |
| maxpaln | thankfully those nice people at Xilinx have already solved this problem so i'll look at how they solve the problem! | 19:02 |
| stekern | umm, where do xilinx have a wb interface? | 19:09 |
| stekern | but, if you want a "quick test fix", just disable burst support all together in your SDRAM controller | 19:10 |
| _franck_ | make | 19:41 |
| _franck_ | oups, sorry | 19:41 |
| stekern | I am making, ham in the oven! ;) | 19:42 |
| _franck_ | :) | 19:42 |
| maxpaln | there's a wb interface to the DDR2 controller in the Xilinx Spartan board distribution in orpsocv2 | 21:27 |
| maxpaln | I presume it made it v3 | 21:27 |
| maxpaln | I was also wondering if I could disable cache - would that solve it | 21:27 |
| maxpaln | havent got a chance to look now though | 21:28 |
| maxpaln | well solve is probably the wrong word - allow me to workaround for a tes fix | 21:29 |
| stekern | maxpaln: ah, so the nice people you are referring to isn't actually Xilinx people, but the friendly people of the openrisc community ;) | 21:32 |
| stekern | if 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 it | 21:35 |
| stekern | but yes, you can try to disable caches, that way it will not do any burst accesses | 21:36 |
| maxpaln | aha - 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 in | 22:49 |
| maxpaln | oh, 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 design | 22: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!