gufmar

I tested this on multiple v1.3 and 1.4 Boards In the boot sequence the message appears. `A start job is running for Bluetooth Rockpi (3min 1s / no limit)` The boot process continue for other tasks but never completes, even after waiting for hours. All boards boot fine with 20.08

loving this Armbian forum and community. It works great! TYVM

I try to build a customized image as described in https://docs.armbian.com/Developer-Guide_User-Configurations/#user-provided-image-customization-script and by using the template with the OpenMediaVault example https://github.com/armbian/build/blob/master/config/templates/customize-image.sh.template The goal is to build an image who auto-execute an initial setup script after being flashed and frist boot. The device has connected RGB-Leds and an OLED I2c Display on the GPIO pins. It should give color signals durring this initial setup, and then show system parameters (especially the DHCP-Address) on the oled screen *without* having a keyboard and HDMI-Display connected. It generally works but I have some questions: crontab @reboot execution only works when I first set a root password and remove the not_logged_in_yet file. The customize-image function then - overlays a precompiled dtb file - creates a shell script file with commands for execution after first boot - this script is marked as executable - and finaly added to crontab this last crontab command returns a "no crontab for root" in the build console, but is then added and also executed. (but only if I first chpasswd the root user) PrepareDevice() { echo root:1234 | chpasswd rm /root/.not_logged_in_yet # I2c tuned to 400kHz cp /tmp/overlay/boot/dtb/rockchip/rk3399-rockpi4b.dtb /boot/dtb/rockchip/rk3399-rockpi4b.dtb mkdir /initial-setup cat > /initial-setup/step1.sh <<- EOF #!/bin/bash # turn blue RGBLed on as a first sign of life cd /sys/class/gpio echo 154 > export cd gpio154 echo out > direction echo 1 > value # setup and configure the I2c OLED display apt-get --yes --force-yes install git git-core build-essential apt-get --yes --force-yes install python-dev python-pil python-smbus python-setuptools python-pip apt-get --yes --force-yes install i2c-tools libi2c-dev lm-sensors pip install psutil # blink as debug info echo 0 > value sleep 1s echo 1 > value # add the OLED script on every future reboot (crontab -u root -l; echo "@reboot python /root/OLEDisplay/sysinfo.py --display sh1106 --i2c-port 2 --rotate 2" ) | crontab -u root - # remove the initial setup on-boot execution crontab -u root -l | grep -v 'initial-setup/step1.sh' | crontab -u root - reboot EOF chmod +x /initial-setup/step1.sh echo "add crontab for step1" # execute the initial-setup shell script on first boot line="@reboot /initial-setup/step1.sh" (crontab -u root -l; echo "$line" ) | crontab -u root - } So far all ok. The device boots up and the blue led turns on as expected. But then for some (unknown) reason the apt install commands and crontab edits does not work as expected. It works when I connect a keyboard and HDMI display, log in as root and execute the `/initial-setup/step1.sh` The question is if there is a general better way or if someone can tell me how to set and remove the crontab scripts ?

they are all 1.3

Yes most of all my boards run on eMMC (just started experimenting with the NVME extension) I never noticed a difference between A and B regarding eMMC behaviour. I'm not sure if it is related (or my mistake) but 3 from my 8 eMMC cards are not recognised anymore at full size. As they appear with onle 1/8 of size, I guess it is some mistake between 4096 and 512 sector size, happened either on disc resizing after boot, or re-flashing with etcher (on a notebook with weird SDCard driver) I wasn't able to bring them back to original capacity with whatever operating system, device and partitioning tools I tried. I also tried with a usb-2-emmm adapter but no luck. But this didn't happen during normal operation, but while playing around, flashing, re-installing. So in my eyes not a Board or eMMC failure. All other eMMC modules run fine for many months now, with quite a lot of software compilations and benchmarking tests (phoronix).

