richardk

Members
  • Content Count

    60
  • Joined

  • Last visited

About richardk

  • Rank
    Advanced Member

Recent Profile Visitors

982 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 investigate, or should I assume that power protection will solve it?
  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 out.)
  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 might have messed something else up. Anyway, I'm good to go.
  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) 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 ...
  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 /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...
  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 ...