--- Log opened Tue Aug 26 00:00:23 2014 | ||
stekern | poke53282: for this particular bug? I'm fairly certain that this hw bug is what has been responsible | 02:51 |
---|---|---|
stekern | I need to restart the tests, they had stopped during the night due to an old debug trap I had inserted. But the trap was giving a false positive. | 02:57 |
stekern | maybe I can give running prboom a try soon on this setup ;) | 02:58 |
dalias | :) | 02:59 |
poke53282 | Would be nice to see something which is already heavily parallelized. | 03:46 |
poke53282 | something like x264. But this would look boring. | 03:48 |
stekern | yeah, the prboom thing is more that I want to give that a try, and this is the platform I'm working on at the moment | 03:50 |
poke53282 | do you need my compile script? | 03:54 |
stekern | I need to get mouse and keyboard from the silicon-heater (the ARM hps) to the openrisc core though | 03:54 |
stekern | sure, if you could share that, it'd be great | 03:55 |
poke53282 | http://pastie.org/9502987 | 03:57 |
poke53282 | three patches lines. I think all of them solved by googling | 03:57 |
poke53282 | Three patched lines. All of the problems solved by googling. | 03:59 |
stekern | cool, thanks | 04:13 |
stekern | all gcc execute tests ran without crashing now | 05:09 |
poke53282 | great. Did they run already parallel? | 05:13 |
poke53282 | make -j 2 or so. | 05:13 |
poke53282 | take a look at your smp branch. Doesn't look like you had to change much. Shadow registers, ompic and 200 lines of codes for basic functionality. | 05:26 |
poke53282 | Are the timers synced in some place? | 05:28 |
poke53282 | Would be also nice if the number of cpus can be determined automatically during boot that you don't need the .dts file. | 05:33 |
stekern | poke53282: timers are synced, but that's a local hack I have | 05:42 |
stekern | I need to fix that, I think it'll be better to just use a completely external timer | 05:43 |
stekern | but our arch/ code currently makes some assumptions about the tick timer being available | 05:44 |
poke53282 | But doesn't is make sense to have a timer for each cpu? then each cpu can wake up independently. Linux sends some core to sleep for a full second. I think they have their own timer then. | 05:48 |
poke53282 | An external timer is Ok, but an internal timer interrupt for each core. | 05:50 |
stekern | yeah, my point was just that I will need an external (accesible) timer anyway, so it might make sense to implement per-cpu timers in that as well then | 05:55 |
stekern | or, rather. per-cpu interrupts from the external timer | 05:55 |
stekern | because, the per-cpu timers need to be in sync (AFAICT) | 05:56 |
stekern | the current hack I'm using is to have a free running external timer, and then when I enable the internal tick timers, I set the timer value to the value of the external free running timer | 05:57 |
stekern | so they are roughly in sync | 05:58 |
stekern | http://pastie.org/9503137 <- hack | 06:00 |
poke53282 | That's a hack :) | 06:12 |
poke53282 | It looks like you plan that the spr registers will be fully independent for each core. | 06:12 |
stekern | well, it's not something I plan, that's the way things are ;) | 06:13 |
poke53282 | Well, I liked the idea to have the pic and the timer directly in the cpu architecture. | 06:17 |
poke53282 | Of course this is bad for externsions like smp | 06:18 |
olofk | Yeah, I would remove the PIC and timers from the CPU if I could | 06:19 |
poke53282 | But I wouldn't have thought, that we this feature so early. | 06:19 |
poke53282 | ...we get this... | 06:20 |
olofk | What feature? | 06:20 |
poke53282 | smp | 06:20 |
poke53282 | So far, timer and pic worked well. | 06:20 |
olofk | ah ok... Yes. There have been a lot of progress lately, but to be fair, it took 15 years in total ;) | 06:21 |
stekern | early? only ~15 years after the architecture was conceived ;) | 06:21 |
stekern | olofk: stop stealing my sentences | 06:22 |
poke53282 | Ok, for me it is early. Two years ago not even Linux was running | 06:22 |
poke53282 | Hehe | 06:22 |
poke53282 | Linux 3.1 as far as I know | 06:23 |
olofk | :) | 06:23 |
stekern | (out of tree) Linux port has been around a lot longer than that, 2.6.37 was alredy pretty stable | 06:24 |
olofk | And we have had uclinux for quite some time before that | 06:24 |
olofk | stekern: hmm... I just made a defconfig with your linux tree, and when I make menuconfig, the first option I see is 64-bit kernel enabled | 06:26 |
olofk | Ahh.. do I need to run menuconfig with ARCH=openrisc as well? | 06:27 |
poke53282 | make ARCH=openrisc menuconfig | 06:27 |
poke53282 | yes | 06:27 |
olofk | Yep, that changed things. I'll update the wiki | 06:27 |
olofk | And cross-compiler tool prefix? What is that? It's set to or32-linux- | 06:28 |
poke53282 | It changed for some reason. But I don't care.This is the usual way for all architectures. | 06:28 |
poke53282 | http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=09fc07991fd187f5098529dadf758ba6d6c79f7c | 06:29 |
olofk | Yeah, that's the linker script, right | 06:29 |
olofk | But under General setup, there's an option for Cross-compiler tool prefix. I would have assumed that it should be or1k-elf- (toolchain for building the kernel), but I might misunderstand something | 06:30 |
poke53282 | That's the second important place. in .config | 06:31 |
poke53282 | http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?h=smp&id=fdfdd3b038de01c10d61d87c36275dce980dcaf1 | 06:31 |
poke53282 | But this is his development branch. | 06:32 |
olofk | Hmm... | 06:32 |
olofk | It says or1k-linux-musl- there. | 06:32 |
olofk | I'm still not sure what that option is used for. Is it the prefix for building the kernel, or something that is used once the kernel is built? | 06:33 |
poke53282 | Yes, , not sure about the wiki | 06:33 |
poke53282 | it's the prefix of the toolchain | 06:33 |
olofk | If it's the first case, I would change it to or1k-elf-, but otherwise I don't know what to use | 06:33 |
poke53282 | or1k-linux-musl-gcc | 06:33 |
poke53282 | or1k-linux-musl-objdump and so on | 06:34 |
olofk | The host toolchain, or the target toolchain? | 06:34 |
olofk | ahh.. I just realized I could read the help text in menuconfig. I get it now :) | 06:35 |
poke53282 | As far as I understodd, you don't need the -elf- toolchain anymore for compiling linux. | 06:35 |
olofk | It's the only one I got right now, so it's easiest for me to use it | 06:36 |
stekern | you can override it on the command line too: ARCH=openrisc CROSS_COMPILE=or1k-elf- make | 06:36 |
poke53282 | I amstill unsure, which Linux version you mean? In the wiki it is still the link to git://git.openrisc.net/jonas/linux | 06:37 |
olofk | stekern: Yeah, I saw that in the help text | 06:37 |
olofk | Fuck! Forgot to change branch | 06:37 |
olofk | stekern: How is your master branch? | 06:37 |
stekern | hmm... it's at least missing one important fix if your userspace contains l.lwa/l.swa | 06:39 |
olofk | I'll switch. Compilation is quick | 06:40 |
stekern | now that's in master too | 06:42 |
stekern | http://git.openrisc.net/cgit.cgi/stefan/linux/commit/?id=1e5560db77d4b0a2f2a603cb60b2d70e178cede2 | 06:42 |
olofk | There are some warnings for missing casts. Is that anything openrisc-specific? | 06:43 |
stekern | in what parts? | 06:43 |
olofk | Different parts, but many are quite similar | 06:44 |
olofk | small snippet -> http://pastebin.com/8WvRJfZB | 06:45 |
poke53282 | Doesn't seem to be related to or1k | 06:46 |
olofk | No, it looks like generic code to me too | 06:47 |
olofk | hmm... the kernel panics in or1ksim | 06:48 |
poke53282 | update or1ksim too | 06:48 |
poke53282 | l.swa and l.lwa | 06:48 |
poke53282 | support | 06:48 |
olofk | right | 06:49 |
stekern | ...I have a half-baked kernel emulation for that | 06:50 |
olofk | Yep. New or1ksim did the trick | 09:14 |
olofk | Almost... | 09:23 |
olofk | Nothing happens when I telnet to the running instance. I just see the commands being echoed | 09:23 |
stekern | telnet to Linux or telnet to or1ksim? | 09:26 |
olofk | Don't know if I should blame busybox or my telnet connection | 09:26 |
olofk | should be to linux | 09:26 |
olofk | I'm using 10084 (the port from the uart section channel tag) | 09:26 |
olofk | well.. or1ksim then I mean | 09:27 |
olofk | Or what do you mean exactly? :) | 09:27 |
stekern | exactly that | 09:28 |
stekern | not that I know why that doesn't work for you | 09:28 |
stekern | I can try your image here if you want | 09:28 |
olofk | cool. I'll fax it! | 09:29 |
stekern | hold your horses, I'll turn on the fax modem first | 09:29 |
stekern | all set | 09:29 |
olofk | Great. You should be able to see it soon | 09:29 |
stekern | grrr... you put it in the wrong way around... | 09:30 |
olofk | Ah no! I forgot it's big endian | 09:30 |
olofk | I left a copy here as well, in case something goes wrong https://www.dropbox.com/s/r0s5hx36zxcqwcc/vmlinux-olofk?dl=0 | 09:31 |
stekern | I doubt that'll be needed, can't imagine what people need that fancy InterNet for | 09:32 |
olofk | http://cdn03.nyheter24.se/574351b70802021d01/2014/06/02/960063/Screen%20shot%202014-06-02%20at%2010.16.59%20AM.png | 09:33 |
stekern | works here | 09:34 |
olofk | As usual, there's a slight possibility that I need to turn on some use flag in a package somewhere :) | 09:35 |
stekern | that's the right attitude, who needs fancy pancy internet when you have a good trusty mora-knife | 09:36 |
stekern | sanity-check, you did try to type the commands in the session where you typed 'telnet localhost 10084', right? | 09:40 |
stekern | I'm asking, because typing in the session where you started or1ksim will behave just as you described | 09:42 |
stekern | to be clear, I don't think you deliberately typed in that, but might you have done that by mistake? | 09:43 |
stekern | (I for sure have done it many times) | 09:43 |
olofk | Yes, I did | 09:46 |
olofk | Weird that everything is echoed in the or1ksim instance | 09:47 |
olofk | Makes me think that the telnet connection works | 09:47 |
stekern | yes, maybe you have some crumbs under your enter key? | 09:48 |
mor1kx | [mor1kx] skristiansson pushed 4 new commits to multicore: https://github.com/openrisc/mor1kx/compare/f30eed468f40...c539d59e1635 | 09:49 |
mor1kx | mor1kx/multicore 16bfd84 Stefan Kristiansson: dcache: minor whitespace fixes | 09:49 |
mor1kx | mor1kx/multicore 6ec4169 Stefan Kristiansson: dcache: change OPTION_DCACHE_SNOOP checks from "ENABLED" to "NONE"... | 09:49 |
mor1kx | mor1kx/multicore 5b27fcd Stefan Kristiansson: dcache: remove check for dc_enable_i to to snoop_hit... | 09:49 |
olofk | haha.. It worked much better when I removed my local hacks from peripherals/channels/fd.c :) | 09:51 |
stekern | wallento: important bug-fix: https://github.com/openrisc/mor1kx/commit/c539d59e163500c29a28d25aadfa3e6042878eec | 09:53 |
wallento | cool, did this fix your bug? | 11:18 |
stekern | yes, it's stable as a rock now ;) | 11:24 |
stekern | ...it's probably the hardest mor1kx bug to crack I've encountered so far | 11:25 |
stekern | so it's rather satisfying to have it solved | 11:25 |
stekern | so, I will play around with this system a bit more, then I want to start moving multicore stuff over to master | 11:28 |
stekern | I will probably move them over in a completely different order than how they landed in the multicore branch, but I'm thinking that I can try to pull together the stuff you've done into seperate commits with you as author. | 11:30 |
stekern | does that sound ok? | 11:30 |
stekern | wallento: oh, and another thing. I will probably want to move the snoop_valid logic out of mor1kx into the 'snoop unit', does that makes sense to you? | 11:34 |
wallento | mmh, what do you mean with snoop unit? | 13:55 |
stekern | wallento: well, in your case, your bus arbiter | 15:10 |
stekern | in my case, a couple of lines in the top module | 15:11 |
stekern | but, my point is, how that is implemented should be transparent to mor1kx | 15:11 |
stekern | err... I mean, that mor1kx shouldn't need to care about how it's implemented | 15:13 |
stekern | oh, two penguins | 15:33 |
stekern | prboom runs | 15:41 |
poke53282 | :) | 15:45 |
poke53282 | how fast? | 15:45 |
stekern | it's a bit choppy, but I'm only running the cores at 50MHz | 15:55 |
stekern | and fb is 640x480 | 15:55 |
stekern | and I don't have a keyboard | 15:55 |
stekern | and running top: http://pastie.org/9504442 | 15:57 |
LoneTech | I'd note that Doom was designed for 25MHz 486es and the like, though it was carefully hand-optimized for 320x200 iirc. It literally had to be rewritten for higher resolutions. | 16:05 |
poke53282 | Yes, you can't compare prboom with the old doom. | 16:24 |
poke53282 | you work also with 32 Bit per Pixel and not just 8 Bit. | 16:26 |
poke53282 | stekern: Approx. how many instructions per cycle do you have? | 16:37 |
stekern | why would you work with 32 bit/pixel? | 17:02 |
stekern | mor1kx is approx 1 IPC | 17:02 |
dalias | lonetech, higher res did not really require much work. the basic algorithms work for any res | 17:20 |
poke53282 | Well, I think your framebuffer is 32bit/pixel. So the transformation takes already time. And I am not sure whether prboom still uses 8Bit/pixel and a palette like in the old days. | 18:09 |
poke53282 | copying of 1 MB into the framebuffer every second takes at least 4% of your total time. | 18:18 |
stekern | the framebuffer can be configured to 8-bit palette mode (and I'm using that) | 18:27 |
olofk | Has anyone tried to use gdb on an icarus simulation lately? | 21:07 |
olofk | ahh... I need openocd as a proxy between gdb and the sim. Forgot that | 21:08 |
olofk | Hmm... I get "Target ready..." from openocd and "Waiting for client connection...ok" from icarus, but gdb seems to be stuck | 21:35 |
olofk | ahh.. I probably tried to connect to the port between openocd and the sim | 21:39 |
olofk | So... which port should gdb connect to then? 50001 gives me timeout | 21:39 |
olofk | Fuck it. Probably solved tomorrow | 21:41 |
-!- Netsplit *.net <-> *.split quits: stekern, sb0, simoncook | 22:37 | |
-!- Netsplit *.net <-> *.split quits: enghong | 22:43 | |
-!- clopez_ is now known as clopez | 22:50 | |
--- Log closed Wed Aug 27 00:00:25 2014 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!