Hijax

For example Rock64 takes 0,9A at processor peak. Measured by myself. I will later check other SBCs I have, including Odroid XU4. Anyway the 4mm track I placed on PCB shall be enough to provide 7.5W to each of all 4 SUTs. Or max 30W in total, which better describes reality. But to not overload external power supply, I suggest to use such a board in a way to not start all SUTs at the same time, but boot them one by one, with let's say 2s delay. Then after ~15sec all SUT will be running, but power usage will be on reasonable level. Yes, but spacers will secure insulation. Using EDA for several years already. Long time ago I have started with Orcad, then moved to Protel 99, and now KiCad fan.

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.

Can not manage that, u-boot compilation problem: scripts/Makefile.lib:394: recipe for target 'lib/efi_loader/helloworld_efi.so' failed

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?

That simplifies the design. But: ...puts additional demands on power section. To provide lets say 30A from single source creates demand on external power supply and also PCB design. From the other hand if only power control & serial port is needed, then: Moxa Nport Server for serial and some Remote Power Switched PDU ?

Let me start build on my VM. Using compile command as provided by @guidol Shortly I will put here information about results.

This needs to be corrected, some boards specs provides information of high current as assumption is done some USB devices are connected. Typical RPi alike board rarely goes beyond 1.5A This multiplexer design uses IRF7425 mosfet that can drive continuously up to 15A, i.e. 75W with 5V. But I assume it will be used to level up to 3A hence its will heat up to ~4 deg above ambient.

In this solution 2x5 header is used to proxy SPI (SD), serial port ground and power. Imaging one end of the cable with 2x5 header while second end split to two or three separate plugs. One issue that needs prototyping is: now SD card is all the time powered by 3.3V. For high speeds card shall by powered by 1.8V but now there is no connection between SUT card slot power and SD card itself. I do not exactly know if card will work only in let's say 40MB/sec One multilpexer + one MasteSBC = 4 SUT tested. For more SUT, dimensioning is done by adding more Masters/Multiplexers. Hence parallel testing depends on number of MasterSBCs. Yes, not only multiplexer but also micro SD adapter cables shall be provided in single design. Now I have focused on multiplexer as it is "more complicated" than SD card adapter. But when I will decide to send gerbers for PCB manufacturing, I will send not only multiplexer but also adapters.

New rendering: Yeap. To emulate SD first of all a strong machine will be nedded, or FPGA. Cheaper solution is to replace died SD rather than invest / maintain complicated HW / SW. As power is exposed through 2x5 pin header, SUT can be powered using barrel plug, micro USB or USBC connector or using pins 4 & 6 of the header. Multiple options available. Yes, GPIO 2,3 & 4 are 3 bit that selects which SBC is powered, and also which serial works. As SD card used SPI protocol (MISO/MOSI/CLK) all SUTs are connected to the same SBC all the time. But only the one that is powered can utilize the SD. When all GPIO=1 then no SUT is powered, and SD card is available to the master SBC through SD to USB adapter. Master SBC will be powered by 40 PIN header from this multiplexer board. External supply is connected using screw terminal and protected by 3A polymer fuse. BOM is small, all components would cost few bucks. Same with PCB production - china factories will make 10pcs for 5 USD. Also they can mount components (PCBA service) I am imaging that all 4 test boards (RPI shaped) would be stacked on top of this. All connected to some Ethernet switch. Basic test of kernel booting can be done with simple check of HDMI initialization. That is not all, a set of microSD card adapters are needed as well. Something like this: https://wiki.tizen.org/File:Cable.jpg Waiting for comments

@guidol I am doing it in a bit different way. Clone the whole repo, checkout proper branch. To make it working you must put empty file named .ignore_changes Then during run of compile.sh the script will not force change to master branch.

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....

Woudn't it be more convinient to add tcl & rsyslog when EXTERNAL=YES ? For example to add them here (packages/extras/armbian-config.sh): # installing additional dependencies here so they are installed only with armbian-config chroot $SDCARD /bin/bash -c "apt install -q -y iperf3 debconf-utils html2text dirmngr expect libassuan0 libnpth0 libksba8" install_deb_chroot "$DEST/debs/armbian-config_${REVISION}_all.deb" Please check PR https://github.com/armbian/build/pull/1464

