IRC logs for #openrisc Thursday, 2014-08-07

--- Log opened Thu Aug 07 00:00:53 2014
poke53282stekern: At the moment, not even a simple hello world program compiled with g++ works. gcc is fine.01:01
poke53282Can you test this?01:01
stekernpoke53282: interesting. admittedly, I haven't really tested c++ much02:41
poke53282more than one year in this chatroom and I still haven't figured out when stekern sleeps.02:45
stekernat night, mostly ;)02:52
poke53282yes, every half year you switch between the artic and antarctic region.02:53
poke53282That, you have never night02:54
stekernyeah, that might be confusing ;)02:58
stekernI think I have a hunch what this failure might be, it fails with an unaligned access in do_relocs02:59
poke53282so it is reproducible?03:00
poke53282Hmm, jor1k automatically stops when there is an unaligned access. One second03:01
stekernwe have this in glibc (and uclibc too for that matter):
poke53282Oh yes, there is an unaligned access,03:02
poke53282Sorry, have to go, Back in 1 hour.03:04
stekernso, I guess, something like that have to be added in the REL_SYMBOLIC case here:
--- Log closed Thu Aug 07 04:30:22 2014
--- Log opened Thu Aug 07 04:30:35 2014
-!- Irssi: #openrisc: Total of 35 nicks [0 ops, 0 halfops, 0 voices, 35 normal]04:30
-!- Irssi: Join to #openrisc was synced in 25 secs04:30
-!- Netsplit *.net <-> *.split quits: simoncook, juliusb, blueCmd, zama, olofk04:35
poke53282Hmm, the unaligned space is at PC: 0x30024C40, but I cannot find anything mapped there libstdc++ is mapped there, but the code begins at 0x48a1805:13
poke53282s/unaligned space/unaligned access/05:14
stekernpoke53282: I told you that it's in do_reloc() in libc05:26
stekernthe address you want to search for in is 0x24C4005:27
stekern(well, you're probably sane for not trusting me blindly ;))05:32
poke53282patched, let's see.05:39
stekernwhat does the patch look like?05:42
stekern <- a nifty script I've found to do pastes05:47
poke53282quick'n dirty05:47
stekernso you can do: git diff | pastie -l diff05:49
poke53282sounds good.05:49
mor1kx[mor1kx] skristiansson pushed 4 new commits to master:
mor1kxmor1kx/master 5ae50dc Stefan Kristiansson: cappuccino/decode: make branch indicate signal more lightweigth...05:56
mor1kxmor1kx/master 7ae5778 Stefan Kristiansson: cappuccino: move overflow disable to execute_alu...05:56
mor1kxmor1kx/master 5a2a7cf Stefan Kristiansson: make carry flag optional with FEATURE_CARRY_FLAG...05:56
olofk_ok, so the CVC simulator doesn't like using $clog2 in parameter definitions05:56
olofk_My bad for using these bleeding edge features from 200506:05
poke53282Nope, that would have been too easy. Looks like I have to change all relocs in the switch statement.06:08
poke53282Too late for today.06:09
stekernhmm, but it's only R_OR1K_32 that get special treatment in glibc/uclibc06:10
stekernI can take a look later in the evening too06:11
poke53282I will figure out the correct code line tomorrow. It must be one before the memcpy (case REL_COPY:) if I remember correctly the disasm code.06:13
stekernR_OR1K_32 should map into REL_SYMBOLIC06:15
poke53282do I have to recompile only musl?06:21
stekernyes, that should be enough06:25
stekernwow, ISE is really inconsistent when it comes to timing results...09:54
stekernI get fluctations at over 10% fmax with non-functional changes to the source (like commenting out a piece of code versus disabling the code with a parameter)09:55
ysionneauare you using the same random seed ?09:56
stekern...which I guess will change the seed09:56
stekernregardless, it's a huge difference...09:57
ysionneauyep :/09:58
ysionneautry to fix the seed to kick this "variable" out of the equation09:59
stekernquartus fluctates perhaps 1%...09:59
ysionneausome seeds lead to design not meeting timing09:59
stekernyeah, I know all that... but I didn't expect fluctaitions to be > 10%10:00
ysionneauI guess you have a very bad local optimum in the PAR algorithm for your design :x10:01
stekerneither way, the latest changes to mor1kx improves fmax from ~85MHz to 100MHz with MMU disabled, and from ~75MHz to 85MHz with MMU enabled when building for de0 nano10:22
stekernfor ISE *shrugs*, it's just too inconsistent to say if there are any improvements at all...10:22
Stmano/ ysionneau10:22
stekernthe changes *does* remove critical paths, so there should be improvements overall there too...10:24
mafmblueCmd_: with the patch including NO_GETCONTEXT:
ysionneaustekern: great :)10:46
ysionneauyep, good news :)10:47
ysionneaumulti core uC, open source10:47
stekernI agree, it's cool news that they have released their sources10:58
blueCmd_mafm: cool! great11:06
stekernsb0: if you have a spare moment, can you give mor1kx git HEAD a build spin for your kintex7 board?11:24
stekernthere *should* be improvements timing wise, but I'd be interested in seeing if the odd path you showed earlier still pops out11:25
sb0I can't use the board right now, but I can run synthesis11:26
stekernyeah, that's sufficient ;)11:26
sb0so gcc/llvm don't use the carry flag at all?11:26
stekernno, unless you enable the addc instructions11:26
sb0how do you enable them, and what happens then?11:27
stekernthere's a new parameter FEATURE_CARRY_FLAG that you should set to "NONE" in your test too11:27
sb0should I try 200MHz?11:27
stekernyes, try the same test as when you got 200MHz for lm32 and 150 for mor1kx11:27
stekernyou can of course try without that new parameter too if it's not too much trouble ;)11:28
sb0I already have: p_FEATURE_ADDC="NONE"11:28
sb0I should *also* have p_FEATURE_CARRY_FLAG="NONE"?11:29
stekernthe first removes the addc instruction, the latter removes the whole SR[CY] flag all together11:30
stekernseems like I remembered wrong, gcc/llvm doesn't have an option to enable addc generation.11:32
stekernI *think* that those italian guys added that as an option to their LLVM changes though11:33
sb0does it really bring a benefit?11:33
stekernto enable addc generation in the compiler?11:35
sb0well, addc in general11:39
mafmblueCmd_: but most tests are failing anyway11:39
stekernnot sure, I guess for 64-bit arithmetic there are some advantage11:40
sb0stekern, nope.
stekernok, that path makes more sense than the last one at least. was there any improvements in fmax though?11:48
blueCmd_mafm: yes, because of qemu-userspace11:48
blueCmd_mafm: qemu-system will leave maybe 1 failing test11:49
blueCmd_hopefully 011:49
stekernit's funny, using the PIPELINED multiplier has no effect on the timing at all on cyclone iv11:51
stekernon spartan 6, it makes a huge difference11:52
sb0no, it actually became slightly worse. 157->151MHz11:52
stekernanother thing that is funny is that I'm getting better fmax on both them simplesoc and the mixxeo soc with mor1kx than lm32...11:54
sb0by how much?11:56
stekernit's mariginal. on simplesoc I think I had 88 MHz for mor1kx and 83 for lm32 when I tried with a 90MHz clock11:57
stekernbut the path where you get the failure in mor1kx, there have to be a similar path in lm32...11:59
stekernit's just the cache hit check12:00
stekernso it can't just be that individual path that is terrible in mor1kx12:00
rah"They will work towards the tape-out of a prototype test-chip scheduled for 2015"12:49
sb0yet another open arch. neither lm32, mor1kx and leon are great, and what do people do? start yet another one.14:03
sb0instead of e.g. improving sw support for lm32, or debloating mor1kx or leon14:03
sb0likely, their sw support will suck too14:04
sb0and raspberry pi and aspect capital are fishy14:05
sb0"Build your own RISC-V Computer with a Zybo or ZedBoard"14:08
sb0"Let's throw Zynq in there for academic cred and hype"14:09
sb0eeerk. I'm glad I'm mostly not in academia and don't have a corporate job either.14:10
rahstupid academics14:38
rahI never wanted a job with them anyway14:38
mafmblueCmd_: any estimation on when will qemu-system ready?15:25
blueCmd_mafm: nope15:39
blueCmd_I need to spent time debugging glibc, and find out why things lock up15:40
rahanyone seen this?15:57
ysionneauthe github project, yes15:57
rahit's the "Silicon Spectrum" core that they wanted $$$ to release before:16:06
rahthey tried to get some money, failed, and released it anyway :-)16:08
rah(originally Number Nine)16:10
ysionneaucool outcome16:10
ysionneaunot for them but for the public16:10
poke53282stekern: I like your pastie script.
poke53282Still doesn't work. But the alignment issue is gone16:20
poke53282what is missing is a git apply with the pastie script something like "git apply < pastie"16:31
poke53282Yes, I know, I can use wget or curl for this.16:35
poke53282"or1k-linux-musl-g++ -static-libstdc++ hello.c" works16:46
poke53282according to ldd it is still loaded as a shared library. But probably not linked anymore. Another bug.16:48
stekernpoke53282: how doesn't it work?17:23
poke53282stops, no output and I have to press CTRL+C.17:24
poke53282is there an easy musl debug option which I can activate?17:24
stekernoh, the best kind of 'not work'...17:25
poke53282uclibc had something like this.17:25
stekernyou mean something like LD_DEBUG?17:26
stekernafaik there's no support for that in musl17:26
stekernbut you can of course just add the printfs yourself17:26
poke53282yes, something like this17:27
stekernis it the hello world that still fail?17:30
poke53282if I exchange libstdc++ with a dummy it works too with -static-libstdc++. So the link is indeed not necessary17:31
poke53282I can give you the output of readelf, objdump,nm,... with and without -static-libstdc++.17:33
jeremybennettY'all might be interested in this EE Times post about RISC-V
poke53282I use qemu-user by the way. And here an unaligned access should not matter.17:33
jeremybennettNotwithstanding my comments on the article, should we be thinking about RISC-V as the basis of OpenRISC 2000?17:34
stekernpoke53282: I can check things on my side in an hour or two17:35
poke53282wait, if I compile *without* -static-libstdc++ and *exchange* libstdc++ with a dummy it works too.17:39
poke53282so, g++ links without reason.17:41
poke53282Hmm, maybe we should take a closer look on those patches17:42
stekernhmm, looks like we still haven't seen an end to this libgcc saga...18:33
poke53282So far, I haven't compiled the native gcc. I used the libstdc++ libraries from the toolchain. Maybe this is the problem.18:57
poke53282Nope, still not working19:13
stekernno, there's some problem with still20:17
stekernhmm, or then not... I can load it with my old, but not the one I just built from git20:20
daliaswhat failures do you have with different
stekernwith the latter I get 'Error loading shared library Exec format error (needed by ./umodsi)'20:22
daliaswhat's the last syscall (strace) before that ?20:28
daliasstekern, it looks to me like your is all zeros....20:45
stekernyeah, but it's not for real :/20:48
stekernoh... wait a sec...20:50
stekerndalias: yup, I've got my rootfs on a initramfs and it had grown to big20:52
stekernand the difference between the old and new libc was size, 1.1M vs 2.8M20:52
dalias-g vs no -g ?20:54
stekernno idea why they differ that much, one was built with musl-cross and the other 'by hand'20:55
fnunesI'm not at the lab right now so I cannot test anything, but any ideias are apreciated.Hi there. I'm trying to connect OpenOCD to a FT4232H minimodule to a OpenRISC on a Digilent Atlys board. So far I have it connected but the output I got is this:; verbose: .20:56
fnunesThe first sentence was suposed to apear at the end. Sorry for that.20:56
stekernpoke53282: the dynlinked cpp hello world works here21:00
stekerndalias: did you see the discussion about misaligned relocations btw?21:01
daliaswhat were they arising from?21:03
stekernI don't have details exactly where they are, but we've had the same issue in uclibc and glibc (and other archs that can't handle unaligned accesses have had similar issues).21:05
stekernthat's how we handle it in uclibc and glibc, but iirc that is just copy-pasted from something Mike Frysinger did21:07
daliasunaligned relocs should not arise21:07
daliasif they really do, they need to be handled, but i think it's more likely these are textrels or something21:08
stekernI'll take a deeper look if they actually belong there21:09
daliasrelocations should only be applied to the GOT or to pointer objects in .data21:10
daliasand both of those are aligned21:10
stekernI found the patch from Mike Frysinger at least:
stekernah, right, this makes me remember.
stekernit's that symbol: __gxx_personality_v021:13
poke53282dalias: This is my current patch. But we need it only for one relocation type according to stekern:
poke53282stekern. Hmm, that's strange.21:30
poke53282just "g++ hello.c" ?21:31
poke53282and the libstdc++ is in /usr/lib ?21:31
stekernit's in /lib/21:31
poke53282what does ldd say?21:31
stekernand yes: or1k-linux-musl-g++ hello.c -o hello21:32
poke53282you have to symlink to /usr/bin/ldd21:32
daliashow does this relocation arise?21:34
daliasi still think it's a bug. misaligned pointers should never exist21:34
stekerndalias: not sure, it's in .eh_frame21:35
daliasi don't see where the reference to it comes from....21:38
stekernlooking at those bug reports, seems that both arm and mips have had similar problems21:38
stekernbut in my arm libstdc++ I only see this:21:47
stekernf9ca8: R_ARM_JUMP_SLOT  __gxx_personality_v021:47
olofk_stekern: Earlier today when I was standing naked under the how water and smearing soap on my body I came to think of the critical path in mor1kx21:48
olofk_I'm wondering if it's a problems with control sets21:48
stekernolofk_: wtf ;)21:48
olofk_Yeah, I got issues21:48
stekernit's comforting, then my own doesn't seem so severe =)21:48
stekernyeah, I've had similar thoughts (although fully dressed)21:51
olofk_As the issues seem to be varying between FPGA vendors and families, it could be that ISE in this case fails to map big logical expressions into one LUT21:51
olofk_Eeew... Showering with your clothes on? Weird21:51
olofk_Oh well. Time to go comatose for a few hours, hallucinate vividly, and then maybe suffer amnesia about the whole experience21:53
stekernor into a slice, comparing the reg/lut ratio between lm32 and mor1kx, lm32 has about 1/1 while mor1kx 1/221:54
olofk_Yeah, that might be an indication. I know that Xilinx devices prefer sync reset for example. What's the default for mor1kx?21:55
stekernsync reset21:55
olofk_ah ok21:56
olofk_I'm interested in firing up the good ol' fpga_editor and take a look when I got time21:57
olofk_Best tool ever! Has saved a few last minute releases for large projects I've been working on :)21:57
poke53282stekern, can you send me your hello binary?21:57
poke53282something is really messed up here.22:06
daliasstekern, is .eh_frame even writable?22:06
poke53282sorry, stekern. My fault. The busybox wget gave me a zero byte cpptest.22:10
poke53282Ok, so same problem with cpp test.22:11
poke53282Next request. Please provide me your libstdc++xxxx.so22:11
daliasi want an explanation from the gcc side23:29
daliasbased on this thread:23:30
daliasthey claim the misaligned reloc is valid23:30
daliasat least on arm23:30
daliasbut the PDF file they cite says that R_ARM_ABS32 is not even valid as a dynamic reloc; it's a static relocation23:30
daliasanyway, it seems ABS32 has become a de facto dynamic reloc, but the part of the spec about allowing misalignment is for static linking (where misaligned relocs are basically always supported)23:33
daliasanyway, i want to know what kind of craziness the misaligned reloc is coming from23:33
--- Log closed Fri Aug 08 00:00:55 2014

Generated by 2.15.2 by Marius Gedminas - find it at!