IRC logs for #openrisc Tuesday, 2014-08-05

--- Log opened Tue Aug 05 00:00:51 2014
poke53282This commit is not part of gcc yet?01:52
poke53282not of the official distribution I mean.01:52
stekernpoke53282: no, I don't think it is03:07
stekernI mean, it's definitely not in 4.9.003:08
stekerndalias probably now what's the status/agenda of getting in the official distribution03:11
stekernhmm, I think I might have an idea how to fix crappy timing of the PIPELINED multiplier03:16
poke53282Ok, no problem.04:33
poke53282But I have bad news. scummvm does no longer link.04:33
poke53282with musl04:33
poke53282stekern: I get "Error relocating /usr/lib/ unsupported relocation type 6"04:34
stekernpoke53282: yes, that's the thing I've been scratching my head about for the last week or so04:34
poke53282Oh :)04:34
stekern and
poke53282gcc, binutils, make link so far.04:35
stekernthose patches should fix that04:36
stekernthe first is for binutils-gdb and the second for or1k-gcc04:36
poke53282I see04:38
stekernI'm going to commit both, but I want to test them a bit more first04:39
poke53282Ok, anyother software with that problem?04:40
poke53282seems to be a very rare link type04:41
stekerneverything that links dynamically to libgcc04:41
stekernit's a very common relocation type (R_OR1K_INSN_REL_26), but it shouldn't ever be present in dynamic libraries04:42
poke53282Hmm, another problem when I try to compile openssl05:28
poke53282"  /usr/sbin/ld: libcrypto.a(cryptlib.o): Relocations in generic ELF (EM: 92)05:28
poke53282this is probably related05:29
poke53282You habe to apply the patch from:
stekernfor the EM: 92 error?05:31
poke53282cross=or1k-linux-musl- ./Configure linux-generic32 shared --prefix=/usr --libdir=lib --openssldir=/etc/ssl zlib-dynamic -DB_ENDIAN05:32
poke53282make CC=or1k-linux-musl-gcc AR="or1k-linux-musl-ar r" RANLIB="or1k-linux-musl-ranlib"05:32
poke53282the commands for configure and make05:32
poke53282sorry to compile you have to apply the patch05:33
poke53282to come to the possition where it links05:34
poke53282otherwise make will stop earlier05:34
poke53282I get the error line exactly three times. The same number like the libgcc linking error.05:35
stekernok, but that error is unrelated to the libgcc error05:38
stekernyou usually get that error when you mistakenly try to link together elfs from different machines05:39
stekernso, my guess is that something still gets wrong in the cross-compile05:50
stekern'/usr/sbin/ld' doesn't sound like it'd be the or1k ld05:50
poke53282yes, your are right.05:51
poke53282It takes the wrong executables here for some reason.05:51
poke53282it works. I had to apply another patch.06:05
stekernsb0: is that kintex7 build something I could try? or is that FPGA not covered by the 'webpack' (or whatever it's called nowdays) license?08:26
sb0the fpga I'm using is not covered by webpack, idk if some k7's are08:43
blueCmdstekern: that's much nicer if it does what it's supposed to :P09:49
stekernit does ;)09:55
stekerni.e., with that bfd patch, R_OR1K_INSN_REL_26 relocs get resolved at linktime when linked with -Bsymbolic or the symbol that is referenced is hidden.09:57
stekern...and hopefully it's not going to break anything else...09:59
blueCmdbfd patch?10:16
blueCmdah, I backlogged and found it10:17
stekernblueCmd: or, what were you speaking about? =P10:38
maxpalnI have a strong lead in the reason my Linux kernel doesn't boot with the mor1kx processor - actually it's nothing to do with Linux at all. It is a problem in the execution of the bootrom code that loads data from SPI flash to RAM11:28
maxpalnare there differences in the way the instruction works between or1200 and mor1kx?11:28
maxpalnThe bootrom includes an instruction that *should* write 0x3 to address B0000002 in the SPI peripheral11:29
maxpalnin the OR1200 this works, in the mor1kx it writes 0x3 to address 0xB000000011:29
maxpaln(and it turns out this problem appears in simulation too - I just never ran a simulation that loaded from SPI to RAM, I always preloaded into RAM at the start of simulation - poor skills!)11:30
_franck_it's because of the wb_sel signal11:32
_franck_and address[1:0]11:32
_franck_mor1kx set adress[1:0] to 0 because we do access a 32bits bus11:33
_franck_or1200 set bits [1:0] to their value11:34
_franck_so if your peripheral doesn't handle we_sel properly it won't work11:34
_franck_maxpaln: ^11:35
ysionnea1and there is the EUREKA moment11:39
maxpaln_franck_: great analysis.11:40
maxpalnhmmm, I'm using the simple_spi.v that came with the original orpsocv2 -11:40
maxpalnI am guessing this didn't implement the wb_sel correctly -11:41
maxpalnI'll see if the latest code is any different11:41
maxpalnLOL - the simple_spi.v doesn't even have a wb_sel input!!11:43
maxpalnthat makes analysing whether it handles it correctly a simple process11:43
maxpalnhmmm, my newbie background strikes again -11:48
maxpalnI have orpsoc-cores from git clone
maxpalnbut it doesn't include the source for the simple_spi.v11:49
maxpalnAnyh clues as to where the source is stored - the .core file says this:11:49
maxpalnname = opencores11:49
maxpalnrepo_name = simple_spi11:49
maxpalnrepo_root = trunk/rtl/verilog11:49
maxpalnrevision = 1011:49
_franck_it is fetched when you build the system11:49
_franck_or you can fusesoc fetch simple_spi11:50
_franck_it's going to be put in your cache directory11:50
maxpalnthat would work, only I don't have fusesoc up and running yet - it was next on my list once I  had a working mor1kx implementation based on the original orpsocv2.11:51
maxpalndo you know where it gets pulled from?11:51
_franck_opencores svn11:51
stekernumm... but shouldn't the 32->8 bit bus converter fix that?11:55
stekernI mean, simple-spi is has a 8-bit wb bus, doesn't it?11:56
maxpalnaha - the second problem, I am not using your new arbiter, my arbiter doesn't do any of the fancy bus conversion11:58
maxpalnbut your point is valid, simple_spi is a byte-wide peripheral so actually wb_sel is unlikely to really offer the right functionality here.11:59
maxpalnI suspect I need to upgrade the arbiter I am using to the latest - which essentially means shifting to fusesoc I think12:00
stekernarbiter_bytebus do bus conversion12:00
maxpalnhmm, let me check what mine does12:01
stekernbut it doesn't seem to correctly decode the lower 2 bits from bsel12:03
maxpalnwell, the one I am using doesn't really do anything with the address - it simple assigns the master address to the slave address:12:03
maxpaln assign wbs0_adr_i = wbm_adr_o;12:03
stekernonce in the past mor1kx asserted those two bits... but I removed that since it was wrong..12:03
stekernmaybe I should let that out on the bus again...12:04
stekernseems there's plenty of broken wb slaves that rely on that12:04
maxpalnI can't comment beyond what I am using here - which is actually a cobbled together system from a combination of latest mor1kx and orpsocv2 arbiter, simple_spi etc.12:05
maxpalnits difficult to extrapolate too far from such a small sample size12:06
maxpalnIf your latest arbiter code would handle this situation correctly then my problem would be solved by upgrading to the latest fusesoc implementation12:06
maxpalnbut if there are other problems beyond this scenario then that is a different decision to take12:07
maxpalnI'll hang fire until you decide - if a change to the latest fusesoc arbiter will fix things then I'll head down that route. If not, and a mor1kx 'fix' will solve it I'll wait for the changes. Let me know.12:10
stekernthe wb_intercon converter should handle that, and it should be easy to decode the lowest 2 bits from wbm0_sel in the arbiter_bytebus12:10
maxpalnok, so I'll aim to shift to the latest code and check that everything still works. A bit more learning for me :-)12:14
stekernwbm_adr_o[1:0] = wbm0_sel_o[3] ? 2'b00 : wbm0_sel_o[2] ? 2'b01 : wbm0_sel_o[1] ? 2'b10 : 2'b1112:14
maxpalnah, yes - good solution - I hadn't thought of that12:15
maxpaln[feels a little foolish]12:15
stekernit's not that I'm trying to prevent you from switching over to orpsoc-cores though ;)12:20
stekernbut if it's just 'that last bug before it works' (it's never the last bug), I'd just add that fix and check if it works12:22
maxpaln:-) well, on a separate note, I have noticed the orpsocv2 arbiter produces glitches on the slave STB pins because it latches wb_slave_sel to wb_slave_sel_r, which is then used as part of the STB assert logic. Which means if address is asserted at the same time as STB (which it is in mor1kx) then you get a glitch on STB for one clock cycle before wb_slave_sel_r catches up.12:23
maxpalnIn OR1200 the address gets asserted one clock cycle ahead of STB so this problem never occurs12:23
maxpalnThe cleaner implementation of mor1kx highlights this issue12:23
maxpalnthis, along with several other things, means I am very close to hopping over to fusesoc anyway12:24
maxpalnbut you are right, if this fix allows me to verify a working current implementation it gives me an intermediate 'working' implementation to movce on from12:24
-!- LoneTech_ is now known as LoneTech12:25
-!- Netsplit *.net <-> *.split quits: kiwichris, mboehnert, arokux13:14
-!- Netsplit over, joins: kiwichris, arokux, mboehnert13:15
maxpalnok, that fixes the basic SPI loading issues - thanks, stekern! I can now see the processor boot from 0x100 :-) But still no output on UART :-( I maybe be bothered to debug in detail, but then again I may just assume the problem is in some interaction between the mor1kx and the arbiter logic I am using and jump straight to fusesoc. I'll have a think.13:31
stekernsb0: are you using the carry-flag for anything?15:49
sb0unless llvm or gcc uses it, no15:50
sb0I'm using 64-bit arithmetic, idk if that benefits from the carry flag15:50
stekernllvm and gcc *could* use it through the addc instruction, but by default, they don't15:58
stekernI'm asking, because currently there's no way to turn it off, and I just saw it in a critical path15:59
sb0fast 64-bit adds is something I'd need... but not a very high prio16:04
sb0also, lm32 couldn't do carry flag based acceleration, so ;)16:04
stekernyeah, that'16:04
stekerns what I'm thinking16:05
stekernand that's why I originally turned off addc when I did the "as close as lm32 as possible" instantiation16:05
poke53282stekern: I have compiled the musl toolchain with both patches. But it will take some time to test them.17:51
poke53282But you can tell me the difference between binutils-@VERSION@ and
poke53282because your patch doesn't apply for the latter one.17:52
stekernbinutils-@VERSION@ is an official binutils snapshot18:51
poke53282Yes, I know. The question was meant in a different way.19:27
poke53282More about compatibility.19:27
poke53282I try to renew my small software distribution for jor1k and to test musl.19:28
poke53282And I try to find a stable path through all this. And for the binutils snapshot and or1k-src I don't know the history. Or maybe I missed it.19:29
poke53282Who forked it. Which patches are in the offical binutils snapshot? Is l.swa supported? And so on.19:30
stekernoh, ok. parts (binutils) of what's in or1k-src has been upstreamed (gdb, newlib and sim are still not upstreamed).19:31
stekernall binutils work is done against upstream, so it has everything in or1k-src19:32
poke53282but the patch you send yesterday didn't apply to . Therefore my initial question.19:33
stekernyes, since it was made against upstream19:33
stekernonly use or1k-src for gdb and newlib19:35
stekernwe should split it up, but no-one has got around to it19:35
poke53282Yes, a split would be indeed better.19:36
stekernpoke53282: re your question earlier today:
poke53282This was yesterday for me:). But thanks.20:54
blueCmdjuliusb: is on hackernews23:17
poke53282Why they don't take the Openrisc ISA?23:37
poke53282looks like the instruction set is not that different23:44
--- Log closed Wed Aug 06 00:00:52 2014

Generated by 2.15.2 by Marius Gedminas - find it at!