I wonder if this dependency shows up only if EXTERNAL=YES is selected? Side note, while I am building something I see following error: [ o.k. ] Applying distribution specific tweaks for [ bionic ] /home/op/armbian-build/lib/distributions.sh: line 380: /home/op/armbian-build/.tmp/rootfs-default-rock64-bionic-no/etc/netplan/armbian-default.yaml: No such file or directory [ o.k. ] Applying common tweaks

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.

https://wiki.tizen.org/SD_MUX

As I am a happy user of Rock960 have question here: Adding board definition, kernel config etc is trivial. But as I understand there is no possibility for continuous integration and verification from Arbmian community side, right? So if new broad is added, it will be visible as... CSC?

Essentially yes. My PR is now under testing. Hope in some reasonable time will be merged down to master branch. Shall you check code? Use this branch https://github.com/armbian/build/tree/mini

Hi, Shall work with any combination of SBS/kernel/OS. Like rock64/default/bionic or pineh64/dev/stretch and others To trigger this variant when selecting image type "server" a new dialog will pop up to specify development image (former config) or minimal. Alternatively simply put following options in command line: BUILD_MINIMAL=yes together with BUILD_DESKTOP=no. Observe BUILD_DESKTOP must be set and takes priority, i.e. BUILD_MINIMAL=yes BUILD_DESKTOP=yes will be interpreted as BUILD_MINIMAL=no BUILD_DESKTOP=yes. When no BUILD_DESKTOP option is given in command line, appropriate dialog box will pop up thus BUILD_MINIMAL may be overwritten. Now the changes are put as PR to the mini branch of armbian/build git repository. https://github.com/armbian/build/pull/1463 Final images for minimal and development variants: root@armbian:~/armbian-build# ls -l output/images/*.img -rw-rw-r-- 1 root root 1107296256 Jul 20 12:12 output/images/Armbian_5.91_Rock64_Ubuntu_bionic_default_4.4.184.img -rw-rw-r-- 1 root root 591396864 Jul 20 12:33 output/images/Armbian_5.91_Rock64_Ubuntu_bionic_default_4.4.184_minimal.img root@armbian:~/armbian-build# I was using following command line for testing (note IGNORE_UPDATES=yes FORCE_CHECKOUT=no shall - to my understanding - only be applicable for testing purposes): ./compile.sh CLEAN_LEVEL=none IGNORE_UPDATES=yes FORCE_CHECKOUT=no EXTERNAL=NO BOARD=rock64 BRANCH=default RELEASE=bionic KERNEL_ONLY=no KERNEL_CONFIGURE=no BUILD_MINIMAL=[yes|no] BUILD_DESKTOP=no

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.

Thx @Igor I will start by adding BUILD_CORE variable, modify appropriate dialog and left BUILD_DESKTOP. Then further changes. Have a good time wherever you go Meantime I will try to prepare PR

Exactly. I will then fork the build repository, and start digging into a way how the debootstrap is used. To create additional target is such a way that it provides minimalistic setup while users will use PACKAGE_LIST_ADDITIONAL to add what they need. When will have something interesting, will create pull request. Meanwhile I will appreciate if someone can provide a more comprehensive description of root fs building or alternatively I will need to spend time to reverse engineer that

Yes, but still the resulting img is about 1GB. And with this option I need to run compile.sh twice. That is something I did using very different setup. Just an example. But I very like the armbian build environment. So I will be happy if resulting img would be 500MB or so. Yes, doing that for some of packages. Like fbset as my SBC will only be connected via Ethernet & Serial TTY, no HDMI. But the issue is there is a lot of installed packages and now I need to trace back dependencies. Would it be easier to start from minimal set and add what is needed for CLI or Desktop use or... user specific needs ?

In my project I would like to create Armbian ISO that has only the packages that are really needed for system itself and literally few I need for my application. Just to use smallest possible SD card and not update packages I will never use. Regardless how I configure build at the end I got 1GB image. While I know it is possible to go down to 100MB using Ubuntu bionic and latest kernel. Shall debootstrap use configurable —variant option? For me “minbase” would be perfect. But it does not change anything. Shall I put into lib.config my version of PACKAGE_LIST? Still a rootfs is forced to download. No success. So how to strip down the packages in rootfs compilation? I am using Rock64 modules.