AdamD

Members
  • Content Count

    10
  • Joined

  • Last visited

About AdamD

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @tonymac32 & @igor - I just wanted to follow up here as I believe I might have been mistaken regarding the SD card updates. Although, the emmc models originally bricked right after first reboot after that 5.70 update, the SD units did not... I thought the updates had completed successfully after getting a chance to check up further today, it appears i was wrong, and the SD models did not fully update as I had thought: This is how the 5 SD units were reporting at time of update, Welcome to ARMBIAN 5.60 stable Debian GNU/Linux 9 (stretch) 4.4.156-rockchip after now after update: Welcome to ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.4.166-rockchip where as, for the 3 emmc models, after the initial update, reboot, and fix provided by tony above, they now report: Welcome to ARMBIAN 5.70 stable Debian GNU/Linux 9 (stretch) 4.19.14-rockchip Is the 4.19.14 vs 4.4.166 difference expected for SD / emmc boot ? or, could this be additional update issue on the SD models that i overlooked when dealing with the dead emmc's...?
  2. you are my hero tonight. my cluster is running again. i can go back to sleep now..
  3. ah your right, the file i transferred over didn't keep.. .. i just reconnected the unit and the files missing again.. will try again... and no sd in these units. Thanks for the help! will pick up tomorrow
  4. no, unplugged, replugged.. tried on 2 of the 3 units before reply as well..
  5. Is this my prob? setenv fdt_file "rk3288-miqi.dtb"
  6. # DO NOT EDIT THIS FILE # # Please edit /boot/armbianEnv.txt to set supported parameters # setenv rootdev "/dev/mmcblk0p1" setenv rootfstype "ext4" setenv fdt_file "rk3288-miqi.dtb" setenv ramdisk_addr_r "0x21000000" setenv console "ttyS2,115200n8 console=tty1" setenv verbosity "1" itest.b ${devnum} == 0 && echo "U-boot loaded from SD" itest.b ${devnum} == 1 && echo "U-boot loaded from eMMC" if load ${devtype} ${devnum}:1 ${ramdisk_addr_r} /boot/armbianEnv.txt || load ${devtype} ${devnum}:1 ${ramdisk_addr_r} armbianEnv.txt; then env import -t ${ramdisk_addr_r} ${filesize} fi setenv bootargs "consoleblank=0 scandelay root=${rootdev} rw console=${console} rootfstype=${rootfstype} loglevel=${verbosity} rootwait usb-storage.quirks=${usbstoragequirks} ${extraargs}" ext4load ${devtype} ${devnum}:1 ${fdt_addr_r} /boot/dtb/${fdt_file} || fatload ${devtype} ${devnum}:1 ${fdt_addr_r} dtb/${fdt_file} || ext4load ${devtype} ${devnum}:1 ${fdt_addr_r} dtb/${fdt_file} ext4load ${devtype} ${devnum}:1 ${ramdisk_addr_r} /boot/uInitrd || fatload ${devtype} ${devnum}:1 ${ramdisk_addr_r} uInitrd || ext4load ${devtype} ${devnum}:1 ${ramdisk_addr_r} uInitrd ext4load ${devtype} ${devnum}:1 ${kernel_addr_r} /boot/zImage || fatload ${devtype} ${devnum}:1 ${kernel_addr_r} zImage || ext4load ${devtype} ${devnum}:1 ${kernel_addr_r} zImage bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr
  7. so just copying rk3288-miniarm.dtb into /boot/dtb-4.19.14-rockchip folder and powering on is same red light.. another step?
  8. yes. all 5 of the non-eMMC are functioning fine so far.
  9. Hi all, first post here so please forgive me if I've get any bits wrong. Thanks for all the work put into supporting this project, and thanks in advance for any and all considerations extended in helping me step through my issue here. so i've had an 8 node kubernetes cluster running fairly smoothly on my tb's for nearly a full year now, so far I have not had any major issues with armbian updates until this weekends... I did a round of updates to my cluster and, after rebooting all 3 of my model S tinkerboards seem bricked (redlight only, no output to HDMI).. The remaining five orig TB models with Samsung EVO SD's all came up without issue... since my k8s cluster master is one of the S models i'm really hoping there is someway somebody knows to quickly back out and salvage these machines without a full cluster rebuild... I was thinking there might be an option because I can connect the boards via usb to pc and I am able to view the drive contents... just not sure where to look to fix a u-boot issue or if it's even possible this way. I've just ordered a UART->usb adapter as it looks like I'm going to need one now, but it won't be here until mid-week. Im not sure what other information you might need or that i can get from the boards for you, but I've also attached the last console log of the machines at time of final reboot, HTH.. I'm guessing my questions at this point are: 1) Any known issues or anyone else having issues with S models after the last update to 5.70 ? 2) Any other ideas on how I can debug or recover these machines before I receive a UART adapter? 3) Any other references to point me at to further debug this issue properly? best regards, -ad