richardk

On the main armbian.com page are three boards depicted as "Popular downloads". I was just wondering, what are the most popular downloads, perhaps the top five downloads over the past month? Might be interesting to someone looking for a popular and well supported board. Besides Raspberry Pi, that is...

Just to summarize: 1. Use dtc to de-compile the existing rockchip-spi-spidev.dtbo to .dts: dtc -I dtb -O dts /boot/dtb/rockchip/overlay/rockchip-spi-spidev.dtbo -o rockchip-spi-spidev.dts 2. Edit the resulting rockchip-spi-spidev.dts and change instances of ff1c to ff19, and 3399 to 3328 3. (optional?) remove references to spi1, spi2, spi3 4. Compile rockchip-spi-spidev.dts back to dtbo dtc -I dts -O dtb rockchip-spi-spidev.dts -o /boot/dtb/rockchip/overlay/rockchip-spi-spidev.dtbo 5. Extract rockchip-fixup.script from /boot/dtb/rockchip/overlay/rockchip-fixup.scr (just use a text editor, and delete everything before "# overlays fixup script") 6. Edit rockchip-fixup.script and change instances of ff1c to ff19 7. Recompose rockchip-fixup.scr mkimage -A arm -T script -C none -d rockchip-fixup.script /boot/dtb/rockchip/overlay/rockchip-fixup.scr Now, you can use armbian-config to add spidev, and reboot.

I had tried setting armbianEnv.txt mode 0444, but that failed. The corrupted armbianEnv.txt file still had mode 0444. I am now trying modified /usr/lib/armbian/armbian-hardware-optimization and armbian-firstrun scripts, with lines that modify armbianEnv.txt commented-out. So far so good.

I've been investigating a few devices (Rock64, Armbian 19.11.3 "stable") where the first bytes of /boot/armbianEnv.txt gets overwritten with the contents of /etc/logrotate.d/alternatives. The first time, I concluded it was power-loss-related filesystem corruption. But, then the exact same thing happened again; the same data overwrites the same place in the same file. That's when it became a concern. When deployed, these devices will have power protection (UPS, and power loss notification), but during development many have simply lost power. Should I continue to investigate, or should I assume that power protection will solve it?

Word is, etnaviv driver is pretty good.

What about a NanoPI NEO in an enclosure? https://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=132 https://www.friendlyarm.com/index.php?route=product/product&path=89&product_id=137

Rock64 Rev 3 has the same 4-pin POE connector as Raspberry Pi 4 does. But, that's not as small of cheap as your Zero. Most cost-effective right now is just, buy a POE "splitter" to go with the SBC.

It might be some work, but: https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions

Oh, I was trying to suggest that sources & patches for a Maaxboard (NXP i.MX8) bring-up could be perhaps be sourced from the Solidrun effort. I wasn't suggesting that if ya want an iMX8 buy it from Solidrun. (I do think their stuff is good; there's Cubox-i Armbian support and I've used it.) Another source for i.MX8 kernel sources might be Robert C Nelson. https://www.digikey.com/eewiki/display/linuxonarm/MCIMX8M-EVK (Oh - RCN now has a Rock Pi 4 page, https://www.digikey.com/eewiki/display/linuxonarm/ROCK+Pi+4. Interesting to have that option. I might try that out.)

The Hummingboard Pulse and CuBox Pulse (i.MX8M-based) have Debian available. Might be a place to start. https://developer.solid-run.com/article-categories/i-mx8m-software/

Below 10C? Around 13C? What's Ambient, 0C? You keep this outdoors, in the Arctic?

SUCCESS. I've got it booting the second partition. Lessons: armbianEnv.txt really wants UUID=. If you make a new partition, make sure to match UUIDs. Edit boot.cmd; find: echo "Boot script loaded from ${devtype} ${devnum}" Before that line, add: setenv partnum "2" setenv devnum "${devnum}:${partnum}" That's how it's working. I thought I could adjust so that it took partnum=2 from armbianEnv.txt (and move the new setenv devnum down after armbianEbv.tct is loaded). I don't know why that didn't work; I might have messed something else up. Anyway, I'm good to go.

