IRC logs for #openrisc Thursday, 2014-07-24

--- Log opened Thu Jul 24 00:00:33 2014
stekerndoes anyone have any comments on this?
markus_wannerI think it depends a lot on what a website wants to be. I'm still looking for some kind of directory, i.e. something with the rating and status indication that opencores provided. But without the requirement that these be hosted in a certain place.07:55
olofkstekern: Don't like the idea of a ROM because we need to reserve some address space then. But how about an SPR?08:02
olofkmarkus_wanner: You have a point here. Even though the OpenCores rating and status indication is messy, at least it gave an indication if a core had been silicon proven08:04
olofkstekern: Working it out in the illegal instruction handler might be a good idea too. Is that doable?08:05
olofkAnd do we do something similar for missing class II instructions? Like mul and div?08:06
stekernolofk: yeah, the 'finding out' part is trivial... it was comments what to do when you know it's not supported I was looking for08:07
stekernI understand from Alan's comment that he suggest we'd do something like this:
stekernwhich AFAICT ends up in self-modyfing the code that use the unsupported instruction08:11
stekernI'm just not sure if that's really doable in our case, it's not like the alternate implementation is trivially alike08:12
stekernnot familiar enough with what that alternate code does yet to really tell, but one thing it seems to do is to remove the lock prefix from e.g. cmpxchg in the UP case.08:14
stekernwhich is of course a trivial change to 'patch in' to the current instruction mem.08:15
stekernthis whole thing can of course be solved by just adding emulation of the l.lwa/l.swa instructions in the kernel (something I anyway intend to do)08:16
stekernbut I'm pretty sure that that's many orders of magnitude less efficient than the kernels generic UP implementations of atomic operations.08:17
olofkUP = Unicorn Processor?08:53
stekernUnicorn PĂ„lle09:13
olofkhmmm... vga_lcd doesn't do bursts?10:23
olofk= really shitty bus utilization?10:24
stekerndoes to10:24
olofkah sorry10:25
olofkI looked at the slave port10:25
stekernbut only up to 8 words10:26
stekerneasy to hack it to do longer ones though10:26
stekernI've planned on doing that for the sockit board10:26
stekernsince I have a dedicated port into the mem controller, it could just continously burst data out of it for the whole frame10:27
olofkI think that 8 words is enough as long as you don't use higher resolutions than 4x2 pixels10:28
olofkWhole frame bursts might be mean to architectures that don't have dedicated ports and has to share the bus with something else10:29
olofkIf there wasn't already a master port on vga_lcd, this would be a perfect thing for my wb_streamer thingie10:30
olofk...I think10:30
olofk...without having thought very long10:31
olofkstekern: How does vga_lcd work? Do you just write to a memory area, and let the controller fetch from there every new frame?13:37
victorbHi, I trying to execute a simple program("Hello World") in the  Icarus Verilog simulator, but it give me an error that I can understand14:08
victorbHere is the output that I have:
victorbsomeone can help me?14:09
stekernolofk: you configure the screen setup and the framebuffer memory address in the wb slave registers14:55
stekernand then it just continuously fetch data from that memory area and feed it to the VGA port14:55
stekernthere is a good manual available for that core, you know that right? =)14:56
olofkvictorb: We just moved the location of uart16550_model, so it's probably related to that. I can look it up later tonight15:15
victorbok, thanks15:17
blueCmddo you see anything weird?15:28
blueCmdthat loops forever for me, and I'm trying to figure out what I've done wrong. I'm pretty convinced that it's in qemu15:28
blueCmdI mean, the code is simple but I've been debugging for a long time now so I want a second opinion15:29
stekernblueCmd: no, that looks right16:27
stekernbut you've had other l.lwa/l.swa pairs succeeding, hadn't you?16:29
stekernthe only 'special' thing I can see about that is that the load and store is at an offset from r3016:30
stekernno idea how that is handled in qemu, but something you might look at that it's handled correctly16:31
stekernoh... did I screw up the uart for icarus :(16:36
blueCmdstekern: yeah, the problem there I _think_ was that I used a variable in qemu that wasn't guaranteed to survive branches16:36
blueCmdI fixed that and it now crashes instead of spinning, so that's better I guess :P16:37
blueCmd(in another place)16:37
stekernolofk: tb_private_src_files doesn't of course work to use in the standalone core, but is there some other way to mark that that file should only be included as a part of a testbench?16:47
stekernI can get around the bug without it, but I think it'd be nice if such a feature existed (if it doesn't already exist)16:48
stekernah! tb_src_files16:49
blueCmdI loove squishing bugs that I've spent a sh*tton of hours debugging17:08
stekernblueCmd: please tell me that it was something silly like a typo or calculating words as bytes, so I don't have to feel alone....17:59
blueCmdstekern: almost18:14
blueCmdstekern: memory offset was calculated in a temporary variable in qemu18:15
blueCmdby default temporary variables are not scoped to be valid across branches18:15
blueCmdextending the scope was the fix18:15
stekernok, you mentioned ah crash after that, did you find the fix for that too?18:19
blueCmdstekern: it was due to that18:20
blueCmdah right18:20
blueCmdwhen I wrote about it first I fixed it at one place18:20
blueCmdand it turned out to be at another place as well18:20
blueCmdthe first fix was the order which I do the compares (addr/value vs value/addr), the other was the offset(reg) decoding18:21
blueCmdnow then. futex locks up18:21
blueCmdstekern: futex_atomic_cmpxchg_inatomic18:34
blueCmddoes that really work?18:35
blueCmdto me it looks like it would do l.swa, potentially not branch and just l.j to itself18:35
stekernblueCmd: what's after 3: is in another .section18:58
blueCmdstekern: right, so it will break the asm at that point?18:59
stekernyes, only what's above 3: will be 'inside' futex_atomic_cmpxchg_inatomic19:07
stekernthe point with the fixups is that if you get a pagefault in either 1: or 2:, this code will set the user PC to 4: and the function will then return -EFAULT.19:09
stekernthat way you can initially just do a rudimentary sanity check of the address (access_ok()) and then lazily let the mmu catch the rest19:11
blueCmdstekern: removing or1k override for pthread_once "solved" the futex lock19:34
blueCmdI like that glibc is actually consolidating files so I can remove a lot of overrides19:34
blueCmdthat's most welcome19:34
stekernah, what did the override do?19:36
blueCmdstekern: a lot of subtle differences20:11
blueCmdthe override was for "pthread_once"20:11
blueCmdsome thread setup thing20:11
blueCmdstekern: I get killed when I do FUTEX_WAIT on an adress I know is valid20:12
stekerndalias: looks like you've got company in the gcc 4.9 haters club:
stekernblueCmd: interesting, what's the address? and do you have something I could test here?20:14
blueCmdi'm trying to narrow it down, but as it looks now I can read the value of an address just fine, but when I do a futex_wait on it (it's the TID) I get SIGSGV20:15
blueCmdor it might be SIGSEGV in the other thread actually20:17
blueCmdyes, it must be that - the crash point in the main thread is erradic20:19
blueCmdheh. right. the new thread SIGSEGVs directly after the clone20:39
daliasstekern, thanks20:41
blueCmdstekern: I'm having trouble with clone21:36
blueCmdmy stack seems to lose it's contents. I'm trying to pass the function ptr that the child should jump to, but I think something bad happens :)21:36
blueCmdI don't have any fancy l.nop to help me debug it currently, so I'm asking if you have seen something like this when you ported musl21:37
stekernblueCmd: can you point me to the place where clone is in glibc?21:38
stekerni.e., where the actual clone syscall is being made21:39
blueCmd*sigh* I guess I'll have to compile something statically and throw it into or1ksim21:48
stekernwhy couldn't you just have pulled the args from the stack directly in __or1k_clone?21:49
blueCmdstekern: because I have wrappers for other syscalls everywhere as well21:50
blueCmdalso I'm not sure i knew about the vararg ABI back in 2012 or when I wrote this21:51
stekernwell, obviously you did, since you acocunted for it ;)21:52
blueCmdno, I created wrappers on a "on crash"-basis21:52
blueCmdI knew it bugged and wrappers solved it, but I didn't know why21:52
stekernhmm, you save stuff on the child stack, but I can't see that you are adjusting the stack pointer for that anywhere?21:54
blueCmdstekern: I'm doing that locally, I found that as well but it doesn't appear to fix stuff21:54
blueCmdi'm doing +14 locally21:55
blueCmdit should be -1421:55
stekernheh, ok.. I ask you to point me to the code that is buggy, and you have changed it. Thanks ;)21:55
blueCmdstekern: sorry, I forgot that I changed that21:55
stekernnp, it seems it lead to that we found the bug anyway21:56
blueCmddoesn't seem to help much though21:58
stekernand 14? that sounds awfully unaligned21:58
blueCmdstekern: I'm just not writing what I'm thinking, I'm a bit tierd I think21:59
blueCmdI mean 1221:59
blueCmdI shaved stuff away to remove error sources, fn is a function that writes 'ALIVE', I modified this function so that both threads end up calling the function (it has a while(1); so it should never return)22:00
blueCmdthe main thread calls it and spins, but the child thread does not22:00
stekernI can't find anything obvious wrong in your clone now at least22:10
blueCmdI _thikn_ this started when I switched to your SMP kernel22:10
blueCmdbut it could also just have nudged the right things to reveal the bug22:11
blueCmdI'm considering stuff like if my flags are wrong to clone or something22:11
stekerndo you have the program?22:11
stekernor, can you give it to me22:11
blueCmdit's supposed to print "ALIVE" twice and then do nothing22:13
stekernyou have a l.nop 8 in there?22:18
blueCmdi Just now started it in or1ksim22:18
blueCmdthat was kinda useless22:18
blueCmdsorry about that, I'll move the relevant test first22:18
blueCmdstekern: should be a better version now22:19
stekernwell, it's not that much that is done before it22:19
blueCmdstekern: so, I refined my .lnops a bit22:24
blueCmdthat's l.nop 8; l.lwz func addres; l.nop 9; in both child and parent thread22:24
blueCmdthe address looks fine22:25
blueCmdbetter output:
stekernyou don't have the source to that program in a cut-down form?22:30
blueCmdstekern: which program? testsuite?22:31
stekernbut only the part that does the clone22:31
blueCmdnot cut-down no22:31
blueCmdthe part that does the clone is pthread_create22:31
blueCmdso anything that does that should trigger this22:31
blueCmd that's the row anyway22:32
blueCmdl.sw is the thing that causes a bus exception22:34
blueCmdmaybe not22:34
stekerndoes this test work for you then?;a=blob;f=src/functional/sem_init.c;h=0d30f02f391ee9d32cc12871580aab0df16b1ee3;hb=HEAD22:37
blueCmd.. that's weird22:37
stekerngot to sleep now, let me know if you figure it out, otherwise I can take a fresh look in the morning22:39
blueCmdstekern: yes, thanks - I'm gonna revert my kernel a few versions22:39
blueCmdif that doesn't help I'm gonna call it a night aswell22:40
blueCmdl.jalr. using r9.22:53
blueCmd"It's is not allowed to specify link register r9"22:53
blueCmdwhich I should have realised way earlier22:54
blueCmdoh well22:54
blueCmdyes, now it gets all the way to start_thread - so that's muuch better. it crashes somewhere inside of that, but that's for tomorrow :-)23:06
daliasworking on glibc?23:19
--- Log closed Fri Jul 25 00:00:34 2014

Generated by 2.15.2 by Marius Gedminas - find it at!