| cozy | Ìû | 00:29 |
|---|---|---|
| Action: Fallenou disactivated irq, removed anything not needed from the bios, uses uart with "force_sync" mode, flushes D-cache after each disable_mmu(); and it still crashes right after test n°1 | 01:58 | |
| Action: Fallenou going to sleep, will bang his head against the wall a bit more tomorrow on this | 02:04 | |
| Fallenou | n8 ! | 02:04 |
| kristianpaul | gn8 | 02:04 |
| wolfspraul | n8 | 02:05 |
| wolfspraul | sleep does magic, tomorrow you have a new idea :-) | 02:05 |
| wpwrak | writing an MMU must be as much fun as writing a compiler. the latter is quite traumatizing. for years after, your first thought on any program crashing/exhibiting a problem is that it must be a compiler bug. | 02:20 |
| wolfspraul | don't disturb his dreams | 02:26 |
| lekernel | Fallenou: simulate it... you can't see anything now | 10:01 |
| Fallenou | lekernel: is the HEAD of milkymist-ng functional ? | 13:13 |
| Fallenou | I would like to update my copy, to get the uart to simulate my minimalist bios | 13:13 |
| lekernel | yes, except sdram of course | 13:36 |
| Fallenou | ok thanks | 13:37 |
| lekernel | you can try to simulate it first (with the migen simulation extension) | 13:37 |
| lekernel | this involves fixing icarus though | 13:37 |
| Fallenou | I was planning on simulating it with Isim | 13:37 |
| Fallenou | so when I write something in the uart it will $display() it ? | 13:38 |
| lekernel | you can do more than that - redirect UART both ways to a PTY | 13:38 |
| Fallenou | hum nice but I can't do that with Isim, can I ? | 13:39 |
| Fallenou | I don't need to type anything so I think it's too much for what I need | 13:39 |
| lekernel | no, but fixing icarus would be nice to do anyway | 13:39 |
| Fallenou | if I can do without fixing Icarus it won't be in my todo list | 13:40 |
| Fallenou | I only need uart output | 13:40 |
| lekernel | besides being incompatible with migen, isim is proprietary and bloated | 13:40 |
| Fallenou | $display in Isim would be enough | 13:40 |
| Fallenou | I don't mind if it's proprietary, even if it kills kittens, I just need it to debug my code | 13:40 |
| GitHub169 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/SRkzIw | 14:04 |
| GitHub169 | [milkymist-ng/master] asmicon: move slot time to timing settings - Sebastien Bourdeauducq | 14:04 |
| Fallenou | to be more exact, I do mind if it's proprietary, I just don't want to spend too much time on something else than the mmu itself, just to focus. I will try to use tools that work today, if it's not enough I will try icarus but I first try with things that work today | 14:06 |
| lekernel | well, it seems to me that having excellent simulation tools is important for this task | 14:08 |
| lekernel | otherwise you'll just spend a lot of time with frustrating failing experiments on the hardware | 14:08 |
| Fallenou | I do simulations, don't worry, I test on hw when I'm confident that it could work because I've seen it working on the simulation | 14:11 |
| Fallenou | but sometimes I'm wrong and then I indeed lose time on the hw | 14:11 |
| Fallenou | and then I go back in simulation | 14:11 |
| lekernel | also, if you have the UART, the libc, etc. in the loop, it becomes quite a mess | 14:19 |
| lekernel | what simulations have you done so far? | 14:19 |
| stekern | or then you have one of those fun occasions where it works in simulation but not in hardware, even if you're doing the same thing in both | 14:19 |
| lekernel | stekern: if you don't use X, blocking assignment, or fancy asynchronous stuff, it shouldn't happen | 14:20 |
| lekernel | what often happens, though, is incomplete test coverage | 14:21 |
| Fallenou | what's self.rxtx.re ? | 14:21 |
| Fallenou | the .re | 14:21 |
| lekernel | means that the register has been written from the bus and the device (uart) should read it | 14:21 |
| stekern | if you're not hitting some synthesis specific bug, that could of course be determined with post-synthesis simulations | 14:22 |
| lekernel | Fallenou: have you done simulations for all possible cases of the pipeline control signals? | 14:22 |
| Fallenou | ok I need to add a display() there | 14:22 |
| Fallenou | lekernel: maybe not all but I generated 16 test cases, all are passing in simulation, none on hw | 14:22 |
| lekernel | Fallenou: what do you mean, "test case"? test program? | 14:23 |
| Fallenou | so I wanted to start on understanding why it fails | 14:23 |
| Fallenou | yes | 14:23 |
| lekernel | Fallenou: and do these programs generate all sorts of pipeline and bus timings? | 14:23 |
| lekernel | Fallenou: does the TLB work correctly in the presence of memory latency? | 14:23 |
| Fallenou | https://github.com/fallen/milkymist-mmu/blob/mmu/software/bios/mmu_test_gen.c | 14:23 |
| Fallenou | it's very minimalist test for the moment | 14:24 |
| Fallenou | it's just a combination of sw lw and nop | 14:24 |
| Fallenou | but I will add more in the future | 14:24 |
| Fallenou | with more instructions and combinations | 14:24 |
| Fallenou | but since those are not passing ... | 14:24 |
| lekernel | Fallenou: you don't only need to check instruction combinations. what's really important is the internal pipeline control signals. | 14:25 |
| Fallenou | 15:28 < lekernel> Fallenou: does the TLB work correctly in the presence of memory latency? < well in theory yes, I do mind the stall* signals | 14:25 |
| Fallenou | stall_x stall_m | 14:25 |
| lekernel | yes, but have you run simulations that show clearly that the whole CPU behaves correctly when those signals are asserted in the TLB? | 14:25 |
| lekernel | this would be the nr. 1 source of bugs imo | 14:26 |
| Fallenou | at first it was indeed a source of bug | 14:27 |
| Fallenou | but I think that now it's OK | 14:27 |
| Fallenou | I was getting different signal results if I was accessing an already cached data for example | 14:27 |
| lekernel | when you have a bug, that's usually because you have thought it was OK before :) | 14:27 |
| Fallenou | or if I was accessing a not already cached data | 14:27 |
| Fallenou | but now it's ok | 14:27 |
| lekernel | and? are you sure there are no such critters anymore? | 14:27 |
| Fallenou | well I must have missed something, since it's failing :) | 14:29 |
| Fallenou | so I am trying to get a more "close to real hw" simulation | 14:29 |
| Fallenou | to identify to issue | 14:29 |
| lekernel | e.g. you could have 4 test benches, each showing proper functionality under each combination of (stall_x, stall_m) | 14:29 |
| Fallenou | for example a simulation with uart and irq | 14:29 |
| wpwrak | Fallenou: does it fail at the "t" of the very first test ? or later ? | 14:52 |
| Fallenou | yes the t | 14:52 |
| Fallenou | it prints the t and nothing more | 14:53 |
| wpwrak | do the asm statements create loads/stores before or after them ? i.e., between the test code and disabling/enabling the MMU ? | 14:54 |
| Fallenou | before yes | 14:55 |
| Fallenou | well at first I did something like enable_mmu() generate_test(i, j); disable_mmu() | 14:55 |
| Fallenou | and to avoid code begin generated between enable_mmu() and the test | 14:56 |
| Fallenou | I merged the mmu activation inside the generate_test() | 14:56 |
| Fallenou | you can see the first 3 asm instructions of generate_test(i,j) are actually the mmu activation | 14:56 |
| wpwrak | but not the deactivation. maybe it's that ? | 14:56 |
| Fallenou | and 3 nops after that just in case | 14:56 |
| lekernel | are you sure the "for" loops don't generate load/stores? | 14:56 |
| Fallenou | lekernel: the code you are looking at is not running on the lm32, this code generates the test code | 14:57 |
| Fallenou | there is no loop in the real test code | 14:57 |
| Fallenou | wpwrak: let me see ! | 14:58 |
| wpwrak | stupid question: if you remove the enabling of the MMU, does the test run to completion (with 100% failure then) ? | 14:58 |
| Fallenou | ok no there is no code generated by compilater between the load/store of the test and the disable mmu | 14:59 |
| Fallenou | wpwrak: hum good question actually :p | 15:01 |
| Fallenou | let's do the test | 15:01 |
| wpwrak | and don't you need a clobber for r0, too ? | 15:01 |
| Fallenou | I never modify r0 :o | 15:01 |
| Fallenou | %0 means the first register | 15:01 |
| wpwrak | you xor it lot | 15:01 |
| Fallenou | r0 is always 0 | 15:01 |
| Fallenou | it's meant to be that way | 15:02 |
| wpwrak | ah, i see. so these are nops | 15:02 |
| Fallenou | yes :) | 15:02 |
| Fallenou | sorry | 15:02 |
| Fallenou | those nops are not needed in theory, I added them in a desperate attempt to make test pass | 15:03 |
| wpwrak | another thing to try would be to remove the stores. maybe your test is overwriting the program or such | 15:03 |
| wpwrak | hehe ;) | 15:03 |
| Fallenou | ok nice two tests to do | 15:03 |
| Fallenou | will do that | 15:03 |
| Fallenou | thanks ! | 15:03 |
| wpwrak | of course, in the end you'll find it's a comma missing somewhere or so. all the viciously complex bugs have a trivial cause :) | 15:04 |
| Fallenou | hehe I hope you're right =) | 15:05 |
| lekernel | this is running from flash, so a misplaced write could put the flash into "status" mode | 15:05 |
| Fallenou | oh ! | 15:06 |
| Fallenou | removing the three assembly lines that activate mmu makes the lm32 run through the test code like a charm | 15:06 |
| Fallenou | hum hum | 15:07 |
| wpwrak | good. so the basic structure is good. | 15:07 |
| wpwrak | now let's see what the stores do or don't | 15:08 |
| Fallenou | I was trying with only 1 test and no printf/puts, now I did with all the 15 tests and printf puts, it's writting "PASS" and so on | 15:10 |
| Fallenou | I removed almost all the bios | 15:10 |
| Fallenou | now it's just doing init_uart() dtlbtest(); while(1) puts("."); | 15:10 |
| wpwrak | (PASS) that is still without enabling the MMU ? | 15:10 |
| Fallenou | so I see my tests and then a lot of "....." | 15:11 |
| Fallenou | yes without MMU, tests are not very well designed | 15:11 |
| Fallenou | they pass even without mmu activated | 15:11 |
| wpwrak | sweet ;-) | 15:11 |
| Fallenou | hehe yes it's a serious issue | 15:11 |
| Fallenou | but if mmu is activated and they still pass it's a good news :) | 15:11 |
| Fallenou | but yes they should fail without mmu | 15:11 |
| wpwrak | or maybe the mmu senses the danger of failure and auto-activates to save you ;-) | 15:12 |
| wpwrak | oh. so something solved the troubles you've been having ? | 15:12 |
| Fallenou | it's not hard to correct the test anyway, not a big deal | 15:13 |
| wpwrak | but you're saying the test that used to crash/hang now doesn't ? | 15:14 |
| Fallenou | 16:17 < wpwrak> oh. so something solved the troubles you've been having ? < no, test "pass" without mmu, but if I uncomment the mmu activation it still crashes | 15:14 |
| wpwrak | ah, i see | 15:14 |
| Fallenou | yes test does not crash, but mmu is not activated | 15:14 |
| wpwrak | okay, let's see what happens if you enable the MMU but take out the stores | 15:15 |
| Fallenou | ok | 15:15 |
| Fallenou | ! | 15:16 |
| Fallenou | first test fails and the other pass | 15:17 |
| Fallenou | but mmu is still disactivated | 15:17 |
| Fallenou | oh wait | 15:17 |
| Fallenou | I did not update my test code ... | 15:17 |
| Fallenou | ok ! | 15:20 |
| Fallenou | so now, with mmu activated, no store, all test RUN, and FAIL | 15:21 |
| Fallenou | and no crash :) | 15:21 |
| Fallenou | good news ! | 15:21 |
| Fallenou | well I think ... | 15:21 |
| wpwrak | the noose around the bug's neck is tightening :) | 15:22 |
| Fallenou | hehe | 15:22 |
| Fallenou | so either the store is writting at a flash address | 15:22 |
| Fallenou | or it's writting to 0 or around | 15:22 |
| Fallenou | (because of the mmu doing a wrong translate) | 15:22 |
| wpwrak | can you make the MMU run but not change the address that gets sent on the bus ? | 15:22 |
| wpwrak | and perhaps write the translated address to a debug register where you could then look it up ? | 15:23 |
| Fallenou | when I say "mmu disactivated" | 15:23 |
| Fallenou | mmu is there, running, but it does not replace the virtual address by the physical one | 15:23 |
| lekernel | wpwrak: that's for this sort of thing that there's simulation... | 15:23 |
| wpwrak | ah, perfect. can you thus store the translated address in a debug register ? | 15:24 |
| lekernel | you can just print it :) | 15:24 |
| Fallenou | I could just add a CSR for that ! | 15:24 |
| wpwrak | lekernel: seems that he already tried simulation and didn't see the problem | 15:24 |
| wpwrak | Fallenou: yeah :) | 15:24 |
| lekernel | yes, but not with this program | 15:25 |
| Fallenou | with the same crt0.S and the same function running | 15:25 |
| Fallenou | but not the same path between the crt0.S and the function | 15:25 |
| Fallenou | but the assembly code of the test was the same | 15:25 |
| Fallenou | and in Isim it was working | 15:25 |
| Fallenou | it was writting to the correct physical addresses the correct values | 15:26 |
| Fallenou | for all tests | 15:26 |
| Fallenou | I added a display(); in soc.v when |frag_we is true to print address and value of stores | 15:26 |
| Fallenou | http://pastebin.com/4hs4eiY2 | 15:28 |
| Fallenou | this | 15:28 |
| Fallenou | ok now let's synthetise ... | 16:08 |
| Fallenou | hum hum | 17:17 |
| Fallenou | I run the tests with mmu disactivated, after a store word I do a rcsr %1, TLBDBG (to get the result of previous tlb lookup) | 17:18 |
| Fallenou | and it prints 0x48000000 | 17:18 |
| Fallenou | it should be 0x44000000 :o | 17:20 |
| Action: Fallenou goes back to simulation =( | 17:22 | |
| wpwrak | :) | 17:36 |
| Fallenou | first let's see if the new csr is working properly | 17:38 |
| Action: kristianpaul had crashed the soc before doing silly things inside the csr | 17:41 | |
| Action: Fallenou talking about csr inside lm32 | 17:42 | |
| kristianpaul | ah ! | 17:42 |
| kristianpaul | oh i need check that too ;) | 17:42 |
| Fallenou | hum the simple fact of adding the rcsr crashes the cpu :) | 18:15 |
| wpwrak | Fallenou: i thought that worked ? or how else did you obtain the 0x48000000 vs. 0x44000000 before ? | 18:30 |
| Fallenou | well on real fpga I get 0x48.... | 18:31 |
| Fallenou | on isim the cpu just stops working | 18:31 |
| Fallenou | doesn't make any sense | 18:32 |
| wpwrak | funny :) | 18:32 |
| wpwrak | they take turn in who gets to fail horribly | 18:33 |
| Fallenou | yes | 18:33 |
| Fallenou | maybe it's a bad idea to use the csr "0x1F" | 18:36 |
| wpwrak | why ? | 18:39 |
| Fallenou | dunno | 18:40 |
| Fallenou | will try with the tlbctrl | 18:41 |
| Fallenou | I was only using the wcsr on it, the rcsr is free | 18:41 |
| Fallenou | hehe, it works with another csr | 18:41 |
| wpwrak | wait .. 0x1f for csr_addr ? | 18:41 |
| Fallenou | yes | 18:41 |
| wpwrak | isn't that 4 bits ? | 18:41 |
| Fallenou | the csr id | 18:41 |
| wpwrak | 0x1f may overlap with USB (0xf aka 4'hf) | 18:42 |
| lekernel | that's a different sort of CSR | 18:43 |
| Fallenou | csr inside lm32 is on 5 bit | 18:43 |
| Fallenou | bits* | 18:43 |
| wpwrak | oh :) | 18:43 |
| Fallenou | I get non-aligned memory access ... hum hum ! | 18:43 |
| Fallenou | bbl after diner ! | 18:45 |
| Action: Fallenou is back | 19:12 | |
| Fallenou | I must have done somethign wrong with the rcsr stuff | 19:52 |
| wpwrak | probably. in the movies, the self-destruct mechanism always has a countdown. that seems to be missing here. | 19:55 |
| Fallenou | here you just need to execute a rcsr r11, TLBCTRL , and then count up to 0 and boom :) | 19:57 |
| wpwrak | actually, kristianpaul should be interested in your code. he's been looking for CSR reads with a side-effect. well, on the other CSR, but maybe some concepts can be shared :) | 19:59 |
| Fallenou | sure I would be happy to make his project crash ! | 20:01 |
| Fallenou | more seriously adding a csr seemed quite simple | 20:02 |
| Action: Fallenou wonders what's wrong | 20:02 | |
| kristianpaul | seemed ! | 20:02 |
| kristianpaul | thats what all we tought at first ;-) | 20:02 |
| stekern | famous last wrods ;) | 20:02 |
| wpwrak | if you don't read the TLBDBG, does it still crash ? i.e., is the problem in the CSR access or in storing the lookup result in TLBDBG ? | 20:05 |
| kristianpaul | any bad thing on this makefile http://pastebin.com/DV4kkSYA for getting can not find -lbase and annot find -lhal ? | 20:09 |
| lekernel | do you have those libs in $(MMDIR)/software/libbase or $(MMDIR)/software/libhal ? | 20:11 |
| kristianpaul | yes i do | 20:13 |
| kristianpaul | thats the odd thing.. | 20:13 |
| lekernel | and have they been compiled correctly? | 20:14 |
| lekernel | and built with the correct ar? | 20:14 |
| kristianpaul | let me check | 20:14 |
| Fallenou | wpwrak: if I don't do rcsr TLBCTRL it does not crash, if I do it : it crashes :/ | 20:19 |
| lekernel | Fallenou: what did you modify to add that csr? I can't find that patch in your commits ... | 20:20 |
| kristianpaul | noob question, do i need libhpdmc for something in a baremetal app that access sdram? | 20:24 |
| lekernel | if it's booting directly from flash (not through the bios), yes | 20:25 |
| lekernel | also note that executing from flash is slower than from the sdram | 20:25 |
| kristianpaul | do you have an eskelenton of an app execuded after bios load it too ram? | 20:27 |
| kristianpaul | or a simple c hello world should work i guess | 20:27 |
| lekernel | yes, there was the demo firmware | 20:27 |
| Fallenou | it's pused now | 20:27 |
| kristianpaul | where is it right now? :-) | 20:27 |
| kristianpaul | ah | 20:27 |
| Fallenou | https://github.com/fallen/milkymist-mmu/commit/8505b54f58a50aca182864b8b1d7f9840651ba68 | 20:28 |
| kristianpaul | ok i was ignoring this flash/sdram difference and here my suffering.. | 20:28 |
| kristianpaul | but what would be proper? let bios do initialization stuff | 20:28 |
| lekernel | yes | 20:28 |
| kristianpaul | then load the other app from serial/net and work on ready to use ram? | 20:28 |
| kristianpaul | ok | 20:29 |
| lekernel | here your suffering. poor kristianpaul :) | 20:29 |
| kristianpaul | haha | 20:29 |
| kristianpaul | take as note i used to exagerate a bit on my words ;) | 20:30 |
| sh4rm4 | Fallenou, you shouldnt mix printf with puts | 20:31 |
| sh4rm4 | glibc for example will sometimes mess up the order | 20:31 |
| Fallenou | here there is no difference | 20:32 |
| kristianpaul | hey but i stil can put that "other app" in the harcoded partition for FN and it should boot correct? | 20:32 |
| Action: kristianpaul dont want mess with net/serial boot right now | 20:32 | |
| lekernel | sh4rm4: weird - sometimes gcc replaces printf() with puts() | 20:33 |
| lekernel | when there are no format specifiers | 20:33 |
| sh4rm4 | indeed | 20:34 |
| sh4rm4 | i had the impression that puts uses write() while printf uses fwrite() | 20:34 |
| lekernel | Fallenou: are you aware that it would break if debug is disabled? | 20:34 |
| lekernel | https://github.com/fallen/milkymist-mmu/blob/8505b54f58a50aca182864b8b1d7f9840651ba68/boards/milkymist-one/rtl/lm32_include.v#L243 | 20:34 |
| wpwrak | Fallenou: and how about TLBDBG ? | 20:34 |
| Fallenou | wpwrak: I thought csr 0x1f was not safe to use (but maybe it is) so I use tlbctrl now | 20:35 |
| Fallenou | I removed tlbdbg (0x1f) to use tlbctrl | 20:35 |
| lekernel | Fallenou: ok. either way, there's a problem if the user disables CFG_DEBUG_ENABLED | 20:36 |
| Fallenou | oh yes | 20:37 |
| Fallenou | I should add something to force width 5 if mmu is enabled at synthesis time | 20:38 |
| GitHub35 | [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/6uYMqQ | 21:17 |
| GitHub35 | [milkymist-ng/master] asmicon: multiplexer (untested) - Sebastien Bourdeauducq | 21:17 |
| GitHub11 | [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/d47b564fad08eb5daeade79e752c42e0d14f2a89 | 21:19 |
| GitHub11 | [migen/master] corelogic/fsm: typo - Sebastien Bourdeauducq | 21:19 |
| lekernel | draft of the new SDRAM controller is complete... now leeet's fix a hundred bugs ... | 21:23 |
| Fallenou | hehe have fun ! | 21:23 |
| Action: lekernel scratches is head about the best testing strategy for this little mess | 21:25 | |
| kristianpaul | how it can be complete having bugs? :) | 21:45 |
| kristianpaul | ah, those bugs dont belong to the controller ! | 21:46 |
| mwalle | kristianpaul: yeah i some faster uart working, but that havent brought the boost i thought | 22:17 |
| mwalle | just got 50kbs on gdb | 22:17 |
| mwalle | one major problem is the async character of the uart, you have to use the LCM of the baud settings the ft2232 and mm can run at | 22:19 |
| mwalle | so without some redesign of the uart core youre stuck at 4mbps iirc | 22:20 |
| Fallenou | when the cpu "crashes" while doing the rcsr, I can see that wishbone D_STB_O and D_CYC_O are asserted, and stay asserted indefinitely, they never get acked (by D_ACK_I) | 22:46 |
| Fallenou | that must be the reason for the system hang | 22:46 |
| Fallenou | and D_ADR_O is 0xfffff004 (o_O ?) | 22:47 |
| wpwrak | Fallenou: maybe you can route such signals to LED1/LED2 (B16/A16) in hardware. that way, you can observe visually if they suddenly go DC | 22:57 |
| Fallenou | to check if it's the same issue on hw ? | 22:57 |
| Fallenou | I wonder why a rcsr starts a wishbone transaction | 22:57 |
| wpwrak | that too, in case you still have that problem. i thought of it more as a means to monitor activity. it's not uncommon that you can actually see an unusual pattern | 22:58 |
| wpwrak | like in the old days, you could hear from the FM interference if your home computer was stuck in a busy loop :) | 22:59 |
| Fallenou | hehe :) | 22:59 |
| Fallenou | actually I had such an experience, when I was scrolling in some software, it was disturbing the radio | 23:00 |
| wpwrak | (csr vs. wb) wasn't there an address length change ? at least this sounds like it "Fallenou> I should add something to force width 5 if mmu is enabled at synthesis time" | 23:00 |
| wpwrak | or are the two completely separate ? | 23:01 |
| Fallenou | the length we were talking about is the number of bits reserved for the csr id in lm32 opcode rcsr and wcsr | 23:01 |
| Fallenou | it's either 3 or 4 or 5 bits | 23:01 |
| Fallenou | and it's only inside lm32 design | 23:02 |
| Fallenou | it never goes out | 23:02 |
| Fallenou | it's internal registers | 23:02 |
| Fallenou | it has nothing to do with "CSR" on the SoC | 23:02 |
| wpwrak | hmm, then it's inded a bit mysterious | 23:02 |
| Fallenou | yes I just don't get it | 23:02 |
| wpwrak | FPGA-internal crosstalk ? :) | 23:02 |
| Fallenou | hehe I don't believe that | 23:02 |
| Fallenou | to I guess cpu is stuck because no one ACK the wishbone transaction | 23:05 |
| Fallenou | but why nobody acks it ? | 23:05 |
| Fallenou | does the wishbone arbiter check address boundaries ? | 23:06 |
| wpwrak | can you see if the WB transaction starts before or at the CSR ? | 23:07 |
| wpwrak | btw, do the two CSRs really have to have the same name ? that's horribly confusing | 23:08 |
| Fallenou | assign frag_slave_sel = (wishbonecon0_wishbone_adr_o[28:26] == 3'd0); | 23:08 |
| Fallenou | hum hum ! | 23:08 |
| Fallenou | indeed with 0xfffsomething it's hard | 23:08 |
| Fallenou | wpwrak: yes it's better to have a csr just for our debugging, I did that at first, and then seeing everything crashing I tried with an already existing one | 23:09 |
| Fallenou | I should go back to tlbdbg | 23:10 |
| Fallenou | so wtf is this 0xfffff004 now :o | 23:10 |
| wpwrak | (csr) i mean the buses - the one inside the core and the one outside. just imagine someone trying to learn about the architecture. they's go nuts trying to figure out all the contradictions in the documents. | 23:11 |
| wpwrak | can you see when the 0xfff... first appears on the bus ? | 23:12 |
| Fallenou | well there is the store word | 23:13 |
| Fallenou | and right after this transaction, another one begins (the wrong one) with D_ADR_O == 0xffff*** | 23:13 |
| wpwrak | so it's not related to the rcsr ? | 23:15 |
| Fallenou | in the pipeline you have nop nop nop sw nop rcsr nop lw | 23:15 |
| Fallenou | when the store is executing PC_m (program counter of memory stage) == 0x25C which is the address of the sw instruction | 23:18 |
| wpwrak | so at that point in time already some decoding of rcsr as happened ? what happens if you add a few more NOPs after this sw ? | 23:19 |
| wpwrak | (but not after any that may come before) | 23:19 |
| Fallenou | when the weird transaction starts PC_m == 0x26C | 23:19 |
| Fallenou | oh, this is the lw | 23:19 |
| Fallenou | ooook | 23:19 |
| Fallenou | that explains the wishbone access :) | 23:19 |
| wpwrak | ;-) | 23:19 |
| Fallenou | so this gives one point to lekernel | 23:20 |
| Fallenou | I just hit a case with weird pipeline signaling (with the rcsr) | 23:20 |
| Fallenou | so I just translate the address badly => 0xfffff004 | 23:21 |
| Fallenou | for my defense, it's totally weird, the load_q_m signal is not asserted ... it should be asserted while doing a load word :o | 23:22 |
| wpwrak | lame excuse :) | 23:25 |
| Action: Fallenou had to give it a try | 23:26 | |
| Fallenou | ok it's dcache_select_m fault, it just drops | 23:29 |
| Fallenou | leading to load_q_m not rising | 23:29 |
| Fallenou | arg ok the address is higher than max address cachable | 23:31 |
| Action: Fallenou head bangs against the wall again | 23:31 | |
| wpwrak | so you tried to load from an inaccessible virtual address ? | 23:34 |
| Fallenou | well I don't know what happened but the address_x signal gets the value 0xfffsomething | 23:35 |
| Fallenou | and I have set up max_dcache_addr == 0x7ffff... | 23:35 |
| Fallenou | so as soon as load_store_unit sees address_x >= max_dcache_addr, it unassert dcache_select_m and there is no load_q_m in dcache module | 23:36 |
| Fallenou | and no mmu translation | 23:36 |
| Fallenou | I'm wondering if we really need this max_dcache_addr, since we cache all the RAM | 23:36 |
| Fallenou | or maybe there is something memory mapped above the ram | 23:38 |
| Fallenou | oh yes ok :( | 23:38 |
| wpwrak | poor little bug. it was hiding to well. yet you still found it. | 23:41 |
| Fallenou | ok I got it ... | 23:41 |
| Fallenou | the asm code is wrong | 23:41 |
| Fallenou | totally wrong | 23:41 |
| Fallenou | I do rcsr r2, TLBCTRL and then lw r14, (r2+0) | 23:41 |
| Fallenou | so indeed if the rcsr returns shit, it will load from address "shit" | 23:42 |
| Fallenou | but why is r2 used ? I put a different %k register in the asm() statement | 23:42 |
| Fallenou | let me show you | 23:43 |
| wpwrak | hah. and that explains why the rcsr changed things | 23:43 |
| Fallenou | http://pastebin.com/G6fjFHfS | 23:44 |
| Fallenou | do you understand this ? | 23:44 |
| Fallenou | why does it put r2 for %1 and %3 ? | 23:44 |
| wpwrak | a bit odd indeed. i don't quite remember all the asm constraints, though. maybe there's some special case. lemme see ... | 23:46 |
| Fallenou | all the variables are "register unsigned int" | 23:47 |
| wpwrak | i think you need & | 23:48 |
| wpwrak | http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Modifiers.html#Modifiers | 23:48 |
| Fallenou | oh oh nice link | 23:51 |
| Fallenou | I just don't understand the sentences | 23:51 |
| Fallenou | so you say I just do "=&" ? | 23:51 |
| Fallenou | I should* | 23:52 |
| Fallenou | "=&r" | 23:52 |
| wpwrak | the basic assumption seems to be that "asm" is typically used for a single CPU instruction. so that "early clobber" would be something unusual. that's probably why it's not the default | 23:52 |
| wpwrak | yes, =& looks good | 23:53 |
| Fallenou | hum ok single cpu instruction | 23:53 |
| Fallenou | weird assumption :' | 23:53 |
| Fallenou | I tried with =&r for the tlb_lookup variable, it still generates only r2 register | 23:54 |
| wpwrak | when they started gcc, computer memory probably didn't have room for much more ;-) | 23:54 |
| wpwrak | grmbl | 23:54 |
| Fallenou | oh no it's ok | 23:54 |
| Fallenou | it's still using r2 for rcsr | 23:54 |
| Fallenou | but lw r14, (r14+0) | 23:54 |
| Fallenou | good good | 23:54 |
| wpwrak | good :) | 23:54 |
| Fallenou | awesoem, thanks ! | 23:55 |
| wpwrak | that would have been my next question :) | 23:55 |
| Fallenou | =) | 23:55 |
| Fallenou | ok so it simulates well now | 23:56 |
| Fallenou | no more cpu crash \o/ | 23:58 |
| wpwrak | kewl ! | 23:59 |
| Fallenou | time to go to bed | 23:59 |
| Fallenou | have to work tomorrow morning :' | 23:59 |
| --- Mon Mar 19 2012 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!