| jeremybennett | Anyone have experience of the Yocto project (http://www.yoctoproject.org)? | 11:14 |
|---|---|---|
| Jia | it looks amazing | 11:51 |
| jeremybennett | Jia: The only thing I noticed was when I looked at the Project Members - all but one works for Intel/Wind River. | 11:54 |
| jeremybennett | So I do wonder how much this is really a community project, rather than Intel/Wind River doing their work in public (which is still a very good thing). | 11:54 |
| Jia | is open embedded OK? | 11:57 |
| Jia | almost ARM only | 11:57 |
| jeremybennett | Well these are all good things. The challenge is when projects are dominated by one company, even with the best will in the world, it is hard to stop the project leaning towards that one company's agenda. | 11:58 |
| jeremybennett | Even LLVM suffers from this - with its domination by Apple/ARM/Qualcomm. They are all quite open, but it is simply they have so many people working on stuff it can't help steering the project. | 11:59 |
| Jia | yes, like open64, it is a fake community project. | 11:59 |
| jeremybennett | I'm not sure "fake" is fair. It is a desire for corporations to involve the community, and that is a very good thing. It is just hard for one company to get everyone involved. | 12:01 |
| jeremybennett | The best projects are where there is no one company dominating. | 12:01 |
| jeremybennett | It will be interesting to see how Open Embedded and Yocto play out. ARM and Intel seem to be squaring up for a market battle. Do Open Embedded and Yocto get tainted by this? | 12:02 |
| Jia | OE is supported by NOKIA, ever. | 12:06 |
| Jia | so...... | 12:06 |
| Jia | but OE is not one company dominating. | 12:07 |
| googjosh | Hello all. Can someone help me? gdb command "set $pc=0x100" fails with error "Cannot access memory at address 0xc0000000" both in or1ksim and in fpga. but command "x 0x100" print "0x100:0x1880c015". Google can't answer =(. I use orsoc with de0-nano. All by default. | 18:49 |
| googjosh | I used this "http://kevinmehall.net/openrisc/guide/" manual. | 18:50 |
| derRichard | googjosh: isn't spr? | 18:55 |
| derRichard | +it | 18:55 |
| googjosh | not understood. what does it mean? | 19:06 |
| derRichard | spr the gdb command | 19:07 |
| googjosh | ok. special purpose register? but +it? | 19:07 |
| derRichard | i forgot the "it" :D | 19:08 |
| jeremybennett | googjosh: It's an upstream bug in GDB. | 19:09 |
| jeremybennett | Which version of GDB are you using? | 19:09 |
| jeremybennett | Oh - hold on. Is this after you have started executing the program. The problem I was referring to affected registers prior to execution. | 19:11 |
| jeremybennett | Looking more, it looks like you are trying to use GDB to debug the Linux kernel and it is being thrown by the memory translation. | 19:11 |
| googjosh | Ok. I'll try to debug something other :) | 19:15 |
| googjosh | But why I can't set programm counter? I downloaded the kernel, but do not run it. | 19:19 |
| jeremybennett | It is a problem with the way GDB represents NULL frames. There is a patch somewhere that fixes this, but it breaks other things, so we haven't put it in the distribution. | 19:38 |
| jeremybennett | However GDB is no use on its own for debugging the kernel. You need KGDB or KDB. I know jonibo was looking at this, but I don't know if the necessary bits are in the kernel yet. | 19:39 |
| stekern | bah, he quit... he needs to: spr npc 0x100 | 19:56 |
| derRichard | "Ping timeout: 240 seconds" <-- he died :P | 19:57 |
| stekern | I've managed to compile uclibc with llvm now (after inserting some hacks into it), haven't tried running it yet though | 19:58 |
| jeremybennett | stekern: Well done - you are making fast progress! | 20:37 |
| stekern | jeremybennett: it's easy to keep yourself motivayed when you're having fun ;) | 20:42 |
| stekern | oh, and I have got it to run the dhrystone test as fast as gcc-4.8, by tweaking the limit where memcpys vs inserted load/stores goes | 20:49 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!