| --- Log opened Thu Jul 31 00:00:43 2014 | ||
| poke53281 | blueCmd: The flags are implemented in a horrible way. | 00:27 |
|---|---|---|
| poke53281 | to use it with qemu-user is not so easy on the command line | 00:29 |
| poke53281 | the binfmt-tools don't support options. | 00:29 |
| poke53281 | and a bash script is not possible to execute. | 00:29 |
| poke53281 | I would suggest, that you change the qemu source that the noflags cpu is the default. | 00:30 |
| poke53281 | I guess the speed improvement will be a a factor 2 or 3. | 00:30 |
| poke53281 | stekern: When I try to install the new uClibc I get an error message. http://pastie.org/9433181 | 04:40 |
| poke53281 | Maybe you know anything about it. | 04:40 |
| stekern | poke53281: you should use the Linux headers from upstream | 04:54 |
| stekern | not the ones in jonas repo | 04:54 |
| stekern | poke53281: but really, you should use musl ;) | 04:57 |
| stekern | dalias: thanks for committing the mmap2 fixes | 05:00 |
| stekern | and I think your way of doing it is the right way (defining it as PAGE_SIZE not PAGE_SHIFT) and do the divide in __mmap | 05:01 |
| dalias | :) | 05:01 |
| stekern | arc actually have a chance of working in musl | 05:01 |
| stekern | if it'd ever get ported ;) | 05:02 |
| dalias | arc? | 05:02 |
| dalias | stekern, the divide is in case we ever have to define UNIT as libc.page_size, for an arch where it's variable and the kernel uses the current pagesize for the mmap2 unit | 05:02 |
| dalias | in that case the kernel didn't give us a PAGE_SHIFT, only a PAGE_SIZE... | 05:02 |
| stekern | yes, you can configure the arc kernel to have either 4/8/16K pages and their mmap2 follow that | 05:03 |
| dalias | so unless we go to the trouble of converting it elsewhere (which would be really ugly) there's no choice but to divide | 05:03 |
| stekern | so, exactly the case you just described | 05:03 |
| dalias | ah, i see | 05:03 |
| dalias | is arc interesting? i'm not familiar with it | 05:04 |
| stekern | dunno, I was just browsing the kernel to see which other archs had broken mmap2 and spotted that | 05:04 |
| dalias | :) | 05:07 |
| stekern | jeremy_bennett can probably answer, he has afair been deeply involved with arc in a previous life | 05:07 |
| dalias | btw the whole mmap2 thing is stupid | 05:07 |
| dalias | it can only map up to 16TB offsets | 05:07 |
| dalias | i'm pretty sure there can be files bigger than that now | 05:08 |
| dalias | linux needs to add a proper mmap64 syscall with a full 64bit offset | 05:08 |
| stekern | yeah | 05:09 |
| poke53281 | stekern: How do you know, which linux headers I am using :) | 05:14 |
| poke53281 | Yes, I use indeed some kernel from jonas repo | 05:15 |
| stekern | poke53281: well, you showed me your error messages ;) | 05:16 |
| stekern | you can use that kernel, just not the headers from that | 05:18 |
| stekern | if you want to be adventurous, you can use this: http://git.openrisc.net/cgit.cgi/stefan/linux/log/?h=smp | 05:20 |
| poke53281 | This is annonying. Which each kernel I run into another problem. | 05:20 |
| poke53281 | No, I had enough adventurous for today. Updated binutils, uclibc and gcc. | 05:21 |
| stekern | what problems are you seeing now? | 05:21 |
| stekern | ;) | 05:22 |
| poke53281 | cloning another mega repository. This would be the third incarnation of the Linux repo on my hard drive. | 05:24 |
| stekern | well... you can clone with: git clone --depth 1 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git | 05:27 |
| poke53281 | 1. Linux: segmentation fault, when using my old uClibc. New headers and a bew compilation of uClibc solved this. | 05:27 |
| poke53281 | 2. Linux: The ethernet no longer works. | 05:27 |
| poke53281 | 3. Linux: my compiled X-window system gives strange output and crashed after some time. | 05:28 |
| poke53281 | 4. Linux: I realize that my bzip2 decompression routine is maybe buggy and I add checksums. | 05:28 |
| stekern | but wait.... wasn't 2. when you used another repo than jonas'? | 05:29 |
| poke53281 | Yes, no 2. | 05:29 |
| stekern | so... what Linux repo are you using? | 05:29 |
| poke53281 | The one from jonas currently. | 05:30 |
| poke53281 | But as you can see in No. 4. Maybe the problem is fully kernel related | 05:30 |
| poke53281 | No 2 is also solved I think. But the kernel crashed one or two times. So I went back to 3.13 | 05:31 |
| poke53281 | But I patch the kernel pretty much. | 05:32 |
| poke53281 | Especially the htlb. | 05:33 |
| stekern | did you try to use old userspace with the non-jonas kernel? | 05:36 |
| poke53281 | At least the toolchain compiles now. | 05:36 |
| stekern | that will not work | 05:36 |
| poke53281 | Yes, I tried. And yes, it didn't work. I realized that. | 05:36 |
| stekern | because old userspace will try to call syscalls that openrisc doesn't have | 05:37 |
| stekern | jonas repo have a couple of patches that added the 'deprecated' syscalls, because at that time uclibc couldn't handle archs that were missing them | 05:39 |
| poke53281 | Ahh, Ok. I understand | 05:40 |
| stekern | I removed those patches when I rebased all the out-of-tree patches ontop of 3.15 | 05:40 |
| stekern | because they are not 'needed' anymore | 05:41 |
| stekern | (as long as you are not trying to run old userspace apps) | 05:41 |
| stekern | but you wouldn't have been able to run your old userspace apps on a vanilla kernel from mainline neither | 05:44 |
| poke53281 | Yes, therefore I wanted to take the easy way and use an "old" kernel. | 05:45 |
| stekern | I can dig out the couple of lines that the patch added for you ;) | 05:46 |
| stekern | but as you saw, it will produce 'broken' linux headers | 05:46 |
| poke53281 | Ahh, no problem. Let me see, how far I get if everything is new. | 05:47 |
| stekern | http://pastie.org/9433271 | 05:51 |
| stekern | I dug them out anyway ;) | 05:51 |
| jeremy_bennett | stekern: dalias: just seen the post regarding ARC - it is a configurable architecture, so has a more complex tool chain than most. Joern Rennecke (amylaar) is the maintainer. | 08:50 |
| jeremy_bennett | But I think this is the Linux side of things, so not is particular area of expertise. If you can phrase the question in an email I can try to see who knows about it. | 08:51 |
| stekern | jeremy_bennett: the question was more of general nature, whether ARC is interesting (like where it's typically used and so forth) | 09:25 |
| stekern | the particular issue that it has in the Linux kernel is all clear to us, we don't need further explanations about that ;) | 09:26 |
| blueCmd | stekern: 15665: binding file /usr/lib/or1k-linux-gnu/libapt-pkg.so.4.12 [0] to /lib/or1k-linux-gnu/libgcc_s.so.1 [0]: normal symbol `__umodsi3' [GCC_3.0] | 09:46 |
| blueCmd | :( | 09:46 |
| blueCmd | 105: 00002624 32 FUNC GLOBAL DEFAULT 12 __umodsi3@@GCC_3.0 | 09:46 |
| blueCmd | oooh | 09:48 |
| blueCmd | maaaybe | 09:48 |
| blueCmd | 15681: symbol=__umodsi3; lookup in file=/usr/lib/or1k-linux-gnu/libstdc++.so.6 [0] | 09:48 |
| blueCmd | 15681: symbol=__umodsi3; lookup in file=/lib/or1k-linux-gnu/libm.so.6 [0] | 09:48 |
| blueCmd | 15681: symbol=__umodsi3; lookup in file=/lib/or1k-linux-gnu/libgcc_s.so.1 [0] | 09:48 |
| blueCmd | do you recon this is like a trace? that libm is the one that is accessing it? | 09:48 |
| stekern | where is this from? | 09:48 |
| blueCmd | yes, maybe. Let's recompiled glibc again (which I remember promising but totally not doing) | 09:48 |
| stekern | what are you doing? | 09:48 |
| blueCmd | stekern: LD_DEBUG=all apt-get install asdasdasd | 09:48 |
| stekern | what is going wrong? | 09:49 |
| blueCmd | stekern: it's the same crash as before | 09:49 |
| stekern | =P | 09:49 |
| blueCmd | stekern: :) | 09:49 |
| blueCmd | stekern: but you did a good job being a rubber duck here anyway | 09:49 |
| stekern | but you said it had moved to strcasecmp? | 09:49 |
| blueCmd | stekern: it moved back! | 09:49 |
| stekern | geese and ducks, you're just full of bird analogies | 09:51 |
| blueCmd | yes | 09:52 |
| stekern | can you define 'crash'? | 09:53 |
| stekern | are there fire? | 09:53 |
| stekern | blueCmd: is the current glibc compiled against the asm libgcc without @function and .size? | 09:58 |
| stekern | the one that crashes | 09:59 |
| blueCmd | stekern: yes | 10:02 |
| blueCmd | so I think that's the problem | 10:02 |
| blueCmd | that maybe now everything else works, and in the old case glibc worked but everything else was broken | 10:02 |
| blueCmd | hm, apparently we do not support STT_GNU_IFUNC for binutils | 10:09 |
| stekern | what does it do? | 10:16 |
| maxpaln | Hi, starting to debug the mor1kx - I found I had some simulator hangs and the Linux binary I used in HW for the OR1200 doesn't work. I am guessing I have a SW issue - maybe a GCC version problem or something like that. The first thing I want to do is get a clean set of simulations running using the latest tests that stekern pointed me at. | 10:21 |
| maxpaln | I am missing or1k-asm.h - and poking around I noticed several other aspects to that set of tests that weren't present in the originals. For example, native/lib contains a Makefile but I am not sure how it's targets should be used etc. | 10:23 |
| maxpaln | what's the recommended use model for these new tests? | 10:23 |
| stekern | or1k-asm is included in the or1k- toolchains | 10:23 |
| maxpaln | ok, so I wonder why it isn't being found | 10:24 |
| stekern | I forgot that you were still using the old toolchain when I pointed you to the test repo | 10:24 |
| maxpaln | more generally, I wonder if I am making hard work for myself by trying to back in these new tests into my old test environment. | 10:24 |
| maxpaln | This could be a good spot to segue into a full up to date tool chain etc. | 10:25 |
| maxpaln | thoughts? | 10:25 |
| stekern | yes, but otoh, then you are changing a lot of things at the same time | 10:25 |
| maxpaln | Agreed. | 10:25 |
| stekern | I would stick with the old tests | 10:25 |
| maxpaln | Ok, but the old tests don't pass at the moment | 10:25 |
| maxpaln | well | 10:25 |
| maxpaln | a lot of them do | 10:25 |
| maxpaln | but one of them hung - | 10:26 |
| stekern | at least until you're confident that your soc is sound | 10:26 |
| stekern | the linux kernel compiled 'for or1200' should just work (unless your soc is otherwise substantially different) | 10:27 |
| maxpaln | well, I found that or1200-except didn't complete | 10:27 |
| maxpaln | to speed up sim I wasn't tracing any signals in the simulator - so I haven't been able to debug | 10:27 |
| maxpaln | when I tested the Linux kernel in HW and found it didn't boot either (no UART output) I thought there must be a SW issue somewhere. | 10:28 |
| maxpaln | Let me run the tests again with signal tracing enabled and go back to debugging the individual tests | 10:30 |
| maxpaln | until I have a cleanly passing set of simulation results I think I am on a hiding to nothing... | 10:30 |
| blueCmd | poke53281: man, that noflags thing was much faster. no wonder since it translates adds 1:1 | 10:32 |
| stekern | there *might* be some of the or1200 tests that makes assumptions that are only valid for or1200 (stupid assumptions, like that a certain amount of instructions should take a certain amount of ticks) | 10:33 |
| stekern | I don't know if exactly that assumption exist, but that type of assumptions | 10:33 |
| stekern | or you've just found a bug in mor1kx | 10:34 |
| maxpaln | maybe - I guess we'll see once I start debugging | 10:34 |
| maxpaln | just running through the simulations again now | 10:34 |
| stekern | if you have the or1200-except elf I can give it a run here too | 10:36 |
| maxpaln | Hmmm, interesting - to speed things up I switched from my DDR3 memory model to the basic SRAM - it simulates around 1000 times quicker :-), if I get a clean sweep on the SRAM tests I'll re-run with the DDR3 model | 10:36 |
| maxpaln | Almost immediately I have got a failure on or1200-mmu | 10:36 |
| stekern | if you can gather together the elfs from the failing tests I can try to run them here too | 10:40 |
| maxpaln | ok, I'll zip them up and send them over | 10:41 |
| stekern | I mean, feel free to debug them yourself, but four eyes are always better than two | 10:43 |
| stekern | heh, coincidently I just found a bug in mor1kx mmu | 10:44 |
| maxpaln | :-) don't worry - I'll be doing plenty of debugging | 10:52 |
| maxpaln | but knowing that the ELF *should* work is a nice starting point! | 10:52 |
| maxpaln | ok, 6 failures out of 18 tests - that's a pretty big hit ratio. I have included a README that lists how the test fails in case you care - four of them produce an simulation failure, two them just hang | 11:21 |
| maxpaln | https://www.dropbox.com/s/7j3sck4nfrm8iwo/elfs.tar.gz | 11:21 |
| maxpaln | I'll let you know what I find | 11:21 |
| stekern | great, thanks | 11:27 |
| jeremy_bennett | stekern: Ah OK - the answer to that is that ARC is very interesting. Due to its configurability. It is quite widely used as an embedded core (since it is Synopsys' in house core). | 11:34 |
| stekern | maxpaln: this is the results I gained from these tests: dsxinsn and mmu passes | 11:51 |
| stekern | ext and mac instructions aren't implemented in mor1kx so they are kind of expected to fail | 11:52 |
| stekern | the ext instructions should be easy to add, so that was a good reminder for me to do. | 11:52 |
| stekern | I think the overflow handling in or1200 isn't exactly compliant with the spec, so that might be the reason why that fails | 11:53 |
| stekern | that leaves that and the except test as question marks, I have no good explanation to why the except test fails. | 11:54 |
| stekern | interestingly, the except test doesn't hang for me like it did for you | 11:59 |
| maxpaln | hmm, just back at my desk | 12:00 |
| maxpaln | so i'll remove ext and mac from my tests. | 12:01 |
| maxpaln | so for the remainder your results are: or1200-except: fail, or1200-ov: fail, or1200-mmu: ? or1200-dsxinsn ? | 12:04 |
| maxpaln | sorry - just noticed that the two I marked as ? pass | 12:05 |
| maxpaln | maybe I'll start with the except test - it fails for you and hangs for me, that could be a good clue. | 12:05 |
| maxpaln | out of interest, the OR1200 monitor used to produce some nice log file giving instruction sequences and register dumps etc. Can you MOR1kX monitor do this (yet)? | 12:11 |
| stekern | yes | 12:12 |
| stekern | it can even produce nicer instruction traces | 12:12 |
| stekern | with disassembled instructions | 12:13 |
| stekern | juliusb was crazy enough to write an disassembler in verilog ;) | 12:13 |
| maxpaln | Nice! - I have included the monitor now (I eventually worked out the defines) but the output in the ../out folder is this | 12:13 |
| maxpaln | [root@localhost run]# ls -l ../out | 12:14 |
| maxpaln | total 16 | 12:14 |
| maxpaln | -rw-r--r-- 1 root root 64 Jul 31 05:10 or1200-mmu-general.log | 12:14 |
| maxpaln | -rw-r--r-- 1 root root 38 Jul 31 05:10 or1200-mmu-trace.log | 12:14 |
| maxpaln | neither contain the instructions etc. | 12:14 |
| maxpaln | do I have to enable something in the monitor? | 12:14 |
| stekern | I think you have to poke it with something to make it emit it | 12:14 |
| maxpaln | hmmm , let me have a look | 12:14 |
| stekern | it slows down simulation, so you don't want it always remembered | 12:14 |
| stekern | ehm enabled | 12:14 |
| stekern | I was about to say that I don't remember how that's done in the next sentence... | 12:15 |
| maxpaln | aha, +define+TRACE_ENABLE appers to be the ticket | 12:16 |
| maxpaln | or rather +define+trace_enable | 12:17 |
| fnunes | Hi, I am trying to connect OpenOCD to a digilent atlys board using the digilent programming port or the xilinx platform cable. Is it possible to openocd use the vendors drivers ? | 12:17 |
| stekern | using the xilinx platform cable should definetely be possible, iirc someone did that | 12:17 |
| stekern | using the digilent programming port should be possible in theory, but I don't know how much effort is required to make that work | 12:18 |
| fnunes | I tried but it seems necessary to write a driver/deamon that supports openocd. | 12:19 |
| stekern | hmm... this mmu bug is interesting, it happens under a scenario I'm not sure how it should be handled | 12:29 |
| stekern | the problem is that the kernel has a variable in memory has the cache inhibit bit set (at least during boot), but this variable is also being accessed with the mmu off. | 12:32 |
| stekern | so, the problem is that writes to that memory area when the mmu is on will not be seen by the accesses when the mmu is off | 12:33 |
| stekern | I'm fixing it now by letting the writes go through to the cache even though the cache inhibit bit is set, I can't come up with any drawbacks with this approach | 12:34 |
| maxpaln | oh, nice - the monitor trace output is sweet! | 12:47 |
| maxpaln | it is enabled via +trace_enable on the vsim command BTW | 12:47 |
| blueCmd | poke53281: you cut down the compile time like 6 times with that flag | 12:50 |
| blueCmd | poke53281: \o/ | 12:50 |
| maxpaln | well, my mmu simulation failure is triggered by a Bus Exception - it occurs during the Write Tes Program section of the itlb_translation_test() - here to be precise: | 13:07 |
| maxpaln | S 00002518: 9c420001 l.addi r2,r2,0x0001 r2= 00000007 flag: 1 | 13:07 |
| maxpaln | S 000033f4: c0032000 l.mtspr r3,r4,0x0000 SPR[1802] = 0010c060 flag: 1 | 13:07 |
| maxpaln | S 00000200: 9c21ff00 l.addi r1,r1,0xff00 r1= 0000a444 flag: 1 | 13:07 |
| maxpaln | going to dive into the simulation waveform to track down | 13:07 |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/7b0883381535d3915d302b0f1cfa4fc1eb50ca1c | 13:07 |
| mor1kx | mor1kx/master 7b08833 Stefan Kristiansson: cappuccino/lsu: perform stores to cache during cache inhibit... | 13:07 |
| stekern | maxpaln: hmm, non of those instructions should cause bus errors | 13:08 |
| maxpaln | yep, that is what I concluded | 13:08 |
| stekern | where is the closest load/store before that? | 13:08 |
| maxpaln | although, it is nice to have an expert confirm it | 13:08 |
| stekern | stores on mor1kx is deferred | 13:09 |
| maxpaln | S 0000250c: d410a000 l.sw 0x0000(r16),r20 [0010c064] = 15000000 flag: 1 | 13:09 |
| maxpaln | S 00002510: 9c601802 l.addi r3,r0,0x1802 r3= 00001802 flag: 1 | 13:09 |
| maxpaln | S 00002514: 040003b8 l.jal 0x00003b8 flag: 1 | 13:09 |
| maxpaln | S 00002518: 9c420001 l.addi r2,r2,0x0001 r2= 00000007 flag: 1 | 13:09 |
| maxpaln | S 000033f4: c0032000 l.mtspr r3,r4,0x0000 SPR[1802] = 0010c060 flag: 1 | 13:09 |
| maxpaln | S 00000200: 9c21ff00 l.addi r1,r1,0xff00 r1= 0000a444 flag: 1 | 13:09 |
| stekern | so you can get the exception later in the execution stream, but epcr should still point to the load/store | 13:10 |
| maxpaln | ah, I see | 13:10 |
| maxpaln | putting together a sensible waveform now | 13:10 |
| stekern | ah, it can be the l.jal. instruction fetch can cause bus errors as well | 13:10 |
| stekern | or the store before that | 13:11 |
| stekern | how much ram do you have in your simulation system? | 13:12 |
| stekern | the store is just above 1MB, I bet you at least have that much? | 13:12 |
| maxpaln | not much - its an SRAM | 13:12 |
| stekern | I think the tests expects at least 8MB | 13:12 |
| maxpaln | Ah, good spot - | 13:13 |
| maxpaln | I had shrunk the amount of SRAM so I could run a HW test with it - I only had 64 KB :-) | 13:14 |
| maxpaln | I will run again with 8 MB | 13:14 |
| maxpaln | I think you beat me by about 2 minutes - I had just noticed the WB_RAM component asserting errors, that only really happens when an address larger than the instantiated RAM is accessed! | 13:14 |
| maxpaln | put that one down as a stupid error! | 13:17 |
| maxpaln | I try to keep those under 10 a day!! | 13:17 |
| maxpaln | yep, mmu test now passes. | 13:17 |
| maxpaln | so lets try the except test now - this one failed for you too. | 13:17 |
| maxpaln | ok, I have discovered the cause of the hang in my except | 13:40 |
| maxpaln | I suspect the reason it doesn't hang in your case is that you are using a newer/better arbiter implementation | 13:40 |
| maxpaln | In fact, this comes back to the discussion we had earlier about whether it is valid for STB to remain asserted between ccyles | 13:41 |
| maxpaln | The sequence of events is like this: | 13:41 |
| maxpaln | CPU deliberately attempts to access an invalid memory address at 0xEE - | 13:41 |
| maxpaln | due to the way the arbiter is set up in my SOC this goes nowhere and eventually triggers a watchdog error | 13:42 |
| maxpaln | however, the STB never deasserts before starting the new cycle - | 13:42 |
| maxpaln | and the sourcve of the bug is that the watchdog timer is looking for that transition on STB to start the timer | 13:43 |
| maxpaln | assign wbm_stb_edge = (wbm_stb_o & !wbm_stb_r); | 13:43 |
| maxpaln | always @(posedge wb_clk) | 13:43 |
| maxpaln | if (wb_rst) watchdog_timer <= 0; | 13:43 |
| maxpaln | else if (wbm_ack_i) // When we see an ack, turn off timer | 13:43 |
| maxpaln | watchdog_timer <= 0; | 13:43 |
| maxpaln | else if (wbm_stb_edge) // New access means start timer again | 13:43 |
| maxpaln | watchdog_timer <= 1; | 13:43 |
| maxpaln | so the new access to 0xEE goes nowhere and the watchdog hasn't been triggered! | 13:43 |
| maxpaln | I think the solution is probably to upgrade the arbiter in my SOC - what do you think? | 13:44 |
| stekern | hmm, yeah | 13:51 |
| stekern | but why does that code even look for an edge? | 13:51 |
| maxpaln | we have pulled holes inthe arbiter implementation before - I think it is generally quite poor. | 13:52 |
| maxpaln | The question is how to improve - I am not against a wholesale change to whatever is the newest version | 13:53 |
| maxpaln | With a new processor and arbiter(s) this would essentially bring me close to the latest HW I guess - peripherals aside. | 13:54 |
| maxpaln | At the very least it would be good to review the latest arbiter for ideas on patching up the version I am using. | 13:55 |
| maxpaln | what's the quickest way to download the latest SOC code? Is there a git clone? | 13:55 |
| maxpaln | I guess this would be ORPSoCv3 | 13:57 |
| maxpaln | Found this on the opencores.org websit e- will assume this is up to date | 13:58 |
| maxpaln | git clone https://github.com/openrisc/orpsoc-cores.git | 13:58 |
| blueCmd | maxpaln: git clone https://github.com/olofk/fusesoc.git and the one you said | 14:01 |
| maxpaln | hmmm, this is pretty different - not completely unrecognisable - but different enough that It's not entirely clear how it hangs together. I'll review some of the systems - maybe the atyls board, to see if there are good examples of hanging a SOC together | 14:06 |
| Hesham | Hi | 14:08 |
| maxpaln | hmmm, I see a fundamentally different approach is used here - there is one arbiter per peripheral... | 14:08 |
| Hesham | I have used verilator model as stekern suggested, should I use OpenOCD to connect it with GDB? | 14:09 |
| maxpaln | Hmmm, this comment is interesting - https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_intercon/wb_mux.v#L17 | 14:11 |
| maxpaln | I don't see an external watchog in the atlys system | 14:12 |
| maxpaln | or any of the others for that matter - curious! | 14:13 |
| maxpaln | perhaps even more interesting is the fact that the latest or1k-tests stekern sent me doesn't include an except test - at least not by that name | 14:20 |
| stekern | Hesham: yes | 14:20 |
| stekern | maxpaln: yes, there is no watchdog (yet) | 14:22 |
| stekern | that comment is however false | 14:22 |
| stekern | it will error on out of bound accesses | 14:22 |
| maxpaln | aha - so where is that implemented - because that scenario is pretty much what the watchdog in my arbiter is doing | 14:24 |
| maxpaln | the out of bounds trapping that is, I haven't spotted it anywhere yet | 14:26 |
| stekern | https://github.com/openrisc/orpsoc-cores/blob/master/cores/wb_intercon/wb_mux.v#L112 | 14:30 |
| stekern | man the or1200 tests are crap, there's no clear way they are expressing where they fail... | 14:32 |
| stekern | they just incremenet a counter and then check that that happen to match a 'magic' constant | 14:32 |
| maxpaln | I found them confusing - but then I don't really follow most of the tests so I assumed I was misunderstanding the point. %-) | 14:34 |
| blueCmd | stekern: rebuilding gcc doesn't seem to fix my crash :'( | 14:38 |
| blueCmd | still crashes on loading __umodsi3 | 14:38 |
| stekern | gcc? | 14:38 |
| blueCmd | I'll try to rebuild gcc one final time with the new glibc, then there should be no traces left of the weird asm file | 14:38 |
| blueCmd | glibc* | 14:38 |
| blueCmd | augh. I did rebuild glibc, I'm about to rebuild gcc again | 14:39 |
| stekern | mmm | 14:39 |
| maxpaln | ok, I see - this is starting to make sense now | 14:44 |
| maxpaln | at least, I can see how the arbiter hangs together - but I am a little confused about why the atlys orpsoc_top.v doesn't appear to instantiate wb_intercon() | 14:47 |
| stekern | ok, I understand why the except test fails here too | 14:49 |
| stekern | it has to do with the deferred stores | 14:49 |
| maxpaln | Have I unwittingly highlighted a bug! | 14:51 |
| stekern | maxpaln wb_intercon is instantiated in this autogenerated file: https://github.com/openrisc/orpsoc-cores/blob/master/systems/atlys/rtl/verilog/wb_intercon.vh#L242 | 14:51 |
| stekern | no, it's just that the test will not work with | 14:51 |
| maxpaln | ok, well that is good news, kinda - I can skip the test :-) | 14:52 |
| stekern | -with | 14:52 |
| stekern | so, the assumption is that bus errors are non-recoverable, so when you get the bus exception, you'll get the pc and offending address for debugging purposes | 14:53 |
| stekern | but, the or1200-except test tries to recover after the bus errors it has induced | 14:54 |
| Hesham | OK, thanks stekern | 14:54 |
| stekern | Hesham: you should invoke openocd like this for that: ./src/openocd -c "set TAP_TYPE MOHOR" -f ./tcl/interface/jtag_vpi.cfg -f ./tcl/board/or1k_generic.cfg -s ./tcl | 14:55 |
| maxpaln | aha - ok, actually now you mention it I did wonder how this test managed to carry on after a bus exception but when I was debugging the Linux kernel in HW a bus exception was fatal. | 14:56 |
| maxpaln | and, as for the wb_interconnect - that makes complete sense now. | 14:56 |
| Hesham | stekern: There is no ./tcl/board/or1k_generic.cfg file there | 14:56 |
| Hesham | I only found ./tcl/target/or1k.* file | 14:57 |
| maxpaln | so, I am assuming that wb_interconnect also gets auto generated by the fusesoc tools. | 14:58 |
| stekern | maxpaln: actually, it's a python script in orpsoc-cores/wb_intercon/sw/ | 14:59 |
| Hesham | stekern: https://github.com/openrisc/openOCD/tree/master/tcl/board ain't this the correct repo to clone ? | 14:59 |
| stekern | Hesham: ah, no... http://sourceforge.net/p/openocd/code/ci/master/tree/tcl/board/or1k_generic.cfg | 15:00 |
| stekern | you should use openocd from upstream | 15:00 |
| stekern | i.e. the official openocd repo | 15:00 |
| maxpaln | In light of the abandonment of the except test it is possible I can still get a passing simulation regression suite against my SOC. I will target that for now - if I run into problems I may skip a step and jump to the new fusesoc flow. | 15:00 |
| Hesham | Unfortunately I was following these instruction -> http://opencores.org/or1k/OpenOCD#Mohor_debug_unit I assume it's out-dated now | 15:01 |
| Hesham | Thanks stekern | 15:01 |
| stekern | ah, maybe they are | 15:01 |
| stekern | _franck_ is our openocd expert, but he is busy fixing his house most of the time nowdays ;) | 15:02 |
| stekern | Hesham: I think the orconf2013 workshop notes should be pretty up-to-date | 15:02 |
| stekern | http://opencores.org/or1k/ORCONF2013_Workshop_ORPSoC_On_DE0_Nano#OpenOCD | 15:03 |
| Hesham | I am checking it... | 15:04 |
| stekern | look, _franck_ is so busy so he'll go hide if you mention his name ;) | 15:05 |
| Hesham | stekern: is this the correct configuration for building OpenOCD to run with verilator? -> ./configure --enable-ftdi --enable-usb_blaster_libftdi --enable-maintainer-mode | 15:12 |
| Hesham | Cause I got an error "Error: The specified debug interface was not found (jtag_vpi)" | 15:12 |
| Hesham | When running the command you typed | 15:12 |
| stekern | Hesham: I think you need something else there too | 15:19 |
| stekern | wait, i'll try to find what ;) | 15:19 |
| stekern | ./configure --enable-ftdi --enable-usb_blaster_libftdi --enable-jtag_vpi --enable-maintainer-mode | 15:20 |
| _franck_ | stekern: :) | 15:23 |
| _franck_ | you're right, I spend my free time looking for building material | 15:24 |
| _franck_ | drawing things on sketchup | 15:24 |
| _franck_ | by the time I get back to openrisc things, you'll have a mor1kx v5.0 :( | 15:25 |
| Hesham | stekern: Did you find it? | 15:43 |
| stekern | ./configure --enable-ftdi --enable-usb_blaster_libftdi --enable-jtag_vpi --enable-maintainer-mode | 16:00 |
| stekern | Hesham: ^ | 16:00 |
| Hesham | Thanks stekern :) | 16:07 |
| poke53281 | blueCmd: yes, a factor of 6 is possible. | 16:56 |
| poke53281 | the flags are really really horrible implemented. | 16:56 |
| poke53281 | with 64 bit arithmetic and no optimizations. | 16:57 |
| poke53281 | If we could get rid of the delayed slot, the openrisc cpu would look similar to a byte code machine. | 17:00 |
| poke53281 | No side effects. No history related stuff which has to be implemented. | 17:01 |
| blueCmd | poke53281: there is or1knd | 17:13 |
| poke53281 | I am afraid to try it. Does it work with Linux. | 17:19 |
| poke53281 | ? | 17:19 |
| poke53281 | stekern: When I try to compile a natie gcc I get the error message: pastie.org/9434766 | 17:21 |
| poke53281 | pastie.org/9434770 | 17:23 |
| poke53281 | Oh wait. Maybe a typo in the configure parameters. | 17:24 |
| poke53281 | Yes, was a typo | 17:31 |
| stekern | good, it's enough with blueCmd's problems with those libgcc functions ;) | 17:37 |
| blueCmd | yeah, tell me about it | 17:44 |
| pecastro | rake | 17:46 |
| pecastro | ups ... wrong window... | 17:46 |
| poke53281 | nice, finally I can compile gcc without -fpic | 19:01 |
| stekern | why did you need that before? | 19:10 |
| poke53281 | An error message in gcc 4.8.0. I think one file was supposed to be compiled with -fpic but wasn't. | 19:26 |
| poke53281 | Also nice: looks like linux compiles finally without orkk-elf-gcc. | 19:27 |
| poke53281 | no linker errors anymore | 19:27 |
| stekern | poke53281: yes, that's the main reason we switched back to the asm versions of the libgcc functions | 21:05 |
| dalias | ? | 21:08 |
| dalias | stekern, if you're doing weird stuff with the libgcc functions (rather than just using the existing C), please make sure you make their visibility hidden | 21:09 |
| dalias | (.hidden in asm) | 21:09 |
| dalias | having default visibility on libgcc symbols causes major ABI breakage | 21:09 |
| blueCmd | oh | 21:13 |
| blueCmd | maybe that's related | 21:13 |
| dalias | what happens is that other libraries (including libc) will pull in _parts_ of libgcc.a, depending on what they use (e.g. long long math), then _expose_ that as part of their api/abi (their exported dynamic symbols) | 21:16 |
| dalias | so a program using such a library will get the symbol from the library, and therefore not pull in its own copy from libgcc.a | 21:17 |
| dalias | now, if the shared library later changes in such a way that it no longer needs that particular function from libgcc.a.... | 21:17 |
| dalias | the shared library no longer exports it, and the application breaks with missing symbol errors at runtime | 21:17 |
| blueCmd | that's what I'm seeing I think | 21:17 |
| stekern | yeah, that makes sense, and we should add .hidden, but blueCmd I can't see how that's related to what you are seeing | 21:19 |
| dalias | in general, any .a file that's potentially goin to get linked into a .so file needs to (1) be -fPIC, and (2) have all its symbols hidden | 21:19 |
| blueCmd | stekern: the last sentence that dalias writes is ugly close to the behaviour I'm seeing | 21:19 |
| stekern | blueCmd: all your libs are linked to the C version | 21:20 |
| dalias | and also (3) be free of state that needs to be process-global (since each .so and the main program will all get their own copies of the objects from the .a file) | 21:20 |
| blueCmd | stekern: not libc | 21:20 |
| dalias | stekern, if bluecmd first built an app against the old .so's which were built against libgcc.a with exported symbols... | 21:21 |
| dalias | ...then replaced the .so's with ones built against the all-C libgcc.a | 21:21 |
| stekern | dalias: no, the other way around | 21:21 |
| dalias | the app would then have unresolved symbols at load time | 21:21 |
| blueCmd | dalias: it's the other way around, first all-C then all-ASM | 21:21 |
| dalias | bluecmd, was the first all-C built with --disable-shared? :) | 21:21 |
| blueCmd | I don't think so | 21:22 |
| dalias | gcc has a bug where --disable-shared also turns off visibility attributes | 21:22 |
| blueCmd | we have some visibility bugs thought I think | 21:22 |
| dalias | basically, --disable-shared should be interpreted as "build a gcc that can't produce working shared libraries" :) | 21:22 |
| blueCmd | "gcc.dg/visibility-d.c scan-not-hidden" | 21:22 |
| blueCmd | hah | 21:23 |
| stekern | dalias: looking around other archs asm implementations, there are actually very few (if any) that declare those functions as .hidden (unless I'm missing something when grepping) | 21:32 |
| blueCmd | yeah, I didn't see it either - but it's worth trying if this doesn't solve it | 21:33 |
| dalias | hmm that sounds like a major bug then unless they have something in the build system to fix it | 21:33 |
| dalias | i wasn't aware libgcc had asm | 21:33 |
| stekern | yeah, that's what I'm thinking, that there has to be some black magic, it's gcc after all ;) | 21:34 |
| dalias | :) | 21:34 |
| stekern | the function we are speaking about are __udivsi3, __umodsi3, __divsi3 etc | 21:34 |
| stekern | *functions | 21:34 |
| dalias | *nod* | 21:35 |
| dalias | btw i have an evil asm implementation of those for x86 | 21:35 |
| dalias | using the fpu :) | 21:35 |
| dalias | ld80 fpu can do 64/64 integer division assuming the result is exact | 21:36 |
| stekern | cool | 21:36 |
| dalias | and you can make it exact by first doing fmod | 21:36 |
| dalias | the concept isn't sufficiently tested to consider putting it in musl tho | 21:37 |
| dalias | it's more just a toy at this point | 21:37 |
| stekern | I'm not sure our asm versions are much better than the C versions, but it get around the issue where you have got references in them | 21:38 |
| dalias | libgcc should always be built with -fPIC | 21:40 |
| stekern | exactly, so there *will* be got references in the C versions | 21:40 |
| stekern | but our Linux port uses libgcc.a for those functions | 21:40 |
| blueCmd | just add a GOT to the kernel | 21:41 |
| blueCmd | how hard can it be? | 21:41 |
| dalias | yeah, i think the easiest would but just adding a GOT | 21:42 |
| stekern | so we need them to be position independent, but without got references. and the asm versions fulfill that. | 21:42 |
| blueCmd | I was being sarcastic actually | 21:42 |
| stekern | blueCmd: you still haven't answered, how does it crash? ;) | 21:48 |
| blueCmd | stekern: http://5fe14dfadcaa8920.paste.se/ | 21:50 |
| stekern | blueCmd: are you using my hacked version of or1k.S now? | 22:13 |
| stekern | the one without the R_OR1K_INSN_REL_26? | 22:13 |
| blueCmd | stekern: hm, I haven't looked at the relocations for libgcc | 22:16 |
| stekern | I don't think your dynlinker can handle those | 22:17 |
| blueCmd | really? | 22:19 |
| blueCmd | are those special? | 22:19 |
| blueCmd | (i.e. are they not emitted in normal C?) | 22:19 |
| stekern | https://github.com/bluecmd/or1k-glibc/blob/master/sysdeps/or1k/dl-machine.h#L249 <- this will just write the address of the symbol at the place where the jump is, no? | 22:20 |
| blueCmd | stekern: right, you mean it needs PC + X ? | 22:20 |
| stekern | yes, and then account for if it's a l.jal, l.jalr, l.j or l.jr | 22:21 |
| stekern | what I really mean is that I don't think the dynlinker even should try to resolve those | 22:22 |
| blueCmd | so how did this work for you in musl? | 22:22 |
| stekern | I used my hacked up version that avoids the R_OR1K_INSN_REL_26 relocations | 22:23 |
| dalias | ? | 22:23 |
| blueCmd | stekern: do you have a patch? | 22:23 |
| dalias | i dont think a rel26 reloc should exist at dynamic-linking time | 22:23 |
| dalias | only in .o files | 22:23 |
| dalias | conceptually (whether or not it's in .text) it's a TEXTREL | 22:24 |
| stekern | blueCmd: http://pastie.org/9431862 | 22:24 |
| stekern | dalias: yeah, I think it's a bug in our (ld) linker that those get emitted | 22:25 |
| blueCmd | stekern: aha | 22:26 |
| blueCmd | stekern: this makes sense | 22:26 |
| blueCmd | thanks | 22:26 |
| blueCmd | too bad I didn't get you the first time when you spoke about this | 22:26 |
| blueCmd | oh well, at least my CPU has been getting its exercise | 22:27 |
| stekern | I'm going to look into that too, why they end up in the dyn libs | 22:27 |
| dalias | stekern, where do they get emitted? | 22:27 |
| stekern | dalias: https://github.com/openrisc/or1k-gcc/blob/or1k/libgcc/config/or1k/or1k.S#L213 | 22:29 |
| stekern | that jump will end up in libgcc_s.so both resolved *and* with an R_OR1K_INSN_REL_26 relocation | 22:31 |
| dalias | stekern, i think that's a bug, but it probably comes from not having it hidden | 22:32 |
| dalias | in PIC you should have that as a plt call | 22:32 |
| dalias | or have the function be hidden | 22:32 |
| dalias | otherwise it's a TEXTREL | 22:32 |
| blueCmd | dalias: '.hidden __udivsi' in the entry point should fix that? | 22:35 |
| dalias | for this purpose, i think it needs to be declared .hidden at the point of the call | 22:36 |
| dalias | for the .so issue, what matters is that the definition is .hidden | 22:37 |
| blueCmd | stekern: do you recon this is what R_X86_64_IRELATIV is for? | 22:57 |
| blueCmd | one of the things on my TODO list is to support IFUNC relocations | 22:57 |
| blueCmd | http://30b6328b9b7a051e.paste.se/ < test program that should output a relocation but doesn't for or1k | 22:58 |
| blueCmd | dalias: you might know as well | 22:58 |
| dalias | why should there be a reloc in the output? | 22:59 |
| dalias | it's fully linked | 22:59 |
| dalias | if this were an ET_DYN file it should still have a reloc | 22:59 |
| dalias | but not for a non-pie main program ELF file | 23:00 |
| blueCmd | dalias: gnu_indirect_function should do some magic | 23:00 |
| dalias | oh i missed that.. | 23:00 |
| blueCmd | this code is taken from glibc's configure in order to support --enable-multi-arch | 23:00 |
| blueCmd | it complains that we do not support 'GNU IFUNC' | 23:00 |
| dalias | yes, it looks like you don't support ifunc :) | 23:00 |
| dalias | musl doesn't either and i'm hesitant to add it | 23:01 |
| dalias | because running application/library code while performing relocations and while the dynamic linker holds locks is a really bad design :( | 23:01 |
| blueCmd | I'm not going to argue there | 23:04 |
| dalias | i think the condition for adding it would be having a clearly documented specification from the binutils/glibc/etc. ppl on what ifunc resolvers can do | 23:05 |
| dalias | and a statement that doing anything else is UB | 23:05 |
| dalias | right now there's none as far as i can tell | 23:05 |
| dalias | the contract is "you can do whatever seems to work" ... | 23:06 |
| poke53281 | It is impressive how small a distribution could be, if you care a little bit about size. pastie.org/9435461 | 23:06 |
| blueCmd | dalias: adding .hidden might actually break stuff. I don't get the versioned symbols that the libraries are trying to import anymore | 23:06 |
| poke53281 | I removed the manuals. The include files are included | 23:06 |
| dalias | poke53281, that's not small. http://www.musl-libc.org/jslinux/ :) | 23:06 |
| blueCmd | dalias: I'm going to build it and see if it works, but if it doesn't I'm going to tear that out | 23:07 |
| dalias | bluecmd, ah... i see why magic is needed for .hidden | 23:07 |
| dalias | libgcc_s.so obviously should not have hidden definitions | 23:08 |
| dalias | libgcc.a needs hidden definitions | 23:08 |
| blueCmd | right | 23:08 |
| blueCmd | dalias: you don't have scummvm in that VM though ;) | 23:10 |
| dalias | :) | 23:12 |
| dalias | still pretty impressive i thought | 23:12 |
| poke53281 | dalias: and no gcc and no ssh. What is this? | 23:12 |
| dalias | pcc :) | 23:13 |
| poke53281 | looks like the equivalent of my busybox. And in my case, it is statically compiled | 23:13 |
| dalias | ssh isn't really possible because the browser doesn't give js that kind of network permission | 23:13 |
| poke53281 | Hehe, I know. | 23:14 |
| poke53281 | And now ask the question. Why does it work with jor1k? ;) | 23:14 |
| blueCmd | WEBSOCKETS! | 23:14 |
| blueCmd | maybe.. | 23:14 |
| poke53281 | Yes, of course | 23:15 |
| blueCmd | Web 2.0! | 23:15 |
| dalias | websockets let you connect to arbitrary host/port?? | 23:15 |
| poke53281 | hehe, no | 23:15 |
| blueCmd | dalias: I think poke53281 has a 'private' network that you can connect to via the websocket | 23:15 |
| poke53281 | I use wesocket only asa wrapper for ethernet frames. | 23:16 |
| poke53281 | correct | 23:16 |
| * blueCmd is just trying to show off that he actually read about poke53281's work | 23:16 | |
| dalias | :) | 23:16 |
| dalias | i see | 23:16 |
| dalias | nice | 23:16 |
| dalias | btw how small can you get a usable jor1k setup? | 23:16 |
| dalias | i'm guessing if you want a compiler that's a big limiting factor | 23:17 |
| dalias | since there's no pcc for or1k | 23:17 |
| poke53281 | blueCmd: At least one read the stuff I wrote. | 23:18 |
| poke53281 | compressed or uncompressed? | 23:19 |
| poke53281 | how small? binutils.tar.bz2 and the kernel image | 23:19 |
| poke53281 | which is 2 MB. | 23:19 |
| poke53281 | So, compressed something around 2.7MB. | 23:19 |
| poke53281 | sorry | 23:20 |
| poke53281 | busybox.tar.bz2 I mean | 23:20 |
| poke53281 | not binutils.tar.bz2 | 23:20 |
| poke53281 | gcc+binutils cost around 7MB. | 23:20 |
| poke53281 | If you remove stuff like lto and cpp. | 23:20 |
| blueCmd | poke53281: did I tell you about a party I went to and the guy showed me jor1k? | 23:21 |
| blueCmd | (and I told him I ported Debian to the thing and he was 'Wow! I read aobut that!') | 23:21 |
| poke53281 | No. :) | 23:22 |
| blueCmd | poke53281: so your work is quite high-profile | 23:22 |
| poke53281 | Let's wait until it is really useful. We are working hard on it. | 23:22 |
| blueCmd | yep | 23:22 |
| poke53281 | s-mcke.github.io/jor1k/compile.html | 23:23 |
| poke53281 | s-macke.github.io/jor1k/compile.html | 23:23 |
| poke53281 | you will soon be able to save your state | 23:24 |
| poke53281 | and to access your local filesystem. | 23:24 |
| poke53281 | At least, this is the plan. | 23:24 |
| blueCmd | stekern: _franck_: juliusb: I know you are honorable people and always do as you're told, so there is surely no point in reminding - but I'll do it anyway. Have you emailed the GNU forms yet? | 23:24 |
| blueCmd | poke53281: your thing boots quicker than dalias's | 23:25 |
| poke53281 | I hope so. | 23:25 |
| poke53281 | with or without decompression of the filesystem? | 23:26 |
| blueCmd | poke53281: whatever is default | 23:26 |
| blueCmd | poke53281: looking at http://angrave.github.io/sys/compile.html, this could be pretty cool for kernel module programming and stuff | 23:27 |
| blueCmd | it might even be possible to create a VPI/DPI interface to a verilator instance.. hmm | 23:28 |
| poke53281 | well, it is cool for teaching programming with life examples. | 23:28 |
| blueCmd | having a certain memory area and a couple of IRQs connected to verilator | 23:29 |
| blueCmd | that could be quite cool | 23:29 |
| poke53281 | and yes, even kernel programming. | 23:29 |
| poke53281 | who wants to write a tutorial for programming based on such an online emulator? | 23:29 |
| blueCmd | stekern: simple test case does *not* crash with your patch | 23:30 |
| blueCmd | stekern: thanks x100. this was getting really off-putting | 23:30 |
| blueCmd | poke53281: imagine gdb integration as well | 23:31 |
| poke53281 | does gdb compile? | 23:31 |
| poke53281 | Last time I had problems | 23:31 |
| poke53281 | I plan also to give the user a lot more statistics in future. | 23:32 |
| poke53281 | like number of page faults, number of syscalls and so on. | 23:32 |
| poke53281 | It would be also funny to "acccidentally" link the ata block device with the framebuffer. | 23:33 |
| poke53281 | That you can "see", how such a filesystem works. | 23:34 |
| blueCmd | poke53281: nope, I don't think it does | 23:37 |
| blueCmd | poke53281: cool! | 23:37 |
| --- Log closed Fri Aug 01 00:00:45 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!