| --- Log opened Tue Aug 05 00:00:51 2014 | ||
| poke53282 | stekern: https://github.com/openrisc/or1k-gcc/commit/5b877fb981dbc394a5773dd1976ccaf5b7415721 | 01:51 |
|---|---|---|
| poke53282 | This commit is not part of gcc yet? | 01:52 |
| poke53282 | not of the official distribution I mean. | 01:52 |
| stekern | poke53282: no, I don't think it is | 03:07 |
| stekern | I mean, it's definitely not in 4.9.0 | 03:08 |
| stekern | dalias probably now what's the status/agenda of getting in the official distribution | 03:11 |
| stekern | hmm, I think I might have an idea how to fix crappy timing of the PIPELINED multiplier | 03:16 |
| poke53282 | Ok, no problem. | 04:33 |
| poke53282 | But I have bad news. scummvm does no longer link. | 04:33 |
| poke53282 | with musl | 04:33 |
| poke53282 | stekern: I get "Error relocating /usr/lib/libgcc_s.so.1: unsupported relocation type 6" | 04:34 |
| stekern | poke53282: yes, that's the thing I've been scratching my head about for the last week or so | 04:34 |
| poke53282 | Oh :) | 04:34 |
| stekern | http://pastie.org/9443692 and http://pastie.org/9443689 | 04:35 |
| poke53282 | gcc, binutils, make link so far. | 04:35 |
| stekern | those patches should fix that | 04:36 |
| stekern | the first is for binutils-gdb and the second for or1k-gcc | 04:36 |
| poke53282 | I see | 04:38 |
| stekern | I'm going to commit both, but I want to test them a bit more first | 04:39 |
| poke53282 | Ok, anyother software with that problem? | 04:40 |
| poke53282 | seems to be a very rare link type | 04:41 |
| stekern | everything that links dynamically to libgcc | 04:41 |
| stekern | it's a very common relocation type (R_OR1K_INSN_REL_26), but it shouldn't ever be present in dynamic libraries | 04:42 |
| poke53282 | Ok | 04:46 |
| poke53282 | Hmm, another problem when I try to compile openssl | 05:28 |
| poke53282 | " /usr/sbin/ld: libcrypto.a(cryptlib.o): Relocations in generic ELF (EM: 92) | 05:28 |
| poke53282 | this is probably related | 05:29 |
| poke53282 | You habe to apply the patch from: http://rt.openssl.org/Ticket/Display.html?id=3123&user=guest&pass=guest | 05:30 |
| stekern | for the EM: 92 error? | 05:31 |
| poke53282 | yes | 05:32 |
| poke53282 | cross=or1k-linux-musl- ./Configure linux-generic32 shared --prefix=/usr --libdir=lib --openssldir=/etc/ssl zlib-dynamic -DB_ENDIAN | 05:32 |
| poke53282 | make CC=or1k-linux-musl-gcc AR="or1k-linux-musl-ar r" RANLIB="or1k-linux-musl-ranlib" | 05:32 |
| poke53282 | the commands for configure and make | 05:32 |
| stekern | ok | 05:33 |
| poke53282 | sorry to compile you have to apply the patch | 05:33 |
| poke53282 | to come to the possition where it links | 05:34 |
| poke53282 | otherwise make will stop earlier | 05:34 |
| poke53282 | I get the error line exactly three times. The same number like the libgcc linking error. | 05:35 |
| stekern | ok, but that error is unrelated to the libgcc error | 05:38 |
| stekern | you usually get that error when you mistakenly try to link together elfs from different machines | 05:39 |
| poke53282 | Ok | 05:42 |
| stekern | so, my guess is that something still gets wrong in the cross-compile | 05:50 |
| stekern | '/usr/sbin/ld' doesn't sound like it'd be the or1k ld | 05:50 |
| poke53282 | yes, your are right. | 05:51 |
| poke53282 | It takes the wrong executables here for some reason. | 05:51 |
| poke53282 | it works. I had to apply another patch. | 06:05 |
| stekern | sb0: 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 |
| sb0 | the fpga I'm using is not covered by webpack, idk if some k7's are | 08:43 |
| blueCmd | stekern: that's much nicer if it does what it's supposed to :P | 09:49 |
| stekern | it does ;) | 09:55 |
| stekern | i.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 |
| blueCmd | bfd patch? | 10:16 |
| blueCmd | ah, I backlogged and found it | 10:17 |
| stekern | blueCmd: or, what were you speaking about? =P | 10:38 |
| maxpaln | I 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 RAM | 11:28 |
| maxpaln | are there differences in the way the l.sb instruction works between or1200 and mor1kx? | 11:28 |
| maxpaln | The bootrom includes an instruction that *should* write 0x3 to address B0000002 in the SPI peripheral | 11:29 |
| maxpaln | in the OR1200 this works, in the mor1kx it writes 0x3 to address 0xB0000000 | 11: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 signal | 11:32 |
| _franck_ | and address[1:0] | 11:32 |
| _franck_ | mor1kx set adress[1:0] to 0 because we do access a 32bits bus | 11:33 |
| _franck_ | or1200 set bits [1:0] to their value | 11:34 |
| _franck_ | so if your peripheral doesn't handle we_sel properly it won't work | 11:34 |
| _franck_ | *wb_sel | 11:34 |
| _franck_ | maxpaln: ^ | 11:35 |
| ysionnea1 | :) | 11:39 |
| ysionnea1 | and there is the EUREKA moment | 11:39 |
| maxpaln | _franck_: great analysis. | 11:40 |
| maxpaln | hmmm, I'm using the simple_spi.v that came with the original orpsocv2 - | 11:40 |
| maxpaln | I am guessing this didn't implement the wb_sel correctly - | 11:41 |
| maxpaln | I'll see if the latest code is any different | 11:41 |
| maxpaln | LOL - the simple_spi.v doesn't even have a wb_sel input!! | 11:43 |
| maxpaln | that makes analysing whether it handles it correctly a simple process | 11:43 |
| maxpaln | hmmm, my newbie background strikes again - | 11:48 |
| maxpaln | I have orpsoc-cores from git clone https://github.com/openrisc/orpsoc-cores.git | 11:48 |
| maxpaln | but it doesn't include the source for the simple_spi.v | 11:49 |
| maxpaln | Anyh clues as to where the source is stored - the .core file says this: | 11:49 |
| maxpaln | [provider] | 11:49 |
| maxpaln | name = opencores | 11:49 |
| maxpaln | repo_name = simple_spi | 11:49 |
| maxpaln | repo_root = trunk/rtl/verilog | 11:49 |
| maxpaln | revision = 10 | 11:49 |
| _franck_ | it is fetched when you build the system | 11:49 |
| _franck_ | or you can fusesoc fetch simple_spi | 11:50 |
| _franck_ | it's going to be put in your cache directory | 11:50 |
| _franck_ | ~/.cache/...... | 11:50 |
| maxpaln | that 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 |
| maxpaln | do you know where it gets pulled from? | 11:51 |
| _franck_ | opencores svn | 11:51 |
| maxpaln | thanks | 11:51 |
| _franck_ | http://opencores.org/ocsvn/simple_spi/simple_spi/trunk/rtl/verilog | 11:52 |
| stekern | umm... but shouldn't the 32->8 bit bus converter fix that? | 11:55 |
| stekern | I mean, simple-spi is has a 8-bit wb bus, doesn't it? | 11:56 |
| stekern | -is | 11:56 |
| maxpaln | aha - the second problem, I am not using your new arbiter, my arbiter doesn't do any of the fancy bus conversion | 11:58 |
| maxpaln | but 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 |
| maxpaln | I suspect I need to upgrade the arbiter I am using to the latest - which essentially means shifting to fusesoc I think | 12:00 |
| stekern | arbiter_bytebus do bus conversion | 12:00 |
| maxpaln | hmm, let me check what mine does | 12:01 |
| stekern | but it doesn't seem to correctly decode the lower 2 bits from bsel | 12:03 |
| maxpaln | well, 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 |
| stekern | once in the past mor1kx asserted those two bits... but I removed that since it was wrong.. | 12:03 |
| stekern | maybe I should let that out on the bus again... | 12:04 |
| stekern | seems there's plenty of broken wb slaves that rely on that | 12:04 |
| maxpaln | I 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 |
| maxpaln | its difficult to extrapolate too far from such a small sample size | 12:06 |
| maxpaln | If your latest arbiter code would handle this situation correctly then my problem would be solved by upgrading to the latest fusesoc implementation | 12:06 |
| maxpaln | but if there are other problems beyond this scenario then that is a different decision to take | 12:07 |
| maxpaln | I'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 |
| stekern | the wb_intercon converter should handle that, and it should be easy to decode the lowest 2 bits from wbm0_sel in the arbiter_bytebus | 12:10 |
| maxpaln | ok, so I'll aim to shift to the latest code and check that everything still works. A bit more learning for me :-) | 12:14 |
| stekern | wbm_adr_o[1:0] = wbm0_sel_o[3] ? 2'b00 : wbm0_sel_o[2] ? 2'b01 : wbm0_sel_o[1] ? 2'b10 : 2'b11 | 12:14 |
| stekern | ; | 12:14 |
| maxpaln | ah, yes - good solution - I hadn't thought of that | 12:15 |
| maxpaln | [feels a little foolish] | 12:15 |
| stekern | it's not that I'm trying to prevent you from switching over to orpsoc-cores though ;) | 12:20 |
| stekern | but 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 works | 12: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 |
| maxpaln | In OR1200 the address gets asserted one clock cycle ahead of STB so this problem never occurs | 12:23 |
| maxpaln | The cleaner implementation of mor1kx highlights this issue | 12:23 |
| maxpaln | this, along with several other things, means I am very close to hopping over to fusesoc anyway | 12:24 |
| maxpaln | but you are right, if this fix allows me to verify a working current implementation it gives me an intermediate 'working' implementation to movce on from | 12:24 |
| -!- LoneTech_ is now known as LoneTech | 12:25 | |
| -!- Netsplit *.net <-> *.split quits: kiwichris, mboehnert, arokux | 13:14 | |
| -!- Netsplit over, joins: kiwichris, arokux, mboehnert | 13:15 | |
| maxpaln | ok, 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 |
| stekern | sb0: are you using the carry-flag for anything? | 15:49 |
| sb0 | unless llvm or gcc uses it, no | 15:50 |
| sb0 | I'm using 64-bit arithmetic, idk if that benefits from the carry flag | 15:50 |
| stekern | llvm and gcc *could* use it through the addc instruction, but by default, they don't | 15:58 |
| stekern | I'm asking, because currently there's no way to turn it off, and I just saw it in a critical path | 15:59 |
| sb0 | fast 64-bit adds is something I'd need... but not a very high prio | 16:04 |
| sb0 | also, lm32 couldn't do carry flag based acceleration, so ;) | 16:04 |
| stekern | yeah, that' | 16:04 |
| stekern | s what I'm thinking | 16:05 |
| stekern | and that's why I originally turned off addc when I did the "as close as lm32 as possible" instantiation | 16:05 |
| poke53282 | stekern: I have compiled the musl toolchain with both patches. But it will take some time to test them. | 17:51 |
| poke53282 | But you can tell me the difference between binutils-@VERSION@ and https://github.com/openrisc/or1k-src | 17:52 |
| poke53282 | because your patch doesn't apply for the latter one. | 17:52 |
| stekern | binutils-@VERSION@ is an official binutils snapshot | 18:51 |
| poke53282 | Yes, I know. The question was meant in a different way. | 19:27 |
| poke53282 | More about compatibility. | 19:27 |
| poke53282 | I try to renew my small software distribution for jor1k and to test musl. | 19:28 |
| poke53282 | And 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 |
| poke53282 | Who forked it. Which patches are in the offical binutils snapshot? Is l.swa supported? And so on. | 19:30 |
| stekern | oh, ok. parts (binutils) of what's in or1k-src has been upstreamed (gdb, newlib and sim are still not upstreamed). | 19:31 |
| stekern | all binutils work is done against upstream, so it has everything in or1k-src | 19:32 |
| poke53282 | but the patch you send yesterday didn't apply to https://github.com/openrisc/or1k-src . Therefore my initial question. | 19:33 |
| stekern | yes, since it was made against upstream | 19:33 |
| stekern | only use or1k-src for gdb and newlib | 19:35 |
| stekern | we should split it up, but no-one has got around to it | 19:35 |
| poke53282 | Yes, a split would be indeed better. | 19:36 |
| stekern | poke53282: re your question earlier today: http://www.openwall.com/lists/musl/2014/08/05/10 | 20:07 |
| poke53282 | This was yesterday for me:). But thanks. | 20:54 |
| blueCmd | juliusb: http://www.lowrisc.org/ is on hackernews | 23:17 |
| poke53282 | Why they don't take the Openrisc ISA? | 23:37 |
| poke53282 | looks like the instruction set is not that different | 23:44 |
| --- Log closed Wed Aug 06 00:00:52 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!