IRC logs for #openrisc Tuesday, 2015-01-27

--- Log opened Tue Jan 27 00:00:15 2015
olofkWhat would it take to implement QEMU system emulation? Just a few peripheral devices (disk, stdio...) or a lot more stuff?09:01
amsi suspect that you wouldn't need that even ..09:15
amsto get basic stuff ..09:15
amsunless or uses non ide/ata/scsii stuff ..09:15
amsso prolly just the instructions and stuff09:16
olofkUser mode presumably works, so the instructions should be in place I guess09:34
stekernolofk: for what cpu are you planning on adding QEMU system emulation?10:01
amsstekern: Ivory10:02
stekernas in
amsofcourse :-)10:09
amsi am infiltrating openrisc so that it becomes a modern ivory10:10
stekern"Symbolics Hardware Design Language"10:12
ams yeah, i have a copy of NS ...10:13
amsi've not been able to figure it out well though .. mostly since i am interested in other things10:13
stekernSymbolics is a bad choice of name, it's not google friendly10:14
amswhat do you wanna know?10:14
stekernnothing in particular, just tried searching for some more info on NS10:15
amsah, yeah .. no info on that ..10:15
ams i've been thinking of reverse engineering the source code for NS10:24
poke53282olofk: At the moment, the full system emulation doesn't support much.10:28
poke53282I think only the terminal right now.10:28
poke53282and network10:28
poke53282This patch adds virtio10:30
poke53282blueCmd tried also to include ata. But I think, it didn't work.10:30
poke53282So at the moment, QEMU runs with the rootfs compiled in the kernel.10:31
poke53282If you are talking about full system emulation of course.10:32
poke53282It would be nice a default memory map for the most important devices.10:32
poke53282and to put that into QEMU10:33
poke53282terminal and network are already fixed in all emulators.10:33
amsstekern: Design systems for VLSI circuits: logic synthesis and silicon compilation .. has some pictures ..10:35
amsstekern: page 65 ...10:35
poke53282olofk: 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
poke53282What I would suggest is to implement a default device memory map, which is close to jor1k.10:42
olofkpoke53282: 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 for10:49
olofkI think we have a default memory map for OpenRISC somewhere. I have found it a few times10:51
poke53282you man the or1ksim config?10:54
poke53282and the dts file in the kernel sources.10:55
olofkpoke53282: No, it's a more comprehensive document10:55
poke53282This is mine10:56
poke53282system emulation does solve the limited thread problem. However the system emulation emulates only one core.10:57
poke53282But it does not solve the two different TLBs we have in the system emulation under QEMU.10:57
olofkThat's ok I guess. My main use would be bootstrapping system10:58
poke53282This is kind of crazy. And I wonder everytime I see the source, how this works.10:58
poke53282Linux internal memory mappings -> Openrisc HW TLB -> QEMU TLB.10:59
poke53282And the QEMU TLB is larger than the Openrisc HW TLB.10:59
poke53282olofk: It would be nice, if you can find this default memory map if it exists.12:26
olofkpoke53282: Last time we tried to find it was here :)12:35
olofkWhich yielded the links,filedetails?repname=orsoc_graphics_accelerator&path=%2Forsoc_graphics_accelerator%2Ftrunk%2Fdoc%2ForpsocSetup.pdf and,OpenRISC,0,400412:35
olofkBut I can't find the real source12:35
wallentooh, yes, this makes absolute sense12:38
wallentoespecially as most of the deployed maps look quite similar12:38
poke53282olofk: Thanks for the link. In the document Teh UART and the ethernet are at the right place13:20
olofkpoke53282: Yeah, it looked like the jor1k map was a bit different than I'm used to13:25
poke53282Is there something like an OpenRISC reference platform?13:25
olofkpoke53282: ORPSoC? :)13:25
poke53282Well, I took the or1ksim mapping and did the rest myself.13:25
poke53282And what is the mapping for ORPSoC?13:25
olofkIt's the one I just sent you13:27
olofkIn the forum post juliusb says so at least13:27
poke53282Suggestions: Let's just implement PCI. Problem solved13:27
olofkWe have a PCI core. Haven't tried it myself, but I think it works13:28
poke53282in which are the mappings saved?13:29
olofkNot sure what you mean13:30
poke53282I don't think, that the hardware implementation downloads the pdf and looks up the device mappings itself. :)13:31
olofkAh yes :)13:31
poke53282in which file are the mappings saved?13:32
poke53282Forgot a word in the question.13:32
olofkThe OpenRISC-based systems in orpsoc-cores mostly define them in their wb_intercon.conf files13:32
olofkI've wanted for several years to implement sdb as well13:33
poke53282I guess, the only thing we all agree is the UART at 0x9000000013:34
olofkYeah. That one's most imprtant13:35
poke53282Unfortunately the pdf tells only, which device type belongs to which address, but doesn't go into detail.13:38
poke53282IDE Controller ... Audio Controller ....13:38
poke53282And 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
olofkYes. We have been talking about making a new one for some time based on the older one13:43
olofk_franck_: The OpenCores wiki of course. It's full of fresh information now :)13:43
poke53282This 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
poke53282This is much easier with PCI and USB.13:45
stekernyou can have a generic kernel, but with board specific dts13:45
olofkAnd sdb is supposed to fix this13:46
olofkpoke53282: It's what Alessandro talked about at last orconf13:47
olofkSoftware defined bus13:47
poke53282Ahh, Ok13:47
poke53282I 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
poke53282And interrupt is triggered, the kernel finds, that there are two interrupt tiggered, one of them is not tied to a device.13:51
poke53282So what the kernel does is ignoring all interrupts. Even the one for a known device.13:51
-!- FreezingDroid is now known as FreezingCold13:56
Me1234Seems that is down14:06
olofkMe1234: Yep. all services on are down today14:06
wallentofirst sourceware, now, can't work like this ;)14:23
olofkYeah, and is down too14:27
--- Log closed Wed Jan 28 00:00:16 2015

Generated by 2.15.2 by Marius Gedminas - find it at!