| lkcl | doh missed tlbsync and wait as well | 00:05 |
|---|---|---|
| lkcl | this is the kind of thing that save/restore of verilator state won't help with unfortunately | 00:08 |
| lkcl | adding these extra instructions even as NOPs drastically alters the HDL, which in turn alters the c++ simulation, and wark | 00:09 |
| lkcl | if i could extract (and restore) registers and memory and the D-Cache/I-Cache TLB entries that might do the trick | 00:10 |
| lkcl | off we go agaaaain... | 00:10 |
| programmerjake | just noticed a lot of the bitmanip ops have fields for RA, RB, and RC, but not RT...even though a lot don't need 3 inputs, but they all need an output | 04:19 |
| programmerjake | | NN | RA | RB | RC | 0 | 01 | 0010 110 |Rc| grev | | 04:19 |
| programmerjake | added todos to the wiki, can be fixed later | 04:33 |
| lkcl | argh i'm going to have to deal with mis-aligned LD/STs. | 14:15 |
| lkcl | although the linux kernel is catching 0x600 there's no guarantee it's doing the right thing. | 14:15 |
| lkcl | because 0x600 is supposed to be for page-faulting misalignments | 14:15 |
| programmerjake | run a program under linux and test it...maybe easier than adding support | 15:47 |
| lkcl | it's interfering with running the diffs | 15:48 |
| lkcl | there's several hundred. | 15:48 |
| lkcl | for now i'm going to assume they're successful | 15:48 |
| lkcl | diff is exiting, it can't cope with the size of the files | 15:48 |
| programmerjake | can you disable unaligned memory access on microwatt? | 15:49 |
| programmerjake | try cmp...it's binary diff | 15:51 |
| programmerjake | it may work better on large files | 15:51 |
| lkcl | i'd need to do a full rebuild of the linux kernel and of buildroot | 15:52 |
| programmerjake | i meant disable in the vhdl...to see if linux does sw unaligned access emulation and so you get identical instruction traces | 15:54 |
| lkcl | ah yeah interesting | 15:54 |
| programmerjake | specifically w/o rebuilding linux | 15:54 |
| lkcl | it's a good idea - likely to take me a long time though | 15:55 |
| lkcl | the state machine in loadstore1.vhdl is quite complex | 15:55 |
| programmerjake | ask paul, he likely would know if there's an easy way to disable it...tho you'd have to wait for him to wake up and he may still be on vacation | 15:56 |
| lkcl | yes he's not back until at least the 3rd week of january. | 15:56 |
| programmerjake | maybe ask on irc, see if anyone knows | 16:00 |
| programmerjake | hmm, afaict if you change https://github.com/antonblanchard/microwatt/blob/7fa7b45faa17950de44591f7a73722fdf8a87385/loadstore1.vhdl#L440 to just check misaligned, it'll likely always generate misaligned exceptions (except for lq, the logic for that is right underneath) | 16:07 |
| programmerjake | seems worth trying imho | 16:07 |
| lkcl | yeah | 16:08 |
| lkcl | ok diff has actually worked, let me review it | 16:08 |
| programmerjake | lkcl also, when you have time, can you review and add funding to https://bugs.libre-soc.org/show_bug.cgi?id=745#c53 | 16:14 |
| lkcl | it's on a different grant, which has been approved, but i need to find time to write the Schedule A (milestones) and then NLnet need to approve it | 16:14 |
| lkcl | use the crypto from bee for now | 16:15 |
| programmerjake | k | 16:15 |
| programmerjake | oh, also, idk if you saw, but bee joined irc via matrix, tho iirc he was having some issues with decred's matrix server connecting to libera's server | 16:17 |
| lkcl | yes i saw | 16:17 |
| * lkcl waves to bee[m] | 16:17 | |
| programmerjake | so he may not be able to talk/see anything | 16:18 |
| lkcl | yeah you have to register on libera in order to be able to talk | 16:19 |
| lkcl | otherwise it's a perfect way for spammers to flood thousands of channels | 16:19 |
| programmerjake | i sent him a link to the irclog for your messages via PM, just in case he can't see anything still | 16:22 |
| programmerjake | hmm, when i tried creating a new test matrix acct, it worked for talking on #libre-soc:libera.chat iirc | 16:24 |
| programmerjake | webchat i know works without registering | 16:24 |
| programmerjake | https://web.libera.chat/ | 16:25 |
| lkcl | yes, but you can't talk. | 16:30 |
| lkcl | (not unless you use a nick that you have registered) | 16:30 |
| lkcl | bee stopped using email, and the libera registration i believe requires an email address. | 16:31 |
| lkcl | no email address, no registration. no registration, no talking. | 16:31 |
| programmerjake-i | hi | 16:32 |
| lkcl | email is the base Lowest Common Denominator | 16:33 |
| *** programmerjake-i <programmerjake-i!~programme@2600:6c54:7600:34a:7c06:2439:7e6e:cc27> has left #libre-soc | 16:34 | |
| programmerjake | @lkcl ^ unregistered person talking via webchat | 16:34 |
| lkcl | ah interesting | 16:34 |
| lkcl | ok so that's not it | 16:34 |
| programmerjake | maybe it is it, but libera just whitelists their own webchat and matrix.org accounts, bee's account is at decred.org instead | 16:36 |
| lkcl | ahh | 16:37 |
| lkcl | ah ha! | 17:00 |
| lkcl | + wr @ 000b37a1 do fffffff800000000 sel f0 ........ | 17:00 |
| lkcl | - wr @ 000b37a1 do fffffff8ffffffff sel f0 ........ | 17:00 |
| lkcl | drat, nope, the lower bits ffffffff are masked-out | 17:01 |
| lkcl | not helping to have that in the diffs, though | 17:04 |
| lkcl | mhrrrrmm... i'm noticing a lot of cache misses, and found that i'd halved the number of lines in a cache | 17:11 |
| lkcl | nuts | 17:11 |
| lkcl | that could be mis-matching against the devicetree settings i-cache-block-size = <64>; | 17:12 |
| lkcl | etc | 17:12 |
| lkcl | programmerjake, oh btw i thought of a potential thing to test in python | 17:14 |
| lkcl | variable = "fred"; """the docstring comment""" | 17:14 |
| lkcl | notice the semicolon :) | 17:14 |
| lkcl | took me a while to think that one through, but i think it's a nice compromise | 17:16 |
| lkcl | if it works | 17:16 |
| programmerjake | hmm, vscode may autoformat that to be on separate lines...in which case that'd be a no-go cuz I'm not trying to work around my autoformatter | 17:16 |
| programmerjake | i have it set to autoformat on save | 17:16 |
| lkcl | deep joy :) | 17:16 |
| lkcl | ha, apparently, just put a space after it? | 17:17 |
| lkcl | https://stackoverflow.com/questions/61391472/how-to-remove-warning-about-unnecessary-semicolon-in-visual-studio-code | 17:17 |
| lkcl | cache line size increased | 17:19 |
| programmerjake | it's not linting that i have an issue with (cuz every other line of our code triggers a lint for me anyway --- our code's a mess), it's the autoformatter maybe automatically converting 1 line to 2 lines | 17:19 |
| * lkcl rerunning dtbImage, only 1 hour to go :) | 17:19 | |
| * lkcl waves to tplaten | 17:29 | |
| * lkcl currently running the dtbImage.microwatt image under microwatt-verilator with a libresoc (external) core, external_core_top.v | 17:30 | |
| lkcl | 672,000 instructions executed so far in the past 5 or so minutes, there are another 12.5 million to go | 17:31 |
| lkcl | i have doubled the size of dcache and icache LINE_SIZE | 17:32 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=11489454be1aef4cee4970e50ebf6133492363a6 | 17:33 |
| lkcl | which means it *should* now properly match against the devicetree entries in microwatt.dts | 17:33 |
| octavius | lkcl, I had thoughts about the I/O bank muxing block. I drew a diagram of the single I/O mux block, and how this block can be chained together to increase number of banks. Uploaded it here (will modify and upload to the wiki later as required): https://ibb.co/F8s6BkF | 17:34 |
| octavius | I'm guessing that the block is insufficient because the bank select signal can't be driven the JTAG BS chain | 17:36 |
| lkcl | yyeah this is the bit that's tricky. | 17:39 |
| lkcl | yes, the bank-select will have to be its own special JTAG shift-register | 17:40 |
| octavius | Luckily, only the bank select signals need to be hooked in, as the inputs/outputs can be tested by driving the functions | 17:40 |
| lkcl | but first, before even hooking it into JTAG, we need a GPIO mux system *at all* - one that has absolutely nothing to do with JTAG whatsoever | 17:42 |
| lkcl | and it needs to be controllable via "CSRs", which then are addressable on a wishbone bus | 17:42 |
| lkcl | which involves i think nmigen-stdio (or wherever CSRs are defined) | 17:43 |
| lkcl | the problem is, none of this is properly documented. | 17:43 |
| lkcl | you have to *infer* how to set up and use the CSRs to create wishbone-memory-mappable peripherals, by reading the source code of e.g. lambdasoc | 17:44 |
| lkcl | (!) | 17:44 |
| lkcl | but yes, the muxing block (top left) looks good | 17:45 |
| lkcl | when doing the registers, it's really important to bear in mind that each GPIO setting has to be in the same 8-bit memory-mapped register | 17:49 |
| lkcl | as in: that should be an atomic operation | 17:49 |
| lkcl | the last thing you want is to have to write 8 bits of memory to set the pin direction | 17:50 |
| lkcl | then *another* 8 bits to set the IO bank 0 1 2 3 4 5 6 or 7 | 17:50 |
| lkcl | this would cause output (or input) glitches | 17:50 |
| octavius | So one CSR for both directions, and bank select? | 17:51 |
| lkcl | not quite | 17:52 |
| lkcl | more that when you select the wires which go to the thing-that-sets-direction and thing-that-sets-bank-select | 17:52 |
| lkcl | they *must* come from the same byte, for each of the IO pads | 17:53 |
| lkcl | you can't have IO pad GPIO5 being direction-set from byte 2 of a CSR | 17:53 |
| lkcl | but its bank-select from byte 1 | 17:53 |
| lkcl | it *has* to be *both* from the same byte | 17:53 |
| lkcl | and the reason is not obvious | 17:54 |
| lkcl | it's because although you might create a 64-bit CSR and think, "huh, there's no problem there, everyone's going to write 64-bit data to that, right?" | 17:54 |
| lkcl | wrong | 17:54 |
| lkcl | a wishbone arbiter could *split* that | 17:54 |
| lkcl | funnel sorry | 17:55 |
| lkcl | could split that down even into single-byte writes | 17:55 |
| lkcl | so you *have* to make sure that each individual IO pad has its settings from the same byte | 17:56 |
| lkcl | assuming say a 64-bit CSR, GPIO pad 0 could be in byte 0 | 17:56 |
| lkcl | GPIO pad 1 from byte 1 | 17:56 |
| lkcl | .... | 17:56 |
| lkcl | GPIO pad 7 from byte 7 | 17:56 |
| lkcl | but you must NOT put | 17:56 |
| lkcl | GPIO pads 0-7 direction-setting into byte 0 | 17:56 |
| lkcl | etc. etc. | 17:57 |
| lkcl | the first simplest task would be to create a GPIO-based CSR-thing allowing the IO direction only to be set | 17:58 |
| lkcl | (from bit 0 of any given byte) | 17:58 |
| lkcl | and to be able to read/write IO pads over wishbone | 17:58 |
| lkcl | reminder - again - absolutely nothing to do with JTAG whatsoever | 17:58 |
| lkcl | i did actually write a very dumb GPIO thing already, i wonder where it is... | 17:59 |
| lkcl | ah ha! | 17:59 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/bus/simple_gpio.py;hb=HEAD | 18:00 |
| lkcl | it's very wasteful of the memory-space. no "packing" at all | 18:03 |
| tplaten | I read the last mail about branches, I"ll create one. | 18:05 |
| tplaten | I had a look at microwatt-linux-5.7-verilator-boot-buildroot.txt | 18:12 |
| lkcl | if you want to try running this, there aren't currently any instructions | 18:20 |
| lkcl | let me find the ones online that i started from | 18:21 |
| lkcl | https://shenki.github.io/boot-linux-on-microwatt/ | 18:21 |
| lkcl | so you need joel's microwatt-5.7 | 18:21 |
| lkcl | and you can just use wget to grab the builtroot from ozlabs | 18:22 |
| lkcl | bear in mind that 4 million instructions has taken about 1/2 an hour | 18:22 |
| lkcl | and it's still in the middle of the 3rd line of output you can see on the screenshots | 18:23 |
| lkcl | Allocating 0x5fb320 bytes for kernel... | 18:23 |
| lkcl | and you need the patches to microwatt-5.7 linux kernel that are included here | 18:24 |
| lkcl | http://lists.libre-soc.org/pipermail/libre-soc-dev/2022-January/004308.html | 18:24 |
| lkcl | drat, no they're not 1 sec | 18:25 |
| lkcl | https://patchwork.ozlabs.org/project/linuxppc-dev/patch/CAPweEDw710zFK8KLZY5gsQxEkQKrDiFkNRgABY9HJZ1rxpeVCg@mail.gmail.com/ | 18:25 |
| lkcl | there | 18:25 |
| lkcl | add a new option UNCOMPRESSED | 18:26 |
| lkcl | change clock frequency to 50 mhz | 18:26 |
| tplaten | I've once build joel's microwatt-5.7 and downloaded the builtroot from ozlabs. | 18:29 |
| tplaten | Then I ran that in a chroot on my Talos II natively | 18:30 |
| octavius | lkcl, not sure I understand exact topology of the GPIO block. | 18:33 |
| octavius | Am I correct in that you want the bank to be individually selectable for each GPIO? | 18:33 |
| octavius | For example, gpio0 to bank2, gpio1 to bank0, gpio2 to bank3 etc. | 18:33 |
| octavius | Or are all the individual GPIOs expected to be on the same bank? | 18:33 |
| octavius | Then for the settings, by "thing-that-sets-direction" do you mean the particular gpio is an input or output? | 18:33 |
| lkcl | the decision of what gpio to what bank is not ours to make | 18:46 |
| lkcl | we are designing something that must allow *users* to make that decision | 18:46 |
| lkcl | where "we just happen to be one such user" | 18:46 |
| lkcl | tplaten, nice! | 18:46 |
| octavius | So should the chip have a completely flexible function to pad assignment (any gpio can connect to any pad)? I don't understand what the topology of the banks you expect to have. From my block design, the bank allocation is *fixed* (which I guess is NOT what is expected of the chip) | 18:49 |
| lkcl | yes there should be a way-to-specify-the-naming-relationship | 18:54 |
| lkcl | such that people do not go "oh fer god's sake, i'm forced to name GPIO0 according to some stupid hard-coded numbering" | 18:54 |
| lkcl | "which has nothing to do with the customer's pre-defined (set) requirements" | 18:55 |
| octavius | But we can't possibly fit the logic that assigns gpios to any of the pins on the chip? That would surely take too much logic? | 18:55 |
| lkcl | this is not a routing issue in the ASIC, it's an API issue in python | 18:56 |
| octavius | Are we not describing the ASIC? | 18:56 |
| octavius | What's the advantage of an API that doesn't correspond to the ASIC's bank select? | 18:57 |
| lkcl | yes... and there must be a mapping from the public-names-of-the-pins onto the-number-behind-the-address-used-on-the-register | 18:57 |
| lkcl | look at simple_gpio.py | 18:57 |
| lkcl | https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/bus/simple_gpio.py;hb=HEAD | 18:57 |
| *** tplaten <tplaten!~isengaara@p200300ddff1536002e094dfffe000232.dip0.t-ipconnect.de> has left #libre-soc | 18:57 | |
| lkcl | do you see any evidence of "naming"? | 18:57 |
| lkcl | there isn't any, is there? | 18:58 |
| lkcl | it's just a "bank" of GPIO where the numbers on that GPIO are 0 to N-1 | 18:58 |
| octavius | No, I see the address numbers corresponding to the gpios (addr 0 is gpio0, addr 1 gpio1, etc.) | 18:58 |
| lkcl | this is a construct in your mind that you have created | 18:59 |
| octavius | So it doesn't exist? | 18:59 |
| octavius | That's what the sim shows | 18:59 |
| lkcl | anyone may choose instead that the first 8 GPIOs are in fact GPIO Bank A 0-7 and the second-addressed 8 GPIOs are GPIO Bank B 0-7 | 18:59 |
| lkcl | or, if they do a BGA (which is a 2D grid), they may decide that pad number N20 N21 N22 N23 are the first 4, 0-3 | 19:00 |
| octavius | "anyone may choose", choose where? This is the RTL generator which eventually produce an ASIC | 19:01 |
| lkcl | and G6 G7 G8 G9 are 4-7 | 19:01 |
| lkcl | in *their* specification, which *they* write, *not* us | 19:01 |
| lkcl | it is a very simple level of indirection. a dictionary would suffice | 19:01 |
| lkcl | or one of those Platform Resources | 19:02 |
| lkcl | but we *must* not dictate to them, "YOU MUST CALL THIS PLATFORM RESOURCE GPIO0 OR ELSE" | 19:02 |
| lkcl | we have to let *them* decide the names of the Platform Resource(s) | 19:03 |
| lkcl | it is much simpler than you are thinking it is | 19:03 |
| octavius | I think I'm at least understanding a little. No arbitrary names. | 19:03 |
| lkcl | this has absolutely nothing to do with dynamic routing | 19:03 |
| lkcl | that would be stupid | 19:03 |
| lkcl | to have some HDL that routes GPIO-Pad-A0 to any-GPIO-number-you-damn-well-choose | 19:04 |
| lkcl | that would be insane | 19:04 |
| lkcl | but | 19:04 |
| lkcl | they have to be able to *specify* the name-to-number relationship | 19:04 |
| lkcl | which is very simple and very straightforward | 19:04 |
| lkcl | far simpler than you are thinking "It Must Be Difficult Or Hard" | 19:04 |
| lkcl | "<octavius> No, I see the address numbers corresponding to the gpios (addr 0 is gpio0, addr 1 gpio1, etc.)" | 19:05 |
| lkcl | it _is_ like that... but those names "gpio0", "gpio1" .... | 19:06 |
| lkcl | they are *internal* names that *you* have given them, for your convenience to be able to refer to them | 19:06 |
| lkcl | there must be some *public* names that can be specified via e.g. "a Platform Resource" | 19:06 |
| octavius | So instead it's just a dictionary with a variable number of elements (gpios) | 19:07 |
| lkcl | where "The name in the Platform Resource" refers to "the thing you call inside *your* mind, gpio0" | 19:07 |
| lkcl | well, there's a couple of options here | 19:08 |
| lkcl | 1) the Platform Resource MUST specify a full list of numbered GPIO that MUST be connected ONLY and DIRECTLY to a GPIO bank (in TOTAL)" | 19:08 |
| lkcl | if the length is 16 then the GPIO bank (like simple_gpio.py) MUST be EXACTLY 16 long | 19:09 |
| lkcl | 2) it is permitted to connect SUBSETs of the Platform Resource to SEPARATE simple_gpio.py instances | 19:09 |
| lkcl | e.g. the first 8 pins of Platform Resource(GPIOA-16) are connected to one instance of simple_gpio.py | 19:10 |
| lkcl | and the 2nd 8 to another instance | 19:10 |
| lkcl | start to see why forcing the relationship inside the source code might not be such a good idea? | 19:11 |
| octavius | So where is the bank select logic fitting into this? | 19:11 |
| octavius | hierarchy-wise? | 19:11 |
| lkcl | at this point it's not | 19:11 |
| lkcl | start small | 19:11 |
| lkcl | work incrementally | 19:11 |
| octavius | So in my version of "simple_gpio" there will simply be a parameter "bank select" which won't be used, but perhaps available as an output? | 19:12 |
| lkcl | the next phase once you have a (only barely) more sophisticated version of simple_gpio.py would be to add bank-select | 19:12 |
| lkcl | you mean, as an input, but yes. | 19:12 |
| octavius | Nah, I thought the user specifies the bank select via WB CSR? | 19:13 |
| lkcl | yes, which means you need to write to the wishbone bus, which means it is an input | 19:13 |
| octavius | So the bank select would be an output to a mux bloc | 19:13 |
| lkcl | (from the perspective of the wishbone bus) | 19:13 |
| octavius | ok | 19:13 |
| lkcl | it would be an output *to* the mux block, yes. | 19:13 |
| lkcl | i see what you mean | 19:13 |
| lkcl | but remember that it needs to be possible to read the settings as well (to find out what the current setting is) | 19:14 |
| lkcl | but we are getting ahead, here | 19:14 |
| octavius | sure | 19:14 |
| octavius | Start with the simple_gpio | 19:14 |
| octavius | Where should a copy this file, pinmux repo? | 19:14 |
| lkcl | yes, good idea | 19:15 |
| octavius | I don't have write access to anything else XD | 19:15 |
| lkcl | let's sort that out when you need it. | 19:15 |
| octavius | sure | 19:16 |
| lkcl | you have write-access to the wiki, soc, pinmux and... dev-env-setup | 19:16 |
| lkcl | if you can add a register (use sync to set it) which allows the direction to be set, and also add another for output-enable | 19:16 |
| octavius | sure | 19:17 |
| octavius | "you have write-access to the wiki, soc, pinmux and... dev-env-setup" True | 19:17 |
| lkcl | that will allow any tri-stated IO pad to be turned into an input, output or bi-directional | 19:17 |
| octavius | yeah | 19:17 |
| lkcl | it means actually every IO pad is bi-directional, but hey | 19:18 |
| octavius | I guess some of the pads may be simplified during synthesis though? (If we decide to hardwire one of RGMII interfaces etc.) | 19:19 |
| lkcl | yes. | 19:19 |
| lkcl | now you're getting it | 19:19 |
| lkcl | DDR3/4/5 are good candidates for that, on proprietary SoCs | 19:20 |
| lkcl | because trying to route timing-sensitive / impedance-sensitive pads through a MUX would be damn stupid | 19:21 |
| octavius | Yes, I thought so too | 19:21 |
| lkcl | frick, frick, frick i just wasted an hour by pressing Ctrl-C on the simulator after mis-reading the dump trace | 19:21 |
| lkcl | it had got to here | 19:21 |
| lkcl | Finalizing device tree... flat tree at 0xbd4c80 | 19:22 |
| lkcl | and i thought that it had got stuck in a loop, when in fact it was initialising memory to zero | 19:22 |
| lkcl | frick | 19:22 |
| lkcl | sigh. | 19:22 |
| * lkcl re-running | 19:22 | |
| lkcl | brb | 19:22 |
| octavius | "by pressing Ctrl-C on the simulator" I feel your pain... | 19:24 |
| lkcl | paaatieeeeence.... | 19:25 |
| octavius | Btw, soon I'll be getting an OBD2 scanner. Planning to do diagnostics >:) | 19:34 |
| lkcl | okaay | 21:23 |
| lkcl | [ 0.000000] printk: bootconsole [udbg0] enabled | 21:23 |
| lkcl | -> early_setup(), dt_ptr: 0xbd4c80 | 21:23 |
| lkcl | no 0x700 exception yet, a good sign | 21:24 |
| lkcl | [ 0.000000] dt-cpu-ftrs: setup for ISA 3000 | 21:35 |
| lkcl | i think the 0x700 exception happened some time around... when the info on the MMU was being reported. | 21:37 |
| lkcl | rd @ 0007d900 di 6d6d006f74707972 sel ff rypto.mm | 21:38 |
| lkcl | rd @ 0007d901 di 6d00687361682d75 sel ff u.hash.m | 21:38 |
| lkcl | rd @ 0007d902 di 78696461722d756d sel ff mu.radix | 21:38 |
| lkcl | that looks like reading of device-tree entries | 21:38 |
| lkcl | [ 0.000000] dt-cpu-ftrs: final cpu/mmu features = 0x00000087800391e1 0x3c006041 | 21:41 |
| lkcl | alriiiight | 21:41 |
| lkcl | oh ha ha very funny. i should have spotted this the first time | 23:34 |
| lkcl | [ 0.000000] Page orders: linear mapping = 24, virtual = 12, io = 12, vmemmap = 12 | 23:34 |
| lkcl | [ 0.000000] hash-mmu: Partition table (____ptrval____) | 23:34 |
| lkcl | [ 0.000000] hash-mmu: Initializing hash mmu with SLB | 23:34 |
| lkcl | where the microwatt-boot says "radix-mmu" | 23:34 |
| lkcl | urrrrr | 23:34 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!