Saturday, 2022-01-08

bee[m]I think it works? Hi all :)02:45
tplatenI had a quick look at the load misalign code, store is more complicated here.17:02
tplatenBut I first think how to implement load 8 bytes at *mis*-aligned address which is NOT within the page.17:05
lkclit is17:26
lkclok that's the one that has to throw a pagefault17:27
lkcli am currently adding mmu test5 to show it17:27
lkcl(git pull)17:27
lkclwhat is currently happening is that a LDST pagefault is occurring on the *first* of the requests, which should not be happening17:29
lkcltplaten: test_loadstore1_mmu_test5 is working fine except DAR is 0x3a0005 not 0x3a000018:08
lkcltest 05:store PTE @ 0000000000013cf8 => c00000000000b186 FAIL 3 DAR=00000000003a0005 DSISR=000000004000000018:08
lkclthat's because the MMU_LOOKUP going to the MMU is a request to look up the PTE for 0x3a0005 (which it should be doing)18:09
lkclbut i don't quite understand why the rounding-down is not being reported18:10
lkcli mean, like, i can't even find any evidence in mmu.vhdl or loadstore1.vhdl of the rounding that's clearly occurring!18:11
lkclhmmm this is really tricky18:18
*** tplaten <tplaten!> has left #libre-soc18:25
lkclahh i think it might not matter19:08
* lkcl started re-running linux-5.7 2 hours ago after adding misaligned LDs (not STs)20:29
lkclso far no 0x600 exception20:29
lkclalriiiight, that fixed it20:54
lkcldtb entry ibm,architecture-vec-5 was successfully found20:54
lkclso it's a linux kernel bug and/or a... something-to-do-with-0x600 bug20:54
lkclperhaps DAR is not being set correctly or something20:55
lkclshould now progress to setting up the radix mmu20:55
octaviuslkcl, now that you asked me to document my code, I'm embarrassed to admit I finally understand Resources, ASICPlatform, and how the HDL just sees standard peripheral names (and not caring about the IO pads)21:09
lkclit was intended so that you could write HDL for any FPGA21:11
lkclno need to know or care about21:11
lkclwhat the HDL is actually running on21:11
lkclwe are simply going, "well, we don't care that it's an ASIC"21:11
lkcl[    0.000000] radix-mmu: Mapped 0x0000000000000000-0x0000000000600000 with 2.00 MiB pages (exec)21:16
lkcl[    0.000000] radix-mmu: Mapped 0x0000000000600000-0x0000000010000000 with 2.00 MiB pages21:16
lkclcurrently initialising those pages to zero21:16
octaviusHow long does that take?21:17
lkclwhich sounds perfectly reasonable but21:17
lkclooo maybe... about half an hour to an hour?21:17
octaviusWhy can't you just create an empty area of memory to begin with? Or is this part of the boot process that must be simulated?21:18
lkclit's executing i think... 1,000 instructions per second?21:20
lkcldang, the python-based simulator i think is quicker than that21:21
octaviuslkcl, I'm looking at your JTAG wireup example on the docs/pinmux page, and I'm not sure these two are correct:21:44
octaviusm.d.comb += uart.tx.eq(utx.pad.i) # transmit JTAG to pad21:44
octaviusm.d.comb += utx.pad.o.eq(uart.rx) # pass rx to JTAG21:44
octaviusLooks to me like it should be the other way round (pad.o is an output, so connects to tx)21:44
lkcluart is the function that generates the signal.  therefore, uart.tx is the driver21:45
lkclso yes, wrong way round21:46
octaviusOk, I'll fix the doc21:46

Generated by 2.17.1 by Marius Gedminas - find it at!