IRC logs for #openrisc Sunday, 2014-05-25

--- Log opened Sun May 25 00:00:04 2014
daliasstekern, i'm working on the !__ARCH_WANT_SYSCALL_NO_AT stuff for musl02:41
stekerndalias: ah, nice!07:01
stekernblueCmd: doing a distupgrade fixed the issues07:14
stekernblueCmd: no... scratch that, I think it was still the old libc running...07:44
stekernI get this when I try to install libc6 from the chroot environment: http://pastie.org/920854607:45
wondiwshi blueCmd :)09:47
blueCmdhello10:18
blueCmdstekern: odd10:20
blueCmdhave you mounted /proc and /dev/pts ?10:20
stekernno, should I10:21
blueCmdwell, it complains about that :P10:24
stekernyeah, but it doesn't fail because of that afaict10:24
blueCmdno, but maybe it can log something more helpful10:24
blueCmdoh well10:24
blueCmdI don't know what to tell you here.10:25
blueCmdideally I would love to have a torture tests for the gcc atomics, and this is as close as I will get to that I think10:25
stekernyeah, but I wonder what's different in our systems10:27
blueCmdstekern: http://e955a39045749c84.paste.se/ that's what I get10:45
blueCmdstekern: stupid question, but you do have the lwa/swa patched qemu installed both outside and inside the chroot right?10:46
blueCmd"#interrupt-cells = <1>;" I *always* thought that was a comment, but reading your patch stekern I now see that it's actually a statement10:56
blueCmdthat's horrible if you ask me10:56
stekernI *should* have the patched qemu installed on both sides...10:58
stekernI'll double check and then triple check10:58
stekernright now I've got other issues ;)10:58
stekernthe smp heisenbug and a stm8 board with an input that needs to be pulled-up, but now it turned out that there are two pins on the stm8 that doesn't have internal pull-ups11:00
stekern...guess to what the input that needs to be pulled-up is connected?11:00
blueCmdirq? :P11:01
stekern...but, even though I wouldn't have, dpkg -x'ing the new libc into the initramfs breaks real hw and or1ksim here anyway... so it's some larger issue11:02
stekernirq?11:02
blueCmdinterrupt line or something11:06
stekernah, no, it's of course connected to the pin that doesn't have a internal pull-up11:12
blueCmdright, but that was implicit :)11:13
blueCmdbut what is that pin connected to in the design?11:14
blueCmdthat was what I was guessing on11:14
stekernaha, an optocoupler11:18
stekernbut the "guess what" was more a statement than a real question ;)11:19
blueCmdpff!11:22
blueCmdhm, so many things to persue. I want to get my hardware working to play with that, I want to debug why atomic libc locks / schroot --help doesn't work for me (probably the same issue)11:23
blueCmdI guess the atomic libc locks will bite me in hardware as well though11:24
blueCmds/locks/lockups/11:24
wondiwsblueCmd, opencores on github repositories has an openOCD repo, but my debian system has already an openOCD package, can I use my debian one?11:27
blueCmdwondiws: I don't think so11:28
blueCmdbut try11:29
wondiwsI can't compare yet as I haven't got openOCD working at all ;)11:29
juliusbhello all from chiphack!11:49
juliusbi'm wondering if there's a precompiled linux image around for the de0_nano system in orpsoc-cores11:49
blueCmdthere is I think11:56
blueCmdhttps://www.dropbox.com/s/bi5vx8kmqnjdldx/vmlinux-de0_nano11:57
juliusbblueCmd: nice thanks a lot12:03
_franck_wondiws: you can use openocd from your debian (openocd 0.8.0 ?)12:06
wondiwsis that a question? :)12:06
_franck_the question is: does your debian is up-to-date and has openocd v 0.8.0 ?12:07
_franck_if yes, you can use that one12:07
wondiwsanswer is yes12:07
wondiwsI want to understand OpenOCD a little better, can you use OpenOCD on your Raspberry Pi?12:18
blueCmdwondiws: yes, you need a JTAG adapter to connect to the JTAG pins on it12:21
blueCmdhttp://sysprogs.com/VisualKernel/tutorials/raspberry/jtagsetup/ something like that12:21
simoncookjuliusb on OpenRISC at chiphack: http://t.co/pU1GLf4e1r13:12
blueCmdwoo \o/13:15
simoncookand as all good fpga talks should, ending with linux booting for or1k :)13:22
blueCmdhttps://www.youtube.com/watch?v=ZQ9VDabHGpA this game is now compiled for openrisc :P16:12
simoncooknice17:06
LoneTechin that case, I expect compiled and playable to differ. it eats 3d graphics cards.18:25
poke53281Well the question is, if it runs :)18:29
LoneTechpuzzlebox FAQ was nice :)18:40
blueCmdstekern: you should try installing "neverball" and launching it ;)18:47
stekernblueCmd: yeah, tease the guy that has a broken rootfs, do that! :(18:52
blueCmdogre-1.8 is also built19:11
stekernnow we just need some graphics hw for them19:38
gmarkallHi. I've been trying to get the orpsoc working on the de0-nano, having been at Chiphack this weekend and following the guide: https://github.com/embecosm/chiphack/wiki/OpenRISC-SoC-Practical-Session-Instructions20:02
gmarkalleveryything appears to be working up until the point  where i load the hello world example with or1k-elf-gdb. running the "load" command appears to work20:04
gmarkallhowever, when i run "continue" the CPU always appears to end up executing at 0x600 (the misaligned access exception vector)20:04
gmarkalli tried checking out a slightly older revision of orpsoc-cores (f280ab463972eeb226ef81da595a663e725ab021) to see if that made any difference. with that revision, the same seems to happen, but it always ends up executing at 0x700 (illegal instruction) instead20:06
gmarkallthis seems to be something peculiar to my de0-nano (juliusb tried my de0-nano earlier on and got the same result)20:08
gmarkallfor other purposes the de0-nano seems to be functioning OK - I can run a Nios2 core on it and execute an SDRAM test that passes repeatedly20:09
gmarkalldoes anyone have any hints/advice that might help me track down what the issue is please?20:09
blueCmdhm20:14
blueCmdgmarkall: I never tried bare metal nor via gdb, but maybe try with openocd?20:15
blueCmdI had problems with my de0 nano when it got hot20:15
blueCmdended up executing 0x700 as well20:16
blueCmdthen I would just unplug it, blow on it for a half a minute and plug it in and it would work20:16
blueCmdI suspect timing issue on too high temperature, but I haven't debugged it much20:17
stekernhmm, my de0_nano doesn't get hot at all20:18
blueCmdit doesn't get "hot" but more warm ish20:18
stekern(compared to the atlys, which get insanely hot, even though that has a heat sink)20:19
blueCmdstill I need to let it cool down / unplug it sometimes20:19
stekern...and I've never experienced something like that20:19
stekerndoes that happen both when you have your extension board and not connected?20:20
gmarkallblueCmd: i have openocd running and i'm connecting to it with gdb with the "target remote :50001" command - do you mean using openocd directly somehow?20:21
blueCmdstekern: I had the same idea, but the USB-UART is too comfortable so I never tried without it20:22
blueCmdI'm pretty sure the timing does not close on sythesis for me though, so I might have screwed something up20:22
stekernaha, that's weird20:22
stekernI pass all timing with two cores, so it should ;)20:23
blueCmdI'll just finish porting Debian and I'll have a look20:26
blueCmdso, anyday now...20:26
stekernhaha20:26
stekernI know the feeling20:26
stekernseems so much easier to add stuff to the TODO list than pick them off it, right?20:27
blueCmdhaha yes20:27
blueCmdstekern: you can now encrypt block devices on your atlys board!20:29
blueCmdso as soon as we get block devices working that will be useful I'm sure20:29
stekerncool, if I only had some block devices20:29
blueCmd:D20:29
stekernyay, I might have fixed the heisenbug!20:48
stekernI got tired of chasing it so I started sifting through the code for non-per-cpu stuff, and I found that I had forgot to create a current_pgd for each cpu20:49
stekernso both we're running off the same20:49
stekern*were20:50
stekernit boots now and I can run 'ls' and 'top' now! ;)20:50
blueCmdah ok20:51
blueCmdnice! :D20:51
blueCmdcat /proc/cpuinfo !20:51
stekernehm... I haven't fixed that yet ;)20:51
blueCmd:(20:51
stekernoops, now it crashed too...20:51
blueCmdI'll have a toast anyway20:51
stekernbut it's progress20:52
stekernhttp://pastie.org/921331820:52
stekernnotice the CPU column20:52
blueCmdyes! look at that!20:52
LoneTechnice :)20:53
stekernand now I got RCU stall warnings again21:02
stekernbut... they are less frequent now...21:02
blueCmdstekern: if you get the time, I would have loved if you could do some magic and see if you can dig in where it might be hanging for you during boot21:03
blueCmdI'll set up or1ksim and do some tests myself when I can, but I'm thinking pausing the CPU with OpenOCD or something could be helpful21:04
stekernsure, I'll poke a bit at that21:10
blueCmdthanks21:11
stekernhow did you read sprs in gdb now again...21:23
LoneTechstekern: info spr $group $register21:28
LoneTechiirc21:28
LoneTechso something like info spr sys npc21:29
stekernyes, but I don't think it works in the latest gdb21:29
stekernit says: invalid command name "readspr"21:29
LoneTechhm. that might be at the proxy level21:30
stekernunder all-registers, we have ppc, nc and sr21:30
stekern*npc21:30
LoneTechlooks like recent openocd has an addreg command to register SPRs21:34
LoneTechgtg, sleep21:35
blueCmdstekern: -pie AFAICS is passed straight through to the linker and doesn't do anything on the compiler/as stage22:09
blueCmd-S with and without -pie is identifical. readelf -a on the output with/without -pie is quite different and the one with -pie has quite a lot fewer relocations22:09
--- Log closed Mon May 26 00:00:05 2014

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!