https://turingpi.com logo
bmcd/bmcd/src/hal/pin_controller.rs at m...
# │firmware-dev
s
Did you have a look at the pin_controller and power_controller inside the bmcd repo https://github.com/turing-machines/bmcd/blob/master/bmcd/src/hal/pin_controller.rs also the dts tree in the main repository should give you an overview of all the pinouts
j
I want to experiement a bit with RPIBoot on the TP2. So I stopped the BMCD. My rust ist not the best, so far I understand https://github.com/turing-machines/bmcd/blob/a15e8fc2341bf762a8f653a2d9e6b5491f22df7d/bmcd/src/hal/power_controller.rs#L137 writing
enabled
or
disabled
to
sys/bus/platform/devices/node2-power/state
should power on node 2, But nothing happens do I miss something?
Copy code
tp2 # echo enabled > /sys/bus/platform/devices/node2-power/state 
tp2 # cat /sys/bus/platform/devices/node2-power/state 
enabled
tp2 # echo disabled > /sys/bus/platform/devices/node2-power/state 
tp2 # cat /sys/bus/platform/devices/node2-power/state 
disabled
l
@j0ju, just tested it on the official firmware and a tpi 2.5 and it looks like it still responds to the state commands with the bmcd process killed.
Copy code
[ 2327.412870] realtek-smi 0-005c node3: Link is Down
[ 2327.413010] br0: port 3(node3) entered disabled state
[ 2329.501747] realtek-smi 0-005c node3: Link is Up - 1Gbps/Full - flow control rx/tx
[ 2329.501874] br0: port 3(node3) entered blocking state
[ 2329.501905] br0: port 3(node3) entered forwarding state
Will check it on my tpi 2.4 too. There are hardware differences between the two hardware revisions so this could also be a lucky coincidence.
j
I tested with a 2.4 and a 2.5.2 board. Good point I expect serial output and the RED Power Led of the Node to be switched on. I will have look at the ethernet link (which I not monitored) Will give it a try
l
Tested it again, and the node will power on correctly and serial access from the BMC is working. However i suspect the per node power led needs the BMCD to toggle its state. So this led won't be lit. (tested it with a RK1)
j
The per node power and status LEDs (green, orange) seem to be driven by the SBC itself. On the other side of the slot is very dim red LED, which as far I understand is driver by the BMC.
l
Correct the green status and orange activity leds from each node are driven by de SBC. However the red led on each node indicates the power to the slot, so these won't be lit.
j
okay tested again, on the backside of the CM4 adapters is a green LED I can enlighten, when I write "enabled" to the correct node in sysfs. What I do not get is serial output and an ethernet link.
So I guess the green LED on the backside of the CM4 adapter tell me that it has power. I suspect the rpiboot lines per node, but unsere, as writing 2 4 6 8 with alternating 0,1 values and writing enabled/disabled to the sysfs node do not show a different behavior. :/ Will continue tmmrw.
Copy code
tp2 > ~ > gpioinfo -c 2 # on TP 2.5.2
gpiochip2 - 9 lines:
        line   0:       "node1-en"              output
        line   1:       "node1-usbotg-dev"      input
        line   2:       "node1-rpiboot"         output
        line   3:       "node2-en"              output
        line   4:       "node2-rpiboot"         output
        line   5:       "node3-en"              output
        line   6:       "node3-rpiboot"         output
        line   7:       "node4-en"              output
        line   8:       "node4-rpiboot"         output
l
Hmm, so that's a difference between the RK1 and a CM4 in the adapter. Will do some tests on my side too with the CM4
j
with
Copy code
gpioset  -t 99s,0 -c 2 --by-name node2-en=1 node2-rpiboot=0 & echo enabled > /sys/bus/platform/devices/node2-power/state; fg
I am able to start eg. node2 if it is a CM4/5, and I need to kill the gpioset after a short time I am still missing something here at it is not always reproducible. I might also be struggling with the behavior stat in exit gpioset is resetting the lines to default values.
So writing enabled/disabled to the power/state sysfs node enables power to the modules. How nodeX-rpiboot nodeX-en are wired to CM4 or RK1? I would guess nodexX-rpiboot GPIO is for the rpiboot jumper. Where is nodeX-en connected. I guessed the RUN-jumper, but at least it does not behave that way. Or I am holding it wrong. @svenrademakers Can you shed light on this?
12 Views