Hijax

So you suggest to use CLEAN_LEVEL="debs" to remove debs all the time and eventually add IGNORE_UPDATES ?

Playing with BUILD_MINIMAL I had to several times run compilation script for the same board / system / branch. To speed up verification I thought: what is a point to constantly build u-boot / kernel? So I added CLEAN_LEVEL option to not delete generated debs. I have noted that from one hand I can disable cleaning of (for example) kernel deb files, but from other hand if there is repository update no new deb is produced. And the idea.... or is this already implemented somewhere? Build of u-boot / kernel is initiated when no deb file exists. fetch_from_repo function knows if the repository is updated. What is fetch_from_repo returns update status and this is used also in main.sh as additional check? I.e. deb exists but is older than latest repo update so compilation is required. Essentially, to change: if [[ ! -f ${DEST}/debs/${CHOSEN_UBOOT}_${REVISION}_${ARCH}.deb ]]; then into something like: if [[ ${UBOOT_UPDATED} == "yes" || ! -f ${DEST}/debs/${CHOSEN_UBOOT}_${REVISION}_${ARCH}.deb ]]; then And diff proposal: diff --git a/lib/general.sh b/lib/general.sh index dc0718a4..64edeaa8 100644 --- a/lib/general.sh +++ b/lib/general.sh @@ -294,6 +294,7 @@ fetch_from_repo() fetch_from_repo "$surl" "$workdir/$i" "$sref" done fi + [[ $changed == false ]] && return 1 } ############################################################################# #-------------------------------------------------------------------------------------------------------------------------------- diff --git a/lib/main.sh b/lib/main.sh index 00ec251c..b9779edb 100644 --- a/lib/main.sh +++ b/lib/main.sh @@ -311,10 +311,15 @@ start=$(date +%s) # ignore updates help on building all images - for internal purposes # fetch_from_repo <url> <dir> <ref> <subdir_flag> +BOOT_IS_UPDATED=false +KERNEL_IS_UPDATED=false if [[ $IGNORE_UPDATES != yes ]]; then display_alert "Downloading sources" "" "info" fetch_from_repo "$BOOTSOURCE" "$BOOTDIR" "$BOOTBRANCH" "yes" + [[ $? == 0 ]] && BOOT_IS_UPDATED=true fetch_from_repo "$KERNELSOURCE" "$KERNELDIR" "$KERNELBRANCH" "yes" + [[ $? == 0 ]] && KERNEL_IS_UPDATED=true if [[ -n $ATFSOURCE ]]; then fetch_from_repo "$ATFSOURCE" "$ATFDIR" "$ATFBRANCH" "yes" fi @@ -357,7 +362,7 @@ for option in $(tr ',' ' ' <<< "$CLEAN_LEVEL"); do done # Compile u-boot if packed .deb does not exist -if [[ ! -f ${DEST}/debs/${CHOSEN_UBOOT}_${REVISION}_${ARCH}.deb ]]; then +if [[ $BOOT_IS_UPDATED == true || ! -f ${DEST}/debs/${CHOSEN_UBOOT}_${REVISION}_${ARCH}.deb ]]; then if [[ -n $ATFSOURCE ]]; then compile_atf fi @@ -365,7 +370,7 @@ if [[ ! -f ${DEST}/debs/${CHOSEN_UBOOT}_${REVISION}_${ARCH}.deb ]]; then fi # Compile kernel if packed .deb does not exist -if [[ ! -f ${DEST}/debs/${CHOSEN_KERNEL}_${REVISION}_${ARCH}.deb ]]; then +if [[ $KERNEL_IS_UPADTED == true || ! -f ${DEST}/debs/${CHOSEN_KERNEL}_${REVISION}_${ARCH}.deb ]]; then KDEB_CHANGELOG_DIST=$RELEASE compile_kernel fi

