Jump to content

MaxT

Members
  • Posts

    96
  • Joined

  • Last visited

Recent Profile Visitors

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

  1. Developing solutions and sharing by sending PR and/or using customize image script might be the way address those.
  2. I guess you need something similar to udev rule for Logitech Fn key: http:// https://github.com/sta-c0000/logitech-keyboard-udev-rules. IMHO it is more reliable and less resource hungry vs software package, but I have not seen alike for a Win key. So it might be necessary to spy on software doing this and develop udev rule for win key. May be someone on the forum having enough experience could help.
  3. It would be great, if you could post results of all your findings here, so that someone else could save a few hours on this problem and rather spend them on another one;)
  4. I would open the box make photos of the board with silk prints visible and search similar box in a relevant section of tv boxes on this forum. Name on the plastic box means nothing, silk prints on the board and SoC itself might help.
  5. Probably marking on the board is the only what really matters.
  6. Thanks, very helpful. Maybe someone will be able to bring some light on how second partition could appear (uboot update script transition bug?), while being not a part of Armbian's functionality.
  7. Context of the TV boxes section might be helpful, especially in the sticky thread re their status in Armbian.
  8. If tester is not available, I'd try powering failing ports with their respective cables but feeding them from pins powering other ports (eg with wires from some molex cable, just need to be careful with polarity and shortcuts) and then powering working ports from pins on the board feeding failing ports - to exclude failure of the power rail feeding these ports on the board. If cables are faulty, I'd check them for electrical connections and if they are ok, would replace capacitors.
  9. Disabling automount (drive letter assignment) in windows before flashing might help - probably it is mount time when windows is checking and changing partition table.
  10. I wouldn't be so categorical - I have rock pi 4b, which never saw android or any os other than armbian, which has same thing- two boot devices on emmc. Since it doesn't bother me, I didn't investigate further.
  11. If I remember correctly, recently there was a similar thread on the forum re GPT corruption under windows. Not sure, but there might be some useful info. Alternatively, flashing under Linux might be an option.
  12. WSL might be easier if you're on windows
  13. Either of those, I personally used Ubuntu running in ESXi VM
  14. Are you joking? Open readme.md in GitHub repo, read it and explore links therein
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines