richardk

Members
  • Content Count

    53
  • Joined

  • Last visited

  1. 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/
  2. Below 10C? Around 13C? What's Ambient, 0C? You keep this outdoors, in the Arctic?
  3. 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.
  4. 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 ...
  5. 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.
  6. 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 **
  7. 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...
  8. 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 ...
  9. 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...
  10. 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.
  11. 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".
  12. 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
  13. 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
  14. 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...
  15. Hm. Okay. Posts on the pine64 forum led me to believe that they were controllable. https://forum.pine64.org/showthread.php?tid=5847