--- Log opened Sun May 25 00:00:04 2014 | ||
dalias | stekern, i'm working on the !__ARCH_WANT_SYSCALL_NO_AT stuff for musl | 02:41 |
---|---|---|
stekern | dalias: ah, nice! | 07:01 |
stekern | blueCmd: doing a distupgrade fixed the issues | 07:14 |
stekern | blueCmd: no... scratch that, I think it was still the old libc running... | 07:44 |
stekern | I get this when I try to install libc6 from the chroot environment: http://pastie.org/9208546 | 07:45 |
wondiws | hi blueCmd :) | 09:47 |
blueCmd | hello | 10:18 |
blueCmd | stekern: odd | 10:20 |
blueCmd | have you mounted /proc and /dev/pts ? | 10:20 |
stekern | no, should I | 10:21 |
blueCmd | well, it complains about that :P | 10:24 |
stekern | yeah, but it doesn't fail because of that afaict | 10:24 |
blueCmd | no, but maybe it can log something more helpful | 10:24 |
blueCmd | oh well | 10:24 |
blueCmd | I don't know what to tell you here. | 10:25 |
blueCmd | ideally I would love to have a torture tests for the gcc atomics, and this is as close as I will get to that I think | 10:25 |
stekern | yeah, but I wonder what's different in our systems | 10:27 |
blueCmd | stekern: http://e955a39045749c84.paste.se/ that's what I get | 10:45 |
blueCmd | stekern: 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 statement | 10:56 |
blueCmd | that's horrible if you ask me | 10:56 |
stekern | I *should* have the patched qemu installed on both sides... | 10:58 |
stekern | I'll double check and then triple check | 10:58 |
stekern | right now I've got other issues ;) | 10:58 |
stekern | the 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-ups | 11:00 |
stekern | ...guess to what the input that needs to be pulled-up is connected? | 11:00 |
blueCmd | irq? :P | 11: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 issue | 11:02 |
stekern | irq? | 11:02 |
blueCmd | interrupt line or something | 11:06 |
stekern | ah, no, it's of course connected to the pin that doesn't have a internal pull-up | 11:12 |
blueCmd | right, but that was implicit :) | 11:13 |
blueCmd | but what is that pin connected to in the design? | 11:14 |
blueCmd | that was what I was guessing on | 11:14 |
stekern | aha, an optocoupler | 11:18 |
stekern | but the "guess what" was more a statement than a real question ;) | 11:19 |
blueCmd | pff! | 11:22 |
blueCmd | hm, 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 |
blueCmd | I guess the atomic libc locks will bite me in hardware as well though | 11:24 |
blueCmd | s/locks/lockups/ | 11:24 |
wondiws | blueCmd, 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 |
blueCmd | wondiws: I don't think so | 11:28 |
blueCmd | but try | 11:29 |
wondiws | I can't compare yet as I haven't got openOCD working at all ;) | 11:29 |
juliusb | hello all from chiphack! | 11:49 |
juliusb | i'm wondering if there's a precompiled linux image around for the de0_nano system in orpsoc-cores | 11:49 |
blueCmd | there is I think | 11:56 |
blueCmd | https://www.dropbox.com/s/bi5vx8kmqnjdldx/vmlinux-de0_nano | 11:57 |
juliusb | blueCmd: nice thanks a lot | 12:03 |
_franck_ | wondiws: you can use openocd from your debian (openocd 0.8.0 ?) | 12:06 |
wondiws | is 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 one | 12:07 |
wondiws | answer is yes | 12:07 |
wondiws | I want to understand OpenOCD a little better, can you use OpenOCD on your Raspberry Pi? | 12:18 |
blueCmd | wondiws: yes, you need a JTAG adapter to connect to the JTAG pins on it | 12:21 |
blueCmd | http://sysprogs.com/VisualKernel/tutorials/raspberry/jtagsetup/ something like that | 12:21 |
simoncook | juliusb on OpenRISC at chiphack: http://t.co/pU1GLf4e1r | 13:12 |
blueCmd | woo \o/ | 13:15 |
simoncook | and as all good fpga talks should, ending with linux booting for or1k :) | 13:22 |
blueCmd | https://www.youtube.com/watch?v=ZQ9VDabHGpA this game is now compiled for openrisc :P | 16:12 |
simoncook | nice | 17:06 |
LoneTech | in that case, I expect compiled and playable to differ. it eats 3d graphics cards. | 18:25 |
poke53281 | Well the question is, if it runs :) | 18:29 |
LoneTech | puzzlebox FAQ was nice :) | 18:40 |
blueCmd | stekern: you should try installing "neverball" and launching it ;) | 18:47 |
stekern | blueCmd: yeah, tease the guy that has a broken rootfs, do that! :( | 18:52 |
blueCmd | ogre-1.8 is also built | 19:11 |
stekern | now we just need some graphics hw for them | 19:38 |
gmarkall | Hi. 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-Instructions | 20:02 |
gmarkall | everyything 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 work | 20:04 |
gmarkall | however, when i run "continue" the CPU always appears to end up executing at 0x600 (the misaligned access exception vector) | 20:04 |
gmarkall | i 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) instead | 20:06 |
gmarkall | this seems to be something peculiar to my de0-nano (juliusb tried my de0-nano earlier on and got the same result) | 20:08 |
gmarkall | for 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 repeatedly | 20:09 |
gmarkall | does anyone have any hints/advice that might help me track down what the issue is please? | 20:09 |
blueCmd | hm | 20:14 |
blueCmd | gmarkall: I never tried bare metal nor via gdb, but maybe try with openocd? | 20:15 |
blueCmd | I had problems with my de0 nano when it got hot | 20:15 |
blueCmd | ended up executing 0x700 as well | 20:16 |
blueCmd | then I would just unplug it, blow on it for a half a minute and plug it in and it would work | 20:16 |
blueCmd | I suspect timing issue on too high temperature, but I haven't debugged it much | 20:17 |
stekern | hmm, my de0_nano doesn't get hot at all | 20:18 |
blueCmd | it doesn't get "hot" but more warm ish | 20:18 |
stekern | (compared to the atlys, which get insanely hot, even though that has a heat sink) | 20:19 |
blueCmd | still I need to let it cool down / unplug it sometimes | 20:19 |
stekern | ...and I've never experienced something like that | 20:19 |
stekern | does that happen both when you have your extension board and not connected? | 20:20 |
gmarkall | blueCmd: 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 |
blueCmd | stekern: I had the same idea, but the USB-UART is too comfortable so I never tried without it | 20:22 |
blueCmd | I'm pretty sure the timing does not close on sythesis for me though, so I might have screwed something up | 20:22 |
stekern | aha, that's weird | 20:22 |
stekern | I pass all timing with two cores, so it should ;) | 20:23 |
blueCmd | I'll just finish porting Debian and I'll have a look | 20:26 |
blueCmd | so, anyday now... | 20:26 |
stekern | haha | 20:26 |
stekern | I know the feeling | 20:26 |
stekern | seems so much easier to add stuff to the TODO list than pick them off it, right? | 20:27 |
blueCmd | haha yes | 20:27 |
blueCmd | stekern: you can now encrypt block devices on your atlys board! | 20:29 |
blueCmd | so as soon as we get block devices working that will be useful I'm sure | 20:29 |
stekern | cool, if I only had some block devices | 20:29 |
blueCmd | :D | 20:29 |
stekern | yay, I might have fixed the heisenbug! | 20:48 |
stekern | I 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 cpu | 20:49 |
stekern | so both we're running off the same | 20:49 |
stekern | *were | 20:50 |
stekern | it boots now and I can run 'ls' and 'top' now! ;) | 20:50 |
blueCmd | ah ok | 20:51 |
blueCmd | nice! :D | 20:51 |
blueCmd | cat /proc/cpuinfo ! | 20:51 |
stekern | ehm... I haven't fixed that yet ;) | 20:51 |
blueCmd | :( | 20:51 |
stekern | oops, now it crashed too... | 20:51 |
blueCmd | I'll have a toast anyway | 20:51 |
stekern | but it's progress | 20:52 |
stekern | http://pastie.org/9213318 | 20:52 |
stekern | notice the CPU column | 20:52 |
blueCmd | yes! look at that! | 20:52 |
LoneTech | nice :) | 20:53 |
stekern | and now I got RCU stall warnings again | 21:02 |
stekern | but... they are less frequent now... | 21:02 |
blueCmd | stekern: 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 boot | 21:03 |
blueCmd | I'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 helpful | 21:04 |
stekern | sure, I'll poke a bit at that | 21:10 |
blueCmd | thanks | 21:11 |
stekern | how did you read sprs in gdb now again... | 21:23 |
LoneTech | stekern: info spr $group $register | 21:28 |
LoneTech | iirc | 21:28 |
LoneTech | so something like info spr sys npc | 21:29 |
stekern | yes, but I don't think it works in the latest gdb | 21:29 |
stekern | it says: invalid command name "readspr" | 21:29 |
LoneTech | hm. that might be at the proxy level | 21:30 |
stekern | under all-registers, we have ppc, nc and sr | 21:30 |
stekern | *npc | 21:30 |
LoneTech | looks like recent openocd has an addreg command to register SPRs | 21:34 |
LoneTech | gtg, sleep | 21:35 |
blueCmd | stekern: -pie AFAICS is passed straight through to the linker and doesn't do anything on the compiler/as stage | 22: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 relocations | 22: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!