| --- Log opened Tue Jan 27 00:00:15 2015 | ||
| olofk | What would it take to implement QEMU system emulation? Just a few peripheral devices (disk, stdio...) or a lot more stuff? | 09:01 |
|---|---|---|
| ams | i suspect that you wouldn't need that even .. | 09:15 |
| ams | to get basic stuff .. | 09:15 |
| ams | unless or uses non ide/ata/scsii stuff .. | 09:15 |
| ams | so prolly just the instructions and stuff | 09:16 |
| olofk | User mode presumably works, so the instructions should be in place I guess | 09:34 |
| stekern | olofk: for what cpu are you planning on adding QEMU system emulation? | 10:01 |
| ams | stekern: Ivory | 10:02 |
| stekern | as in http://en.wikipedia.org/wiki/Symbolics | 10:09 |
| stekern | ? | 10:09 |
| ams | ofcourse :-) | 10:09 |
| ams | i am infiltrating openrisc so that it becomes a modern ivory | 10:10 |
| stekern | ;) | 10:12 |
| stekern | "Symbolics Hardware Design Language" | 10:12 |
| stekern | interesting | 10:12 |
| ams | yeah, i have a copy of NS ... | 10:13 |
| ams | i've not been able to figure it out well though .. mostly since i am interested in other things | 10:13 |
| stekern | Symbolics is a bad choice of name, it's not google friendly | 10:14 |
| ams | nope | 10:14 |
| ams | what do you wanna know? | 10:14 |
| stekern | nothing in particular, just tried searching for some more info on NS | 10:15 |
| ams | ah, yeah .. no info on that .. | 10:15 |
| ams | https://archive.org/details/bitsavers_symbolicsItionSet_4540372 | 10:16 |
| ams | i've been thinking of reverse engineering the source code for NS | 10:24 |
| poke53282 | olofk: At the moment, the full system emulation doesn't support much. | 10:28 |
| poke53282 | I think only the terminal right now. | 10:28 |
| poke53282 | and network | 10:28 |
| poke53282 | https://github.com/bluecmd/or1k-qemu/commit/1cfca4421d26b8b02214c9cb3613967566feb18b | 10:30 |
| poke53282 | This patch adds virtio | 10:30 |
| poke53282 | blueCmd tried also to include ata. But I think, it didn't work. | 10:30 |
| poke53282 | So at the moment, QEMU runs with the rootfs compiled in the kernel. | 10:31 |
| poke53282 | If you are talking about full system emulation of course. | 10:32 |
| poke53282 | It would be nice a default memory map for the most important devices. | 10:32 |
| poke53282 | and to put that into QEMU | 10:33 |
| poke53282 | terminal and network are already fixed in all emulators. | 10:33 |
| ams | stekern: Design systems for VLSI circuits: logic synthesis and silicon compilation .. has some pictures .. | 10:35 |
| ams | stekern: page 65 ... | 10:35 |
| ams | 62 | 10:35 |
| poke53282 | olofk: ata is already a problem. or1ksim uses a controller (to support DMA in the long run) which is not supported by Linux. jor1k accesses directly the ATA part and communicates therefore only via PIO. | 10:37 |
| poke53282 | What I would suggest is to implement a default device memory map, which is close to jor1k. | 10:42 |
| olofk | poke53282: Maybe I should have asked first if system emulation would solve the problem with limited thread support and things like that, because that's what I'm looking for | 10:49 |
| olofk | I think we have a default memory map for OpenRISC somewhere. I have found it a few times | 10:51 |
| poke53282 | you man the or1ksim config? | 10:54 |
| poke53282 | and the dts file in the kernel sources. | 10:55 |
| poke53282 | s/man/mean/ | 10:55 |
| olofk | poke53282: No, it's a more comprehensive document | 10:55 |
| poke53282 | https://github.com/s-macke/jor1k/wiki/Technical-details#mapping-or-ram-and-devices | 10:56 |
| poke53282 | This is mine | 10:56 |
| poke53282 | system emulation does solve the limited thread problem. However the system emulation emulates only one core. | 10:57 |
| poke53282 | But it does not solve the two different TLBs we have in the system emulation under QEMU. | 10:57 |
| olofk | That's ok I guess. My main use would be bootstrapping system | 10:58 |
| poke53282 | This is kind of crazy. And I wonder everytime I see the source, how this works. | 10:58 |
| poke53282 | Linux internal memory mappings -> Openrisc HW TLB -> QEMU TLB. | 10:59 |
| poke53282 | And the QEMU TLB is larger than the Openrisc HW TLB. | 10:59 |
| poke53282 | olofk: It would be nice, if you can find this default memory map if it exists. | 12:26 |
| olofk | poke53282: Last time we tried to find it was here http://www.juliusbaxter.net/openrisc-irc/%23openrisc.2014-05-16.log.html :) | 12:35 |
| olofk | Which yielded the links http://opencores.org/websvn,filedetails?repname=orsoc_graphics_accelerator&path=%2Forsoc_graphics_accelerator%2Ftrunk%2Fdoc%2ForpsocSetup.pdf and http://opencores.org/forum,OpenRISC,0,4004 | 12:35 |
| olofk | But I can't find the real source | 12:35 |
| wallento | oh, yes, this makes absolute sense | 12:38 |
| wallento | especially as most of the deployed maps look quite similar | 12:38 |
| poke53282 | olofk: Thanks for the link. In the document Teh UART and the ethernet are at the right place | 13:20 |
| olofk | poke53282: Yeah, it looked like the jor1k map was a bit different than I'm used to | 13:25 |
| poke53282 | Is there something like an OpenRISC reference platform? | 13:25 |
| olofk | poke53282: ORPSoC? :) | 13:25 |
| poke53282 | Well, I took the or1ksim mapping and did the rest myself. | 13:25 |
| poke53282 | And what is the mapping for ORPSoC? | 13:25 |
| olofk | It's the one I just sent you | 13:27 |
| olofk | In the forum post juliusb says so at least | 13:27 |
| poke53282 | Suggestions: Let's just implement PCI. Problem solved | 13:27 |
| olofk | We have a PCI core. Haven't tried it myself, but I think it works | 13:28 |
| poke53282 | https://github.com/openrisc/orpsoc-cores | 13:29 |
| poke53282 | in which are the mappings saved? | 13:29 |
| olofk | Not sure what you mean | 13:30 |
| poke53282 | I don't think, that the hardware implementation downloads the pdf and looks up the device mappings itself. :) | 13:31 |
| olofk | Ah yes :) | 13:31 |
| poke53282 | in which file are the mappings saved? | 13:32 |
| poke53282 | Forgot a word in the question. | 13:32 |
| olofk | The OpenRISC-based systems in orpsoc-cores mostly define them in their wb_intercon.conf files | 13:32 |
| olofk | https://github.com/openrisc/orpsoc-cores/blob/master/systems/sockit/data/wb_intercon.conf | 13:32 |
| olofk | I've wanted for several years to implement sdb as well | 13:33 |
| poke53282 | I guess, the only thing we all agree is the UART at 0x90000000 | 13:34 |
| olofk | Yeah. That one's most imprtant | 13:35 |
| poke53282 | Unfortunately the pdf tells only, which device type belongs to which address, but doesn't go into detail. | 13:38 |
| poke53282 | IDE Controller ... Audio Controller .... | 13:38 |
| poke53282 | And it doesn't tell the interrupts. | 13:39 |
| _franck_ | we should specify this and provide a reference device memory map in our "official documentation" (which is ???) | 13:43 |
| olofk | Yes. We have been talking about making a new one for some time based on the older one | 13:43 |
| olofk | _franck_: The OpenCores wiki of course. It's full of fresh information now :) | 13:43 |
| poke53282 | This would be great. Unfortunately it won't help in providing a generic Linux kernel. If we put everything in the Linux dts file it is considered to be present. No probing of the device. | 13:44 |
| poke53282 | This is much easier with PCI and USB. | 13:45 |
| stekern | you can have a generic kernel, but with board specific dts | 13:45 |
| olofk | And sdb is supposed to fix this | 13:46 |
| poke53282 | sdb? | 13:46 |
| olofk | poke53282: It's what Alessandro talked about at last orconf | 13:47 |
| olofk | Software defined bus | 13:47 |
| poke53282 | Ahh, Ok | 13:47 |
| poke53282 | I had some funny effects with my kernel. I emulate a terminal keyboard and a hardware keyboard. Two different interrupts. If I forget to include the hardware keyboard, none of the keyboard works. | 13:50 |
| poke53282 | And interrupt is triggered, the kernel finds, that there are two interrupt tiggered, one of them is not tied to a device. | 13:51 |
| poke53282 | So what the kernel does is ignoring all interrupts. Even the one for a known device. | 13:51 |
| -!- FreezingDroid is now known as FreezingCold | 13:56 | |
| Me1234 | Seems that lists.openrisc.net is down | 14:06 |
| olofk | Me1234: Yep. all services on openrisc.net are down today | 14:06 |
| wallento | first sourceware, now openrisc.net, can't work like this ;) | 14:23 |
| olofk | Yeah, and closedcisc.com is down too | 14:27 |
| --- Log closed Wed Jan 28 00:00:16 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!