jock
-
Posts
852 -
Joined
-
Last visited
Everything posted by jock
-
Good to know. I had a very recent experience with a DisplayPort -> HDMI adapter that was performing very poorly (blurred with slightly altered colors) when connecting a regular computer (DP) to a regular TV (HDMI). Changing the HDMI cable magically makes the thing work perfect. Did not investigate the reason. edit: the same HDMI cable was performing fine when connected to the HDMI port of the computer
-
you should just use the rkdeveloptool rd command to make a backup, with appropriate arguments as described in the other thread. Actually I don't know why the other commands fails and the multitool does not boot from sdcard, but maybe you have some sort of encrypted bootloader or whatever. Maybe @hexdump can give a hand.
-
Can't say anything more without further details. Please provide photos of the board (both sides), maybe the original dtb or the original firmware (or a link to a firmware upgrade supplied by manufacturer), the link provided by armbianmonitor -u command. As already said, eMCP boards are quite unknown at the moment, so every detail is essential.
-
Hmmm, very strange, it should use native resolution in both desktop and virtual terminal modes. I had to force disable the 3d acceleration of Lima driver via X.org conf file, it was used to work in X but the last time I tried it didn't. Maybe try posting /var/log/Xorg.0.log so we can take a look into... Also did you try with other HDMI cable and/or other device?
-
Hello @Huafu, yes the legacy image is an older one. Most of my effort now is to support mainline because rk3328 (and thus rk3318) support is already quite mature and hardware decoding is already there. The kernel (5.10) may lack some recent things, but yet I didn't test it by myself so I don't know if hardware acceleration really works. The legacy image is not yet up-to-date with latest bits as you notice, so no rk3318-config and no overlays. Device trees from 5.10 need to be reviewed to work on kernel 4.4 without issues and honestly I'm not very motivated now because everything is moving towards mainline.
-
The armsoc .deb package actually installs the armsoc X.org .so driver (the same as .dll in windows) and places armsoc.conf it in /etc/X11/xorg.conf.d to enable it. Looking at the logs you provided I now see something that actually should not be there... a reference to "Lima" driver, which is not expected in non-mainline kernel... now I'm starting to understand that maybe you got 40-serverflags.conf in /etc/X11/xorg.conf.d directory. If so, remove that file and try again. I will double check this, because the way desktop packages are assembled changed recently in armbian and maybe I did a mistake with some configuration.
-
@Khoa Nguyen The kernel crash does not look specific to a device, but it is happening when a core exit the idle state handling an interrupt. I suspect stability issues, so I suggest you these two things: sun sudo rk322x-config and select rk3228a soc from the list. This limits the highest frequency to 1.2ghz edit /boot/armbianEnv.txt and append cpu-stability to overlays= line do both of them, then reboot the board and try again to install the desktop environment. I have a board with similar issues like yours, and cpu-stability overlay solved my issues so far, I hope it solves yours too!
-
No problems about bothering Can you post the dmesg log or even a photo of the kernel crash dump? Normally if the sdcard is sane there should be no crash of any kind, it should work as good as the internal flash.
-
I understand what you mean, but IMHO finance, sport and shop are "abstract" and generic entities whose keys can exist on some remotes (or other devices), like old tablets and mobile-like devices with physical keys (like blackberrys, for example). Youtube and Netflix are just private companies that tomorrow may disappear or be superseded by others. I don't think there are license issues, but a picky lawyer may want to put a trademark there too...
-
You need the userspace program to support them too, so you're back to the original problem. IMHO there already are hundreds of "abstract" keys (all the KEY_* constants) in the kernel you can use to map any device, I don't exclude that you can use hex values to specify custom key maps, but still the userspace has to catch those custom keymaps to do something useful, so I don't think it is really a kernel problem.
-
Oh ok, I understand. Maybe try to do apt update && apt upgrade via ssh or via virtual terminal, there was a bug in lightdm display manager that was causing issues during X.org boot. If you see the bootstrap messages then your HDMI should be fine
-
The keycodes are defined in this kernel header file (look for the KEY_ constants). Youtube, netflix and others are purely userspace programs. What I would do is map the remote keys to KEY_FN_13, KEY_FN_14 and above, and then use an userspace program (I think xfce has some utility that already allows that) that on KEY_FN_13, KEY_FN_14, ... opens the program you want. edit: you may map the remote keys to KEY_FN_12, KEY_FN_11, and below, map the keystrokes to the userspace program you like, so if you hit F12, F11, ... keys on the keyboard the trigger the same program as the remote.
-
@lucky62 Interesting success story (for rk322x box) to use the box as an hi-quality audio player that can be controller via remote control: https://forum.armbian.com/topic/18178-mxq-rk322x-as-audiophile-music-box/
-
MXQ RK322X as audiophile music box
jock replied to Hai Nguyen's topic in TV Boxes's Rockchip CPU Boxes
Thanks very much for this success and cool story! I will point it from the rk322x big thread as an interesting way to handle both sound/alsa configuration and rc configuration. I underline the need for a linear quality power supply to get high quality output from the connected USB audio device. Maybe connecting a separate DAC with coaxial SPDIF coming out from the box may decouple the two devices so the box could be powered by its own power adapter and only the DAC requires a high quality power supply, but I'm not sure though because coaxial still shares the common ground and it's up to the DAC to have an insulated SPDIF input. Optical SPDIF (never seen any on rk322x boxes) has no such problem though. -
It's uncommon but not so unexpected that the sdcard does not boot. Unfortunately my experience about rk3318 boxes is yet limited. Maybe @fabiobassacan help us spotting a serial port, but also I see that you have three unpopulated and suspect pads near the led panel. Indeed to be sure of what they really are requires an oscilloscope, but often using a multimeter you can read around 1.5v on both RX/TX pins in reference to ground; this is just a hint though, not a sure way to recognize them. Indeed such kind of pads are difficult to solder without a proper precision tool and some skills. What you can also do is put the board in loader/maskrom mode. Pressing the "reset" button behind the AV jack (or spdif, whatever it is) and keeping it pressed while plugging an USB male to male cable in the USB OTG port of the board should bring the SoC in loader mode. Once there, you can do some advanced maintenance using your computer and rkdeveloptool rockchip tool. Clearing the internal eMMC will force the board to boot from sdcard. You can backup, restore and clear the eMMC using rkdeveloptool, you can refer to rk322x (beware: rk322x, not rk3318! Don't use images and multitool for that soc for your board!) thread for rkdeveloptool commands. See paragraph "Alternative backup, restore and erase flash for EXPERTS" in this thread: https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/
-
armbian-config is not available in minimal installations, but you can install it via apt if you need it's configuration capabilities. It allows you to install software, desktop interface, configure timezones and locales, install Armbian to internal flash and lot's of other things. See the armbian documentation if you want further details. You can do whatever you want with your box, you have a fully working debian linux box now.
-
@kruzer FYI, rk3318 branch on my repository is now updated!
-
@lucky62 The key mapping is stored in the kernel, and ir-keytable is a tool to test but also store the key mappings in the kernel, It also allows you to retrieve and restore the whole mapping table at once. You should use ir-keytable to do the mapping, then retrieve the whole table from the kernel and save it in a file, then restore the table in the kernel on every reboot.
-
@beretas Your NAND is detected but is not available to operating system, probably because it is not correctly formatted. I suggest to you to follow the "Upgrade NAND bootloader" procedure from the first page carefully, then your NAND device should be visible from multitool and operating system, thus you will be able to install Armbian on NAND. PS: please don't paste such huge logs in the forum posts: they make the reading very difficult especially on smartphone devices. There is the spoiler section (the eye symbol in the post toolbar) that you can use.
-
Ahh ok, yes I remember the offending patch: it has been fixed in mainline armbian and I just forgot to align the online github repo. Tomorrow I will align. If you're in a hurry, you can even download that patch file from master armbian repository and substitute, it should work.
-
microsd and sd are the same thing, microsd if just smaller. Your board is just another rk3328-based board, but with a rk3318 soc installed. Nothing so fancy, just made this way by the manufacturers to cut some more cost plugging in cheaper socs. Multitool should work fine for you, if you could put images of the whole board and both sides maybe a serial could be spotted. Also do the multitool freeze at boot or Android just boots even if multitool sdcard is inserted? My rk3318 box sometimes refuses to boot from sdcard even if the sdcard is inserted, so maybe try three or four times to unplug and replug power before giving up with multitool.
-
@lucky62 The legacy rockchip kernel (the Android one) uses a special driver from rockchip to handle the infrared module, but the mainline kernel uses the standard gpio-ir-receiver driver, which is already in the dtb: https://github.com/paolosabatino/armbian-build/blob/0a7db86c08d77e73c3fba97487d66defa36768ce/patch/kernel/archive/rockchip64-5.10/board-tvbox-rk3318.patch#L199 Also the gpio pin of the ir receiver is correcly configured in the armbian dtb, so it should work. I remember I tested on my board and the hardware layer was working. Maybe you need instead to configure the remote keymapping. For that use you can ir-keyable utility, in particular, ir-keytable -t should help you test the remote. Usually box remotes use the NEC protocol. In the device tree I can also add a "default" keymapping, but actually I forgot to provide one of that and should recompile the image. Tomorrow I will take a look to this too. In the meantime, if you can report that the remote keystrokes are detected by ir-keytable -t may just confirm that the hardware works.
-
@kruzer it looks like a patch is not applied or sort of. You can take a look into output/debug/patching.log if all the patches are applied correctly, but tomorrow I will take a look myself if the github repo is correctly aligned, can't remember if I have some fixes not yet uploaded in my local repository.
-
Try this experimental image posted here: https://forum.armbian.com/topic/12656-csc-armbian-for-rk322x-tv-boxes/?do=findComment&comment=123438 I can't see the photo of your board, but from the board name it clearly has an eMCP module, which is completely untested and at the moment the stable image does not boot on them. I'm still thinking about a workaround, but without the hardware in my hands it could take a while...
-
@beretas please post the result of armbianmonitor -u. Also run sudo rk322x-config and reboot the board to see if the NAND is detected