IRC logs for #openrisc Thursday, 2013-04-04

--- Log opened Thu Apr 04 00:00:00 2013
jonibogithub toolchain gives me a bunch of these:  or1k-unknown-linux/libgcc/../../../gcc/libgcc/udivmod.c:28: undefined reference to `_GLOBAL_OFFSET_TABLE_'09:16
joniboany idea what's wrong?09:16
jonibobulding with --disable-shared09:20
@juliusbstekern: I did run mor1kx on ml501 in the early days09:44
@juliusbI still have the ml501, though, I could run it on that09:45
stekernjuliusb: our old friend nassim bakiri is building mor1kx for it and ISE for virtex5 doesn't like this:
@juliusbI've synthesised that with XST before....10:16
@juliusbit shouldn't matter whether you're targeting the ml501 or not10:17
@juliusboh, apparently it does?! as stated on that page you posted: "This issue is fixed for Virtex-6 and Spartan-6 devices."10:18
@juliusbthis indicates that the frontend behaves differently for different technologies10:18
stekernjonibo: when do you get that?10:19
stekernjuliusb: yes, it does10:24
jonibostekern: when building libgcc, I think10:49
jonibowhen building with --enable-shared, it doesn't fair much better:  .......toolchain-out/or1k-unknown-linux/bin/ld: cannot find /lib/uclibc_nonshared.a10:52
joniboah, sorry:  the GLOBAL_OFFSET_TABLE errors come when building Linux with the github toolchain (--disable-shared)10:52
jonibothe --enable-shared toolchain dies when building libgcc10:53
stekernhmm, didn't the target change to linux-uclibc for uclibc10:57
jonibois that relevant?10:58
stekernI don't know, I was just thinking about the /lib/uclibc_nonshared.a error10:58
jonibothat target seems to be or1k-*-linux* so no differentiation between libc's10:59
stekernok, blueCmd was touching those bits last, he probably can shine some light on that10:59
stekernbut 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
stekernI don't think I ever figured out how to get around that.11:02
stekernthe simplest workaround is to compile the kernel with the baremetal toolchain11:02
jonibohmm... I thought enable-shared would have taken care of that for gcc11:04
stekernisn't the enable/disable-shared flags for gcc itself, or was that just for binutils?11:05
jonibofor binutils it must primarily affect ld11:05
jonibofor gcc, libgcc, I guess11:05
jonibobut i'm guessing here11:05
stekernI mean, in binutils, it affect wether libopcodes et al builds as shared libraries or are statically linked in11:06
jonibosure... that's more or less what I mean11:07
stekernbut yeah, I guess you're right, that should affect libgcc too11:09
stekernso why doesn't it? I can't find anything target specific that does anything against that11:26
jonibook, 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 up12:16
blueCmdstekern: IIRC -linux will link with glibc ld name12:27
blueCmd-uclibc is probably better to use if one uses uclibc12:28
jonibook, I fixed up the sysroot paths and that toolchain now builds... but the Linux build error persists with issues in libgcc:12:33
joniboor1k-unknown-linux/libgcc/../../../gcc/libgcc/udivmod.c:28: undefined reference to `_GLOBAL_OFFSET_TABLE_'12:33
stekernand that is still with disabled-shared?12:42
jonibosame resule as with disable-shared12:44
jonibooddly enough12:44
stekernI 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 -fPIC12:50
joniboyeah, that's the conclusion I've pretty much come to as well12:52
jonibolibgcc is -fPIC which doesn't mesh with what the kernel needs12:52
jonibolooking into it now12:52
stekernbut other archs manage to share the linux toolchain between building userland and kernel, right?12:52
stekernan other way of looking at it could be, why would libgcc access symbols via got?12:55
joniboyeah, that's the conundrum... we have to be able to build the kernel with this toolcahin12:57
joniboit seems to force everything to be PIC...????12:57
jonibodoes that make sense for a static libgcc???12:57
stekernnot if you're not going to link it with shared libraries12:58
jonibook, libgcc should be PIC... it needs to be so that it can be copied in to shared libraries, of course13:02
stekernbut the question was rather, why does it have to access global symbols13:05
jonibodoes it?  isn't it just a matter of getting an offset for its own symbols?13:06
joniboso the X86 libgcc.a is also PIC (has the GLOBAL_OFFSET_TABLE symbol), but Linux can link fine against it13:08
joniboso that's presumably not the problem13:08
joniboI take that back... x86 Linux doesn't link against libgcc13:08
stekernah, that's interesting13:09
stekernthe GLOBAL_OFFSET table in libgcc seems to come from calls via plt to abort13:09
stekernfrom a quick look13:09
joniboso many Linux arches don't link to libgcc but implement the libgcc symbols directly13:17
jonibothat's how they get around that one13:17
jonibothat said, several arches DO link to libgcc13:17
jonibook, I guess the way forward is to implement the symbols that linux uses in Linux itself and stop linking in libgcc13:29
stekernyou could use compiler-rt ;)13:34
stekernjoking aside, doesn't linux have generic implementations for the libgcc functions?13:35
jonibono, apparently not13:36
jonibothe annoying thing with this is that I really don't like the idea of having two copies of these functions around... they should be equivalent13:38
jonibobut it seems that many arches have some kind of hand-coded assembly version (optimized?) in Linux and use the generic C implementations in GCC13:38
joniboseems odd to me13:38
joniboundefined reference to `__ashldi3'13:51
joniboundefined reference to `__ashrdi3'13:51
joniboundefined reference to `__divsi3'13:51
joniboundefined reference to `__lshrdi3'13:51
joniboundefined reference to `__modsi3'13:51
joniboundefined reference to `__muldi3'13:51
joniboundefined reference to `__udivsi3'13:51
joniboundefined reference to `__umodsi3'13:51
joniboThose are the symbols that need to be implemented for openrisc linux... arch/openrisc/lib/...13:51
joniboif someone wants to take a crack at that, be my guest13:52
jonibootherwise I might give it a go next week, time permitting13:52
jonibopatches to, please, if there's any progress there!  thanks! :)13:53
@juliusbWhy wouldn't this work: ??13:55
joniboit probably would13:56
joniboyup, ok, there are a couple of arch's that actually seem to share some C code for this... let's steal that13:57
@juliusbya looks like generic C code to me14:00
@juliusbfar from optimised, of course14:00
jonibounoptimized is fine for now... just to get us something that builds14:02
@juliusbi 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
jonibono, only found ashldi3 and ashrdi314:06
jonibomuldi3 seems to have a couple of C implementations14:06
jonibothe rest, assembly14:06
joniboI 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 differently14:06
jonibothe muldi's aren't quite clean C though14:08
joniboThe list to implement then is at least these, for now:14:09
joniboundefined reference to `__lshrdi3'14:09
joniboundefined reference to `__modsi3'14:09
joniboundefined reference to `__muldi3'14:09
joniboundefined reference to `__umodsi3'14:09
joniboI'm calling it a day... will look at this later.14:09
joniboThanks for the help, stekern and juliusb14:09
_franck_muldi3 and lshrdi3 here:;a=tree;f=arch/openrisc/lib;h=6e93b446f4808af6ddcd43d7f86b8f94fc4c26b6;hb=HEAD14:22
@juliusb_franck_: those look good! :)14:52
@juliusbyou might need to rename the intermediate labels, though14:52
@juliusbif it's going in the kernel, I guess14:52
@juliusbmaybe not, though? i don't know actually :p14:52
olofkThe IRC logs are great. The channel has become so chatty that my IRSSI scroll buffer can't keep up ;)15:03
stekernthere seems to be some problem with the search function from time to time though15:06
olofkGoogle will index it soon enough anyway15:08
@juliusbyes search broke again the other day (some permissions thing)15:13
@juliusbbut appears to work OK now15:13
@juliusbI agree I love the buffer15:13
@juliusberr, i love the HTTP-accessible chat buffer that is the logs on my website :)15:14
@juliusbone 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 browsing15:15
@juliusbI should get rid of the joins/leaves things15:15
stekernonly or1k-simple and uart-simple fails with branches in decode stage now15:24
olofkstekern, juliusb: How do you simulate your maximum frequency numbers for mor1kx? Is that just for building it stand-alone with default parameters?15:28
@juliusbhuh simulate maximum frequency numbers?!15:33
olofkWell, estimate, not simulate15:36
olofkYou're mostly running it on cyclone IV, right?15:37
@juliusbgenerally just yeah, do a wrapper15:37
@juliusband then synthesise15:37
@juliusbI have only done on Xilinxs thus far15:37
@juliusbbut stekern uses the de0 nano15:37
stekernMy numbers are from the orpsoc soc15:38
olofkI thought I could make myself useful, so I'm running some tests on Virtex 6 with Synplify pro for synthesis15:39
olofkPatches will be sent :)15:39
stekernwill be intersting to hear what kind of numbers you get15:41
@juliusboh cool15:41
stekerninteresting too15:41
olofkI tried 100 MHz, but got a few timing errors on ff 2 pads, so I'm adding a wrapper with some dummy registers right now15:42
olofkBut there were no internal timing errors, so I'm expecting it to run > 100 MHz at least15:42
stekernsince cappuccino does around 80 on cyclone 4 in orpsoc, i'd certainly expect it to go over 10015:45
stekernespresso does 60 last I checked15:45
stekern80 with mmus disabled, 70 when enabled15:46
stekernthat's far from satisfactory though...15:57
olofkOne error with cappucino @125MHz15: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
olofkIs that the register file?16:00
stekernyeah, register file port b16:01
stekernthe destination is odd though, that should be coming from the instruction in decode16:02
olofkSo for Virtex 6 it would probably benefit from being register based I guess. Is that the worst path in other archs too?16:02
stekernah, but it uses the flag, so it's probably from that16:03
stekernon cyclone 4 it's usually dcache out on the wb bus16:05
stekernbut i guess you don't have a complex bus there16:05
stekernbut the rf port b is registered in your path in my working tree16:06
stekernif you have spare time, you could do a test run with the tree from my github repo16:07
olofkArrgh.. stupid non-standard attributes. Looks like Altera uses logic, and Xilinx uses registers for the syn_ramstyle attribute16:07
olofkIs that something that you intend to push to mor1kx master?16:08
stekernnot exactly looking like that, but otherwise yes16:09
olofkI'll probably have an extra hour next time we switch to daylight saving16:11
olofkI'll check it then16:11
olofkWell, changing it to a register based memory helped. It runs 125 MHz now. Time to constrain it a bit harder16:15
olofk150 MHz looks good too, but this is without any surrounding logic of course16:21
olofkAt 165 MHz I get this worst path16: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
olofkIt's a lot faster than what I got with or1200 on the same hardware. Can't remember what settings I used for that though16:46
stekernthat imm_branch again17:08
stekernwonder if I made it better or worse in my WIP17:08
stekernjuliusb: I still haven't understood the mor1kx-utils.h stuff17:37
stekernI must say I'm a bit lost in the mor1kx-devenv's makefile system17:38
stekernI can't even find where I could prevent the makefiles from removing the .elf17:39
@juliusbya sorry maybe a little bit obfuscated :-/18:07
@juliusbhey so I have a question stekern 18:07
@juliusbI want to build some mor1kx system for de0-nano18:07
@juliusbI see you have one on your git.chokoladfabriken18:07
@juliusbwell, i have 2 questions18:08
@juliusb1) will that largely lift up from your orpsoc dir and into mor1kx-dev-env?18:08
@juliusb2) you use adv-debug-sys with it.... is that easy?18:08
stekernuse the one on, they should be identical as long as I haven't forgot to double push to chokladfabriken though18:24
stekern1) I believe it's just a matter of copying the directory into mor1kx-dev-env18:25
stekern2) it's easier in that way that you don't need to build an adapter for the jtag debugger, openocd works with it18:26
stekernbut you can use the other one as well, it's just a matter of swapping two defines18:26
stekernyou still need a ttl uart interface though18:26
@juliusbI thin I want to use adv_debug_sys though18:27
@juliusbfor the de0-nano demo18:27
@juliusbit means we don't need an additional dongle, doesn't it?18:27
stekernyeah, just plug the usb-cable in and connect with openocd18:28
stekernbut as I said, you still need something like this:
@juliusboh huh what is that for??!18:34
@juliusbok sorry I didn't read :-018:35
@juliusbThere's really no way to get UART back to the system via the debug cable?18:36
@juliusbI thought that thing had UART in it?18:36
stekernno, the only way is to use a jtag-uart server18:36
stekernthere is one in adv debug sys, but I've never tried it18:36
@juliusbohh right18:37
@juliusbthat sounds good :)18:37
stekernjuliusb: I put out a pull request with the de0_nano added18:51
@juliusbthank ye18:51
stekernyou might wanna apply this patch too though:
stekernI haven't tested without that in a while, might or might not worl18:54
stekernit's just setting the SDRAM clock = wb_clk18:54
@juliusbah yep18:56
stekernI 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
@juliusboh yeah making it keep intermediate things is a bit hard sometimes :-/19:02
@juliusbQuartus download is 4.2GB - it there some sort of EDA bloatware arms race on between Xilinx and Quartus20:18
@juliusbXilinx still win right - isn't it like 8GB with the Vivado crap now?20:18
stekernI don't understand what it is that takes so much space20:23
stekernotoh, what is 4.2 gb nowdays20:25
glowplugThat sucks for me.  My CR-48 only has a 16gb SSD.  Haha20:28
stekernI wonder how much smaller it'd be if you remove all the gui stuff20:42
stekernyay! all tests passes now20:49
stekernhad 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 tests20:50
--- Log closed Fri Apr 05 00:00:01 2013

Generated by 2.15.2 by Marius Gedminas - find it at!