Is this something related to the overlay file, or where do I have the chance to play with this value? By using the python spidev library I can set something like spi.max_speed_hz=10000000 But I can't see any effect. Also spi.xfer has some factor and it looks like it depends a bit on the HW, wiring and CPU components spi.xfer(tx.tolist(), int(4/1.25e-6)) #works, on Zero (initially didn't?) #spi.xfer(tx.tolist(), int(4/1.20e-6)) #works, no flashes on Zero, Works on Raspberry 3 #spi.xfer(tx.tolist(), int(4/1.15e-6)) #works, no flashes on Zero #spi.xfer(tx.tolist(), int(4/1.05e-6)) #works, no flashes on Zero #spi.xfer(tx.tolist(), int(4/.95e-6)) #works, no flashes on Zero #spi.xfer(tx.tolist(), int(4/.90e-6)) #works, no flashes on Zero #spi.xfer(tx.tolist(), int(4/.85e-6)) #doesn't work (first 4 LEDS work, others have flashing colors) #spi.xfer(tx.tolist(), int(4/.65e-6)) #doesn't work on Zero; Works on Raspberry 3 #spi.xfer(tx.tolist(), int(4/.55e-6)) #doesn't work on Zero; Works on Raspberry 3 #spi.xfer(tx.tolist(), int(4/.50e-6)) #doesn't work on Zero; Doesn't work on Raspberry 3 (bright colors) #spi.xfer(tx.tolist(), int(4/.45e-6)) #doesn't work on Zero; Doesn't work on Raspberry 3 when I change the timing I can see best (but not perfect) results with 4/.70e-6 As this code example also mentions (first 4 LEDS work) I can only drive the first two LEDs - whatever value I try. So I wonder if the "base frequency" is set to the optimal value and how I can cange it (without having at hand a singal analyzer to verify)

still some fine-tuning required but .... it works !

yes. First kernel compilation in my life, worked fine, with expert mode (at least afaik for now ;- ) no, will do this evening. I wasn't sure if I need to do this as for I2C in the dts/dtb file (okay) or somewhere else. Thanks.

ok, whatever I did, the flashed eMMC booted up and run fine. But there is still no /dev/spi* device. Do I need to enable it in the .dts file and recompile to to dtb (similar as with i2c devices) ?

TIL: there are many branches. thanks. will try my best.

This sounds great! So I while waiting the setup of my new armbuilder vm, I read through the https://docs.armbian.com/Developer-Guide_Build-Process/ and https://docs.armbian.com/Developer-Guide_Build-Options/ and wonder if I need some special options set or if I can just go with defaults? (I checked out the build repo after your two commits, but as far as I can see it's master, not DEV branch)

Instead of breaking the (bright) onboard LED's it might be a good idea to use some small piece of black tape. This topic is interesting because I'm also currently working on LEDs on the RockPi. The very bright green LED is very well suited to make the logo appear in a 3d-printed case. But it can only light up in one colour. A first problem arises when the M.2 NVME adapter board is screwed on top and hides the green light. I could connect an RGB LED (cathode) to the GPIOs. But it would need 3 digital (PWM) pins. So I looked at the small WS2812 LED modules. The existing libraries are made for RPi boards with either PWM, PCM or SPI-MISO As SPI1 on RockPi is used for the SPI-Flash and boot functionality, I tried to enable SPI2 and use Pin 29 (TXD) to generate the serial bit sequence for the WS2812 chips. With the Help of @martinayotte ...I was able to activate I2C (which in newer releases now is enabled by default) and fill the OLED devices with the LUMA library. But whatever I tried - by using the current stable or nightly Armbian Bionic build - I wasn't able to se /dev/spi* devices or use them in any other way. TBH I'm not an expert and have no clear idea what of the following things should or must play together and what are different approaches that shouldn't be mixed. First I tried to enable SPI in the decompiled .dts file like I did with the I2C port status = "okay"; compatible = "spidev"; spi-max-frequency = <1000000>; then I also tried to install libmraa and turn on SPI switches in /boot/hw_intfc.conf as described in https://wiki.radxa.com/Rockpi4/dev/libmraa I guess many other approaches like a layer acting as an universal SBC GPIO library like or also https://github.com/rahul-thakoor/rust_gpiozero still require the SPI* devices enabled and working at OS level. I also tried to look into documentations like http://linux-sunxi.org/SPIdev and adopt it to the RockPi specs, but no luck. So for now it looks more like I must consider to keep my project simple (static green LED and no covering NVME) or I try to get some hints here in this forum...

Ah thanks will try again

The buster image boots up, and has both Ethernet and Wifi devices enabled. But no IP packets leave or reach the board, trying both dhcp or static setup, on ipv4 and ipv6. Ping shows destination unreachable msgs. Eth0 interface shows up in desktop GUI as well as armbian-config tool and with ip interface command Switching to an eMMC with bionic image works fine.

I have a and b versions in my lab (all 4GB equipped) Do you still need some confirmation/verification?