Separate bug for documentation task of the core/pad JTAG tests. For the tests, see bug #763 The temporary documentation can be found here: https://libre-soc.org/docs/pinmux/temp_pinmux_info/ Plan: - Merge general overview information about JTAG/GPIOs with the main pinmux page (https://libre-soc.org/docs/pinmux/) - Reword the explanation of the core/pad JTAG tests - Expand on the pinmux (with diagrams and proposals) - Add any missing references to useful sources (GPIO, JTAG, etc.)
I've updated the GPIO section of my temporary documentation page: https://libre-soc.org/docs/pinmux/temp_pinmux_info/ As for merging with the main pinmux page, is it worthwhile to have a page on the theory (the pinmux), and the implementation (temp_pinmux_info, but with a new name)? For example, the current section 4 which covers the GPIO block can go into the main page, however the testing and brief code explanation can be on the second page. Also, let me know if 500EUR is an appropriate budget, and what else should be documented before the bug can be closed.
(In reply to Andrey Miroshnikov from comment #1) > I've updated the GPIO section of my temporary documentation page: > https://libre-soc.org/docs/pinmux/temp_pinmux_info/ looks great > As for merging with the main pinmux page, is it worthwhile to have a page on > the theory (the pinmux), and the implementation (temp_pinmux_info, but with > a new name)? yyeah i think that's a good idea. [btw can you put a width on this https://libre-soc.org/docs/pinmux/io_mux_bank_planning.JPG in the tag you can set width=800 or size=800x something like that, there's loads of examples, grep the mdwn files] > For example, the current section 4 which covers the GPIO block can go into > the main page, however the testing and brief code explanation can be on the > second page. yeah go for it > Also, let me know if 500EUR is an appropriate budget, and what else should > be documented before the bug can be closed. it can always go up later the idea i had was that when setting to "mux bank 7" this indicates that the IOpad is to be connected to JTAG boundary scan. if this is _not_ done. the only other way is to have double-MUXing, which introduces yet more gate delay. i haven't fully thought this through, i'd have to see it as an actual diagram, when we get to combining the pinmux with JTAG BS. but, whatever is done, it needs to be documented because it will surprise the heck out of people otherwise
(In reply to Luke Kenneth Casson Leighton from comment #2) > > As for merging with the main pinmux page, is it worthwhile to have a page on > > the theory (the pinmux), and the implementation (temp_pinmux_info, but with > > a new name)? > > yyeah i think that's a good idea. Nice, I'll do some more re-arranging on it next week. > [btw can you put a width on this Funny thing is I did add the width statement, I just wrote "px" instead of "x" (esoteric ikiwiki syntax hahaha) > yeah go for it Moved the GPIO block explanations to main pinmux page, will do the same to the JTAG ones next week. https://libre-soc.org/docs/pinmux/ > it can always go up later Ok, then this bug can cover both 763 and 762 development documentation. > the idea i had was that when setting to "mux bank 7" this indicates that > the IOpad is to be connected to JTAG boundary scan. From my understanding, we'll just need access to all bits of the bank select to choose the connected peripheral during the JTAG testing, and perhaps the wishbone bus to adjust puen/pden. How will the specific bank select of 7 (111) help? Does the GPIO need to know it's being controlled by the JTAG BS? Now that I think about it, I didn't consider where the JTAG chain will be. Is it going to be: 1. Between the GPIO block outputs and the IO pad 2. Or between the peripherals and the GPIO block The first case means that we'll need a lot more of the GPIO block's signals to be in the BS chain (including the WB bus). As for the second, the tester still has to be able to send WB transactions. Is this why you specified using "mux bank 7"? As a way to control the block without the WB bus? There probably needs to some kind of shift register, or the chain needs to be long enough to control all the GPIO parameters. >if this is _not_ done. > the only other way is to have double-MUXing, which introduces yet more > gate delay. Gate delay is unfortunately unavoidable (unless you have some optimisation tricks up your sleeve), as there's a lot of MUXing going on regardless. > i haven't fully thought this through, i'd have to see it as an actual > diagram, when we get to combining the pinmux with JTAG BS. Thanks for the suggestion, I'll do some brainstorming and make a scary diagram >:) (will go in a subsection 4.5 of the main pinmux page) > but, whatever > is done, it needs to be documented because it will surprise the heck out > of people otherwise Very much so. This topic took me waaaaay too long to understand, hopefully the new docs will improve the onboarding time.
Updated the documentation related to the pinmux block (Section 4): https://libre-soc.org/docs/pinmux/
(In reply to Andrey Miroshnikov from comment #4) > Updated the documentation related to the pinmux block (Section 4): > https://libre-soc.org/docs/pinmux/ looks great, the only thing the numbering in each cell is wrong, here https://libre-soc.org/docs/pinmux/xgpio-mem-layout.jpg.pagespeed.ic.p5E850LcdR.webp it should be add/row 0 7 6 5 4 3 2 1 0 1 15 14 13 12 11 10 9 8 and here: For example, if 16 GPIOs are instantiated and 64-bit data bus is used, GPIOs 0-7 are accessed via address 0, whereas GPIOs 8-15 are accessed by address 0. should be: For example, if 16 GPIOs are instantiated and 64-bit data bus is used, GPIOs 0-7 are accessed via address 0, whereas GPIOs 8-15 are accessed by address 1.