• Content Count

  • Joined

  • Last visited

1 Follower

About jock

  • Rank
    Embedded member

Recent Profile Visitors

2369 profile views
  1. @Alex83 can't really say what is broken with your configuration. ssv6051p received little to nothing changes, except for an optimization compile flag and the disable of the p2p interface which was causing reboots and crashes and slowing down the connection. Slow boot times may be due to many things. Not able to connect is one of them, but can be a faulty NAND, a network device mount that is not waiting for timeout, etc... etc... Try to do apt update && apt upgrade to get the latest packages up to date. Post armbianmonitor -u link the help in troubleshooting
  2. That's the most probable explanation. The idbloader is the most vulnerable part in terms of breakage: a totally wrong (ie: no binary signatures) idbloader is discarded by the SoC, but an apparently good one will make the board stay stuck at boot time without any further chance to recover it. Do you have a serial attached to the board? If something is coming out of the UART so we could at least figure out where the board is freezing. Just to be sure, did you try the OTG USB port for maskrom mode? Others won't work, only the OTG port will show up as external device using the mal
  3. Did you have any problems before? Stock bootloader does not support USB boot, you have to use an sdcard if you want to boot using the multitool. If you don't have any sdcard slot, you can use rkdevtool (or rkdeveloptool for linux, better but only command line) to write directly the armbian image on the board. This is generally very safe, but in very rare hardware configurations the bootloader shipped with armbian refused to load. In this unfortunate case, you may be able to follow the unbrick procedure described in the first page.
  4. I'm always happy about tidying up things, and tv boxes section is still far from being ideal. Honestly I don't know if it is a wise idea to have a section "TV Boxes running Armbian" and I explain why: it could work well with serious and proper brand products, but if you mean to tidy up the forum against the chinese brands, well, we have to face the reality that cheap chinese tv boxes don't have any proper nomenclature. Often you get a recognizable pattern, sometimes you don't. This is especially true for the cheapest products and so things that have the same market name may have a different ha
  5. @Attilatilla Ok, fixed the device tree and updated the legacy kernel images in the first post. They are still for testing, but seems to work fine so far with the media installer for tinkerboard in the apt repositories (don't remember the actual package, just search for tinkerboard and you'll probably find with ease). I tried only the debian minimal image and Kodi was starting fine. Did not try any video though. Feel free to report here!
  6. @Joãobt If you're going to follow @SteeMan suggestion, please report here your experience!
  7. @qiheng Very cool that you solved the issue Just to recap for future users: the mainline 5.10 kernel is working fine but the legacy 4.4 kernel was not working? Or you just added verbosity=7 and things started to work?
  8. First page -> instructions for experts (ie: use male-to-male cable, rkdeveloptool and maskrom mode)
  9. I looked into the dts and there are no clear differences which are hampering the booting process against the rk322x-box device tree. I talked with @fabiobassa and we thought that you should enable logging through the serial port that maybe can give some more hints. Normally kernel logging happens on the HDMI, but you should switch to serial console. You should modify the file in /boot/armbianEnv.txt and add: verbosity=7 extraargs=console=ttyS2,115200n8 But you have the problem that probably can't access the eMMC from your computer. To overcome this, you shou
  10. Reasons can be many, yours is not a regular tvbox too, which may have a very different hardware configuration, thus the regular rk322x-box device tree may or may not work. Providing the original DTB can be very useful to understand what's wrong. The issue can be in the dtb or even in the kernel configuration because I never had the chance to test a 512mb board so some settings may need to be fixed for that reason. Also providing the original android boot log is very helpful, that's a matter of reverse engineering and if you don't provide anything it is too hard to guess what's wrong.
  11. The orange led flashing is indicating the Multitool booted and is waiting for you input. You may try to unplug and replug HDMI cable while the led is flashing. Some people reported it worked. Otherwise the causes may be too many, including an unsupported TV/monitor due to some HDMI clock issues. HDMI clocks are a moving target and issues always arise with some uncommon or untested TVs. Try with another HDMI device too, or even an image with the mainline kernel, can't tell anything more without dmesg logs and other details.
  12. @JVMS Thanks for the photos of the board. Do you have any problem or is it working fine? Everything should be supported out of the box, but leds may have a different wiring from the common chiptrip/r329q setups. In that case, the original DTB file that comes from the stock android is very helpful
  13. @Attilatilla For you information, I did some testing using the latest ffmpeg/kernel patched for rockchip hardware decoding, but had no success yet. Since @JMCC found his way to integrate the media installer for rk3288 too in the armbian repositories, I guess I may reconsider to pour some love into bringing up back the rockchip 4.4 legacy kernel for people who wants video/3d hardware acceleration made easy, so stay tuned!
  14. That's all in the loader you uploaded on the eMMC. I don't know how you did that or where you got it so can't really guess what is happening, but once you put a loader on the eMMC everything is passing through that. Also "the loader" is made of several steps: ddrbin -> miniloader -> uboot + trustos. Which step is misbehaving is unknown to me because I can't know what software you placed on your eMMC. If the multiboot is not booting anymore, blame the loader. The dtb I provided has to be placed in the armbian /boot/dtb directory, in place of the existing dtb; it
  15. Happy you're happy, but performance should not be so much worse: legacy and mainline have similar CPU performance and usually legacy has better compatibility