Hijax

Ok chaps, final design of serial mux board, plus zip file full of gerber files.


serial-mux.zip
 
BOM:

 
 
manufacture.pdf
 
Simple example how to control mux from bash (not verified, concept only
 
#!/bin/bash # pin allocation MOSI_PIN=353 #GPIO2 SCK_PIN=3 #GPIO3 EN_PIN=19 #GPIO4 function gpio-setup { for pin in $MOSI_PIN $SCK_PIN $EN_PIN; do [[ -d /sys/class/gpio/gpio$PIN ]] && echo $pin > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio$PIN/direction done } function gpio-write_byte { for i in {1..8}; do // set data pin to high or low value BIT=0 (( $1 > 127 )) && BIT=1 echo "$BIT" > /sys/class/gpio/gpio$MOSI_PIN/value // set clock high echo "1" > /sys/class/gpio/gpio$SCK_PIN/value $1=$(( $1 << 1 )) // set clock low echo "0" > /sys/class/gpio/gpio$SCK_PIN/value done } # 16 bits: -- -- -- -- -- b3 b2 b1 p7 p6 p5 p4 p3 p2 p1 # px - power status on port x # bx - serial connected to port x function setup_mux { local high_byte=$(( $1 >> 8 )) local low_byte=$(( $1 & 255 )) gpio-setup gpio-write_byte(high_byte) gpio-write_byte(low_byte) # toogle EN bit to latch new value on 595s echo "1" > /sys/class/gpio/gpio$EN_PIN/value echo "0" > /sys/class/gpio/gpio$EN_PIN/value }  

One more update, I have added LEDs close to every port to show powering status and 7seg LED display to show which Serial is currently connected.
 
3D view: https://autode.sk/2OcgRSL

Today @Igor has merged correction that address wrong DNS server address setup. Maybe that helped you

Ok chaps, final design of serial mux board, plus zip file full of gerber files.


serial-mux.zip
 
BOM:

 
 
manufacture.pdf
 
Simple example how to control mux from bash (not verified, concept only
 
#!/bin/bash # pin allocation MOSI_PIN=353 #GPIO2 SCK_PIN=3 #GPIO3 EN_PIN=19 #GPIO4 function gpio-setup { for pin in $MOSI_PIN $SCK_PIN $EN_PIN; do [[ -d /sys/class/gpio/gpio$PIN ]] && echo $pin > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio$PIN/direction done } function gpio-write_byte { for i in {1..8}; do // set data pin to high or low value BIT=0 (( $1 > 127 )) && BIT=1 echo "$BIT" > /sys/class/gpio/gpio$MOSI_PIN/value // set clock high echo "1" > /sys/class/gpio/gpio$SCK_PIN/value $1=$(( $1 << 1 )) // set clock low echo "0" > /sys/class/gpio/gpio$SCK_PIN/value done } # 16 bits: -- -- -- -- -- b3 b2 b1 p7 p6 p5 p4 p3 p2 p1 # px - power status on port x # bx - serial connected to port x function setup_mux { local high_byte=$(( $1 >> 8 )) local low_byte=$(( $1 & 255 )) gpio-setup gpio-write_byte(high_byte) gpio-write_byte(low_byte) # toogle EN bit to latch new value on 595s echo "1" > /sys/class/gpio/gpio$EN_PIN/value echo "0" > /sys/class/gpio/gpio$EN_PIN/value }  

Ok. So to see the usability of second design, I have quickly reorganized the schematics (attached) and placed components.
I mean routing is far from completion but 8 port (with different sockets, Molex KK 254 AE 6410 04A) is max for this board size. Mainly due to power distribution (look at the cad picture)
 



serial-mux.pdf

@Igor if we go towards no SD option then it would be possible to have 8 ports towards SUTs, that conveys serial port and power supply.
I can change design easily: control of power outputs (0 to 8 powered simultaneously) and multiplex of 8 serial ports to be connected to MasterSBC one.
 
One note: as the SBC itself is not system under test I strongly suggest to drop idea of powering through barrel or usb ports, but use header. First 2x5 pins are enough in that case. Simple, secure, and will limit down number of test environment failures.

Ok. So to see the usability of second design, I have quickly reorganized the schematics (attached) and placed components.
I mean routing is far from completion but 8 port (with different sockets, Molex KK 254 AE 6410 04A) is max for this board size. Mainly due to power distribution (look at the cad picture)
 



serial-mux.pdf

One can use spacers. In my projects I typically use 25mm, like on images. Pine H64 with spacers and with installed some fancy hat board.
Please remember this multiplexer is not designed to test SBC beneath it. It is designed to sit on some RPi like SBC to create master controller.
Yes, as this is .. multiplexer. The goal of this design was to able automate SD card change, So in real life it will be similar to setup when you have 4 SBC to test and one SD card you need to move around.
What is the verification strategy here?
1) One thing is to test uboot/kernel, every time new patch arrives. Kernel can be tested using USB port. Is the difference between SD/USB important here?
2) Another is to test rootfs, rarly done. And rootfs can be loaded remotely via TFTP. So only special uboot would be needed.
3) Integration test, assuming end to end approach. So full image on SD card - lets say once per week.
 