Hi, few days delay as I had to do also other things Anyway... By latest I meant respective versions of default NOT dev branches. Thus: Pine H64 - branch next results in kernel 4.19.59 Rock64 - branch default results in kernel 4.4.184 Both had problems to boot. PineH64 did not start kernel at all while Rock64 has some crashes during kernel initialization resulting in no /bin/init. As I had to progress somehow I decided to switch to dev branch. After that numbering changes to: Pine H64 - kernel 5.2.2 Rock64 - kernel 5.2.0 Using dev branch I have successfuly build minimal images for those two boards using Ubuntu Bionic as base. Both boards works fine using mini images. Only one issue I have noted: pineh64:~$ /etc/update-motd.d/10-armbian-header error: could not load font standard Welcome to Ubuntu Bionic with Armbian Linux 5.2.2-sunxi64 This is because there is no standard font for toilet usage. https://packages.ubuntu.com/xenial/all/toilet-fonts/filelist Standard font is available for figlet. But figlet is not installed and not in use by 10-armbian-header script. Shall other available be used instead, like mono12?

Back to main (from my perspective) topic: - Serial MUX board: I have changed analog to digital switching. I.e. instead of 4052 I placed 74HC151 & 74HC238 chips. Used P-MOS IRF7425 are chosen to minimize heat generation. - SD mux board: total redesign here. Eight 74HC157 (quad 2-input multiplexer) are used to connect SD either to SUT or MasterSBC. Only SPI mode of SD is utilized here. From MasterSBC perspective CLK, DI and CS signals are connected to all SDs, while DO signal of every SD card is multiplexed so only only selected card is available at the time. PCBs are designed to use only 2 layers (hence cheaper) with chips in SOIC enclosures. To make those easier for hand soldering. I have already sent for production initial design of Serial-Mux board. I will use it to test some ideas. But before sending next order I would appreciate comments on this design (fairly simple though)

I am using this multiviewer https://www.dmtrade.pl/p8826,multi-viewer-hdmi-4-1-pip-spacetronik-sph-mv41pip.html

I assume all SUTs will also be connected to network by means of Ethernet at least. Then not only uboot/kernel booting proces can be tested but also login via ssh over network as well. Detection if USB ports are working. Proper apt update etc. One thing that will not be tested is the hdmi output. This however can be accomplished easily by connecting SBCs to single monitor via hdmi multi-viewer and camera that will take a picture when needed. I have several SBCs. Several cameras. 4-port multi viewer as well. What I do not have is the topic of this thread But now you shall understand why I am so keen on constructing this mux device

2x595 or MCP23017 - no problem to switch. Actually 595 as simple shift register can be driven by SPI directly, yet on RPi header (first 10 pins) there is I2C, so no big deal to use MCP23017 instead. Why I have chosen 595 initially? As it saves some pennies and footprint. And it it really simple to send command using "software SPI". And commands are to be sent rarely, no need for high speeds. Concept picture of the automated test device: No spacers are visible. Rock64 is a MasterSBC here, it is to be used to control 8 system under test - SBCs. Each of them connected using 10pin header (power + serial) plus custom SD card adapter. On top of the MasterSBC is a (shorter) SD mux board, micro SD sockets placed on both sides of the PCB are invisible, as I have no 3D model for them (MOLEX 47219-2001 one). Also 4 pin headers would be replaced by JST XH2.54 ones. Yes, instead of single SD shared between all SUTs, newest design has 8 SD cards, and MasterSBC can connect those to SUT or to itself for image uploading process. Of course if SDx card is beeing used by MasterSBC, then SUTx shall be powered of as it will not see and SD card "inserted", will not boot. Next to it, top one its serial mux + power distribution board, with 8 sockets of type Molex KK 254 AE 6410 04AKK 254. Both add-on boards works together. When it comes to use cases, one shall use SPI / i2C interface to program 16 bit configuration word. From msb to lsb: ME M2 M1 M0 SE S2 S1 S0 | P7 P6 P5 P4 P3 P2 P1 P0 Meaning of particular bits: - "Px" is power section control (8 independent ports) - "Mx" is a SD card multiplexer control (8 micro SD cards) - "Sx" is a serial interface multiplexer control Meaning of bits ME & SE: ME : 0 - SUTx disconnected from SDx, MasterSBC connected to SDx pointed by M2-0 ME : 1 - SUTx uses SDx SE : 0 - MasterSBC connected to SUTx serial pointed by S2-0, 7-seg led active SE : 1 - No serial link crossed, 7-seg led inactive So with this design all 8 SUTs can be power controlled at the same time, serial console be connected to one of he powered SUT while at the same time other SD card can be used to upload new image. Examples: Upload image to SD card 3, SUT 5 & 7 working, Master listens to Serial from SUT7 0 0 1 1 0 1 1 1 1 0 1 0 0 0 0 0 Upload image to SD#1 (thus) SUT#1 disconnected, all other SUT are working 0 0 1 1 1 0 0 0 1 1 1 1 1 1 0 1 Upload image to SD#1 all SUT are working (SUT1 do not see SD card, will not boot) 0 0 1 1 1 0 0 0 1 1 1 1 1 1 1 1 Comments appreciated. I am attaching also schematics for anyone wanted to take a look. (now with 595 which can be replaced for I2C connectivity). serial-mux.pdf sd-card-mux.pdf

