| wolfspraul | wow, so nice to see the mmu documentation evolving | 00:35 |
|---|---|---|
| kristianpaul | lekernel_: this looks like a proper way get 5 bit csr support for you http://fpaste.org/NwrP/raw/ ? | 04:42 |
| kristianpaul | s/proper/upstream | 04:51 |
| Fallenou | cladamw: hey :) | 08:45 |
| Fallenou | very good news ! | 08:45 |
| Fallenou | So R4 is finished finished ? | 08:46 |
| cladamw | Fallenou, hi just design files( sch, routes, gerber files) | 08:46 |
| Fallenou | so it's ready for manufacturing ? :) | 08:47 |
| cladamw | they are done from altium design version not KiCad. :-) | 08:47 |
| Fallenou | sure, for now only schematics are done in KiCad, right ? | 08:48 |
| cladamw | yes, also includes footprints in KiCad is also done. | 08:48 |
| Fallenou | awesome | 08:49 |
| cladamw | (initial done) for KiCad, since no one has given feedback or review so far. if more one to review that is very welcome. | 08:50 |
| Fallenou | unfortunately I don't have any skill in schematics/routing, sorry :' | 08:51 |
| cladamw | btw, m1r4's footprints are very common to use in other projects though. Take those footprints if you like or to modify or maybe fix potential bug. :-) | 08:51 |
| cladamw | not sure how many people use Fped to generate footprints now. :-) | 08:52 |
| Fallenou | what is Fped ? *excuse my ignorance* | 08:53 |
| cladamw | (footprint editor, Fped) designed/contributed by Werner: http://projects.qi-hardware.com/index.php/p/fped/ | 08:54 |
| cladamw | (footprints) and all parts of m1r4's Fped footprints are collected under: http://projects.qi-hardware.com/index.php/p/kicad-libs/source/tree/master/modules | 08:57 |
| Jia | hi all, I think I've fixed the lm32-gcc bug. | 08:59 |
| Fallenou | \o/ | 08:59 |
| Fallenou | congratz ! | 08:59 |
| Jia | and I'll send the patch to gcc-patches this night. | 08:59 |
| Fallenou | what was the bug about ? I didn't follow this thread | 08:59 |
| Fallenou | great :) | 08:59 |
| Jia | the mov pattern | 08:59 |
| Fallenou | is there a bug tracking ticket somewhere about this , | 09:00 |
| Jia | Fallenou: you are working on? | 09:00 |
| Fallenou | I am working on the MMU | 09:00 |
| Jia | MMU is reallllllllllllllllllllllllllllllllly a complex thing! | 09:01 |
| Fallenou | I'm trying to make a simple one :) | 09:01 |
| Fallenou | simple that works fine ! | 09:01 |
| Jia | is IMMU and DMMU speratelly? | 09:02 |
| Fallenou | ITLB and DTLB are separate yes | 09:02 |
| Fallenou | a few informations about the mmu design : https://github.com/fallen/milkymist-mmu/wiki/Documentation-of-milkymist-mmu | 09:03 |
| Fallenou | I am using gcc to test the mmu (modifying Milkymist BIOS) | 09:04 |
| Fallenou | so if there is gcc bugs I feel concerned :p | 09:04 |
| Jia | clang is cool! both gcc and llvm is good to me. I'm one of the offical llvm developer :-) | 09:05 |
| Fallenou | oh nice :) | 09:05 |
| Fallenou | we are trying to get rid of using gcc here because we have very few support from gcc | 09:05 |
| Jia | when I working on QEMU-OpenRISC, I find, MMU is really complex. | 09:06 |
| Fallenou | and gcc is hard to understand/patch | 09:06 |
| Fallenou | so clang is really much appreciated :p | 09:06 |
| Jia | gcc's code is mess..... | 09:06 |
| Fallenou | yes =( | 09:06 |
| Fallenou | oh you did the OpenRISC model in qemu ? | 09:06 |
| Jia | QEMU is very stickly right now, my V8 patches is still some problem... | 09:07 |
| Fallenou | MMU can be a very complex thing, especially when you add tons of features in it | 09:08 |
| Fallenou | here I am trying to do one that does the minimum needed features | 09:08 |
| Fallenou | to keep it efficient and simple | 09:08 |
| Jia | simple is nice. | 09:09 |
| Fallenou | so basically translation of virtual address to physical ones using a TLB translation cache | 09:09 |
| Fallenou | exception generation when TLB miss | 09:09 |
| Fallenou | and (to be done) check for permissions (read, write, execute) | 09:09 |
| Fallenou | and maybe a dirty bit thing but it's not yet clear in my head | 09:10 |
| Fallenou | and that's basically all | 09:10 |
| Fallenou | no hardware page walker for instance | 09:10 |
| lekernel_ | the devil is in the details :) | 09:10 |
| Fallenou | sure :) | 09:10 |
| lekernel | Jia: cc me on the gcc patch | 09:10 |
| Jia | lekernel: OK | 09:11 |
| Jia | lekernel: and, may I get to know how did you make clang support lm32 directly? :D | 09:14 |
| lekernel | main commit is this one: https://github.com/milkymist/clang-lm32/commit/ddbd2d49c5cfc2ec56da676a74a9cdc6d6611806 | 09:16 |
| lekernel | then I just renamed "mico32" into "lm32", otherwise clang was looking for tools named mico32-elf-ld etc. | 09:17 |
| Jia | is offical clang have this feature? | 09:19 |
| Jia | and, sbourdeauducq make this change? | 09:19 |
| Action: Jia can using clang instead gcc in my work! | 09:20 | |
| lekernel | no, it's not merged yet (neither is lm32 support) | 09:20 |
| lekernel | i'm sbourdeauducq | 09:20 |
| Jia | you should summit this to clang-commits! It is very cool! | 09:21 |
| Jia | lekernel: and, when you summit it to clang-commits, I'll ping for you :-) | 09:26 |
| stekern | yeah, I agree, I find the notion of a baremetal toolchain useful as well (i've been thinking about cherry-pick it into clang-or1k ;)) | 09:31 |
| Jia | lekernel: your email? | 14:04 |
| Jia | sebastien AT milkymist.org is OK? | 14:11 |
| lekernel | yes, got it... thanks! | 14:20 |
| lekernel | kristianpaul: looks quite ok, except that you probably need to fix the address slice in csrbrg too. but why not just use -ng? | 14:26 |
| kristianpaul | lekernel: to be honest but not offesive of course, i think ng besides the memory improvement is over eng effort | 15:55 |
| kristianpaul | and just offer me another layer of posible trouble besides verilog machine generated code :) | 15:55 |
| kristianpaul | i would not mind at first automate the arbiter generation for example | 15:56 |
| kristianpaul | using makefiles or some more basic scripting... | 15:57 |
| wpwrak | that's often the more expedite approach: handle the highly structured generation task in a script that you feed with the interface definitions (signal names or whatever), then include the result in the rest of your program | 16:01 |
| lekernel | kristianpaul: and you know, of course, that with migen your messy change would be a 1-line patch for the whole system, right? | 16:02 |
| wpwrak | e.g., you see very few people write C/C++ preprocessors these days. it's much more common to just generate a few .c/.h files and use these | 16:02 |
| wpwrak | (of course, verilog has an awkward preprocessor, which diminishes its value) | 16:04 |
| kristianpaul | lekernel: yes i know | 16:24 |
| Fallenou | wpwrak: reading your email ! | 17:19 |
| Fallenou | wpwrak: you wrote about IE because IE has a lot of unused bits I could use as a status and control register for *TLB ? | 17:24 |
| wpwrak | IE because it is already saved in this sort of context. and yes, it has a lot of unused bits, too :) | 17:25 |
| Fallenou | ok good idea | 17:25 |
| Fallenou | wpwrak: what you call X.USR is whether we are in the kernel or user land ? | 17:31 |
| wpwrak | yes, 0 for kernel/supervisor (i.e., CSR unrestricted), 1 for user (i.e., CSR restricted) | 17:33 |
| Fallenou | ok | 17:33 |
| Fallenou | so basically the switch_to_kernel/user_mode function of TLBCTRL CSR would be moved to IE CSR | 17:34 |
| Fallenou | which has the nice backup/restore feature | 17:34 |
| wpwrak | yup, that's the idea. may make things easier than having to tweak a number of other CSR registers | 18:00 |
| larsc | we could really use a mode flag for the IE register even for non-mmu mode. right now we have to emulate this using a global variable | 18:04 |
| larsc | which is kind of tedious, because you have to pay carefull attention to race condtions | 18:04 |
| larsc | careful | 18:05 |
| larsc | I always write all these -ful and al- words with two l's, that's kind of annoying | 18:06 |
| wpwrak | a kernel mode flag ? or a disable/enable interrupt flag ? | 18:06 |
| Fallenou | kernel mode flag I think | 18:06 |
| larsc | kernel/user mode flag | 18:08 |
| larsc | yes | 18:08 |
| larsc | and opencores has it too in non-mmu mode, iirc | 18:09 |
| Fallenou | wpwrak: about the last comment of your email, you mean making sure legacy code that used to play with IE csr don't overwrite/drop TLB flags ? | 18:09 |
| wpwrak | almost every architecture has some supervisor/kernel mode. i'm a bit surprised LM32 doesn't have it already. | 18:10 |
| wpwrak | Fallenou: yes. plus, be able to control IE.IE without having to worry about the TLB | 18:10 |
| larsc | oh and access to the csr register should be disabled in user mode | 18:11 |
| larsc | registers | 18:11 |
| Fallenou | usually when you modify a CSR, you read it first in an unsigned int, then you modify and you write it back | 18:11 |
| wpwrak | at least writes | 18:11 |
| Fallenou | larsc: sure | 18:11 |
| Fallenou | so you should never lose TLB flag in IE if you touch IE.ie | 18:11 |
| larsc | wpwrak: I wouldn't worry too much about legacy applications | 18:12 |
| larsc | we are not intel ;) | 18:13 |
| Fallenou | +1 | 18:14 |
| wpwrak | larsc: well, it's just painful if you introduce quirks :) | 18:16 |
| Fallenou | it's not quirk, it's normal that if you modify a CSR you don't overwrite flags | 18:17 |
| Fallenou | you just read it, |= / &= and write it back | 18:17 |
| Fallenou | all legacy code should have done it this way | 18:17 |
| wpwrak | nasty surprises could include a "supervisor mode" bit which, if you clear it by accident, disables access to the CSRs. that would send you bug-hunting for a while :) | 18:19 |
| larsc | how much legacy code is there? | 18:20 |
| Fallenou | rtems code/flickernoise code | 18:20 |
| Fallenou | and actual linux port | 18:20 |
| Fallenou | indeed current milkymist bios code does irq_enable(0); and irq_enable(1); without reading IE :x | 18:24 |
| Fallenou | but it's easily fixable | 18:24 |
| Fallenou | (irq_enable() being declared in https://github.com/milkymist/milkymist/blob/master/software/include/base/irq.h) | 18:24 |
| larsc | if the mode bit is 1 = usermode, 0 = kernel, this shouldn't be a problem, should it? | 18:26 |
| Fallenou | it should be fine I guess | 18:28 |
| Fallenou | would you see a special exception vector for page persmission exception ? | 18:28 |
| Fallenou | or a unique exception for both TLB miss and page permission ? | 18:29 |
| Fallenou | unique exception vector* | 18:29 |
| larsc | no idea, to be honest | 18:30 |
| wpwrak | having a separate vector would help to keep the TLB refill path short | 18:32 |
| wpwrak | the TLB miss handler may basically look like this: | 18:33 |
| wpwrak | uint32_t *p = page_table[addr >> 22]; | 18:33 |
| wpwrak | if (!p) goto fault; | 18:34 |
| wpwrak | p = (uint32_t *) page_table[(addr >> 12) & 0x3ff]; | 18:34 |
| wpwrak | if (!p) goto fault; | 18:35 |
| wpwrak | TLBPADDR = p; | 18:35 |
| wpwrak | TLVADDR = virt; | 18:35 |
| wpwrak | do_update_magic; | 18:35 |
| wpwrak | return; | 18:35 |
| wpwrak | so if you don't need to check permissions at all, that helps | 18:36 |
| Fallenou | ok ! | 19:08 |
| Fallenou | fair enough | 19:08 |
| --- Wed Jul 11 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!