IRC logs for #openrisc Wednesday, 2016-11-02

--- Log opened Wed Nov 02 00:00:24 2016
olofkkc5tja: Good job. Great to see the progress02:40
ZipCPUkc5tja: Congrats, a lot of work must have gone into that documentation.07:08
ZipCPUWhat 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
ZipCPUI actually found the story of the kestrel the most interesting, "How did kestrel receive its name".07:09
ZipCPULooks like you've been at this a while.07:09
ZipCPUNot certain what your end goal is, though.  Is it the computer?  The process of getting there?07:10
kc5tjaZipCPU: 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
kc5tjaZipCPU: 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
kc5tjaZipCPU: S-Mode = Supervisor mode.  This is our ring 0.10:23
kc5tjaZipCPU: U-Mode = User mode.  This is our ring 3.  This is the lowest privilege mode.10:23
kc5tjaU- 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
ZipCPUOkay, that makes sense(now).  A lot of sense in fact.10:24
kc5tjaBack 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
kc5tjaHowever, that really sucks from an "upward compatibility should be easy" point of view.10:25
kc5tjaSo 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
ZipCPUWell, yeah, and what good is it to have an MMU that never gets enabled?10:25
ZipCPUBut ... don't you need a non-address-translated mode, if for no other purpose than to set up address translations?10:26
kc5tjaSo 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
kc5tjaYes, 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
ZipCPUOk, that makes more sense.10:27
ZipCPUI'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
ZipCPUMy work would go faster if cache integration were simpler.  ;)  Well, that and if I weren't chasing around other bugs.10:28
ZipCPUToday's work is chasing a bug in GCC.10:28
kc5tjaThat 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
ZipCPUThat'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
ZipCPUkc5tja: How does that work?  A trap takes place, and you have the same MMU settings?10:30
ZipCPUWouldn't you want to get a new setting to handle the trap?10:30
kc5tjaZipCPU: 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
kc5tjaZipCPU: 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
kc5tjaYou just need to remember to map kernel pages at the place where stvec points to.10:32
kc5tjaThis 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
kc5tjaI think Linux identity-maps that to the motherboard's physical memory map, but I could be wrong.10:33
kc5tjaNot sure how BSD works.10:33
kc5tjaTo 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
ZipCPUYeah, I thought I remember reading that Linux identity maps as well.10:34
kc5tjaNow, there is talk about setting up separate supervisor and user mode page tables.10:35
kc5tjaThis treats supervisor mode as a completely independent process.10:35
kc5tjaThis would let the kernel access up to 4GB of memory (for 32-bit systems), *and* user processes access the same amount.10:35
kc5tjaThere's some talk that it's also easier on the TLB architecture as well.10:36
kc5tjaNot sure if it'll happen though.10:36
ZipCPUAt 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
kc5tjaIt might appear as an extension separate from the current privilege spec.10:36
kc5tjaThis is where machine-mode enters into the picture.10:37
kc5tjaTypically, 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
kc5tjaBut, 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
kc5tjaBut, if the kernel maps its pages correctly, this would not be a problem.10:39
kc5tjaAnything 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
ZipCPUKey word "if" ... but I get your point.10:39
kc5tjaWell, that's why we have privilege modes.  :)10:39
kc5tjahave three privilege10: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
kc5tjaBoth 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
ZipCPUMy favorite debug practice remains debug by printf.  There are some CPU modes and faults that make that difficult.10:41
kc5tjamepc/sepc, mbadaddr/sbadaddr, etc.10:41
kc5tjaIt'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
ZipCPUWell, 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
ZipCPUPretty 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
kc5tjaSuch 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
ZipCPUOk.  Now I get to go back to debugging GCC.10:44
RelaxAtionHello, 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 hardware11:08
SMDwrkRelaxAtion: you can run mor1kx rtl on simulator with given file, is that what you need?11:10
ZipCPURelaxAtion: Should be, but I've only done Verilator sims on bare metal simulations.  Are you simulating within Linux?11:10
RelaxAtionWhich is the procedure to run mor1kx rtl on the simulator?11:12
RelaxAtionYes we are working on Linux11:12
SMDwrkin that case mor1kx-generic might not work, I guess11:12
RelaxAtionWhat is mor1kx-generic?11:13
ZipCPUThat's why I asked.  My own experience is with mor1kx-generic and bare metal, not Linux.11:14
ZipCPUmor1kx-generic is one of the "systems" available within orpsoc-cores.11:14
ZipCPUIt is a "generic" system in that it isn't specific to any piece of hardware.11:14
RelaxAtionAh ok11:14
SMDwrkRelaxAtion: fusesoc sim --sim=verilator mor1kx-generic --elf-load=<fullpathtoelf>11:14
ZipCPUYeah, but SMDwrk, that only works for bare metal.11:14
olofkIt might boot Linux11:14
ZipCPUAh ... the voice of wisdom joins in.  Thanks for joining the conversation olofk.11:15
ZipCPUI 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
olofkIt should, at least. Haven't tried in a while11:15
olofkTo vmlinux11:15
olofkI/O is a bit of a problem though, since we haven't integrated the fantastic wbuart yet11:16
olofkBut you can watch it boot :)11:16
RelaxAtionWe are trying to simulate on bare metal my bad, I confused myself11:16
ZipCPUWell then that makes things easier.11:16
olofkRelaxAtion: You can even simulate the de0_nano system11:17
RelaxAtionThat's what we are trying to do11:17
RelaxAtionBut their is an issue in a file when we try it11:18
olofkfusesoc sim de0_nano --elf-load=/path/to/elffile11:18
RelaxAtionWe try to use fusesoc Sim de0_nano11:18
olofkDoes it work?11:19
kc5tjaolofk: 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
RelaxAtionNo, their is an error in the file s25fl064p.v11:19
kc5tjaolofk: Respond when you have bandwidth.  :)11:20
RelaxAtionIt says "unable to bind wire/reg/memory [...]"11:21
olofkkc5tja: furcula? Wishbone in latin :)11:21
olofkRelaxAtion: Can you give me the exact error message? Please use a paste service11:22
kc5tjaolofk: Sounds like the name of a vampiric fursona would take.  ;)11:22
kc5tjaBut I like it.  Thanks!11:23
olofkkc5tja: I'll send an invoice for my two cents11:23
olofkkc5tja: 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_Ationis this good olofk ?11:26
kc5tjaolofk: Hahah, YES.  :)11:27
kc5tjaolofk: You were in town and you didn't let me know?  :(  Could have had lunch!11:27
olofkkc5tja: 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 time11:28
olofkRelaxAtion: Strange...11:33
olofkI 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
olofkWhat does iverlog -v say about the version?11:35
olofkA bit old, but should work11:36
Relax_Ationwe really don't understand where does this error come from11:36
olofkRelaxAtion: Can you check what you have in ~/.cache/fusesoc/s25fl064p-1.7/11:39
olofkhmm... I can't connect to freemodelfoundry11:40
Relax_Ationtheir is only s25fl064p-1.7.v11:41
olofkJust 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 hash11:43
olofkBut I think you should try upgrading icarus anyway. That might be the root cause11:50
Relax_Ationis it hard to upgrade ?11:51
olofkYou're on ubuntu, right? It's probably possible to find a newer package somewhere. I usually install from the git sources11:52
Relax_Ationok thank you :)11:52
olofkWaiting for pull requests :)17:34
olofkJust finished my latest blog post on IP-XACT
kc5tjaolofk: 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 2.15.2 by Marius Gedminas - find it at!