| --- Log opened Wed Aug 28 00:00:31 2013 | ||
| hansfbaier | stekern: got your message from the log | 01:02 |
|---|---|---|
| hansfbaier | thanks | 01:03 |
| hansfbaier | will try | 01:03 |
| stekern | getting the right epcr for dbus error exceptions is going to be even harder with the storebuffer than I first anticipated... | 03:42 |
| stekern | because I'd need to not only the pc for each store in the storebuffer, but also information wether it's in a delay slot or not | 03:45 |
| stekern | maybe it's better to just feed the delay slot information back into the lsu and just save the potential epcr in the storebuffer | 03:46 |
| stekern | or even better, just feed the potential epcr into the lsu and storebuffer | 04:46 |
| hansfbaier | _franck_: running the blinky | 04:58 |
| hansfbaier | 2 leds light up | 04:58 |
| hansfbaier | but then it jumps to nirvana | 04:58 |
| hansfbaier | reason: | 04:58 |
| hansfbaier | the jump destination addrs get garbled somehow | 04:58 |
| hansfbaier | for instance: | 04:59 |
| hansfbaier | 12c: 0f ff ff fe l.bnf 124 <t1> | 04:59 |
| hansfbaier | Thatis how it should be with label t1 on | 04:59 |
| hansfbaier | 00000124 <t1>: | 04:59 |
| hansfbaier | but in the gdb disassembly it looks like that: | 04:59 |
| hansfbaier | 0x0000012c <t1+8>:l.bnf 0xff83fffe | 05:00 |
| hansfbaier | destination address garbled | 05:00 |
| hansfbaier | Could it be that sdram does not work correctly? | 05:00 |
| hansfbaier | But if so the instructions could be garbled too, but they aren't | 05:00 |
| hansfbaier | stekern: any idea? | 05:00 |
| stekern | hansfbaier: hmm, the instruction us garbled isn't it? | 05:05 |
| stekern | s/us/us | 05:05 |
| stekern | *is | 05:05 |
| hansfbaier | stekern | 05:06 |
| stekern | man, I can't even write properly in my corrections.. | 05:06 |
| hansfbaier | parts | 05:06 |
| hansfbaier | yes | 05:06 |
| hansfbaier | wait a moment send a screenshot | 05:06 |
| knz | hi all | 05:07 |
| stekern | if you've got timing problems, usually you'd get a result like that, some bits doesn't arrive in time | 05:08 |
| hansfbaier | http://i.imgur.com/wTBePBy.png | 05:08 |
| stekern | but could of course be a bug somewhere too | 05:08 |
| hansfbaier | stekern: Yes that makes sense | 05:09 |
| hansfbaier | TimeQuest complains about some negative setup times | 05:09 |
| knz | sorry to disturb, small questions: 1) trying to build or1knd-gcc: which binutils should I get beforehand? 2) ork1nd = no delay branches, correct? | 05:09 |
| hansfbaier | unfortunately I don't know how to fix timing problems yet..... | 05:09 |
| hansfbaier | The reading on timing constraints is a bit heavy and I don't know where to start | 05:09 |
| hansfbaier | stekern: could you give me any pointers? | 05:10 |
| stekern | hansfbaier: what board and memory controller are you using? | 05:10 |
| hansfbaier | Or maybe there is a set of constraints | 05:10 |
| stekern | knz: http://github.com/openrisc/or1k-src | 05:11 |
| knz | stekern: thx | 05:11 |
| hansfbaier | stekern: I use this board: http://www.wvshare.com/product/OpenEP4CE10-C-Standard.htm | 05:12 |
| hansfbaier | Memory is a H57V1262GTR | 05:12 |
| hansfbaier | memory controller is wb_sdram_ctrl | 05:13 |
| hansfbaier | I modified the orpsoc de0_nano project | 05:13 |
| hansfbaier | since it came pretty close to my setup | 05:13 |
| hansfbaier | but I halved cpu data and isn caches to make it fit into the EP4CE10 | 05:14 |
| stekern | knz: you can use the build instructions from here: http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 | 05:14 |
| stekern | just change the target to or1knd-elf | 05:14 |
| hansfbaier | stekern: I used this one so far: http://kevinmehall.net/openrisc/guide/ | 05:15 |
| hansfbaier | is it outdated? | 05:15 |
| knz | thanks to both | 05:15 |
| knz | but I won't do either | 05:15 |
| knz | I am targeting a barebones binutils+gcc install | 05:15 |
| knz | no libc, no sysroot | 05:15 |
| hansfbaier | stekern: sorry | 05:16 |
| stekern | knz: ah well, the instructions are still valid, sans the newlib | 05:16 |
| hansfbaier | that post was to knx :] | 05:16 |
| knz | stekern: I just hope I can limit myself to the binutils in or1k-src | 05:17 |
| knz | there's a lot of stuff there otherwise | 05:17 |
| stekern | knz: I usually just build the whole newlib thing, even though I have a couple of projects where I'm not using anything of newlib (i.e. bare-bare-metal) | 05:18 |
| knz | iirc newlib assumes you have something of an OS to provide services, doesn't it? | 05:19 |
| stekern | no | 05:19 |
| knz | aha | 05:19 |
| knz | then I might consider | 05:20 |
| stekern | it's a "baremetal" libc | 05:20 |
| knz | well a "bare metal" libc that provides pthreads is an oxymoron | 05:20 |
| stekern | =) | 05:21 |
| knz | seriously, newlib is a bitch when you don't use linux headers | 05:21 |
| stekern | anyway, the way we are using it is kind of a convinence layer to build bare metal apps | 05:22 |
| knz | ok | 05:22 |
| stekern | so basically you can just do 'or1k-elf-gcc a.c -o a' and load a to the board and you're ready | 05:23 |
| knz | for the time being my use is for an architecture course and the students will not have the luxury of a libc | 05:23 |
| stekern | and startup code and friends is pulled in from newlib/libgloss | 05:23 |
| knz | hm | 05:24 |
| stekern | hansfbaier: ok, so I should be quite familiar with that, since I've been using the de0 nano alot, and I wrote that sdram controller | 05:24 |
| knz | any of you going at orconf? | 05:25 |
| stekern | hansfbaier: one thing that caused me problems was that the sdram clock phase had to be tweaked, otherwise problems as you are seeing would sometimes occur | 05:25 |
| stekern | knz: I am and olofk, _franck_, juliusb and jeremybennett at least too | 05:26 |
| knz | cool | 05:27 |
| stekern | knz: out of curiousity, at what institution are you giving the students the great benefit of working with or1k? | 05:28 |
| knz | hehe :) | 05:28 |
| knz | two of them | 05:28 |
| knz | university of amsterdam & university of leiden | 05:29 |
| knz | they got MIPS last year, and this year I wanted something different | 05:29 |
| hansfbaier | stekern: Thanks. There is one PLL in the design. Am I able to do it there or will I need to insert another PLL? | 05:29 |
| knz | plus, if I'm happy with the docs & tool chain I might use it in my research | 05:29 |
| knz | actually | 05:30 |
| hansfbaier | stekern: Ah I see | 05:30 |
| hansfbaier | it is that one PLL | 05:30 |
| hansfbaier | it is c0 | 05:31 |
| stekern | hansfbaier: yes, and there are some phase parameters in there. and they are usually board specific | 05:31 |
| hansfbaier | clock phase shift in ns | 05:33 |
| stekern | knz: cool, as a learning aid I think or1k is very well suited and similiar to MIPS, but with the added benefit of a lot more transparency (and open source implementations available) | 05:33 |
| knz | other practical question: any affordable dev boards that run or1k? | 05:33 |
| hansfbaier | stekern: Here it says phase shift: requested settings: -1.81ns, actual settings -1.75 | 05:33 |
| hansfbaier | stekern: How would I proceed here.... | 05:33 |
| stekern | hansfbaier: as a test, try to connect the sdram clock to the wb clock | 05:34 |
| hansfbaier | stekern: lower the requested settings? | 05:34 |
| hansfbaier | wb clock is much slower? | 05:34 |
| hansfbaier | looks like sdram is 2x the main clock | 05:34 |
| stekern | the default settings for de0 nano is 50 MHz for wb and 100 MHz for sdram | 05:35 |
| knz | ok I'm changing desks, ttyl | 05:35 |
| stekern | knz: the de0 nano board is pretty affordable and used a lot | 05:35 |
| stekern | hansfbaier: for more information about the actual phase shifting, look at this commit where I added that: http://git.openrisc.net/cgit.cgi/stefan/orpsoc/commit/?id=192293d3ea08ebb826583d013ef2c67e7d7980f7 | 05:37 |
| stekern | there are links to some altera documentation regarding how you should decide on the value of it | 05:38 |
| stekern | but try using the wb clock first | 05:39 |
| hansfbaier | stekern: Great! Thanks a lot.... | 05:41 |
| stekern | hansfbaier: and to take a step back, where did you have those timing failures? | 05:43 |
| hansfbaier | stekern: where in which context? | 05:45 |
| hansfbaier | stekern: in altera timequest analyzer, I had a couple of complaints | 05:45 |
| hansfbaier | about negative slack times related to the sdram controller | 05:46 |
| hansfbaier | stekern: wait for screenshot | 05:46 |
| hansfbaier | stekern: screenshot not coming, just compiling with sdram clock connected to wb clock | 05:46 |
| stekern | heh, ok. so perhaps the phase is ok, but the timing constraints isn't met for the 100 MHZ clock | 05:48 |
| stekern | we can hope that reducing that clk freq by /2 will make those disappear too | 05:49 |
| hansfbaier | stekern: with sdram clock connected to wb clock | 05:52 |
| hansfbaier | I get different timing errors in timequest related to altsyncram, not sdram anymore | 05:53 |
| hansfbaier | less is garbled | 05:53 |
| hansfbaier | but the address pointers of absolute jumps | 05:53 |
| hansfbaier | stekern: or maybe I try go back to 100MHz and shift the phase like in the diff, let me try that | 05:54 |
| stekern | hmm, didn't you have the phase shift as in the diff? | 05:57 |
| hansfbaier | stekern: Yes it was already in my code | 05:58 |
| hansfbaier | but I used -1900 instead of -1807 now | 05:58 |
| hansfbaier | stekern: kindof blind shoot-in-the-bush approach | 05:59 |
| stekern | but the timing errors sounds worrying, exactly what altsyncram is it complaining about | 05:59 |
| hansfbaier | stekern: sorry compiling again with -1900, | 05:59 |
| hansfbaier | will send the report | 05:59 |
| stekern | yeah, no problem, I'm in no hurry | 05:59 |
| hansfbaier | stekern: we need to adjust our phase shift haha | 06:00 |
| hansfbaier | stekern: Thanks for your patience and kindness | 06:00 |
| stekern | but I'd leave the sdram clock connected to the wb clock, that should at least be pretty safe and you avoid the CDC between the clocks (which *should* be handled properly in the memory controller, I've put effort into that, but taking away possible errro producing variables is always good) | 06:02 |
| stekern | and the second thing to try is to reduce the wb clock, just to get rid of the timing errors | 06:03 |
| stekern | if that works, then you can be pretty sure that your problems are caused by the timing errors and we can start looking into if/how they can be fixed | 06:04 |
| hansfbaier | stekern: https://dl.dropboxusercontent.com/u/3377727/orpsoc-TimeQuest%20Timing%20Analyzer.rpt | 06:08 |
| hansfbaier | stekern: If I connect sdram clock to wb clock I need to set the frequency parameter of the sd controller to 50MHz (or whatever), right? | 06:09 |
| hansfbaier | stekern: What would be the most elegant way to connect the wb to sdram clk, I did it with an assign in the pll module | 06:10 |
| hansfbaier | stekern: or would be top better? | 06:10 |
| stekern | hansfbaier: yes, the frequency parameter should be adjusted | 06:31 |
| stekern | but as long as you're not clocking it faster than what you state there, it shouldn't brake it if you don't change it | 06:31 |
| stekern | it will just do the refreshes more often | 06:32 |
| stekern | umm, no, scratch that.. I've got my logic turned the wrong way around... | 06:33 |
| stekern | ... so let's just say, "yes, you need to adjust the parameter" | 06:34 |
| stekern | =) | 06:34 |
| hansfbaier | stekern: Ok now I'm compiling the whole design for 25MHz | 06:34 |
| hansfbaier | changed the divider on c1 to 2 | 06:34 |
| hansfbaier | and | 06:35 |
| hansfbaier | assign sdram_clk_o = wb_clk_o; | 06:35 |
| hansfbaier | in clkgen.v | 06:35 |
| stekern | yes, that is the "cleanest" place to do that I think | 06:35 |
| hansfbaier | stekern: great, thanks | 06:36 |
| hansfbaier | Warning (15064): PLL "clkgen:clkgen0|pll:pll0|altpll:altpll_component|pll_altpll:auto_generated|pll1" output port clk[1] feeds output pin "sdram_clk_pad_o~output" via non-dedicated routing -- jitter performance depends on switching rate of other design elements. Use PLL dedicated clock outputs to ensure jitter performance | 06:36 |
| hansfbaier | Or better use clk0 and clk1 separately, but with identical settings? | 06:37 |
| stekern | yeah, I know, but lets ignore that for now | 06:37 |
| hansfbaier | stekern: now the timing errors are gone | 06:43 |
| hansfbaier | but | 06:43 |
| hansfbaier | it says Fmax is 36.36 MHz | 06:44 |
| hansfbaier | on clkgen0|pll0|altpll_component|auto_generated|pll1|clk[1] | 06:44 |
| hansfbaier | I don't really know how i should read this. The oscillator which feeds sysclk_pad_i | 06:45 |
| hansfbaier | runs 50MHz | 06:45 |
| stekern | mmm... and you divided that by 2, to get the 25 MHz clock, right? | 06:46 |
| stekern | the Fmax is just an indication on how fast you *could* clock your design | 06:46 |
| hansfbaier | stekern: http://i.imgur.com/hRM3D3x.png | 06:47 |
| stekern | and now it is > than what you *are* clocking it, which means you're fine | 06:47 |
| hansfbaier | stekern: ok that's what I thought | 06:47 |
| hansfbaier | great | 06:47 |
| hansfbaier | thanks | 06:47 |
| hansfbaier | the code seems to be fine right now | 06:47 |
| stekern | yup | 06:47 |
| hansfbaier | but the addresses of the jumps goes nowhere | 06:47 |
| hansfbaier | that's weird | 06:48 |
| hansfbaier | stekern: saw the screenshot? | 06:48 |
| stekern | yes | 06:48 |
| stekern | goes nowhere? what do you mean? | 06:48 |
| hansfbaier | l.bnf 0xfffffffe | 06:49 |
| hansfbaier | vs l.bnf 124 <t1> | 06:49 |
| hansfbaier | which should be equivalent to: | 06:49 |
| hansfbaier | l.bnf 124 | 06:49 |
| hansfbaier | but it's 0xfffffffe | 06:50 |
| hansfbaier | weird | 06:50 |
| stekern | ah, no, that's all fine | 06:50 |
| hansfbaier | stekern: really/ | 06:50 |
| hansfbaier | ? | 06:50 |
| hansfbaier | How so? | 06:50 |
| hansfbaier | RTFM | 06:50 |
| stekern | the branches use relative addresses (relative to the current pc) | 06:50 |
| hansfbaier | ? | 06:50 |
| hansfbaier | aaaah negative | 06:50 |
| hansfbaier | I see | 06:50 |
| stekern | so what's encoded in the instruction is just a -8 offset | 06:51 |
| hansfbaier | stekern: yes, thats ok | 06:51 |
| stekern | yup | 06:51 |
| hansfbaier | cool | 06:51 |
| hansfbaier | let's run this baby | 06:51 |
| stekern | let's ;) | 06:52 |
| hansfbaier | stekern: ok fine | 06:53 |
| hansfbaier | now the PC doesn't go into outer space any more | 06:53 |
| hansfbaier | stekern: weird thing, the LEDs don't light up anymore grrrr | 06:53 |
| stekern | :( | 06:54 |
| hansfbaier | stekern: before the LEDs lit before it jumped into outer space | 06:54 |
| hansfbaier | hmmmm | 06:54 |
| hansfbaier | what could it be... | 06:54 |
| stekern | oh, I might know | 06:57 |
| hansfbaier | stekern: you have my undivided attention | 06:57 |
| hansfbaier | stekern: are you german BTW? | 06:58 |
| stekern | no, I'm swedish, but currently living in finland | 06:59 |
| hansfbaier | stekern: ah I am german living in indonesia :) | 07:00 |
| stekern | in <board-path>/rtl/verilog/gpio/gpio.v change this row: gpio_dir[7:0] <= ~wb_dat_i; to: gpio_dir[7:0] <= wb_dat_i; | 07:00 |
| stekern | that's a workaround for a bug in a linux driver, it shouldn't be there in the rtl, it should be fixed in the driver | 07:01 |
| stekern | I have a fix for that in my working dir that I need to push, but I've made some other changes to how the direction logic works (removed the 'inout') and I'll need to adapt to all other boards before I can push that | 07:03 |
| _franck_ | hansfbaier: great to here your are making progress | 07:04 |
| hansfbaier | _franck_: Yes, with a lot of handholding.... Thanks so much guys | 07:05 |
| hansfbaier | I'll try to be brave and try boot linux now hehe | 07:05 |
| hansfbaier | while the synthesizer runs | 07:05 |
| stekern | hansfbaier: remember to change the clock frequency in the device tree configuration file then | 07:07 |
| hansfbaier | stekern: good idea :) | 07:07 |
| hansfbaier | WOOOOOOOOOOOOOOT! | 07:10 |
| hansfbaier | the LEDs blink | 07:10 |
| hansfbaier | awesome!!!! | 07:10 |
| _franck_ | welcome to the openrisc world ! | 07:11 |
| hansfbaier | THANKS a lot! | 07:11 |
| hansfbaier | THE LINUX KERNEL BOOTS | 07:13 |
| stekern | yup, in the openrisc world blinking with leds is our greatest satisfaction! | 07:13 |
| hansfbaier | Compiled-in FDT at c0265840 | 07:13 |
| hansfbaier | Linux version 3.4.0 (jack@jack-desktop) (gcc version 4.5.1-or32-1.0rc4 (GCC) ) #3 Wed Aug 28 14:10:53 WIT 2013 | 07:13 |
| hansfbaier | CPU: OpenRISC-12 (revision 8) @25 MHz | 07:13 |
| hansfbaier | -- dcache: 8192 bytes total, 16 bytes/line, 1 way(s) | 07:13 |
| hansfbaier | -- icache: 8192 bytes total, 16 bytes/line, 1 way(s) | 07:13 |
| hansfbaier | -- dmmu: 64 entries, 1 way(s) | 07:13 |
| hansfbaier | -- immu: 64 entries, 1 way(s) | 07:13 |
| hansfbaier | ... | 07:13 |
| stekern | cool! | 07:13 |
| hansfbaier | Thanks a lot! | 07:14 |
| hansfbaier | Your patience with me was extraordinary | 07:14 |
| _franck_ | you can now run barebox and add a lot of drivers in there ;) | 07:15 |
| hansfbaier | May thanks | 07:15 |
| hansfbaier | _franck_: barebox is a bootmanager, right? | 07:15 |
| _franck_ | it's like uboot | 07:16 |
| stekern | hansfbaier: you know how to ask questions without straining peoples patience, that helps a lot | 07:16 |
| _franck_ | kind of an uboot v2 | 07:16 |
| hansfbaier | stekern: thanks for the kind words | 07:16 |
| hansfbaier | I try to be the 'minimally dump' newbie | 07:16 |
| hansfbaier | s/dump/dumb/ | 07:16 |
| hansfbaier | I know spare time is precious | 07:17 |
| hansfbaier | nevertheless | 07:17 |
| hansfbaier | your effort was out of the ordinary | 07:17 |
| _franck_ | during my dayjob I have more spare time than at night sometime ;) | 07:17 |
| hansfbaier | question: Is linux supposed to start a shell or something | 07:17 |
| hansfbaier | just seems to hang there | 07:18 |
| _franck_ | how did you get cpuinfo ? Not using a shell ? | 07:19 |
| stekern | _franck_: that's what it spits out during boot | 07:20 |
| hansfbaier | Just the bootmessages from the serial | 07:20 |
| _franck_ | ah ok, sorry | 07:20 |
| hansfbaier | maybe I have too little memory | 07:20 |
| stekern | hansfbaier: where does it hang? i.e., what's the last message? | 07:20 |
| stekern | how much memory do you have? | 07:21 |
| stekern | (i probably could find out from the part nr you gave me, but it's easier to ask) | 07:21 |
| hansfbaier | http://pastebin.com/r99Jh5Nq | 07:22 |
| hansfbaier | 128MBit | 07:23 |
| hansfbaier | That would be 16MB | 07:23 |
| hansfbaier | should be enough | 07:23 |
| hansfbaier | I started using linux on a 386SX with 4MB RAM | 07:23 |
| stekern | hmm, yes, that should be enough | 07:23 |
| stekern | heh, yes, but you can't make that analogy, linux has became "bloated" since then | 07:24 |
| stekern | I think you should be able to go down to 8MB, but 16MB should be enough | 07:25 |
| stekern | how large is your vmlinux? | 07:25 |
| stekern | ...and if you break with gdb, what is it doing when it's frozen? | 07:28 |
| hansfbaier | vmlinux is 4759054 | 07:30 |
| hansfbaier | should be alright | 07:30 |
| hansfbaier | Memory: 12368k/16384k available (2054k kernel code, 4016k reserved, 299k data, 1416k init, 0k highmem) | 07:37 |
| hansfbaier | mem_init_done ........................................... | 07:37 |
| hansfbaier | Unpacking initramfs | 07:37 |
| hansfbaier | Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled | 07:37 |
| hansfbaier | 90000000.serial: ttyS0 at MMIO 0x90000000 (irq = 2) is a 16550A | 07:37 |
| hansfbaier | console [ttyS0] enabled, bootconsole disabled | 07:37 |
| hansfbaier | console [ttyS0] enabled, bootconsole disabled | 07:37 |
| hansfbaier | NET: Registered protocol family 17 | 07:37 |
| hansfbaier | Freeing unused kernel memory: 1416k freed | 07:37 |
| hansfbaier | weird | 07:37 |
| hansfbaier | but bootconsole = ttyS0???? | 07:38 |
| hansfbaier | looks like a linux config problem... | 07:38 |
| stekern | nah, that seems fine | 07:38 |
| hansfbaier | stekern: hmmm but where would my shell prompt be...?? | 07:39 |
| hansfbaier | I only have one uart | 07:40 |
| stekern | ah, it's that one | 07:40 |
| _franck_ | ah, the bug hno found | 07:41 |
| _franck_ | ? | 07:41 |
| stekern | yes, but that's not yet introduced in the kernel he is using | 07:41 |
| hansfbaier | it's looping somewhere around 0x000f60b0 | 07:43 |
| stekern | weird | 07:43 |
| hansfbaier | linux$ git pull | 07:44 |
| hansfbaier | remote: Counting objects: 95830, done. | 07:44 |
| hansfbaier | remote: Compressing objects: 100% (12968/12968), done. | 07:44 |
| hansfbaier | that's quite a bunch of patches | 07:44 |
| hansfbaier | let's see if it fixes something | 07:44 |
| _franck_ | https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=258a9fd17b92552637bc74776c11737e0472dc86 | 07:45 |
| _franck_ | but your seem ok | 07:45 |
| enghong | du coup, 100M, c'est un peu violent, mais bon :) | 07:45 |
| enghong | oups, sorry :) | 07:45 |
| stekern | this is what you would expect to see after your output: http://pastie.org/8276424 | 07:46 |
| hansfbaier | haha, the linux kernel does not like the LED blinky being flashed to RAM while it is running. | 07:46 |
| stekern | presumably not =) but how do you even do that? | 07:47 |
| hansfbaier | stekern: used the download script from tcl-tools | 07:48 |
| hansfbaier | I thought that would reset the machine, but no.... | 07:48 |
| hansfbaier | behaved funny the linux kernel haha | 07:49 |
| stekern | oh, of course, I thought you were using gdb | 07:49 |
| hansfbaier | Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007 | 07:49 |
| hansfbaier | Unable to handle kernel NULL pointer dereference at virtual address 0x00000100 | 07:49 |
| hansfbaier | Oops#: 0000 | 07:49 |
| hansfbaier | even then impressive it still manages to get the message out to serial | 07:49 |
| stekern | yeah, that's funny. so what happened was that the loader script tried to jump to 0x100, but the mmu is turned on so a tlb miss will occur when the fetch from that address is performed | 07:51 |
| stekern | and the kernel will scream and shout when it doesn't find a valid mapping for that address | 07:52 |
| stekern | that's why I always do the spr sr 0x1 in gdb, that will turn off mmu's, caches and interrupts | 07:53 |
| stekern | presumably that can be added to the loader script as well | 07:54 |
| _franck_ | stekern: if I can remember how it works ;) | 07:54 |
| stekern | =) | 07:55 |
| hansfbaier | stekern: After I pulled the fix is already in there, so let's compile the kernel... | 07:55 |
| stekern | where did you pull from and what was your starting point? | 08:07 |
| hansfbaier | stekern: [submodule "linux"] | 08:11 |
| hansfbaier | url = git://openrisc.net/jonas/linux | 08:11 |
| hansfbaier | stekern: one weird thing is, when I try to start linux inside gdb like you wrote: spr sr 1; spr npc 0x100; c | 08:14 |
| hansfbaier | won't work | 08:14 |
| hansfbaier | but when I input those commands | 08:14 |
| hansfbaier | one by one without semicolon it works | 08:14 |
| hansfbaier | gdb bug? | 08:14 |
| hansfbaier | Looks like the spr command does not like the semicolons | 08:15 |
| hansfbaier | grr after the pull and recompile the kernel won't boot anymore | 08:24 |
| hansfbaier | maybe I need to pull everything the whole toolchain | 08:24 |
| hansfbaier | stekern: _franck_: which tag should I use | 08:30 |
| hansfbaier | is head ok? | 08:30 |
| _franck_ | don't know | 08:31 |
| hansfbaier | _franck_: what baudrate to use for serial | 08:34 |
| hansfbaier | on barebox? | 08:34 |
| hansfbaier | spits out garbage | 08:34 |
| hansfbaier | on 115200 | 08:34 |
| hansfbaier | aah need to adapt clock freq | 08:34 |
| hansfbaier | Bingo | 08:37 |
| hansfbaier | but hangs | 08:37 |
| hansfbaier | $ miniterm.py /dev/ttyUSB0 115200 | 08:37 |
| hansfbaier | --- Miniterm on /dev/ttyUSB0: 115200,8,N,1 --- | 08:37 |
| hansfbaier | --- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H --- | 08:37 |
| hansfbaier | barebox 2013.08.0-00167-g14ac2e4-dirty #2 Wed Aug 28 15:36:20 WIT 2013 | 08:37 |
| hansfbaier | Board: or1k | 08:37 |
| stekern | hansfbaier: ah, sorry, I was just lazy and delimited each command row by ';' | 08:44 |
| stekern | they were indeed meant to be entered seperately | 08:45 |
| stekern | and master from jonas repo should be fine, I've booted that on de0 nano | 08:48 |
| hansfbaier | stekern: git://openrisc.net/stefan/orpsoc | 08:52 |
| hansfbaier | that's yours | 08:52 |
| stekern | mmm | 08:52 |
| hansfbaier | this is orpsocv3,right? | 08:52 |
| stekern | no, it's orpsocv2 | 08:52 |
| hansfbaier | ah | 08:52 |
| hansfbaier | ok | 08:52 |
| hansfbaier | stekern: weird, just hangs | 08:53 |
| hansfbaier | linux that is | 08:53 |
| hansfbaier | grrr | 08:53 |
| hansfbaier | regression | 08:53 |
| stekern | are you sure it's not just the gdb loading that acts up, it can be a bit tempramental sometimes | 08:54 |
| hansfbaier | maybe | 08:55 |
| hansfbaier | he's getting tired | 08:55 |
| stekern | usually, the best way to ensure that it succeeds is to: de-attach gdb and and openocd, reset the board (or reprogram it) attach openocd and gdb | 08:56 |
| stekern | and then load | 08:56 |
| hansfbaier | stekern: ah | 08:58 |
| hansfbaier | stekern: thanks | 08:58 |
| * hansfbaier blinks some LEDs while kernel compiles to refresh his mind | 08:58 | |
| hansfbaier | stekern: you were right | 09:02 |
| hansfbaier | boots again | 09:02 |
| hansfbaier | but still hangs :-| | 09:02 |
| hansfbaier | ahhhh | 09:04 |
| * hansfbaier messed up his Linux USB stack need reboot :{ | 09:10 | |
| hansfbaier | stekern: Kernel command line: console=uart,mmio,0x90000000,115200 | 09:25 |
| hansfbaier | Early serial console at MMIO 0x90000000 (options '115200') | 09:25 |
| hansfbaier | still hangs :[ | 09:26 |
| hansfbaier | I probably should call it a day | 09:27 |
| stekern | that miniterm.py seemed so nice that I had to give it a go =) | 09:27 |
| stekern | I don't like minicom, and screen is good, but a pain when you use it inside another screen | 09:28 |
| stekern | but, it seems like it's somewhere in init that you freeze... hard to say what cause that | 09:29 |
| stekern | possibly still some hardware issue | 09:29 |
| hansfbaier | stekern: when I break | 09:35 |
| hansfbaier | I only get disassembly | 09:35 |
| hansfbaier | aren't I supposed to get source code? | 09:35 |
| hansfbaier | list just returns | 09:35 |
| hansfbaier | the beginning of the source | 09:36 |
| hansfbaier | mabe this helps: http://elinux.org/Debugging_The_Linux_Kernel_Using_Gdb | 09:36 |
| hansfbaier | ah might have to enable compiling with debug info | 09:37 |
| stekern | that and you have to do: file vmlinux | 09:38 |
| stekern | I hardly use that though, I just check where it breaks and then run obdjump -d vmlinux manually | 09:38 |
| hansfbaier | got it | 09:38 |
| hansfbaier | ah | 09:39 |
| hansfbaier | good to know | 09:39 |
| stekern | and then just grep the source for the function that indicates | 09:39 |
| stekern | but perhaps I just have masochistic tendencies ;) | 09:41 |
| hansfbaier | nfs3_rpc_wrapper.clone.8 | 09:41 |
| hansfbaier | NFS3???? | 09:42 |
| stekern | humm, exactly: ??? | 09:42 |
| hansfbaier | wrong | 09:42 |
| hansfbaier | wait | 09:42 |
| hansfbaier | no correct | 09:43 |
| hansfbaier | weird | 09:43 |
| hansfbaier | maybe try to disable NFS3 in kernel. | 09:43 |
| hansfbaier | Or might have been a wild jump | 09:43 |
| hansfbaier | (gdb) bt | 09:44 |
| hansfbaier | #0 0x000f60b4 in ?? () | 09:44 |
| hansfbaier | #1 0x000f60b4 in ?? () | 09:44 |
| hansfbaier | Backtrace stopped: previous frame identical to this frame (corrupt stack?) | 09:44 |
| hansfbaier | that's looks suspicious | 09:44 |
| stekern | if you do spr info sys, what does r9 say? | 09:45 |
| _franck_ | you should try to disable icache and dcache. I had some hanging problem we fixed here: http://git.openrisc.net/cgit.cgi/stefan/orpsoc/commit/?id=7ccad7e1c122b7289c3a361059b4a4f3438da6e9 | 09:47 |
| _franck_ | I didn't have those problems with caches disabled | 09:47 |
| hansfbaier | (gdb) spr info sys | 09:48 |
| hansfbaier | Group or register name not recognized. | 09:48 |
| hansfbaier | r9 0x108ad41084116 | 09:48 |
| hansfbaier | info reg | 09:48 |
| _franck_ | stekern: FYI "spr info sys" is be deprecated in or1k-elf-gdb (because of openocd). That will be "info registers system" | 09:49 |
| stekern | yes, sorry: info spr sys | 09:50 |
| stekern | I always forget the order of those | 09:50 |
| stekern | anyways, waht do you have at 0x108ad4? | 09:52 |
| hansfbaier | Weird, I wonder why NFS client support is enabled in the kernel | 09:54 |
| hansfbaier | threw it out | 09:54 |
| hansfbaier | 18 80 c0 21 l.movhi r4,0xc021 | 09:55 |
| hansfbaier | belongs to <kobject_uevent_env> | 09:56 |
| stekern | I think jonas used to mount the rootfs over nfs at some point in the history, probably a reminiscent of that | 09:56 |
| hansfbaier | identical to objdump | 09:56 |
| stekern | ok, what do you have at 0x108ad4 - 8 | 09:57 |
| stekern | because that's presumably the wild jump source | 09:57 |
| stekern | not sure if this is going to lead us anywhere, but it's usually good to have some clue about what's happening | 09:58 |
| hansfbaier | stekern: In gdb or objdump? | 09:58 |
| hansfbaier | gdb i assume | 09:58 |
| hansfbaier | wait need to reboot | 09:59 |
| hansfbaier | wrecked the linux usb stack again | 09:59 |
| hansfbaier | c0108ac4: a4 84 00 01 l.andi r4,r4,0x1 | 09:59 |
| hansfbaier | c0108ac8: 9c 60 00 0c l.addi r3,r0,0xc | 09:59 |
| hansfbaier | c0108acc: d4 02 18 34 l.sw 0x34(r2),r3 | 09:59 |
| hansfbaier | c0108ad0: 84 8e 00 00 l.lwz r4,0x0(r14) | 09:59 |
| hansfbaier | c0108ad4: a4 84 00 01 l.andi r4,r4,0x1 | 09:59 |
| hansfbaier | objdump | 09:59 |
| hansfbaier | ^ | 09:59 |
| stekern | humm, why does that differ from 18 80 c0 21 l.movhi r4,0xc021? | 10:07 |
| hansfbaier | (gdb) nexti | 10:08 |
| hansfbaier | 0x000f60b4 in ?? () | 10:08 |
| hansfbaier | (gdb) nexti | 10:08 |
| hansfbaier | 0x000f60b0 in ?? () | 10:08 |
| hansfbaier | (gdb) nexti | 10:08 |
| hansfbaier | 0x000f60b4 in ?? () | 10:08 |
| hansfbaier | (gdb) nexti | 10:08 |
| hansfbaier | 0x000f60b0 in ?? () | 10:08 |
| hansfbaier | (gdb) nexti | 10:08 |
| hansfbaier | 0x000f60b4 in ?? () | 10:08 |
| hansfbaier | (gdb) nexti | 10:08 |
| hansfbaier | 0x000f60b0 in ?? () | 10:08 |
| hansfbaier | (gdb) nexti | 10:08 |
| hansfbaier | 0x000f60b4 in ?? () | 10:08 |
| hansfbaier | same behavior | 10:08 |
| hansfbaier | totally different instructions (NFS disabled) | 10:09 |
| hansfbaier | looks like a hardware bug | 10:09 |
| hansfbaier | will try now with caches disabled | 10:09 |
| stekern | yeah, that's a good idea | 10:09 |
| hansfbaier | => 0x000f60b0:l.jal 0x30869 | 10:09 |
| hansfbaier | 0x000f60b4:l.addi r3,r3,0x360 | 10:09 |
| hansfbaier | 0x000f60b8:l.jal 0x31079 | 10:09 |
| hansfbaier | 0x000f60bc:l.nop 0x0 | 10:09 |
| hansfbaier | same thing with caches disabled :( | 10:13 |
| hansfbaier | same address | 10:13 |
| hansfbaier | grrrr | 10:13 |
| hansfbaier | at least it is deterministic | 10:13 |
| hansfbaier | CPU: OpenRISC-12 (revision 8) @25 MHz | 10:14 |
| hansfbaier | -- dcache: 8192 bytes total, 16 bytes/line, 1 way(s) | 10:14 |
| hansfbaier | -- icache: 8192 bytes total, 16 bytes/line, 1 way(s) | 10:14 |
| hansfbaier | wait doesn't look like that. | 10:14 |
| hansfbaier | weird. | 10:14 |
| stekern | how did you disable them? | 10:14 |
| stekern | you have to do that in the or1200-defines.v file | 10:14 |
| hansfbaier | yes I thought I did | 10:14 |
| hansfbaier | wait | 10:14 |
| stekern | (and in the right place) | 10:14 |
| stekern | it's a bit messy, something we are doing better in mor1kx ;) | 10:15 |
| hansfbaier | `define OR1200_NO_DC | 10:15 |
| hansfbaier | `define OR1200_NO_IC | 10:15 |
| hansfbaier | but | 10:16 |
| hansfbaier | also | 10:16 |
| hansfbaier | `define OR1200_IC_1W_8KB | 10:16 |
| hansfbaier | `define OR1200_DC_1W_8KB | 10:16 |
| hansfbaier | maybe I have to comment the latter two | 10:16 |
| hansfbaier | aaaa | 10:16 |
| hansfbaier | that was in ASIC | 10:16 |
| hansfbaier | stekern: now it gives me lots of compile errors | 10:19 |
| hansfbaier | I commented `define OR1200_IC_1W_8KB | 10:19 |
| hansfbaier | etc | 10:19 |
| hansfbaier | shouldn't I? | 10:19 |
| stekern | no, just uncomment the OR1200_NO_xC | 10:20 |
| stekern | for FPGA | 10:20 |
| hansfbaier | ok | 10:20 |
| hansfbaier | CPU: OpenRISC-12 (revision 8) @25 MHz | 10:28 |
| hansfbaier | -- dcache disabled | 10:28 |
| hansfbaier | -- icache disabled | 10:28 |
| hansfbaier | still hangs | 10:28 |
| hansfbaier | grrrrrr | 10:28 |
| hansfbaier | but on a different address now | 10:28 |
| hansfbaier | function __lshrdi3 | 10:30 |
| hansfbaier | stekern, _franck_: ^ | 10:30 |
| hansfbaier | but same behavior: | 10:31 |
| hansfbaier | (gdb) nexti | 10:31 |
| hansfbaier | 0x000ea740 in ?? () | 10:31 |
| hansfbaier | (gdb) | 10:31 |
| hansfbaier | 0x000ea744 in ?? () | 10:31 |
| hansfbaier | (gdb) | 10:31 |
| hansfbaier | 0x000ea740 in ?? () | 10:31 |
| hansfbaier | (gdb) | 10:31 |
| hansfbaier | 0x000ea744 in ?? () | 10:31 |
| hansfbaier | (gdb) | 10:31 |
| hansfbaier | 0x000ea740 in ?? () | 10:31 |
| hansfbaier | (gdb) | 10:31 |
| hansfbaier | weird | 10:31 |
| hansfbaier | So I'd call it a day now | 10:31 |
| hansfbaier | or I'll get family problems :) | 10:31 |
| hansfbaier | Anyway, thanks a LOT | 10:31 |
| * hansfbaier blinks some LEDs for enjoyment | 10:31 | |
| stekern | =) | 10:32 |
| stekern | next step would be to attach signaltap and look at some waveforms from the failure | 10:32 |
| hansfbaier | stekern: Will have to read up on signaltap | 10:32 |
| hansfbaier | is that the altera logic analyzer? | 10:33 |
| stekern | yes | 10:33 |
| hansfbaier | stekern: recommended readings? | 10:33 |
| hansfbaier | will google | 10:33 |
| stekern | it's pretty straight forward, open it up and play with it from quartus | 10:34 |
| stekern | your biggest problem will be that it will hog your usb-blaster port | 10:34 |
| hansfbaier | _franck_: barebox also hans | 10:34 |
| hansfbaier | hangs | 10:34 |
| hansfbaier | Yes, already put that into its own roothub | 10:35 |
| hansfbaier | Yes, I will put it into ... | 10:35 |
| hansfbaier | stekern: Which nodes to inspect? | 10:38 |
| stekern | hmm, it was quite a long time since I looked inside or1200, I'm more familiar with mor1kx, but the execute pc would be a good candidate to just get a nice trace of instruction flow | 10:39 |
| stekern | ...that's another thing you could try, swap in mor1kx for or1200 | 10:42 |
| hansfbaier | stekern: Ok I've got to call it a day now. | 10:43 |
| hansfbaier | timeout | 10:43 |
| hansfbaier | Many thanks! | 10:43 |
| knz | success: got my or1knd toolchain running | 12:13 |
| stekern | knz: yay! | 12:18 |
| knz | hmm | 12:22 |
| knz | small practical quesiton, is the standard ABI in the reference manual? | 12:22 |
| knz | yeah, found it | 12:22 |
| knz | other question: what are the .cfi_* directives for? | 12:27 |
| knz | (to the point: can I strip them away from my gcc-generated, hand-modified assembly?) | 12:28 |
| knz | never mind (exception handling) | 12:39 |
| stekern | knz, yeah exception handling (as in c++) exceptions | 14:20 |
| stekern | you can safely strip them for your purposes I'd say | 14:21 |
| knz | yes I did | 14:21 |
| knz | I am surprise that they are still generaed when I compile with -fno-exceptions | 14:21 |
| knz | +d | 14:21 |
| stekern | blueCmd is our cfi guru, maybe he has some insight on that | 14:26 |
| olofk | Jesus christ. That was the busiest backlog I have read in ages | 14:28 |
| stekern | but -fno-asynchronous-unwind-tables should prevent them at least | 14:29 |
| stekern | olofk: great isn't it ;) | 14:30 |
| olofk | Yep. Every new face in the channel is a possible future code generator :) | 14:31 |
| blueCmd | knz: they are used for other things than exceptions IIRC | 14:31 |
| blueCmd | been a while since I did things with cfi, but stekern's -fno-asynchronous-unwind-tables is what I used to remove them IIRC | 14:31 |
| blueCmd | libc uses them all the time, I think one can use them to get stack traces and stuff like that | 14:34 |
| olofk | stekern: If I have understood things correctly, the mem model doesn't precharge because cas is low. Is precharge something that is normally done first? | 14:44 |
| knz | blueCmd: many thanks | 14:45 |
| stekern | olofk: I don't remember the details, but I don't think I did that sequence randomly | 14:47 |
| olofk | Ah. I had a very long powerup_delay set | 14:47 |
| olofk | What's that for anyway? | 14:47 |
| stekern | the chips need that, but I don't think the models care, so you can reduce that | 14:48 |
| olofk | Wouldn't the same effect be achieved by delaying the reset release? | 14:49 |
| stekern | basically yes, but the same logic would be needed to hold the reset line, so it can as well be explicit | 14:55 |
| olofk | stekern: I found the problem. I inverted ras, cas and we, as the were named *_n in the model | 19:46 |
| olofk | btw, WB_PORTS=1 doesn't seem to work | 19:47 |
| olofk | Still having some trouble though. Are bursts required to be of a certain length? | 20:34 |
| olofk | Hmm.. I'm getting acks without valid data from wb_sdram_ctrl | 20:53 |
| olofk | Ahh.. might be because I'm doing writes :) | 20:54 |
| _franck_ | hope this time my openocd patch will pass the review stage... | 20:55 |
| _franck_ | so I can focus on orpsocv3 | 20:55 |
| olofk | _franck_: Yeah, I hope so too. Both for openocd and orpsocv3 | 21:27 |
| --- Log closed Thu Aug 29 00:00:32 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
