richardk

Members
  • Content Count

    60
  • Joined

  • Last visited

About richardk

  • Rank
    Advanced Member

Recent Profile Visitors

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