lekernel | wpwrak: yeah, yeah, continue being sarcastic. meanwhile, linux/x11 don't work while rtems/mtk do (also using cooperative multitasking for the UI by the way) | 09:26 |
---|---|---|
lekernel | done in a more messy way than with lua coroutines even | 09:27 |
lekernel | I agree that it won't work in the general case, it's enough here. | 09:29 |
lekernel | s/it's/but it's | 09:29 |
lekernel | also 100% of the linux UIs are shitty, so it has to be NIH. so why the bickering? :) | 09:29 |
Fallenou | NIH = ? | 09:32 |
Fallenou | not invented here ? | 09:32 |
lekernel | mwalle: not much difference, simply using the migen CSR bank generator | 09:33 |
lekernel | Fallenou: yes | 09:33 |
lekernel | http://en.wikipedia.org/wiki/Not_invented_here | 09:33 |
Fallenou | thx | 09:33 |
Fallenou | about MMU, I thought we did not want to check for page permissions ? | 09:48 |
Fallenou | do we add 3 permission bits ? (read write execute) ? | 09:48 |
lekernel | execute definitely not - the way to make something executable or not is by mapping it or not in the itlb | 09:49 |
lekernel | read/write yes | 09:50 |
Fallenou | ok | 09:50 |
lekernel | wpwrak: why do you want to track the _page_'s dirty status? | 10:02 |
lekernel | I assume you meant the associated cache lines, which makes sense for a write back cache... | 10:02 |
GitHub131 | [milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/95a82041432f573319c9fa7fc57b0ac15243948f | 10:18 |
GitHub131 | [milkymist/master] softusb: interrrupt support for navre - Michael Walle | 10:18 |
Fallenou | it seems the cache is behaving correctly right now, it's part of the test "detest" | 11:30 |
Fallenou | I map a->a, I write 42 to a, I read back from a, I write 43 to b, I map a->b, I read back from a, and it reads 43 , not 42 | 11:31 |
Fallenou | and without any cache flush | 11:34 |
lekernel | when writing, you are reading the TLB, then sending the write directly and immediately on the bus, right? | 11:35 |
Fallenou | yes I did not change the way the cache works | 11:39 |
Fallenou | it's still write through | 11:39 |
Fallenou | it's written both on the bus and in the cache at the same time | 11:40 |
Fallenou | tlb does its lookup when the instruction is still in the X stage | 11:40 |
Fallenou | so that when the instruction reaches the M stage, the tlb lookup is already done and ready | 11:41 |
Fallenou | just like the cache in fact | 11:41 |
lekernel | how do you inhibit the write into the cache on a TLB miss? | 11:43 |
lekernel | (you'll see... itlb will be easier ;) read only, no permission bits, ...) | 11:45 |
Fallenou | 13:50 < lekernel> how do you inhibit the write into the cache on a TLB miss? < I can't see where it's done in the code so I guess it's not done and it's a bug :) I will test that ! thanks for pointing that out | 11:46 |
Fallenou | I would just do something like assign write_port_enable = ((refill_ready == `TRUE) || !stall_m) && ~dtlb_miss; | 11:47 |
Fallenou | (add the && ~tlb_miss) | 11:47 |
Fallenou | there https://github.com/fallen/milkymist-mmu/blob/mmu/cores/lm32/rtl/lm32_dcache.v#L569 | 11:47 |
lekernel | the problem is the write is already done when the TLB data becomes available | 11:58 |
lekernel | maybe the solution would be to revert the write on a TLB miss | 11:58 |
lekernel | or invalidate the whole cache line | 11:58 |
wpwrak | lekernel: (dirty) it's for swapping, rw-mapping files, and so on. the memory manager needs to know when a page has changed so that it only has to write things that have actually changed. | 11:59 |
lekernel | if you want to implement #1, it is possible to configure block-RAMs so that they output the previous data on a write | 11:59 |
lekernel | you just have to describe it in the verilog, and the synthesizer will (usually) do the right thing | 11:59 |
wpwrak | lekernel: you can assume all pages are dirty, but i'd expect this to be pretty inefficient | 11:59 |
Fallenou | yes I've seen that in Xst doc | 11:59 |
lekernel | just do whatever is easier... since you have to run slow software on a TLB miss, the performance gain of #1 over #2 is negligible | 12:01 |
wpwrak | lekernel: (nih) i'm a bit surprised you suddenly see a need to go in a new direction with the underlying OS. linux infrastructure is coming along nicely, so why spend now weeks on reinventing the ROM BASIC ? | 12:01 |
lekernel | maybe you could even modify the cache control system to let the software invalidate individual lines | 12:01 |
Fallenou | I think it should be pretty easy to allow invalidating cache lines | 12:02 |
Fallenou | it's already possible to invalidate just one TLB line | 12:02 |
lekernel | would save you the pain of implementing the little stall cpu/multiplex cache control/invalidate line sequencer in hardware | 12:02 |
wpwrak | (NIH) and RTEMS seems give little enough trouble at the moment that there doesn't seem to be a pressing need to abandon it in a hurry | 12:02 |
lekernel | wpwrak: one of the points is also to evaluate LLVM, and building RTEMS with clang is messy | 12:03 |
lekernel | not because of LLVM but because of autocrap | 12:03 |
Fallenou | I guess a CC=clang isn't enough ? :) | 12:03 |
lekernel | with my last clang patch, in theory it should be enough... except you also need -ccc-host-triple lm32-elf in the cflags | 12:04 |
wpwrak | i have my hopes set on autocrap behaving a little better on linux. at least the OS environment will be known. but yes, autocrap will be more visible on linux. | 12:04 |
lekernel | and autocrap is all about prefixing tool names (e.g. lm32-elf-xxxx), not passing the arch in the cflags | 12:05 |
lekernel | so much for something meant to make software portable ... | 12:05 |
lekernel | wpwrak: calling it a "rom basic" is a bit like calling a ferrari a renault 4L | 12:09 |
lekernel | besides, I'm not reinventing much - it's a lot of libs and copy and paste - except stuff like the graphics/rendering toolkit which is non-existent in linux anyway | 12:10 |
stekern | lekernel: do you need the -ccc-host-triple if you make a symlink called lm32-elf-clang? | 12:12 |
lekernel | maybe not... but I like the -ccc-host-triple. having one compiler per architecture while >80% of the code is shared is stupid. | 12:14 |
lekernel | wpwrak: is the javascript in your browser a rom basic as well? :) | 12:16 |
stekern | well, it still the same compiler with all the targets compiled in. i.e. lm32-elf-clang == clang -ccc-host-triple lm32 | 12:16 |
stekern | you can still run clang -ccc-host-triple mips if you like | 12:17 |
lekernel | sure. but why keep the gcc legacy, except for supporting inane tools like autocrap? | 12:17 |
lekernel | besides I'm pretty sure there will be other problems | 12:17 |
stekern | oh, yes, probably | 12:18 |
lekernel | Fallenou: I kinda like the software cache line invalidation. otherwise you need to mux cache access, stall the CPU, etc. | 12:30 |
lekernel | more LUTs, more delay (ie less MHz), more complexity, more probablity of nasty bugs | 12:31 |
lekernel | if you implement the per-line invalidation, maybe you can even remove the current mechanism that invalidates the whole cache (it's just a counter + sequencer) | 12:33 |
lekernel | you could do that counter in software. not sure how slow it will be compared to the hardware counter, though. | 12:33 |
wpwrak | (rom basic) i mean as a simple language that's "hardwired" into the platform | 12:38 |
lekernel | take it as an additional means of doing modifications | 12:39 |
wpwrak | and the silly javascript in my brower is that i rarely have to worry about it, let alone write a libc for it ;-) | 12:39 |
lekernel | the rest of the software is still open source, and you are free to modify it - if you feel like installing a toolchain, recompiling, etc. | 12:40 |
lekernel | also, lua allows you not to worry about things like memory management, annoying C string manipulations, etc. | 12:41 |
Fallenou | if it's working correctly I think it's best to keep the hardware implementation for invalidating the whole cache | 13:18 |
Fallenou | it's really more efficient | 13:18 |
wpwrak | i'm not against lua. one can probably learn it in a day. | 13:19 |
Fallenou | but yes OK I will add a way to invalidate just one cache line, I will need to be smart to multiplex CSR though :) it's a scarce resource | 13:19 |
wpwrak | i just find it odd that you write your own operating system around it | 13:19 |
Fallenou | I'm already doing different things whether you rcsr or wcsr with the same CSR ID | 13:20 |
Fallenou | rcsr dtlbvaddr gives you the virtual address of latest page fault, wcsr dtlbvaddr writes to the dtlb_vaddress_reg register which is used to set up a mapping | 13:20 |
Fallenou | or to invalidate a line | 13:20 |
Fallenou | in the rcsr dtlbvaddr case I defined an alias "dtlbma" (dtlb miss address) to "dtlbvaddr" in binutils in order to keep source code readability | 13:21 |
lekernel | Fallenou: when you write to DCC, you give a register no? | 13:21 |
lekernel | iirc the value is ignored atm | 13:22 |
Fallenou | afaik yes the value is ignored | 13:22 |
lekernel | you can say that if bit 31 is set, then it only invalidates one line determined by the other bits in that reg | 13:22 |
Fallenou | a simple write is enough to trigger invalidation | 13:22 |
Fallenou | hum that breaks software compatibility but ok | 13:22 |
lekernel | who cares | 13:22 |
Fallenou | ok =) | 13:23 |
Fallenou | I'm already using that kind of trick for DTLBCTRL csr | 13:23 |
lekernel | and iirc software uses r0 atm, so it wouldn't even break | 13:23 |
Fallenou | if bit 31 is set it's targetting DTLB, if not it's targetting ITLB | 13:23 |
lekernel | maybe "DTLBCTRL" is a ill-chosen name then :) | 13:37 |
Fallenou | it's TLBCTRL actually | 13:42 |
lekernel | good | 13:43 |
Fallenou | to help spot problems with the MMU, in parallel of writting "hard written" test sequences, I will implement a few commands to directly play with the MMU from the bios prompt | 14:53 |
Fallenou | like "map", "invalidate" | 14:54 |
Fallenou | memory read and memory write are already implemented afaik | 14:54 |
Fallenou | so that one can directly try a scenario by just entering a few commands | 14:54 |
Fallenou | to check if it's supported or behaving correctly :) | 14:54 |
Fallenou | like write there, map this, read back there, invalidate this etc etc | 14:55 |
Fallenou | it won't spot tricky timing problems, but will spot big implementation problems :) | 14:55 |
Fallenou | cache coherency and such | 14:55 |
wpwrak | sounds reasonable | 14:56 |
Fallenou | and quick to implement : | 14:57 |
Fallenou | :) | 14:57 |
Fallenou | helpful and quick | 14:57 |
wpwrak | you may want to do cached and uncached reads and maybe even writes, so that you can also set up or test unusual situations | 14:57 |
Fallenou | wpwrak: I think I may not have understood all your emails about page dirty and such, I may ask you some questions about it later ^^ | 14:58 |
wpwrak | sure :) | 14:58 |
Fallenou | thx | 14:58 |
wpwrak | my memory on those things is a bit dated. i looked into paging quite a bit when i implemented "zero-copy" for ATM, but that was about 16 years ago | 15:00 |
Fallenou | aouch | 15:11 |
Fallenou | I was still drinking milk | 15:11 |
wpwrak | linux was still in its infancy back then as well ;-) | 15:24 |
lekernel | I remember running your LILO on my 486 :) | 15:28 |
Fallenou | wpwrak: you are the original author of LILO ? | 15:45 |
wpwrak | Fallenou: yup :) | 15:59 |
Fallenou | ohoh I used it too :p but not on my 486 ^^ | 16:02 |
GitHub186 | [milkymist-ng] sbourdeauducq pushed 3 new commits to master: http://git.io/y_bdnA | 17:46 |
GitHub186 | [milkymist-ng/master] software/base/limits.h: add some more - Sebastien Bourdeauducq | 17:46 |
GitHub186 | [milkymist-ng/master] base/stdlib.h: abs/labs - Sebastien Bourdeauducq | 17:46 |
GitHub186 | [milkymist-ng/master] software/libbase: qsort - Sebastien Bourdeauducq | 17:46 |
GitHub45 | [misp] sbourdeauducq pushed 2 new commits to master: http://git.io/_baF6w | 17:53 |
GitHub45 | [misp/master] liblua/Makefile: cleanup - Sebastien Bourdeauducq | 17:53 |
GitHub45 | [misp/master] Add Freetype - Sebastien Bourdeauducq | 17:53 |
kristianpaul | hmm, do we have framwbuffer already? | 18:24 |
kristianpaul | http://paste.debian.net/172848/ | 18:27 |
kristianpaul | missing a file to push in clang ? | 18:28 |
lekernel | hmm I believe it should have been built from ./tools/clang/include/clang/Basic/DiagnosticSerializationKinds.td | 18:32 |
kristianpaul | hmm | 18:33 |
kristianpaul | i'll start over again just in case | 18:33 |
kristianpaul | but clang in build inside llvm right? | 18:42 |
lekernel | yes | 18:42 |
lekernel | you should put the clang sources in a directory called "clang" in llvm/tools | 18:42 |
kristianpaul | yup right there it is | 18:44 |
GitHub196 | [misp] sbourdeauducq pushed 1 new commit to master: http://git.io/fdp-cw | 18:57 |
GitHub196 | [misp/master] Define properly the Freetype config - Sebastien Bourdeauducq | 18:57 |
--- Tue Jun 5 2012 | 00:00 |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!