IRC logs for #openrisc Tuesday, 2014-07-29

--- Log opened Tue Jul 29 00:00:40 2014
stekernblueCmd: ok, your fix looks good to me, the jrr9 thing too ;)02:42
stekernI'm curious though, under what circumstances did it break without the @function?02:42
* stekern is reading further back in the backlog02:47
stekernhaha, "juggling to many things", oh so familiar02:48
stekernyay, I've got a working network connection on sockit04:50
stekernblueCmd: did you find out anything about the lockups?05:21
stekernI'm seeing something similar on the sockit when running with 2 cores05:22
stekernboth cores are just in cpu_idle, but the program should still be running05:23
maxpalnstarting work on the shift to mor1kx :-)08:53
maxpalnjust downloaded the repository - the organisation looks sensible, I am going to run through some simulations as well as HW testing08:54
maxpalnI 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
maxpalnin fact, looking at the monitor I am not entirely sure what should be connected - it has no ports!08:57
maxpalnI'll continue without it for now...09:01
blueCmdstekern: 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 functions09:02
blueCmdand apparently the asm construct doesn't match that in some way09:02
blueCmdso stuff crashes09:02
blueCmd     10501:     binding file /usr/lib/or1k-linux-gnu/ [0] to /lib/or1k-linux-gnu/ [0]: normal symbol `__umodsi3' [GCC_3.009:02
blueCmdis the last entry before boom09:03
blueCmdthe line looks better:09:03
blueCmd   105: 00002624     0 FUNC    GLOBAL DEFAULT   12 __umodsi3@@GCC_3.009:03
blueCmdbut the size is still bad09:03
stekernmaxpaln: the monitor 'peeks' into mor1kx, so basically you just have to include it in your simulation09:29
stekernthere was a similar monitor available for or120009:29
stekernblueCmd: oh...09:30
blueCmdstekern: 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
blueCmdstekern: I'm going to add .size to the end of the function, maybe that works09:36
stekernI was just about to suggest that09:37
maxpalnstekern: 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
stekernnot an issue ;)09:44
stekernit's 4 or 8 (words)09:44
stekernactually, I have a out-of-tree patch from wallento that ties the burst length to the cache size, that I haven't applied09:46
stekernit's set by this parameter:
maxpalncool - and good news for me :-)09:58
maxpalnI'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 unit09:59
maxpalnis that the case?09:59
stekernthe debug-unit is deeply embedded into the cpu, so that part is different10:17
stekernbut then the part that connects to jtag etc, that's 'generic', so that's the same10:17
HeshamHi all, I want to ask about or1ksim memory management, I assume that TLB misses, PTE reload should be handled in software right?10:18
HeshamThanks stekern, can 16 MB, 8 KB pages be mixed in a single system?10:19
stekernnot sure if or1ksim support 16MB10:21
HeshamThere is nothing at or1ksim manual to tell about that, how can I make sure?10:23
stekernif it does, then I don't see why you wouldn't be able to mix them10:23
HeshamThe 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
HeshamWill setting this value to 16 MB be enough?10:26
stekernnot sure, but if it's in the config it will not work to mix10:26
blueCmdstekern: that didn't work, so I'm more into the idea that the function itself crashes10:28
blueCmdI'm not even 100% sure qemu has floating point instructions implemented thinking of it10:28
Heshamstekern: 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
stekernHesham: check if the PL1 (bit 1) is implemented in the dtlb match regs10:29
stekerni.e. does or1ksim care about that anywhere10:29
stekernthat's how 16MB pages should be implemented if supported (mor1kx does that)10:29
HeshamOK, thanks, I will check about it.10:30
stekernblueCmd: how is floating point related?10:30
blueCmdstekern: I thought these functions were using that, but no - they are not, so it's not related10:40
stekernthat looks suspicious10:42
stekernbut maybe it's ok10:43
mafmI created this patch for jemalloc:  , original file:
mafmI am unsure if the value should be 3 or 410:52
mafmblueCmd told me in the past that he cannot see a reason why 3 is not OK10:53
mafmany 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
Heshamstekern: I took a look there
Heshamand 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
blueCmdmafm: can you try to build it and run whatever testsuite it has/10:55
blueCmdstekern: did you test these functions?10:57
mafmblueCmd: fails in the wannabuild for unrelated reasons, with -DLG_QUANTUM=3 defined in debian/rules at compile time (instead of hardcoded in the file):
blueCmdmafm: right, pthreads. I can run the testsuite if you give me the patched sources10:59
blueCmdyou need to run it in a full simulator (qemu-system or or1ksim) and it's a bit of a pain to set up currently11:00
mafmalso 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 performant11:01
mafmblueCmd: the current .deb package is already ready for it, can you compile that in a full simulator?11:02
mafmyou can easily switch between 3 and 4 by modifying the LG_QUANTUM in debian/rules11:03
stekernhmm, this seems broken...
blueCmdmafm: right. I might need stekern to validate his patch before I'm able to run a full debian compile though11:19
blueCmdstekern: if you don't have time, let me know and I'll revert it for now in my tree11:19
stekernI can take a look in the evening11:23
blueCmdstekern: thanks!11:24
stekernbut surely __umodsi3 is used somewhere?11:24
blueCmdI don't think it is11:24
stekernand, that code was in use for a *looong* time before I reverted the patch that removed it11:25
blueCmdstekern: no, AFAIK the C functions take precedence11:25
blueCmdyour patch changed between using C-functions and using ASM functions11:25
blueCmdso in this case __umodsi3 would be from libgcc/udivmod.c11:26
blueCmdand not the asm one11:26
stekernreverting the change pgavin did to use the C-functions, and he did that because the asm was delay-slot specific11:26
blueCmdah I see11:27
stekernall I did was to make it delay-slot agnostic11:27
stekernso, these functions have been in use all the time in 4.5.x11:27
blueCmdit'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 used11:27
blueCmdapt-get uses it, and rdfind11:27
stekernand we *need* to use the asm, otherwise we can't compile the kernel11:27
stekerni.e., we can't do references through got in that code11:28
stekernperhaps it'd be possible to compile the C code with -Bsymbolic-functions11:29
stekernblueCmd: how does it crash?11:32
stekernat least a super-rudimentary test doesn't make it crash11:41
stekern <- super-rudimentary test11:48
stekernblueCmd: can you give the 'faulty'
blueCmdlibgcc_{broken, broken_still, working}.so12:03
stekernwhat's the diff between still and stirred?12:03
stekerndoes it crash in or1ksim?12:05
stekernI can't see how it can crash though, unless sp is screwed up or resolving the function doesn't work at all12:07
stekernbut if it's the latter, why doesn't that happen to the other functions?12:07
blueCmdstekern: it crashes in qemu-user after LD_DEBUG=all prints the row above, that's all I know12:44
blueCmdif 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 pain12:45
stekernconfident and confident, scratching a bit on the surface I can't see anything wrong with it ;)12:50
stekernoh... actually...12:52
stekernwhy is this here:
stekernthat's bad...12:54
fnunesHi there. Could you check this site ? 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
maxpalnQuick question: the monitor includes this line:14:22
maxpaln`define CPU_INST `CPU_WRAPPER.`MOR1KX_CPU_PIPELINE.mor1kx_cpu14:22
maxpalnwhere is MOR1KX_CPU_PIPELINE defined? Should it be part of the module instantiation - in which case, is CAPPUCCINO a valid setting?14:23
maxpalnin fact, looking at it - I am not sure what it is supposed to be defined as14:31
stekernmaxpaln: 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:
maxpalnah, ok -14:33
stekernfor a large part of verification, I've been using verilator, which of course can't use the monitor14:35
maxpalnah, I see - well I have concluded that something is wrong with those 'defines -14:36
maxpalnthe name CPU_INST suggests it should point to the mor1kx_cpu instance - but CPU_WRAPPER already points there -14:36
maxpalnso `define CPU_INST `CPU_WRAPPER.`MOR1KX_CPU_PIPELINE.mor1kx_cpu is never going to work14:36
maxpalnI'll just leave out the monitor for now14:37
stekernyeah, you don't *need* it to simulate the cpu, it just have some nifty features like the ability to produce instruction traces etc14:38
stekernfnunes: not sure, possibly. I think it should be possible to use the adept tools somehow too, but haven't investigated.14:39
maxpalnwell, 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
maxpalnas long as I get passes I will move onto HW testing.14:40
maxpalnJust 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
maxpalnThe 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
stekernheh, no, it's not needed at all.14:53
stekernit's just for simulation purposes14:53
stekerni.e., you can manually generate interrupts with it14:53
maxpalnah, newbie error :-)14:58
maxpalnout of interest, I am assuming the mor1kx does actually pass the original or1200 tests "or1200-simple" and so on.15:16
maxpalnis that a fair assumption?15:16
stekernyes, it should15:16
maxpalngood -15:16
stekernthere are these:
stekernblueCmd: I get a segfault in this function when I load
maxpalnhmmm, 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
maxpalnor1k-tests/native/mor1kx_cappuccino.tests lists or1k/or1k-simple.c as a test15:42
maxpalnbut or1k/or1k-simple.c doesn't exist15:42
maxpalnI wonder if I picked badly15:42
maxpalnAlso, there are considerable differences between the versions of the tests I am running and the ones you pointed me at15:42
maxpalnI 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
stekernwhat did or1200-simple.c do?15:44
maxpalnvirtually nothing:15:45
maxpaln *15:45
maxpaln * Test run first, to check the main loop is reached and the exit mechanism15:45
maxpaln * functions OK15:45
maxpaln *15:45
maxpaln */15:45
maxpaln#include "cpu-utils.h"15:45
maxpalnint main()15:45
maxpaln  report(0x8000000d);15:45
maxpaln  exit(0);15:45
maxpalnBut it still didn't complete15:45
maxpalnyep, that's what I have - but oddly, it just hung!15:46
stekerncan you through me the elf?15:46
stekernthrow too15:46
maxpaln:-) - I'll do both15:46
maxpalnone minute - the make script deletes them after building them15:47
maxpalnI'll regenerate15:47
maxpalnhere you go15:49
maxpalnwell, the simulation is very odd - I can't see any activity on the bus after a certain point in the test.15:54
stekernmaxpaln: I just ran that elf successfully on
stekernI assume this is simulating your SoC?15:56
maxpalnyep, so something must be going awry in my SOC15:58
maxpalnbut it is very odd - it simulates for ages (around 800 us) doing what I would expect it to do15:58
maxpalnthen everything just stops happening.15:58
stekerncan you dump a VCD?15:59
maxpalnI think so - what do you want to see. I capture 100% of signals in the design - that's a lot of signals! :-)15:59
maxpalnI can dump everything under the mor1kx15:59
maxpalnhmmm, hang on - maybe not16:00
stekernwell, it should be a fairly short dump, does it become huge if you include all?16:01
maxpalnI am running Aldec's Riviera - I can't seem to find the export option, just to save as an Aldec format.16:01
maxpalnThe mor1kx is pretty compact - it's all the DDR3 memory stuff that makes it very sizeable16:01
maxpalnlet me see if I can dump it to VCD - the mor1kx that is.16:01
stekernyeah, mor1kx would be enough (with the bus interface)16:02
maxpalnI was just looking at that - helpfully file -> export -> waveforms doesn't exist!!!16:05
maxpalnin fact file -> export doesn't exist16:05
maxpalnok, I can convert from ASDB to VCD -16:10
maxpalnSCRIPTER: Error: child killed: segmentation violation16:10
mafmquestion: or1k is *always* big endian?  or can be little endian?16:10
maxpalnok, time has run out today - this will have to wait until tomorrow.16:11
maxpalna clear head will no doubt see the problem.16:11
stekernmafm: in theory it can16:13
mafmstekern: then, what's the best way to say something like this?
mafmis __BYTE_ORDER always defined in libc, and thus can be relied upon?16:16
mafmone thing to clarify: with "or1k" above I mean or1k-the-name-in-architecture-triplets, not the processor in general16:17
stekernah, then I guess it'll always be big endian.16:21
mafmstekern: 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
stekernyes, at least to me it would make most sense to have an or1kle/or1kel16:29
mafmok, thanks stekern16:55
olofkWhat? Someone actually did make a clone of the ordb2a board18:00
stekernyes, and it's for sale too18:04
olofkI always assumed it was one of the regular I-don't-really-have-a-fucking-clue-what-I'm-doing people18:10
olofkI learned about event in verilog yesterday, btw. That's pretty handy18:10
olofkInteresting read about the CLANG improvements18:33
blueCmdstekern: hm19:17
blueCmdstekern: so it might be the loading / linking19:17
blueCmdafter all19:17
blueCmdso apparently is Open-Source now19:18
--- Log closed Wed Jul 30 00:00:42 2014

Generated by 2.15.2 by Marius Gedminas - find it at!