[Libre-soc-bugs] [Bug 846] Pinmux Pinspec Interconnect Auto-Generation

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Oct 1 12:33:02 BST 2022


https://bugs.libre-soc.org/show_bug.cgi?id=846

--- Comment #5 from Andrey Miroshnikov <andrey at technepisteme.xyz> ---
Here's the latest commit:
https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/stage2.py;h=1669149e22bed1776e7aa7c9ace5772ca0a607f4;hb=HEAD

By reverse engineering the PinSpec "write()" method, I was initially able to
extract only the bank, pin, and mux information.
https://git.libre-soc.org/?p=pinmux.git;a=blob;f=src/spec/base.py;hb=HEAD#l51

ps.pinbanks.keys() <-- Gives the available banks for the chip (A/B/C/D etc)
ps.keys() <-- Gives all pins (summing all banks)

But running in interactive shell was useful to find the rest of the dicts.
Also I answered my own question before finishing this comment.
"keys()" is a method you added to the Pinouts class (which PinSpec inherits)
that internally calls .pins.keys().

ps.byspec <-- dict that has the signal names with IOType information

Now that I have the information, I'll integrate it into the pinmux block by
feeding PinSpec object directly!



There seems to be a strange recursive duplication.
ps.items() gives the pin information (as ps is PinSpec and inherits Pinouts),
but the same dict is returned by ps.gpio.pinouts.items()
and this can be continued for a while (tried up to 20 levels, 4 shown):
ps.gpio.pinouts.gpio.pinouts.gpio.pinouts.gpio.pinouts.items()

Is this a bug? It doesn't seem like there are infinite objects (otherwise my
RAM
wouldn't be happy), but perhaps a circular reference somewhere?


Also added new sections to the pinmux doc (they may need to move around, but
haven't focused on that yet), 4.1.1-4.1.4 covering the terminology and the
PinSpec and Pinouts classes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the libre-soc-bugs mailing list