This multiplexer addresses point 3, but it is my point of view only. Again what is the strategy?
 

Quick update.
 
Middle of the work: 4 ports to connect 4 SUT: power, serial & SD card adapter.
Dedicated screw terminal to connect +5V
Dedicated micro SD socket.
 
Size - Raspberry Pi hat.
Connection with Master SBC - through 26 pin header (compatible with oldest Raspberry Pi as well)
 
Preview....

 

Speaking of the needed hardware. As I understand you need a multiplexer that will connect a real SD card to some connected SBCs under test (let's call them SUT) and the controller itself.
Why real SD? As I do believe there is no point to emulate it.
 
So the HW shall be something like hat on top of one of cheapest SBC, like Rock64 (that I will call MasterSBC), that multiplex:
- SD card to USB-to-SD adapter connected to MasterSBC, for writing new image to it or one of SUT for read/write
- Serial port of selected SUT to MasterSBC,
- Select SUT by applying also power to it, trivial circuit with MOSFET will do the job, controlled by HC4515 chip (4 to 16 decoder) (I suggest to power SUTs via 40pin header)
Of course with such mux only one SUT will be possible to control at the time.
 
With this setup, MasterSBC will use native USB to access SD card, using 4 GPIO to select SUT and serial port for monitoring what SUT is doing. Capacity? 15 connected SUTs
All easy scriptable with basic python commands.
 
In my free time, I can design such a hat and publish schematics & gerber files here.

Hi,
 
BUILD_MINIMAL is now implemented in separate branch.
-rw-rw-r-- 1 root root 675282944 Jul 20 08:42 Armbian_5.91_Rock64_Ubuntu_bionic_default_4.4.184_minimal.img First of all I had to correct error in rootfs hash creation. In  similar way to yours.
I have also added --variant=minbase to debootstrap.
 
PR is now visible.
 
I will continue to test the changes.

Hi,
 
BUILD_MINIMAL is now implemented in separate branch.
-rw-rw-r-- 1 root root 675282944 Jul 20 08:42 Armbian_5.91_Rock64_Ubuntu_bionic_default_4.4.184_minimal.img First of all I had to correct error in rootfs hash creation. In  similar way to yours.
I have also added --variant=minbase to debootstrap.
 
PR is now visible.
 
I will continue to test the changes.

Hi,
 
BUILD_MINIMAL is now implemented in separate branch.
-rw-rw-r-- 1 root root 675282944 Jul 20 08:42 Armbian_5.91_Rock64_Ubuntu_bionic_default_4.4.184_minimal.img First of all I had to correct error in rootfs hash creation. In  similar way to yours.
I have also added --variant=minbase to debootstrap.
 
PR is now visible.
 
I will continue to test the changes.

Hi,
 
BUILD_MINIMAL is now implemented in separate branch.
-rw-rw-r-- 1 root root 675282944 Jul 20 08:42 Armbian_5.91_Rock64_Ubuntu_bionic_default_4.4.184_minimal.img First of all I had to correct error in rootfs hash creation. In  similar way to yours.
I have also added --variant=minbase to debootstrap.
 
PR is now visible.
 
I will continue to test the changes.