| --- Log opened Thu Apr 04 00:00:00 2013 | ||
| jonibo | github toolchain gives me a bunch of these: or1k-unknown-linux/libgcc/../../../gcc/libgcc/udivmod.c:28: undefined reference to `_GLOBAL_OFFSET_TABLE_' | 09:16 |
|---|---|---|
| jonibo | any idea what's wrong? | 09:16 |
| jonibo | bulding with --disable-shared | 09:20 |
| @juliusb | stekern: I did run mor1kx on ml501 in the early days | 09:44 |
| @juliusb | I still have the ml501, though, I could run it on that | 09:45 |
| @juliusb | why? | 09:45 |
| stekern | juliusb: our old friend nassim bakiri is building mor1kx for it and ISE for virtex5 doesn't like this: https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_ctrl_espresso.v#L871 | 10:01 |
| stekern | http://www.xilinx.com/support/answers/20391.htm | 10:02 |
| @juliusb | odd | 10:16 |
| @juliusb | I've synthesised that with XST before.... | 10:16 |
| @juliusb | surely | 10:16 |
| @juliusb | it shouldn't matter whether you're targeting the ml501 or not | 10:17 |
| @juliusb | oh, apparently it does?! as stated on that page you posted: "This issue is fixed for Virtex-6 and Spartan-6 devices." | 10:18 |
| @juliusb | ?!?!?!?!??! | 10:18 |
| @juliusb | this indicates that the frontend behaves differently for different technologies | 10:18 |
| stekern | jonibo: when do you get that? | 10:19 |
| stekern | juliusb: yes, it does | 10:24 |
| jonibo | stekern: when building libgcc, I think | 10:49 |
| jonibo | when building with --enable-shared, it doesn't fair much better: .......toolchain-out/or1k-unknown-linux/bin/ld: cannot find /lib/uclibc_nonshared.a | 10:52 |
| jonibo | ah, sorry: the GLOBAL_OFFSET_TABLE errors come when building Linux with the github toolchain (--disable-shared) | 10:52 |
| jonibo | the --enable-shared toolchain dies when building libgcc | 10:53 |
| stekern | hmm, didn't the target change to linux-uclibc for uclibc | 10:57 |
| jonibo | is that relevant? | 10:58 |
| stekern | I don't know, I was just thinking about the /lib/uclibc_nonshared.a error | 10:58 |
| jonibo | that target seems to be or1k-*-linux* so no differentiation between libc's | 10:59 |
| stekern | ok, blueCmd was touching those bits last, he probably can shine some light on that | 10:59 |
| stekern | but the building Linux with the linux toolchain is a different problem, I can't remember the details from the top of my head, but libgcc.a have to be built with -fPIC in order to be linked into shared libraries (that happens). | 11:01 |
| stekern | I don't think I ever figured out how to get around that. | 11:02 |
| stekern | the simplest workaround is to compile the kernel with the baremetal toolchain | 11:02 |
| jonibo | hmm... I thought enable-shared would have taken care of that for gcc | 11:04 |
| stekern | isn't the enable/disable-shared flags for gcc itself, or was that just for binutils? | 11:05 |
| jonibo | both | 11:05 |
| jonibo | for binutils it must primarily affect ld | 11:05 |
| jonibo | for gcc, libgcc, I guess | 11:05 |
| jonibo | but i'm guessing here | 11:05 |
| stekern | I mean, in binutils, it affect wether libopcodes et al builds as shared libraries or are statically linked in | 11:06 |
| jonibo | sure... that's more or less what I mean | 11:07 |
| stekern | but yeah, I guess you're right, that should affect libgcc too | 11:09 |
| stekern | so why doesn't it? I can't find anything target specific that does anything against that | 11:26 |
| jonibo | ok, the enable-shared issue seems to be down to thefact that I dropped the use of --with-sysroot and that's got the libc paths (ld-so paths) all messed up | 12:16 |
| blueCmd | stekern: IIRC -linux will link with glibc ld name | 12:27 |
| blueCmd | -uclibc is probably better to use if one uses uclibc | 12:28 |
| jonibo | ok, I fixed up the sysroot paths and that toolchain now builds... but the Linux build error persists with issues in libgcc: | 12:33 |
| jonibo | or1k-unknown-linux/libgcc/../../../gcc/libgcc/udivmod.c:28: undefined reference to `_GLOBAL_OFFSET_TABLE_' | 12:33 |
| stekern | and that is still with disabled-shared? | 12:42 |
| jonibo | enable-shared | 12:43 |
| jonibo | same resule as with disable-shared | 12:44 |
| jonibo | oddly enough | 12:44 |
| stekern | I think the whole issue still boils down to the problem I couldn't figure out, that shared libraries tries to link in libgcc.a, so with shared libraries, libgcc.a has to be built with -fPIC | 12:50 |
| jonibo | yeah, that's the conclusion I've pretty much come to as well | 12:52 |
| jonibo | libgcc is -fPIC which doesn't mesh with what the kernel needs | 12:52 |
| jonibo | looking into it now | 12:52 |
| stekern | but other archs manage to share the linux toolchain between building userland and kernel, right? | 12:52 |
| stekern | an other way of looking at it could be, why would libgcc access symbols via got? | 12:55 |
| jonibo | yeah, that's the conundrum... we have to be able to build the kernel with this toolcahin | 12:57 |
| jonibo | it seems to force everything to be PIC...???? | 12:57 |
| jonibo | does that make sense for a static libgcc??? | 12:57 |
| stekern | not if you're not going to link it with shared libraries | 12:58 |
| jonibo | ok, libgcc should be PIC... it needs to be so that it can be copied in to shared libraries, of course | 13:02 |
| stekern | exactly | 13:05 |
| stekern | but the question was rather, why does it have to access global symbols | 13:05 |
| jonibo | does it? isn't it just a matter of getting an offset for its own symbols? | 13:06 |
| jonibo | so the X86 libgcc.a is also PIC (has the GLOBAL_OFFSET_TABLE symbol), but Linux can link fine against it | 13:08 |
| jonibo | so that's presumably not the problem | 13:08 |
| jonibo | I take that back... x86 Linux doesn't link against libgcc | 13:08 |
| stekern | ah, that's interesting | 13:09 |
| stekern | the GLOBAL_OFFSET table in libgcc seems to come from calls via plt to abort | 13:09 |
| stekern | from a quick look | 13:09 |
| jonibo | so many Linux arches don't link to libgcc but implement the libgcc symbols directly | 13:17 |
| jonibo | that's how they get around that one | 13:17 |
| jonibo | that said, several arches DO link to libgcc | 13:17 |
| jonibo | ok, I guess the way forward is to implement the symbols that linux uses in Linux itself and stop linking in libgcc | 13:29 |
| stekern | you could use compiler-rt ;) | 13:34 |
| stekern | joking aside, doesn't linux have generic implementations for the libgcc functions? | 13:35 |
| jonibo | no, apparently not | 13:36 |
| jonibo | the annoying thing with this is that I really don't like the idea of having two copies of these functions around... they should be equivalent | 13:38 |
| jonibo | but it seems that many arches have some kind of hand-coded assembly version (optimized?) in Linux and use the generic C implementations in GCC | 13:38 |
| jonibo | seems odd to me | 13:38 |
| jonibo | undefined reference to `__ashldi3' | 13:51 |
| jonibo | undefined reference to `__ashrdi3' | 13:51 |
| jonibo | undefined reference to `__divsi3' | 13:51 |
| jonibo | undefined reference to `__lshrdi3' | 13:51 |
| jonibo | undefined reference to `__modsi3' | 13:51 |
| jonibo | undefined reference to `__muldi3' | 13:51 |
| jonibo | undefined reference to `__udivsi3' | 13:51 |
| jonibo | undefined reference to `__umodsi3' | 13:51 |
| jonibo | Those are the symbols that need to be implemented for openrisc linux... arch/openrisc/lib/... | 13:51 |
| jonibo | if someone wants to take a crack at that, be my guest | 13:52 |
| jonibo | otherwise I might give it a go next week, time permitting | 13:52 |
| jonibo | patches to linux@lists.openrisc.net, please, if there's any progress there! thanks! :) | 13:53 |
| @juliusb | Why wouldn't this work: http://lxr.free-electrons.com/source/arch/mips/lib/ashldi3.c ?? | 13:55 |
| jonibo | it probably would | 13:56 |
| jonibo | yup, ok, there are a couple of arch's that actually seem to share some C code for this... let's steal that | 13:57 |
| @juliusb | ya looks like generic C code to me | 14:00 |
| @juliusb | far from optimised, of course | 14:00 |
| jonibo | unoptimized is fine for now... just to get us something that builds | 14:02 |
| @juliusb | i only saw a few of the ones you listed as generic C-code in the mips port directory, were you able to find all? | 14:04 |
| @juliusb | (in other archs?) | 14:04 |
| jonibo | no, only found ashldi3 and ashrdi3 | 14:06 |
| jonibo | muldi3 seems to have a couple of C implementations | 14:06 |
| jonibo | the rest, assembly | 14:06 |
| jonibo | I think the divsi3's can be made to go away... need to check what code is generating those and see if it can be done differently | 14:06 |
| jonibo | the muldi's aren't quite clean C though | 14:08 |
| jonibo | The list to implement then is at least these, for now: | 14:09 |
| jonibo | undefined reference to `__lshrdi3' | 14:09 |
| jonibo | undefined reference to `__modsi3' | 14:09 |
| jonibo | undefined reference to `__muldi3' | 14:09 |
| jonibo | undefined reference to `__umodsi3' | 14:09 |
| jonibo | I'm calling it a day... will look at this later. | 14:09 |
| jonibo | Thanks for the help, stekern and juliusb | 14:09 |
| _franck_ | muldi3 and lshrdi3 here: http://git.pengutronix.de/?p=barebox.git;a=tree;f=arch/openrisc/lib;h=6e93b446f4808af6ddcd43d7f86b8f94fc4c26b6;hb=HEAD | 14:22 |
| @juliusb | _franck_: those look good! :) | 14:52 |
| @juliusb | you might need to rename the intermediate labels, though | 14:52 |
| @juliusb | if it's going in the kernel, I guess | 14:52 |
| @juliusb | maybe not, though? i don't know actually :p | 14:52 |
| olofk | The IRC logs are great. The channel has become so chatty that my IRSSI scroll buffer can't keep up ;) | 15:03 |
| stekern | there seems to be some problem with the search function from time to time though | 15:06 |
| olofk | Google will index it soon enough anyway | 15:08 |
| @juliusb | yes search broke again the other day (some permissions thing) | 15:13 |
| @juliusb | but appears to work OK now | 15:13 |
| @juliusb | I agree I love the buffer | 15:13 |
| @juliusb | err, i love the HTTP-accessible chat buffer that is the logs on my website :) | 15:14 |
| @juliusb | one of my tabs on the browser on my nexus 4 is always on the latest.log.html page, always give it a quick scan when I'm browsing | 15:15 |
| @juliusb | I should get rid of the joins/leaves things | 15:15 |
| stekern | only or1k-simple and uart-simple fails with branches in decode stage now | 15:24 |
| olofk | stekern, juliusb: How do you simulate your maximum frequency numbers for mor1kx? Is that just for building it stand-alone with default parameters? | 15:28 |
| @juliusb | huh simulate maximum frequency numbers?! | 15:33 |
| olofk | Well, estimate, not simulate | 15:36 |
| @juliusb | ahhh | 15:37 |
| @juliusb | Umm | 15:37 |
| olofk | You're mostly running it on cyclone IV, right? | 15:37 |
| @juliusb | generally just yeah, do a wrapper | 15:37 |
| @juliusb | and then synthesise | 15:37 |
| @juliusb | I have only done on Xilinxs thus far | 15:37 |
| @juliusb | but stekern uses the de0 nano | 15:37 |
| stekern | My numbers are from the orpsoc soc | 15:38 |
| olofk | I thought I could make myself useful, so I'm running some tests on Virtex 6 with Synplify pro for synthesis | 15:39 |
| stekern | cool | 15:39 |
| olofk | Patches will be sent :) | 15:39 |
| stekern | will be intersting to hear what kind of numbers you get | 15:41 |
| @juliusb | oh cool | 15:41 |
| stekern | interesting too | 15:41 |
| olofk | I tried 100 MHz, but got a few timing errors on ff 2 pads, so I'm adding a wrapper with some dummy registers right now | 15:42 |
| olofk | But there were no internal timing errors, so I'm expecting it to run > 100 MHz at least | 15:42 |
| stekern | since cappuccino does around 80 on cyclone 4 in orpsoc, i'd certainly expect it to go over 100 | 15:45 |
| stekern | espresso does 60 last I checked | 15:45 |
| stekern | 80 with mmus disabled, 70 when enabled | 15:46 |
| stekern | that's far from satisfactory though... | 15:57 |
| olofk | One error with cappucino @125MHz | 15:59 |
| olofk | Source: i_mor1kx/mor1kx_cpu/cappuccino.mor1kx_cpu/mor1kx_rf_cappuccino/rfb/ram_ram_0_0 (RAM) | 15:59 |
| olofk | Destination: i_mor1kx/mor1kx_cpu/cappuccino.mor1kx_cpu/mor1kx_ctrl_branch_cappuccino/imm_branch (FF) | 15:59 |
| olofk | Is that the register file? | 16:00 |
| stekern | yeah, register file port b | 16:01 |
| stekern | the destination is odd though, that should be coming from the instruction in decode | 16:02 |
| olofk | So for Virtex 6 it would probably benefit from being register based I guess. Is that the worst path in other archs too? | 16:02 |
| stekern | ah, but it uses the flag, so it's probably from that | 16:03 |
| stekern | on cyclone 4 it's usually dcache out on the wb bus | 16:05 |
| stekern | but i guess you don't have a complex bus there | 16:05 |
| stekern | but the rf port b is registered in your path in my working tree | 16:06 |
| stekern | if you have spare time, you could do a test run with the tree from my github repo | 16:07 |
| olofk | Arrgh.. stupid non-standard attributes. Looks like Altera uses logic, and Xilinx uses registers for the syn_ramstyle attribute | 16:07 |
| olofk | Is that something that you intend to push to mor1kx master? | 16:08 |
| stekern | not exactly looking like that, but otherwise yes | 16:09 |
| olofk | I'll probably have an extra hour next time we switch to daylight saving | 16:11 |
| olofk | I'll check it then | 16:11 |
| stekern | heh | 16:11 |
| olofk | Well, changing it to a register based memory helped. It runs 125 MHz now. Time to constrain it a bit harder | 16:15 |
| olofk | 150 MHz looks good too, but this is without any surrounding logic of course | 16:21 |
| olofk | At 165 MHz I get this worst path | 16:45 |
| olofk | Source: i_mor1kx/mor1kx_cpu/cappuccino.mor1kx_cpu/mor1kx_decode/decode_valid_o (FF) | 16:45 |
| olofk | Destination: i_mor1kx/mor1kx_cpu/cappuccino.mor1kx_cpu/mor1kx_ctrl_branch_cappuccino/imm_branch (FF) | 16:45 |
| olofk | It's a lot faster than what I got with or1200 on the same hardware. Can't remember what settings I used for that though | 16:46 |
| stekern | that imm_branch again | 17:08 |
| stekern | wonder if I made it better or worse in my WIP | 17:08 |
| stekern | juliusb: I still haven't understood the mor1kx-utils.h stuff | 17:37 |
| stekern | I must say I'm a bit lost in the mor1kx-devenv's makefile system | 17:38 |
| stekern | I can't even find where I could prevent the makefiles from removing the .elf | 17:39 |
| @juliusb | hmmm | 18:07 |
| @juliusb | ya sorry maybe a little bit obfuscated :-/ | 18:07 |
| @juliusb | hey so I have a question stekern | 18:07 |
| @juliusb | I want to build some mor1kx system for de0-nano | 18:07 |
| @juliusb | I see you have one on your git.chokoladfabriken | 18:07 |
| @juliusb | well, i have 2 questions | 18:08 |
| @juliusb | 1) will that largely lift up from your orpsoc dir and into mor1kx-dev-env? | 18:08 |
| @juliusb | 2) you use adv-debug-sys with it.... is that easy? | 18:08 |
| stekern | use the one on openrisc.net, they should be identical as long as I haven't forgot to double push to chokladfabriken though | 18:24 |
| stekern | 1) I believe it's just a matter of copying the directory into mor1kx-dev-env | 18:25 |
| stekern | 2) it's easier in that way that you don't need to build an adapter for the jtag debugger, openocd works with it | 18:26 |
| stekern | but you can use the other one as well, it's just a matter of swapping two defines | 18:26 |
| stekern | you still need a ttl uart interface though | 18:26 |
| @juliusb | I thin I want to use adv_debug_sys though | 18:27 |
| @juliusb | for the de0-nano demo | 18:27 |
| @juliusb | it means we don't need an additional dongle, doesn't it? | 18:27 |
| stekern | yeah, just plug the usb-cable in and connect with openocd | 18:28 |
| stekern | but as I said, you still need something like this: http://www.miniinthebox.com/cp2102-usb-2-0-to-ttl-uart-6pin-module-serial-converter_p391022.html | 18:29 |
| @juliusb | oh huh what is that for??! | 18:34 |
| @juliusb | UART? | 18:35 |
| @juliusb | ok sorry I didn't read :-0 | 18:35 |
| @juliusb | There's really no way to get UART back to the system via the debug cable? | 18:36 |
| @juliusb | I thought that thing had UART in it? | 18:36 |
| stekern | no, the only way is to use a jtag-uart server | 18:36 |
| stekern | there is one in adv debug sys, but I've never tried it | 18:36 |
| @juliusb | ohh right | 18:37 |
| @juliusb | that sounds good :) | 18:37 |
| stekern | juliusb: I put out a pull request with the de0_nano added | 18:51 |
| @juliusb | thank ye | 18:51 |
| stekern | you might wanna apply this patch too though: http://pastie.org/7318203 | 18:53 |
| stekern | I haven't tested without that in a while, might or might not worl | 18:54 |
| stekern | *work | 18:54 |
| @juliusb | cool | 18:54 |
| stekern | it's just setting the SDRAM clock = wb_clk | 18:54 |
| @juliusb | ah yep | 18:56 |
| stekern | I gave up on the makefiles btw, just hacked in a cp file.elf to file.elf.bak in the elf rule for now ;) | 18:56 |
| @juliusb | oh yeah making it keep intermediate things is a bit hard sometimes :-/ | 19:02 |
| @juliusb | Quartus download is 4.2GB - it there some sort of EDA bloatware arms race on between Xilinx and Quartus | 20:18 |
| @juliusb | Xilinx still win right - isn't it like 8GB with the Vivado crap now? | 20:18 |
| stekern | I don't understand what it is that takes so much space | 20:23 |
| stekern | otoh, what is 4.2 gb nowdays | 20:25 |
| glowplug | That sucks for me. My CR-48 only has a 16gb SSD. Haha | 20:28 |
| stekern | I wonder how much smaller it'd be if you remove all the gui stuff | 20:42 |
| stekern | yay! all tests passes now | 20:49 |
| stekern | had a real puzzle going on where a change in one direction broke stuff in some tests and a change in the other direction broke stuff in other tests | 20:50 |
| --- Log closed Fri Apr 05 00:00:01 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!