| --- Log opened Wed Nov 02 00:00:24 2016 | ||
| olofk | kc5tja: Good job. Great to see the progress | 02:40 |
|---|---|---|
| ZipCPU | kc5tja: Congrats, a lot of work must have gone into that documentation. | 07:08 |
| ZipCPU | What I still don't know and get, though, us what is "U-Mode" or how it differs from "M" mode? I've seen a lot of discussions on #riscv, but this question has just left me befuddled--perhaps because I've never read the privilege mode spec. | 07:09 |
| ZipCPU | I actually found the story of the kestrel the most interesting, "How did kestrel receive its name". | 07:09 |
| ZipCPU | Looks like you've been at this a while. | 07:09 |
| ZipCPU | Not certain what your end goal is, though. Is it the computer? The process of getting there? | 07:10 |
| kc5tja | ZipCPU: M-Mode = Machine Mode. In this mode, no address translation happens (even if enabled in mstatus register), since it's role is to serve as a kind of microcode interpreter for emulated instructions. Think PALcode for DEC Alpha processors. | 10:22 |
| kc5tja | ZipCPU: H-Mode = Hypervisor mode. We don't actually know what this mode is, because it's not yet been specified by anyone, RISC-V included. But it's reserved for that purpose, and lots of speculation treats it as a "more supervisor" mode than S-mode. | 10:22 |
| kc5tja | ZipCPU: S-Mode = Supervisor mode. This is our ring 0. | 10:23 |
| kc5tja | ZipCPU: U-Mode = User mode. This is our ring 3. This is the lowest privilege mode. | 10:23 |
| kc5tja | U- and S-mode both share the same address translation mechanism and run in the same address space (for now; there's talk about changing this in order to better support hypervisors in the future, but it's only talk at this point). | 10:24 |
| ZipCPU | Okay, that makes sense(now). A lot of sense in fact. | 10:24 |
| kc5tja | Back in v1.7 of the privilege architecture, if you wanted to make a single-mode processor, you had no choice but to make it an M-mode device. That's why Polaris is M-mode only now. | 10:24 |
| kc5tja | However, that really sucks from an "upward compatibility should be easy" point of view. | 10:25 |
| kc5tja | So I'm going to transition the processor to a U-mode only design, where the only operating mode on the chip is user-mode. | 10:25 |
| ZipCPU | Well, yeah, and what good is it to have an MMU that never gets enabled? | 10:25 |
| ZipCPU | But ... don't you need a non-address-translated mode, if for no other purpose than to set up address translations? | 10:26 |
| kc5tja | So when I upgrade to a later CPU design, I can rely on program traps to emulate missing features, use the MMU to fake the legacy Kestrel memory maps, etc. | 10:26 |
| kc5tja | Yes, it boots with MMU disabled. You don't *have* to use the MMU in lower modes. It's just that M-mode *never* uses the MMU. :) | 10:27 |
| ZipCPU | Ok, that makes more sense. | 10:27 |
| ZipCPU | I'm in the process of working an MMU into the ZipCPU design, and I was going to make two modes only: a user mode, where the MMU may or may not be enabled, and a supervisor mode where the MMU was always disabled. | 10:28 |
| ZipCPU | My work would go faster if cache integration were simpler. ;) Well, that and if I weren't chasing around other bugs. | 10:28 |
| ZipCPU | Today's work is chasing a bug in GCC. | 10:28 |
| kc5tja | That said, once enabled, S-mode and U-mode use the same MMU settings, even when handling a trap. This provides some isolation for the kernel as well as for the user-mode process too. | 10:29 |
| kc5tja | (Sorry, was with my wife for a bit) | 10:29 |
| ZipCPU | That's okay, my security officer likes to come visit and press keys on my keyboard with her jaw. (She's a German Shepherd) | 10:30 |
| ZipCPU | kc5tja: How does that work? A trap takes place, and you have the same MMU settings? | 10:30 |
| ZipCPU | Wouldn't you want to get a new setting to handle the trap? | 10:30 |
| kc5tja | ZipCPU: A two-mode design is still quite viable. If you implement an instruction like "SIE" in IBM S/370 mainframes, you actually don't even *need* any additional modes (supervisor included). | 10:30 |
| kc5tja | ZipCPU: Yep. stvec register has a virtual address, not a physical address. It works exactly as it does on x86 architecture, which also preserves translation when in ring 0. | 10:31 |
| kc5tja | You just need to remember to map kernel pages at the place where stvec points to. | 10:32 |
| kc5tja | This is why Linux on x86 can only address up to 2GB or 3GB of memory per process; that extra GB is reserved for the kernel. | 10:33 |
| kc5tja | I think Linux identity-maps that to the motherboard's physical memory map, but I could be wrong. | 10:33 |
| kc5tja | Not sure how BSD works. | 10:33 |
| kc5tja | To address additional memory, it just maps a small window to transfer data between user- and supervisor-mode memory regions. Hence why Linux has copy_from_user() functions to transfer buffers of data from user-mode into kernel-mode memory. | 10:34 |
| ZipCPU | Yeah, I thought I remember reading that Linux identity maps as well. | 10:34 |
| kc5tja | Now, there is talk about setting up separate supervisor and user mode page tables. | 10:35 |
| kc5tja | This treats supervisor mode as a completely independent process. | 10:35 |
| kc5tja | This would let the kernel access up to 4GB of memory (for 32-bit systems), *and* user processes access the same amount. | 10:35 |
| kc5tja | There's some talk that it's also easier on the TLB architecture as well. | 10:36 |
| kc5tja | Not sure if it'll happen though. | 10:36 |
| ZipCPU | At some point, it makes sense. It's just that ... whatever must handle page table misses (I assume that would be supervisor mode of some sort) must ... be able to load page tables from real memory addresses, not virtual addresses lest you get into a loop, right? | 10:36 |
| kc5tja | It might appear as an extension separate from the current privilege spec. | 10:36 |
| kc5tja | This is where machine-mode enters into the picture. | 10:37 |
| ZipCPU | Yes. | 10:37 |
| kc5tja | Typically, machine-mode is set up to accept a page fault, look at the source, determine that it's best handled by supervisor mode, then delegates it down the privilege stack. | 10:37 |
| kc5tja | But, if it happens *again*, without any acknowledgement from S-mode software that the previous trap has been properly handled, machine-mode knows that a loop likely happened, and can either reboot the machine (Intel "triple bus fault" style) or perform some other diagnostics. | 10:38 |
| kc5tja | But, if the kernel maps its pages correctly, this would not be a problem. | 10:39 |
| kc5tja | Anything that causes the kernel to deadlock on virtual memory would also cause a double fault as well, so in practice it's debugged pretty quickly. | 10:39 |
| ZipCPU | Key word "if" ... but I get your point. | 10:39 |
| kc5tja | Well, that's why we have privilege modes. :) | 10:39 |
| kc5tja | have three privilege | 10:39 |
| ZipCPU | "Debugged pretty quickly" doesn't mean "easy" to debug. That means there's just a *bunch* of angry customers insisting the fault get taken care of quickly. | 10:40 |
| kc5tja | Both M- and S-modes have mepc (exception PC) and mbadaddr (the address that caused the trap) and mcause (the reason for the trap) registers, so that at least points you at the faulting code directly. | 10:40 |
| ZipCPU | My favorite debug practice remains debug by printf. There are some CPU modes and faults that make that difficult. | 10:41 |
| kc5tja | mepc/sepc, mbadaddr/sbadaddr, etc. | 10:41 |
| kc5tja | It's entirely legal and accepted that an M-mode trap handler terminate in a set of printfs. I've done that plenty of times. :) | 10:41 |
| ZipCPU | Well, I have too ... but the usually the utility of those printf's is really in the context that was taking place, which is often lost in the trap. | 10:42 |
| ZipCPU | Pretty soon you have a debugger popping up with a list of registers and memory addresses that appears *quite* cryptic to all but the master programmers. | 10:43 |
| kc5tja | Such is the nature of event-driven programming in general, I'm afraid. Ask any node.js programmer how useful those stack traces are. | 10:43 |
| ZipCPU | Ok. Now I get to go back to debugging GCC. | 10:44 |
| RelaxAtion | Hello, I have a question, do you think it is possible to simulate entirely the OPENRISC based on a file *.elf? In order to be sure that it will work well on the hardware | 11:08 |
| SMDwrk | RelaxAtion: you can run mor1kx rtl on simulator with given file, is that what you need? | 11:10 |
| ZipCPU | RelaxAtion: Should be, but I've only done Verilator sims on bare metal simulations. Are you simulating within Linux? | 11:10 |
| RelaxAtion | Which is the procedure to run mor1kx rtl on the simulator? | 11:12 |
| RelaxAtion | Yes we are working on Linux | 11:12 |
| SMDwrk | in that case mor1kx-generic might not work, I guess | 11:12 |
| RelaxAtion | What is mor1kx-generic? | 11:13 |
| ZipCPU | That's why I asked. My own experience is with mor1kx-generic and bare metal, not Linux. | 11:14 |
| ZipCPU | mor1kx-generic is one of the "systems" available within orpsoc-cores. | 11:14 |
| ZipCPU | It is a "generic" system in that it isn't specific to any piece of hardware. | 11:14 |
| RelaxAtion | Ah ok | 11:14 |
| SMDwrk | RelaxAtion: fusesoc sim --sim=verilator mor1kx-generic --elf-load=<fullpathtoelf> | 11:14 |
| ZipCPU | Yeah, but SMDwrk, that only works for bare metal. | 11:14 |
| SMDwrk | sure | 11:14 |
| olofk | It might boot Linux | 11:14 |
| ZipCPU | Ah ... the voice of wisdom joins in. Thanks for joining the conversation olofk. | 11:15 |
| ZipCPU | I suppose if you were going to boot Linux, the full-path-to-elf file would need to be the name of the Linux kernel image, no? | 11:15 |
| olofk | It should, at least. Haven't tried in a while | 11:15 |
| olofk | Yes | 11:15 |
| olofk | To vmlinux | 11:15 |
| olofk | I/O is a bit of a problem though, since we haven't integrated the fantastic wbuart yet | 11:16 |
| olofk | But you can watch it boot :) | 11:16 |
| RelaxAtion | We are trying to simulate on bare metal my bad, I confused myself | 11:16 |
| ZipCPU | Well then that makes things easier. | 11:16 |
| olofk | RelaxAtion: You can even simulate the de0_nano system | 11:17 |
| RelaxAtion | That's what we are trying to do | 11:17 |
| RelaxAtion | But their is an issue in a file when we try it | 11:18 |
| olofk | fusesoc sim de0_nano --elf-load=/path/to/elffile | 11:18 |
| RelaxAtion | We try to use fusesoc Sim de0_nano | 11:18 |
| olofk | Does it work? | 11:19 |
| kc5tja | olofk: Since my CPU's bus is inspired by (but isn't compatible with) Wishbone, I was wondering if you had any suggestions for a name for it? Right now, I'm just calling it a "D port" bus since it's used to implement the D port for my CPU design. But, I think a better name is warranted. | 11:19 |
| RelaxAtion | No, their is an error in the file s25fl064p.v | 11:19 |
| kc5tja | olofk: Respond when you have bandwidth. :) | 11:20 |
| RelaxAtion | It says "unable to bind wire/reg/memory [...]" | 11:21 |
| olofk | kc5tja: furcula? Wishbone in latin :) | 11:21 |
| olofk | RelaxAtion: Can you give me the exact error message? Please use a paste service | 11:22 |
| kc5tja | olofk: Sounds like the name of a vampiric fursona would take. ;) | 11:22 |
| kc5tja | But I like it. Thanks! | 11:23 |
| olofk | kc5tja: I'll send an invoice for my two cents | 11:23 |
| olofk | kc5tja: By the way, I got a fortune cookie when I was in Mountain View this weekend that I think was really meant for you. It said "Go Forth and Open Source" :) | 11:24 |
| Relax_Ation | http://pastie.org/private/pinoft2livsnzfpbp7e5uw | 11:26 |
| Relax_Ation | is this good olofk ? | 11:26 |
| kc5tja | olofk: Hahah, YES. :) | 11:27 |
| kc5tja | olofk: You were in town and you didn't let me know? :( Could have had lunch! | 11:27 |
| olofk | kc5tja: Yeah, it was a busy schedule. Just popped over for the GSoC mentor summit. I'll definitely let you know when I'm back and have some more time | 11:28 |
| olofk | RelaxAtion: Strange... | 11:33 |
| olofk | I got another bug report recently, that might have been from one of the other CSAW people. Could it be that you have a really old Icarus? | 11:34 |
| olofk | What does iverlog -v say about the version? | 11:35 |
| olofk | iverilog | 11:35 |
| Relax_Ation | 9.7 | 11:35 |
| olofk | A bit old, but should work | 11:36 |
| Relax_Ation | we really don't understand where does this error come from | 11:36 |
| olofk | RelaxAtion: Can you check what you have in ~/.cache/fusesoc/s25fl064p-1.7/ | 11:39 |
| olofk | hmm... I can't connect to freemodelfoundry | 11:40 |
| Relax_Ation | their is only s25fl064p-1.7.v | 11:41 |
| olofk | Just to check that we got the same version of the file, can you run "sha256sum ~/.cache/fusesoc/s25fl064p-1.7/s25fl064p.v" and give me the hash | 11:43 |
| olofk | But I think you should try upgrading icarus anyway. That might be the root cause | 11:50 |
| Relax_Ation | is it hard to upgrade ? | 11:51 |
| olofk | You're on ubuntu, right? It's probably possible to find a newer package somewhere. I usually install from the git sources | 11:52 |
| olofk | gtg | 11:52 |
| Relax_Ation | ok thank you :) | 11:52 |
| olofk | https://github.com/olofk/fusesoc/blob/master/doc/migrations.adoc | 17:33 |
| olofk | Waiting for pull requests :) | 17:34 |
| olofk | Just finished my latest blog post on IP-XACT http://olofkindgren.blogspot.com/2016/11/ip-xact-good-bad-and-outright-madness.html | 19:40 |
| kc5tja | olofk: Just skimmed your blog article, and it looks fairly interesting. I'm particularly interested in using IP-XACT for register mapping, ironically. Just to keep the docs and the Verilog in sync. | 19:59 |
| kc5tja | (since CSRs are the most likely to change from generation to generation) | 20:00 |
| --- Log closed Thu Nov 03 00:00:25 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!