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