| --- Log opened Tue Jul 29 00:00:40 2014 | ||
| stekern | blueCmd: ok, your fix looks good to me, the jrr9 thing too ;) | 02:42 |
|---|---|---|
| stekern | I'm curious though, under what circumstances did it break without the @function? | 02:42 |
| * stekern is reading further back in the backlog | 02:47 | |
| stekern | haha, "juggling to many things", oh so familiar | 02:48 |
| stekern | yay, I've got a working network connection on sockit | 04:50 |
| stekern | blueCmd: did you find out anything about the lockups? | 05:21 |
| stekern | I'm seeing something similar on the sockit when running with 2 cores | 05:22 |
| stekern | both cores are just in cpu_idle, but the program should still be running | 05:23 |
| maxpaln | starting work on the shift to mor1kx :-) | 08:53 |
| maxpaln | just downloaded the repository - the organisation looks sensible, I am going to run through some simulations as well as HW testing | 08:54 |
| maxpaln | I notice there is a monitor in the bench directory - I am not sure if the OR1200 had one of these, I will need to check. But given the mor1kx is underneath the orpsoc_top - is there an example of connecting the monitor from within the testbench? | 08:56 |
| maxpaln | in fact, looking at the monitor I am not entirely sure what should be connected - it has no ports! | 08:57 |
| maxpaln | I'll continue without it for now... | 09:01 |
| blueCmd | stekern: it might not have solved the problem anyway. the problem I have is that I have a lot of binaries linked to the libgcc that used the C functions | 09:02 |
| blueCmd | and apparently the asm construct doesn't match that in some way | 09:02 |
| blueCmd | so stuff crashes | 09:02 |
| blueCmd | 10501: 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:02 |
| blueCmd | is the last entry before boom | 09:03 |
| blueCmd | the line looks better: | 09:03 |
| blueCmd | 105: 00002624 0 FUNC GLOBAL DEFAULT 12 __umodsi3@@GCC_3.0 | 09:03 |
| blueCmd | but the size is still bad | 09:03 |
| stekern | maxpaln: the monitor 'peeks' into mor1kx, so basically you just have to include it in your simulation | 09:29 |
| stekern | there was a similar monitor available for or1200 | 09:29 |
| stekern | blueCmd: oh... | 09:30 |
| blueCmd | stekern: tbf, I'm not 100% sure this is the cause, but it seems logical since 1) that's the last line of the ever-spewing LD_DEBUG=all before the crash and 2) this has changed between my gcc-4.8 package and gcc-4.9 package (albeit a lot of stuff has) | 09:33 |
| blueCmd | stekern: I'm going to add .size to the end of the function, maybe that works | 09:36 |
| stekern | I was just about to suggest that | 09:37 |
| maxpaln | stekern: thanks - out of interest, do you know the burst length on the read accesses to the wishbone bus from the mor1kx? My memory controller has a limitation that I am yet to fix - it can't handle burst lengths greater than 60 - doubt this is an issue but I thought I'd check. | 09:40 |
| stekern | not an issue ;) | 09:44 |
| stekern | it's 4 or 8 (words) | 09:44 |
| stekern | actually, I have a out-of-tree patch from wallento that ties the burst length to the cache size, that I haven't applied | 09:46 |
| stekern | it's set by this parameter: https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx_bus_if_wb32.v#L56 | 09:46 |
| maxpaln | cool - and good news for me :-) | 09:58 |
| maxpaln | I'm not making use of the debug interface but I presume from looking at the instantiation example you sent to me that the mor1kx uses a different debug unit | 09:59 |
| maxpaln | is that the case? | 09:59 |
| stekern | 'yes' | 10:15 |
| stekern | ;) | 10:15 |
| stekern | the debug-unit is deeply embedded into the cpu, so that part is different | 10:17 |
| stekern | but then the part that connects to jtag etc, that's 'generic', so that's the same | 10:17 |
| Hesham | Hi all, I want to ask about or1ksim memory management, I assume that TLB misses, PTE reload should be handled in software right? | 10:18 |
| stekern | yes | 10:19 |
| Hesham | Thanks stekern, can 16 MB, 8 KB pages be mixed in a single system? | 10:19 |
| stekern | not sure if or1ksim support 16MB | 10:21 |
| Hesham | There is nothing at or1ksim manual to tell about that, how can I make sure? | 10:23 |
| stekern | if it does, then I don't see why you wouldn't be able to mix them | 10:23 |
| Hesham | The only attribute I see, is "pagesize = value" withing dmmu/immu sections. Value must be a power of 2, and the default is 8KB pages. | 10:25 |
| Hesham | Will setting this value to 16 MB be enough? | 10:26 |
| Hesham | within** | 10:26 |
| stekern | not sure, but if it's in the config it will not work to mix | 10:26 |
| blueCmd | stekern: that didn't work, so I'm more into the idea that the function itself crashes | 10:28 |
| blueCmd | I'm not even 100% sure qemu has floating point instructions implemented thinking of it | 10:28 |
| Hesham | stekern: Does this mean that I can neglect this attribute and do the mixing (if or1ksim provides 16 MB pages)? | 10:28 |
| blueCmd | (but I cannot see that the functions are using any, so that should be fine I guess) | 10:29 |
| stekern | Hesham: check if the PL1 (bit 1) is implemented in the dtlb match regs | 10:29 |
| stekern | i.e. does or1ksim care about that anywhere | 10:29 |
| stekern | that's how 16MB pages should be implemented if supported (mor1kx does that) | 10:29 |
| Hesham | OK, thanks, I will check about it. | 10:30 |
| stekern | blueCmd: how is floating point related? | 10:30 |
| blueCmd | stekern: I thought these functions were using that, but no - they are not, so it's not related | 10:40 |
| stekern | https://github.com/bluecmd/or1k-gcc/blob/c8d8f384777c7181adb6a282531a128ef7056b6f/libgcc/config/or1k/or1k.S#L215 | 10:42 |
| stekern | that looks suspicious | 10:42 |
| stekern | but maybe it's ok | 10:43 |
| mafm | I created this patch for jemalloc: http://paste.debian.net/112358/ , original file: https://github.com/jemalloc/jemalloc/blob/dev/include/jemalloc/internal/jemalloc_internal.h.in | 10:52 |
| mafm | I am unsure if the value should be 3 or 4 | 10:52 |
| mafm | blueCmd told me in the past that he cannot see a reason why 3 is not OK | 10:53 |
| mafm | any opinion before I send the patch upstream? | 10:53 |
| mafm | (there's a brief explanation at the top of the #ifdef about what it means) | 10:54 |
| Hesham | stekern: I took a look there https://github.com/openrisc/or1ksim/blob/or1k-master/mmu/dmmu.c | 10:55 |
| Hesham | and did not find any thing to tell that page table levels are implemented, or PL1. Only TLB oriented, and from there translation and protection assertion happens. The attributes used for TLB there are only LRU, protection, ppn, and vpn. | 10:55 |
| blueCmd | mafm: can you try to build it and run whatever testsuite it has/ | 10:55 |
| blueCmd | stekern: did you test these functions? | 10:57 |
| mafm | blueCmd: fails in the wannabuild for unrelated reasons, with -DLG_QUANTUM=3 defined in debian/rules at compile time (instead of hardcoded in the file): http://wannabuild.cmd.nu/package.php?p=jemalloc&suite=sid | 10:58 |
| blueCmd | mafm: right, pthreads. I can run the testsuite if you give me the patched sources | 10:59 |
| blueCmd | you need to run it in a full simulator (qemu-system or or1ksim) and it's a bit of a pain to set up currently | 11:00 |
| mafm | also I am not sure if this is an option more related with tuning, so I think that it might work either with 3 or 4, but perhaps one is more performant | 11:01 |
| mafm | blueCmd: the current .deb package is already ready for it, can you compile that in a full simulator? | 11:02 |
| mafm | you can easily switch between 3 and 4 by modifying the LG_QUANTUM in debian/rules | 11:03 |
| stekern | hmm, this seems broken... http://lxr.free-electrons.com/source/arch/openrisc/mm/init.c#L200 | 11:09 |
| blueCmd | mafm: right. I might need stekern to validate his patch before I'm able to run a full debian compile though | 11:19 |
| blueCmd | stekern: if you don't have time, let me know and I'll revert it for now in my tree | 11:19 |
| stekern | I can take a look in the evening | 11:23 |
| blueCmd | stekern: thanks! | 11:24 |
| stekern | but surely __umodsi3 is used somewhere? | 11:24 |
| blueCmd | I don't think it is | 11:24 |
| stekern | and, that code was in use for a *looong* time before I reverted the patch that removed it | 11:25 |
| stekern | 'reverted' | 11:25 |
| blueCmd | stekern: no, AFAIK the C functions take precedence | 11:25 |
| stekern | ? | 11:25 |
| blueCmd | your patch changed between using C-functions and using ASM functions | 11:25 |
| blueCmd | no? | 11:25 |
| stekern | yes | 11:25 |
| blueCmd | so in this case __umodsi3 would be from libgcc/udivmod.c | 11:26 |
| blueCmd | and not the asm one | 11:26 |
| stekern | reverting the change pgavin did to use the C-functions, and he did that because the asm was delay-slot specific | 11:26 |
| blueCmd | ah I see | 11:27 |
| stekern | all I did was to make it delay-slot agnostic | 11:27 |
| stekern | so, these functions have been in use all the time in 4.5.x | 11:27 |
| blueCmd | it's only very few applications that crash in debin from what I've seen, so it might be the case that it's rare that they are used | 11:27 |
| blueCmd | apt-get uses it, and rdfind | 11:27 |
| stekern | and we *need* to use the asm, otherwise we can't compile the kernel | 11:27 |
| stekern | i.e., we can't do references through got in that code | 11:28 |
| stekern | perhaps it'd be possible to compile the C code with -Bsymbolic-functions | 11:29 |
| stekern | blueCmd: how does it crash? | 11:32 |
| stekern | at least a super-rudimentary test doesn't make it crash | 11:41 |
| stekern | http://pastie.org/9429200 <- super-rudimentary test | 11:48 |
| stekern | blueCmd: can you give the 'faulty' libgcc_s.so.1? | 11:58 |
| stekern | +me | 11:59 |
| blueCmd | stekern: http://openrisc.debian.net/tmp/ | 12:03 |
| blueCmd | libgcc_{broken, broken_still, working}.so | 12:03 |
| stekern | what's the diff between still and stirred? | 12:03 |
| stekern | does it crash in or1ksim? | 12:05 |
| stekern | I can't see how it can crash though, unless sp is screwed up or resolving the function doesn't work at all | 12:07 |
| stekern | but if it's the latter, why doesn't that happen to the other functions? | 12:07 |
| blueCmd | stekern: it crashes in qemu-user after LD_DEBUG=all prints the row above, that's all I know | 12:44 |
| blueCmd | if you're confident that the function indeed has the same interface as the C-variant and returns the same values, then I'll debug it deeper, but that is a pain | 12:45 |
| stekern | confident and confident, scratching a bit on the surface I can't see anything wrong with it ;) | 12:50 |
| stekern | oh... actually... | 12:52 |
| stekern | why is this here: http://pastie.org/9429310 | 12:53 |
| stekern | that's bad... | 12:54 |
| fnunes | Hi there. Could you check this site http://ixo-jtag.sourceforge.net/ ? Do you think I could use that firmware to connect OpenOCD to a Digilent Atlys board to debug an OpenRISC processor ? Using the Digilent programming port. | 12:58 |
| maxpaln | Quick question: the monitor includes this line: | 14:22 |
| maxpaln | `define CPU_INST `CPU_WRAPPER.`MOR1KX_CPU_PIPELINE.mor1kx_cpu | 14:22 |
| maxpaln | where is MOR1KX_CPU_PIPELINE defined? Should it be part of the module instantiation - in which case, is CAPPUCCINO a valid setting? | 14:23 |
| maxpaln | in fact, looking at it - I am not sure what it is supposed to be defined as | 14:31 |
| stekern | maxpaln: we haven't made much use of the monitor in the current build systems AFAIK, but you can take a look at how it was used here: https://github.com/juliusbaxter/mor1kx-dev-env | 14:33 |
| maxpaln | ah, ok - | 14:33 |
| stekern | for a large part of verification, I've been using verilator, which of course can't use the monitor | 14:35 |
| maxpaln | ah, I see - well I have concluded that something is wrong with those 'defines - | 14:36 |
| maxpaln | the name CPU_INST suggests it should point to the mor1kx_cpu instance - but CPU_WRAPPER already points there - | 14:36 |
| maxpaln | so `define CPU_INST `CPU_WRAPPER.`MOR1KX_CPU_PIPELINE.mor1kx_cpu is never going to work | 14:36 |
| maxpaln | I'll just leave out the monitor for now | 14:37 |
| stekern | yeah, you don't *need* it to simulate the cpu, it just have some nifty features like the ability to produce instruction traces etc | 14:38 |
| stekern | fnunes: not sure, possibly. I think it should be possible to use the adept tools somehow too, but haven't investigated. | 14:39 |
| maxpaln | well, my main aim is to run the original OR1200 regression tests I was using before - the OR1200 passes them all. I am hoping the mor1kx will do too - although I saw there was no MAC so I'll skip that test. | 14:40 |
| maxpaln | as long as I get passes I will move onto HW testing. | 14:40 |
| maxpaln | Just noticed the mor1kx supports a 32-bit irq input - which triggered me to compare the interrupt assignments between the mor1kx example you sent through and the orpsocv2 original I was using. | 14:49 |
| maxpaln | The orpsocv2 includes an intgen module that is missing from the mor1kx version - I had assumed this module was a crucial part of the interrupt handling. Is it not needed for mor1kx designs? | 14:49 |
| stekern | heh, no, it's not needed at all. | 14:53 |
| stekern | it's just for simulation purposes | 14:53 |
| stekern | i.e., you can manually generate interrupts with it | 14:53 |
| maxpaln | ah, newbie error :-) | 14:58 |
| maxpaln | out of interest, I am assuming the mor1kx does actually pass the original or1200 tests "or1200-simple" and so on. | 15:16 |
| maxpaln | is that a fair assumption? | 15:16 |
| stekern | yes, it should | 15:16 |
| maxpaln | good - | 15:16 |
| stekern | there are these: https://github.com/openrisc/or1k-tests | 15:17 |
| stekern | blueCmd: I get a segfault in this function when I load libgcc_s.so http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n654 | 15:17 |
| maxpaln | hmmm, curious - the first test I ran didn't complete - it just hung after doing a lot of sensible stuff, which I thought was odd. I picked or1200-simple. | 15:42 |
| maxpaln | or1k-tests/native/mor1kx_cappuccino.tests lists or1k/or1k-simple.c as a test | 15:42 |
| maxpaln | but or1k/or1k-simple.c doesn't exist | 15:42 |
| maxpaln | I wonder if I picked badly | 15:42 |
| maxpaln | Also, there are considerable differences between the versions of the tests I am running and the ones you pointed me at | 15:42 |
| maxpaln | I think I need to put a bit of leg work in to update my test suite to the set you just point me at. | 15:43 |
| stekern | what did or1200-simple.c do? | 15:44 |
| maxpaln | virtually nothing: | 15:45 |
| maxpaln | * | 15:45 |
| maxpaln | * Test run first, to check the main loop is reached and the exit mechanism | 15:45 |
| maxpaln | * functions OK | 15:45 |
| maxpaln | * | 15:45 |
| maxpaln | */ | 15:45 |
| maxpaln | #include "cpu-utils.h" | 15:45 |
| maxpaln | int main() | 15:45 |
| maxpaln | { | 15:45 |
| maxpaln | report(0x8000000d); | 15:45 |
| maxpaln | exit(0); | 15:45 |
| maxpaln | } | 15:45 |
| stekern | https://github.com/openrisc/or1k-tests/blob/master/native/or1k/or1k-csimple.c | 15:45 |
| maxpaln | But it still didn't complete | 15:45 |
| maxpaln | yep, that's what I have - but oddly, it just hung! | 15:46 |
| stekern | can you through me the elf? | 15:46 |
| stekern | throw too | 15:46 |
| maxpaln | :-) - I'll do both | 15:46 |
| maxpaln | one minute - the make script deletes them after building them | 15:47 |
| maxpaln | I'll regenerate | 15:47 |
| maxpaln | here you go | 15:49 |
| maxpaln | https://www.dropbox.com/s/pbgmrq6l5ea7wil/or1200-simple.elf | 15:49 |
| maxpaln | well, the simulation is very odd - I can't see any activity on the bus after a certain point in the test. | 15:54 |
| stekern | maxpaln: I just ran that elf successfully on https://github.com/openrisc/orpsoc-cores/tree/master/systems/mor1kx-generic | 15:55 |
| stekern | I assume this is simulating your SoC? | 15:56 |
| maxpaln | yep, so something must be going awry in my SOC | 15:58 |
| maxpaln | but it is very odd - it simulates for ages (around 800 us) doing what I would expect it to do | 15:58 |
| maxpaln | then everything just stops happening. | 15:58 |
| stekern | can you dump a VCD? | 15:59 |
| maxpaln | I think so - what do you want to see. I capture 100% of signals in the design - that's a lot of signals! :-) | 15:59 |
| maxpaln | I can dump everything under the mor1kx | 15:59 |
| maxpaln | ? | 15:59 |
| maxpaln | hmmm, hang on - maybe not | 16:00 |
| stekern | well, it should be a fairly short dump, does it become huge if you include all? | 16:01 |
| maxpaln | I am running Aldec's Riviera - I can't seem to find the export option, just to save as an Aldec format. | 16:01 |
| maxpaln | The mor1kx is pretty compact - it's all the DDR3 memory stuff that makes it very sizeable | 16:01 |
| maxpaln | let me see if I can dump it to VCD - the mor1kx that is. | 16:01 |
| stekern | yeah, mor1kx would be enough (with the bus interface) | 16:02 |
| stekern | https://www.aldec.com/en/support/resources/documentation/faq/1036 | 16:03 |
| stekern | or? | 16:03 |
| maxpaln | I was just looking at that - helpfully file -> export -> waveforms doesn't exist!!! | 16:05 |
| maxpaln | in fact file -> export doesn't exist | 16:05 |
| maxpaln | ok, I can convert from ASDB to VCD - | 16:10 |
| maxpaln | Denied!! | 16:10 |
| maxpaln | SCRIPTER: Error: child killed: segmentation violation | 16:10 |
| maxpaln | Grrr! | 16:10 |
| mafm | question: or1k is *always* big endian? or can be little endian? | 16:10 |
| maxpaln | ok, time has run out today - this will have to wait until tomorrow. | 16:11 |
| maxpaln | a clear head will no doubt see the problem. | 16:11 |
| stekern | mafm: in theory it can | 16:13 |
| mafm | stekern: then, what's the best way to say something like this? http://paste.debian.net/112444/ | 16:16 |
| mafm | is __BYTE_ORDER always defined in libc, and thus can be relied upon? | 16:16 |
| mafm | one thing to clarify: with "or1k" above I mean or1k-the-name-in-architecture-triplets, not the processor in general | 16:17 |
| stekern | ah, then I guess it'll always be big endian. | 16:21 |
| mafm | stekern: so in that case, in the code above, it's not necessary to consider that __or1k__ can ever be little endian, right? if there's ever an or1k-little-endian, it will be named __or1kle__/__or1kel__ or something like that? | 16:26 |
| mafm | (I ask because I'm upstreaming some changes to important libs, it's better if we get things right from the start and don't have to re-patch later) | 16:27 |
| stekern | yes, at least to me it would make most sense to have an or1kle/or1kel | 16:29 |
| mafm | ok, thanks stekern | 16:55 |
| olofk | What? Someone actually did make a clone of the ordb2a board | 18:00 |
| stekern | yes, and it's for sale too | 18:04 |
| olofk | I always assumed it was one of the regular I-don't-really-have-a-fucking-clue-what-I'm-doing people | 18:10 |
| olofk | I learned about event in verilog yesterday, btw. That's pretty handy | 18:10 |
| olofk | Interesting read about the CLANG improvements | 18:33 |
| blueCmd | stekern: hm | 19:17 |
| blueCmd | stekern: so it might be the loading / linking | 19:17 |
| blueCmd | after all | 19:17 |
| blueCmd | so apparently http://sel4.systems/ is Open-Source now | 19:18 |
| --- Log closed Wed Jul 30 00:00:42 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!