richardk

  • Content Count

    61
  • Joined

  • Last visited

About richardk

  • Rank
    Advanced Member

Recent Profile Visitors

1258 profile views
  1. 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/overla
  2. 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.
  3. 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 inves
  4. Word is, etnaviv driver is pretty good.
  5. 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
  6. 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.
  7. It might be some work, but: https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions
  8. 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
  9. 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/
  10. Below 10C? Around 13C? What's Ambient, 0C? You keep this outdoors, in the Arctic?
  11. 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
  12. 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) 204
  13. 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.
  14. 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 **
  15. 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 /b