| --- Log opened Fri Sep 25 00:00:58 2015 | ||
| _franck__ | andrzejr: you dont need gdb for your test . | 04:44 |
|---|---|---|
| _franck__ | just use openocd console (telnet on port 4444) | 04:45 |
| andrzejr | _franck_, yes, I'm using both. Two questions: | 07:15 |
| andrzejr | How do you download software to the chip. With this: https://github.com/fjullien/or1k-tcltools ? | 07:15 |
| andrzejr | Any clues for fixing the "readspr" error? | 07:16 |
| -!- orsonmmz|away is now known as orsonmmz | 07:41 | |
| _franck__ | andrzejr: or1k-tcltool must be used with altera virtual jtag | 09:11 |
| _franck__ | gdb readspr does not exist anymore | 09:12 |
| _franck__ | instead you can use ckassic gdb read and write registzr commands | 09:13 |
| _franck__ | to get register names do "info register timer" for example | 09:14 |
| _franck__ | but you can also do that with openocd | 09:14 |
| _franck__ | it haq been a while i havenr used gdb | 09:15 |
| _franck__ | cant help you more i boarding plane | 09:17 |
| andrzejr_ | _franck_: thank you, much appreciated. now I can use openocd I started to appreciate what I can do with it. eg downloading a hex file was a single command and it takes less than a second to execute | 10:55 |
| andrzejr_ | much better than my previous UART debug if. but, my, it was a pain to set it up starting from scratch. | 10:56 |
| ysionneau | still no schedule for orconf? | 13:39 |
| orsonmmz | for people looking for a hotel to staying during orconf - perhaps it is worth to look for a place in Saint Genis-Pouilly | 14:08 |
| orsonmmz | it is actually closer to CERN than Geneva | 14:08 |
| orsonmmz | might be also a bit cheaper, as its on the French side | 14:09 |
| orsonmmz | but I do not have any specific recommendations | 14:09 |
| maxpaln | so, I now have a nice fresh Ubuntu install on VirtualBox :-) I'm now going to set about installing the tool chains etc. | 14:48 |
| maxpaln | From the descriptions I am guessing I should be using the musl toolchain... | 14:49 |
| maxpaln | ok, it must be getting late in the week - I incorrectly followed the instructions here: | 15:11 |
| maxpaln | http://opencores.org/or1k/OpenRISC_GNU_tool_chain | 15:11 |
| maxpaln | I am now prt way through the 'Linux (uClibc) toolchain (or1k-linux-uclibc)' instructions instead of the musl version. | 15:12 |
| maxpaln | since it isn't totally clear to me which tool chain is the one I need to ultimately run a multi-threaded Linux kernel (which is my ultimate aim in all of this) can anyone advise? | 15:13 |
| knz | probably you will want to use musl, as uclibc's thread support is not always stable | 15:13 |
| maxpaln | knz: thanks | 15:14 |
| maxpaln | Can these tool chains can sit alongside each other as long as I set the environment up accordingly? | 15:14 |
| knz | I would recommend doing so, yes | 15:14 |
| maxpaln | ok, great | 15:14 |
| knz | just install in separate directories | 15:14 |
| maxpaln | yep | 15:14 |
| maxpaln | coolio | 15:14 |
| maxpaln | also, I missed the note about installing or1ksim first (having a bad day) - does anyone know if I am destined for a life of misery by having completed the 'initial preparations' section of the uclib toolchain instructions without or1ksim installed? | 15:16 |
| knz | I am not sure | 15:17 |
| maxpaln | yeah, I doubt anyone is %-) | 15:18 |
| maxpaln | hmmm, ok. | 15:37 |
| maxpaln | so my uclib installation appears to be missing the sys-root directory. Bit weird - can't imagine this is related to the or1ksim out of sequence install but maybe so... | 15:39 |
| blueCmd | juliusb: olofk: any tips re: hotels in the area where orconf will be? | 15:45 |
| maxpaln | !144:p | 16:20 |
| maxpaln | oops - wrong window !:-) | 16:20 |
| stekern | maxpaln: you most probably want musl over uclibc | 16:31 |
| dalias | :) | 16:32 |
| -!- orsonmmz is now known as orsonmmz|away | 16:48 | |
| maxpaln | stekern: yeah - I had come to that conclusion. | 17:21 |
| maxpaln | I was just trying the installation since I started down it - | 17:22 |
| maxpaln | interestingly I found that the sys-root directory was missing from /opt/or1k-toolchain/or1k-linux-uclibc - | 17:23 |
| maxpaln | its listed as the directory for the headers in the 'Linux Headers' section | 17:23 |
| maxpaln | I thought this was a problem but now I am wondering if I just need to manually create this directory - I thought perhaps the previous step was supposed to create the directory but maybe not. Something to try later... | 17:24 |
| olofk | andrzejr: Great to hear that you've got things running | 21:37 |
| olofk | blueCmd: I'm staying at Nash airport hotel. Many others stay at IBIS. That's all I can say for recommendation | 21:37 |
| blueCmd | olofk: fair enough, nashed showed up when I looked for hotels so that's good to have as a reference then | 22:36 |
| blueCmd | thanks! | 22:36 |
| andrzejr | olofk, even better! I've finally found why newlib's hello.c program was not booting. so much easier with the debugger | 22:36 |
| blueCmd | now I just have to figure out if I shoulds sneak away early on friday to attend the first part of orconf, pretty tempted.. | 22:36 |
| andrzejr | btw, the error occurs in the startup code (in _or1k_cache_init) and is triggered by setting OPTION_ICACHE_BLOCK_WIDTH and OPTION_DCACHE_BLOCK_WIDTH to 4. | 23:12 |
| andrzejr | strangely, the code works in rtl simulation but fails in HW - _or1k_cache_init contains an infinite loop. | 23:13 |
| andrzejr | I was previously using 16B=128b cache lines because this size matches the width of DDR2 controller bus, so I expected it to be better for performance. My own cache enabling code worked fine but it wasn't doing any autodetection of cache sizes like _or1k_cache_init does. | 23:15 |
| --- Log closed Sat Sep 26 00:00:00 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!