updated documentation for bbai

[gomer]

this updated documentation dated 1/22/25 is the missing link that was needed to complete the data analysis for a config-pin type tool. I started looking into this over a year ago and started this topic:

device tree bindings for EGPIO : bbai

I’m digging into device tree for bbai and have been unable to find something more definitive than comments that bind the egpio bit to the header. There are at least two instances where the comments assign the same egpio bit to two different (P8) headers. The author of Moving to the BeagleBone AI — BeagleBoard Documentation , seems to have found the same inconsistency. there are 10 (ten) instances on the P8 header where this occurs. ( you have to interpret the reference to ‘PRU2’ to be ‘pr2’,…

the data analysis has these data / relationships:
SRM dated:1/22/25 1:M pin–>ball, pin–>address, pin–>signal (mode)
TRM 1:M pad–>signal (mode) 1:1 pad<–>physical address
DTS (device tree (decompiled from DTB)) … 1:M pin–>function
datasheet 1:M signal–>ball , 1:M ball–>signal

I still have the question about the same signal being exposed to two different header pins… is there any guidance as to what would happen if the board was (mis)configured in this way? I’m looking for some warning or documentation that describes this, not some (snide) ‘YEAH, dont do that’.

here are some examples;

config-pin: signal pr2_pru0_gpo2
pr2_pru0_gpo2:
	pr2_pru0_gpo2:
		VOUT1_D5     D 0x15F0	F9	P8_42
		MMC3_CLK     D 0x177C	AD4	P8_21
	pr2_pru0_gpo20:
	    VOUT1_D23    D 0x1638	A10	P8_46
        MCASP1_AXR15 D 0x16F0	F14	P8_08
		
config-pin: sig pr2_pru0_gpo3
pr2_pru0_gpo3:
	pr2_pru0_gpo3:
		VOUT1_D6     D 0x15F4	F8	P8_39
		MMC3_CMD     D 0x1780	AC4	P8_20

here is another example for uart7_txd:

config-pin: sig uart7_txd
uart7_txd:
	uart7_txd:
		GPMC_A3      7 0x144C		
		VIN1A_FLD0   5 0x14E8	AF9	P8_33
		VOUT1_D17    2 0x1620	B8	P9_11
		MCASP3_FSX   3 0x1728

at this point in the project, I have a competent data analysis tool that reports by pin or function or signal or ball or pad. I can hand edit the decompiled DTB, recompile it, and it works fine (I think).

the question is whether this is a tool just for me (easier) or are others interested in further automation? The problem is that it is a tool of many pieces and would probably require that I post an image with everything configured, rather than describe all the perl modules that need to be installed, and nmap installation, and, and, and.

here is another snip of the current ‘help’ command:

config-pin: help
ball : USAGE: 
	ball <ball fragment> : report details for some or all balls
default : USAGE: 
	default <header fragment> : 
		report default configuration for header pin(s)
function : USAGE: 
	function <function fragment> : report details for one or more functions
header : USAGE: 
	header <header fragment> : report details for header pin(s)
help : USAGE: 
	help <command> : report usage of command
pad : USAGE: 
	pad <pad fragment> : report details for pad(s)
q : USAGE: 
	quit : 
signal : USAGE: 
	signal <signal fragment> : report details for one or more signals
update : USAGE: 
	update header signal : change the default signal for a given pin
config-pin:

one last snip for the header report:

config-pin: head p8.15
P8.15:
	P8_15
		4A003570 --> VIN2A_D2 D1
			default     	0x4000e	gpio4_3
			gpio        	0x5000e	gpio4_3
			gpio_pu     	0x6000e	gpio4_3
			gpio_pd     	0x4000e	gpio4_3
			pru_ecap_pwm	0x4000b	pr1_ecap0_ecap_capin_apwm_o
			ecap_pwm    	0x4000a	eCAP1_in_PWM1_out
			pruin       	0x1000f	
			pruout      	0x1000f	
			eqep        	0x4000e	gpio4_3
		4A0035B4 --> VIN2A_D19 A3
			default     	0x1000f	
			gpio        	0x1000f	
			gpio_pu     	0x1000f	
			gpio_pd     	0x1000f	
			pru_ecap_pwm	0x1000f	
			ecap_pwm    	0x1000f	
			pruin       	0x5000c	pr1_pru1_gpi16
			pruout      	0x4000d	pr1_pru1_gpo16
			eqep        	0x1000f

feedback solicited.
gomer