--- Log opened Tue Oct 01 00:00:20 2013 | ||
stekern | juliusb: umm, check it in where? | 02:29 |
---|---|---|
stekern | gdb doesn't compile much after or1k-src sync... | 02:46 |
stekern | now it does | 03:19 |
stekern | I don't think I'll do the rebase after all | 03:19 |
stekern | or, I've already done it, but I don't think I'll push that. I'll push a merged tree instead. | 03:20 |
stekern | poke53282: I just successfully tested compiling a simple hello world with a native 4.9.0 gcc now | 03:29 |
stekern | so you should be able to switch over to that | 03:29 |
hansfbaier | stekern: Is there a test suite to make sure the self hosted gcc does alright? | 03:44 |
stekern | yes, but we haven't succeeded to build a selfhosted gcc yet | 03:44 |
stekern | we can build a native gcc using the cross compiler though | 03:45 |
hansfbaier | stekern: ah | 04:38 |
hansfbaier | ok | 04:38 |
hansfbaier | is there a test suite of some kind for that | 04:38 |
hansfbaier | ? | 04:38 |
stekern | yes, the same test suite | 05:23 |
stekern | i.e. the gcc regression tests | 05:24 |
stekern | but we haven't run that against the native gcc yet neither, running the tests takes about a day when they are compiled on a seperate machine and transferred and executed on the target | 05:25 |
_franck_ | juliusb: I never did that test (reset the board while openocd is connected) | 05:33 |
_franck_ | juliusb: it need to be fixed | 05:34 |
stekern | poke53282: I also put your vararg patch in a special branch: https://github.com/openrisc/or1k-gcc/tree/alt-vararg-cc | 07:46 |
juliusb | stekern: I mean can I commit these changes to the de0 nano core? how should we handle slight modifcations/variatns out of the box like this? | 08:31 |
juliusb | _franck_: ok cool, something for a TODO list :) | 08:31 |
stekern | juliusb: in general, I think it's best to just have a default and let people that don't like it adjust it in their local tree | 08:46 |
juliusb | ok, but for the workshop, how do you think we should handle this? have a patch or something? | 08:49 |
stekern | yeah, not sure | 08:50 |
stekern | cleanest would be to just insert another uart there | 08:52 |
juliusb | mm, not a bad idea! | 08:52 |
stekern | another option is to do what you did on the ml501 board connect the rx/tx to both places | 08:53 |
stekern | but there was some problem with that | 08:54 |
stekern | when the second uart wasn't connected | 08:54 |
juliusb | hmm yeah that's kinda messy | 08:54 |
stekern | I think that should be ok if you use internal pullups on the rx lines though | 08:56 |
stekern | but I think I'm happy with either, as long as you don't put it like in this picture: http://www.embecosm.com/2013/04/25/chip-hack-fpga-programming-for-beginners/ | 08:58 |
stekern | I have the LCD add-on connected to that | 08:58 |
juliusb | no it's on the other side | 09:00 |
stekern | that was the reason I choose the connector under the board for jtag and uart, all add-ons (well many are discontinued now) use the side connectors | 09:00 |
stekern | the uart or am I mixing up where I have my LCD? | 09:01 |
juliusb | https://raw.github.com/embecosm/chiphack/master/src/verilog_sessions/uart/de0-nano-embecosm-uart.jpg | 09:01 |
juliusb | that's where I'm connecting mine | 09:01 |
stekern | ok, yeah, other side. so the other one is a staged foto ;) | 09:02 |
stekern | *photo | 09:05 |
stekern | I really should have went to bed 3 hours earlier than I did yesterday... | 09:08 |
Powermaniac | So how is everyone OpenRISC projects going? | 10:01 |
Powermaniac | everyone's* | 10:05 |
olofk | juliusb, stekern: Generally speaking, systems are meant to be cheap. So if we want something out of the ordinary for the workshop, we could just create a new system based on de0_nano in a separate archive and use --cores-root to find it | 10:11 |
olofk | Powermaniac: I think it's business as usual. Some new stuff working. Other stuff is breaking apart :) | 10:13 |
Powermaniac | olofk: Ahh okay, I can't believe I can put Debian on ORPSoCv3 but can't put it on my Nexus 7...=\ | 10:14 |
Powermaniac | olofk: Well not as a full install exactly... | 10:14 |
olofk | I'm really stressed out about the orpsocv3 presentation at orconf right now. Can we delay the conference for a few months perhaps? :) | 10:14 |
olofk | Powermaniac: I don't think anyone has done a debian build for or1k. Seems like a huge amount of work to get that running | 10:15 |
Powermaniac | olofk: Oh...Hmm | 10:15 |
* hansfbaier compiles the sockit with orpsocv3 | 10:20 | |
hansfbaier | stekern / olofk: Is the current orpsoc able to accomodate 10 or1k cores? | 10:22 |
stekern | I don't think it's orpsoc that is teh limiting factor there | 10:22 |
stekern | *the | 10:22 |
hansfbaier | stekern: would be nice for the gcc regression suite, for parallel build | 10:24 |
hansfbaier | stekern: But the sockit probably can do something close to 10 cores. I run one on an EP4CE10 | 10:24 |
hansfbaier | stekern: What would be the limiting factor, block ram? | 10:25 |
Powermaniac | hansfbaier: 10 or1k cores holy O_O | 10:27 |
Powermaniac | hansfbaier: Trying to make a clone of the Parallella epiphany core but with or1k? | 10:27 |
stekern | yes, I was thinking about fpga resources | 10:28 |
hansfbaier | Powermaniac: No, just think that would be nice for running the gcc regression tests | 10:28 |
hansfbaier | stekern: maybe interconnect | 10:29 |
Powermaniac | Oh okay | 10:29 |
hansfbaier | Powermaniac: if that takes a whole day so 10 cores would cut that time down, hopefully | 10:30 |
hansfbaier | Powermaniac: and it would be cool | 10:30 |
hansfbaier | too | 10:30 |
stekern | but you can run the gcc test suite against or1ksim | 10:30 |
hansfbaier | stekern: Ah yes. Is that faster? | 10:31 |
stekern | and when jeremybennett used to do that a lot, he'd run several instances of or1ksim to get it parallel | 10:31 |
hansfbaier | stekern: When building sockit orpsocv3 I get this: Error (12006): Node instance "hps" instantiates undefined entity "sockit" File: /home/jack/HDL/src/openrisc/orpsocv3/orpsoc-cores/build/sockit/src/sockit/rtl/verilog/orpsoc_top.v Line: 570 | 10:32 |
stekern | no it's probably about the same, but the reference "1 day" was with or1ksim | 10:32 |
stekern | hansfbaier: yes, you need to generate the qsys generated system | 10:33 |
hansfbaier | stekern: is that in the docs? | 10:33 |
hansfbaier | there are no docs as it seems :) | 10:34 |
hansfbaier | hmmm | 10:34 |
hansfbaier | UTSL | 10:34 |
stekern | you can either do that by opening the .qsys file with the qsys gui and set the output directory to build/sockit/src/qsys/ | 10:34 |
stekern | or run it from commandline like this: http://pastie.org/8369255 | 10:35 |
olofk | ..or stekern could check in the generated files ;) | 10:36 |
stekern | never! | 10:36 |
stekern | have you seen the files it generates? | 10:36 |
hansfbaier | stekern: many thanks | 10:38 |
stekern | besides, are there no issues distributing the generated files? | 10:38 |
stekern | license/legal wise I mean | 10:39 |
stekern | with that logic we should check in the quartus project files, db, the resulting .sof as well ;) | 10:40 |
olofk | stekern: Yes, I know. Just wanted to annoy you. Sorry :) | 10:45 |
olofk | I'm as allergic to crappy generated files as you are. I have to force myself every time to accept the pull requests with generated PLL wrappers | 10:46 |
stekern | I've avoided them in sockit! | 10:46 |
stekern | but they are much nicer for cyclone iv | 10:47 |
hansfbaier | stekern: can you point me to a good intro for qsys? Purposefully avoiding google here.... | 10:47 |
stekern | https://github.com/skristiansson/orpsoc-cores/blob/master/systems/sockit/rtl/verilog/clkgen.v#L121 | 10:47 |
stekern | hansfbaier: humm, for just generating, you open the last page in the qsys gui and press generate. | 10:48 |
stekern | as for editing... you click around until you learn how it works... or that's how I did it at least | 10:49 |
stekern | but the only thing the qsys generated system does is to instantiate the arm processor and ddr3 memory controller | 10:53 |
stekern | everything else is done in orpsoc | 10:54 |
stekern | hansfbaier: (no docs) there is a README | 11:02 |
stekern | ;) | 11:02 |
stekern | I intend to write something more into that before submitting to orpsoc-cores | 11:03 |
hansfbaier | http://pastebin.com/uTGKjuzh | 12:02 |
hansfbaier | stekern: It almost worked.... | 12:03 |
stekern | hmm... | 12:05 |
stekern | was that with my commandline option? | 12:08 |
stekern | hansfbaier: aha! http://www.alteraforum.com/forum/showthread.php?t=36840 | 12:12 |
stekern | google win again | 12:12 |
stekern | but the root cause seems to be the good old "ubuntu uses dash", are you still using that? | 12:15 |
stekern | "still", I don't know your prior shell uses ;) | 12:16 |
stekern | but I swapped that out for bash so long ago that I have forgot about it | 12:16 |
juliusb | olofk: ah it'll be cool man! Don't stress about it. the workshop will go well, there's certainly no showstoppers | 12:22 |
juliusb | and what has been achieved so far is very, very impressive | 12:22 |
juliusb | I hadn't been keeping much of an eye on it the last 6 months but then all of a sudden it's this incredible system with a bunch of great features and combined with things like the wb intercon generation etc. it's a seriously useful bit of kit | 12:24 |
juliusb | it'll surely be honed a bit more over the coming 12 months or so, but I think it's good for what we want to do this weekend | 12:24 |
stekern | I'm completely of the same opinion | 12:25 |
stekern | as a soc building tool, it's way beyond what orpsocv2 ever was already now. There are features in orpsocv2 that is missing in orpsocv3, sure, but they'll come in time. | 12:28 |
stekern | I'm more worried about our mor1kx presentation, at least my part, I haven't even started planning the presentation... | 12:29 |
hansfbaier | stekern: thanks a lot. Sorry I was so lazy but had to go away from the computer. Family duties | 12:30 |
hansfbaier | stekern: And gotta practise my horn. Tomorrow night big time Jam Session in jakarta | 12:30 |
hansfbaier | stekern: weird, qsys ran through nicely now | 12:52 |
hansfbaier | but still the same error | 12:52 |
hansfbaier | Error (12006): Node instance "hps" instantiates undefined entity "sockit" File: /home/jack/HDL/src/openrisc/orpsocv3/orpsoc-cores/build/sockit/src/sockit/rtl/verilog/orpsoc_top.v Line: 570 | 12:53 |
hansfbaier | let's look | 12:53 |
hansfbaier | stekern: maybe another day. difficult thing to do with 2yr old on la\\p | 12:55 |
stekern | hansfbaier: hehe, sounds familiar ;) | 13:19 |
stekern | bit did you put the files in your-build-dir/build/sockit/src/qsys | 13:20 |
stekern | ? | 13:20 |
hansfbaier | stekern: maybe not will look | 13:53 |
hansfbaier | thanks a lot | 13:53 |
hansfbaier | bye | 13:53 |
_franck_ | olofk: how do you choose between modelsim and icarus when both are in you core file ? | 14:02 |
juliusb | stekern: (mor1kx presentation) I was mainly going to leave it to you.... I was just going to present my wishes for what it should be in future (my ROM/TCM port) etc. | 14:51 |
juliusb | but I'm sure if you just list what you've done so far, it's going to be an impressive enough session | 14:52 |
stekern | I just have to start doing the list then... ;) | 14:59 |
juliusb | lucky for us git has commit history | 15:05 |
stekern | haha, yes, just copy&paste a git log into a pdf and "this is what we have done, questions?" | 15:19 |
poke53282 | Thanks stekern. One question. Did you compile X with or without the vararg patch. I am curious if there is a problem as well. | 16:28 |
poke53282 | I think I should start slowly the eglibc project. blueCmd has done such a nice job in porting it. | 16:41 |
stekern | poke53282: which vararg patch are you referring to now? the one we had in or1k-native, the one that got applied to upstrean (now in our or1k branch) or your vararg patch? | 16:47 |
stekern | I currently compiled the whole 'demo' with or1k branch | 16:48 |
poke53282 | Ok, so no patch applied. | 16:48 |
-!- Netsplit *.net <-> *.split quits: Amadiro, trevorman, knz, LoneTech, hno | 19:27 | |
-!- trevorman is now known as Guest65383 | 20:06 | |
juliusb | stekern: how much testing has this DE0 nano image had? | 20:30 |
juliusb | I'm having trouble getting a basic timer interrupt bit of software going | 20:30 |
juliusb | it's just locking up | 20:30 |
juliusb | well, it's running, I can printf() stuff out, and I can see the TTCR counting up and wrapping but the timer interrupts aren't firing ?! | 20:59 |
juliusb | mmm... somehow I can't write the TEE bit in the SR? | 21:07 |
juliusb | and even SR_SM isn't set but it should be | 21:08 |
juliusb | alright somehow, because I haven't been resetting it, SM got set to 0, and of course you can't write to SR if SR[SM] is 0! | 21:11 |
juliusb | a hardware reset via the debug interface would be good! | 21:12 |
juliusb | alright, oldest trick in the book is making this work - disable the instruction cache.... | 21:18 |
juliusb | and I have the timer working OK | 21:19 |
juliusb | with the baremetal newlib stuff | 21:19 |
_franck_ | juliusb: you can to a target reset with openocd | 21:22 |
_franck_ | via the telnet console | 21:23 |
_franck_ | "reset" | 21:23 |
juliusb | oh, cool | 21:23 |
juliusb | mmm, that didn't do a full reset | 21:23 |
juliusb | it just unstalls the processor as far as I can see?! | 21:24 |
_franck_ | need to look at the de0 top to see if the cpu reset is ORed with the reset from the debug interface | 21:25 |
juliusb | ok cool | 21:26 |
_franck_ | that should do it | 21:27 |
_franck_ | assign or1k_rst= wb_rst | or1k_dbg_rst; | 21:27 |
_franck_ | no | 21:27 |
_franck_ | mor1kx: .rst(wb_rst), | 21:28 |
_franck_ | should be .rst(or1k_rst) | 21:29 |
juliusb | alright, nice. Would be good to reset the entire system, though | 21:30 |
juliusb | (except the TAP and debug IF obviously) | 21:31 |
_franck_ | right | 21:31 |
juliusb | cool, yep the reset command works well now :) | 22:32 |
poke53282 | blueCmd: Compiling the whole toolchain with eglibc works without problems. But then I compile busybox statically and exchange the provided one in /arch/openrisc/support/initramfs/bin/busybox | 23:14 |
poke53282 | I end up in a kernel oops. This does not happen if use the provided busybox binary. | 23:15 |
poke53282 | The problem is a null pointer dereference at virtual address 0x0 in the function sys_or1k_atomic | 23:17 |
poke53282 | I use the normal or1ksim and no other patches | 23:17 |
poke53282 | If you don't know the answer no problem, I will find myself. | 23:17 |
poke53282 | Crazy: This problem happens in process modprobe (pid: 17) | 23:27 |
poke53282 | Ok, probably this is wrong. The call graph looks like this: ptmalloc_init.part.9 -> __linkin_atfork -> Syscall 224 -> or1k_atomic -> Kernel oops | 23:52 |
--- Log closed Wed Oct 02 00:00:21 2013 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!