And works for me. I have created set of regular & mini bionic images for pineh64 and rock64. The thing I am struggling with is that latest kernels do not boot :/ but this is different story not for this topic.

Correct

Actually missing } in line 69... I have already informed @Igor via git comment

@lanefu hold yourself with sending for production. Let me build the prototype, and when verified, I will publish final production files.

Two 4mm lanes for 4 SUTs equals 8 SUTs in total. Did that already, so the version with LEDs is now in production ( 5pcs). Hope within a week (DHL) boards will reach my workshop. Be careful, as the gerbers I attached previously are for other version w/o LEDs. As well as BOM and manufacture pdf. Some comments: - for 7seg display essentially all common anode will work with distance between pin rows 5.08mm - 10k resistor, any 0805 will do the job - for assembly one will need "2.54mm 10 Pin Double Row Stackable Long Legs Female Header" and 4 screwed spacer sleeves

Note there was no prototype yet but... Yeah, I cool with it. And surly I will shortly create order. Will try jlcpcb as usually I use seeed studio fusion service. Components I will order from TME, my nearby "local" company I expect that within 1-3 weeks (depending on PCB avaiability) first few boards will be assembled. And I will test them in my workshop.

Good luck! I have compiled dozen of configurations using 4 systems. All went well.

The link I have provided points to line # 171

Yeap, but please modify that line to put there resolvconf

What I was after is to add resolvconf to list of packages to install during image creation. For example here: https://github.com/armbian/build/blob/4b8ce083771800bc1fcb3d284856cc15f5a2c25e/lib/configuration.sh#L171 This is something I have discussed with @Igor. Finally for mini build both network-manager and old style ifupdown shall be available. As it is not standard package, and Armbian defaults to use root account. One can install sudo later on if needed. Very possible as mini build is in WIP mode now Actually I do not know what happens in your build environment. Can you please include console log with this error and surroundings?

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

Should if it is properly configured to use mini branch. Anyway the error you see means resolvconf is not installed. This must by corrected in configuration.sh

@guidol, have you refreshed the git repo?

As for now command line only. Which is not big deal as you an write: compile.sh EXTERNAL=no And continue to use dialogs. Frankly speaking if you do need you can also resign from building kernel source package (time reduction) as well as kernel includes installation. By the way work on relaxing armbian-tools from unneeded dependencies shall also be started. One script I have already rewritten from python to bash. But this is jus tip of the ice berg

Yes Armbian-Configuration depends on those packages. For minimal image building use EXTERNAL=no else you will return to the “server image” level.

Well, the idea was to shrink down image, to contain only subset of packages, i.e. to reduce not only SD card memory usage but mainly bandwidth as smaller number of packages will be subject for upgrade. From operational point of view one shall not see any difference, I mean RAM usage shall stay on the same level.

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 }