Well, progress made. Added to boot.cmd: setenv partnum "2" setenv devnum "${devnum}:${partnum}" After that, the kernel image gets loaded, but shortly thereafter it resets and boots again... [ 44.604791] reboot: Restarting system The device tree seems to be unresolved... Scanning mmc 1:2... Found U-Boot script /boot/boot.scr 3048 bytes read in 21 ms (141.6 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1:2 171 bytes read in 18 ms (8.8 KiB/s) 8018124 bytes read in 394 ms (19.4 MiB/s) 20498944 bytes read in 959 ms (20.4 MiB/s) 51131 bytes read in 33 ms (1.5 MiB/s) 293 bytes read in 38 ms (6.8 KiB/s) Applying kernel provided DT overlay rockchip-spi1.dtbo 2698 bytes read in 32 ms (82 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND ## Loading init Ramdisk from Legacy Image at 04000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 8018060 Bytes = 7.6 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to fc75b000, end fcf0088c ... OK reserving fdt memory region: addr=1f00000 size=72000 Loading Device Tree to 00000000fc6e6000, end 00000000fc75afff ... OK Starting kernel ...

It loos like maybe "first partition" is coded into boot.scr... # get PARTUUID of first partition on SD/eMMC the boot script was loaded from if test "${devtype}" = "mmc"; then part uuid mmc ${devnum}:1 partuuid; fi I'll need to edit boot.cmd and recompile boot.scr.

Sigh, no change using /dev/mmcblk1p2. Found U-Boot script /boot/boot.scr 2949 bytes read in 21 ms (136.7 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 reading /boot/uInitrd ** Unable to read file /boot/uInitrd ** reading /boot/Image ** Unable to read file /boot/Image ** reading /boot/dtb/rockchip/rk3328-rock64.dtb ** Unable to read file /boot/dtb/rockchip/rk3328-rock64.dtb **

Well, firstly don't overwrite your u-boot sectors with a fat partition. Nothing works. Secondly: rootdev=/dev/mmcblk0p2 isn't it either. I get: This seems like the relevant portion of the log: mmc1 is current device Scanning mmc 1:2... Found U-Boot script /boot/boot.scr 2949 bytes read in 21 ms (136.7 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 1 reading /boot/uInitrd ** Unable to read file /boot/uInitrd ** reading /boot/Image ** Unable to read file /boot/Image ** reading /boot/dtb/rockchip/rk3328-rock64.dtb ** Unable to read file /boot/dtb/rockchip/rk3328-rock64.dtb ** It appears it found /boot/boot.scr, but then didn't find other files. Oh - maybe it's mmcblk1p2...

Wow, copying the contents of p2:/boot in ext4 to p1:/boot in FAT is worse. Gets into a loop... SdmmcInit=2 0 BootCapSize=0 UserCapSize=0MB FwPartOffset=2000 , 0 SdmmcInit=2 0 BootCapSize=0 UserCapSize=0MB FwPartOffset=2000 , 0 SdmmcInit=2 0 ...

Okay, make sure to set BOOT flag on the second partition. Adding setenv rootdev "/dev/mmcblk0p2" to armbianEnv.txt to the second partition's /boot/armbianEnv.txt doesn't work. Moving on...

I'm trying to create a microSD card to boot Armbian, but first would be inserted into a Windows laptop to edit some configuration. To make the microSD show up in Windows, the first partition must be a FAT partition, and so Linux would be ext4 partion 2. I suspect I'll need to put the /boot partition on the FAT volume, with directions to load from mmcblk1p2. In case it matters, this is a Rock64 without emmc. I've just started this research, but I'd be grateful for any u-boot-savvy person's help here. Thanks.

Instead of (unsigned long) you might choose (intptr_t); specifically, that's the C data type for "an int the same size as a pointer".

Furthermore... these i2cset commands work: i2cset -f -y 1 0x18 0x52 3 # turn off both LEDs i2cset -f -y 1 0x18 0x52 2 # turn off white, turn on red i2cset -f -y 1 0x18 0x52 1 # turn off red, turn on white i2cset -f -y 1 0x18 0x52 0 # turn on both red and white

It seems Armbian is missing out in some way. The Pine64 folks know how to control them. https://forum.pine64.org/showthread.php?tid=5764

Okay, I see, they are connected to out1 and out2 on the RK805 PMIC. So they wouldn't be just GPIOs. But - presumably - the RK805 could be told how to control them...

Hm. Okay. Posts on the pine64 forum led me to believe that they were controllable. https://forum.pine64.org/showthread.php?tid=5847

I have a C++ app that wants to indicate its activity by blinking an LED on the Rock64. How can the LEDs be controlled? The sysfs leds do not appear to be present. I'm okay with libgpiod or sysfs gpios, but I don't know what gpio numbers represent the LEDs. Anyone know? Thanks. Linux rocky64 5.0.0-rockchip64 #5.85 SMP Wed May 8 19:38:28 CEST 2019 aarch64 aarch64 aarch64 GNU/Linux Distributor ID: Ubuntu Description: Ubuntu 18.04.3 LTS Release: 18.04 Codename: bionic