jock
-
Posts
852 -
Joined
-
Last visited
Everything posted by jock
-
Hi @nerdherd96 , welcome to the forum HDMI issue is just a news, it is rare but sometimes happens that a box has an incompatibility of some kind. I think @Dragao has the same issue you have, but he didn't report he try to access via ssh AFAIK so can't be sure. Usually it is related to some internal timing calculations done in the kernel to accomodate HDMI signals of the various devices, something that works on a setup may not work on another. Are you trying the box with an HDMI monitor or an HDMI television? If you have the chance, change the cable with another one of another quality or test the box on another TV/monitor and see if you solve the issue. In the meantime I could take a look if there are some patches, especially done by LibreELEC guys, that may bring better HDMI compatibility. Do those tests if you can and want, maybe later we can hangout on telegram!
-
Thanks a lot, I will poke my nose into
-
@ArkhanLK Mmh, I think you have other kind of problems, maybe storage issues, because everything you are describing right now is totally out of any experience I ever had. apt update && apt upgrade should not break anything. If apt breaks something, you must investigate why it happens and solve that problem first, because the issue is system-wide and not related to the media framework. To be honest, there was an issue with lightdm greeter that was preventing the X.org server to start, but should be solved now in the shipped stable image and surely apt upgrade should fix it. Nonetheless you are having issues with the GUI-less system too, so there is something rotten elsewhere. Consider also that in xorg.conf.d directory there is just one file right after the installation, and another file is installed there when the media framework installs the armsoc driver. There should be nothing else than these two files, if you follow the same steps I did. I still can confirm that the Focal minimal image works and the media framework installation script (which does apt update as first step) never encountered a single error. Anyway, storage issues are very subtle and they may cause any kind of unexpected troubles. I don't remember if are using the internal flash an external sdcard, but maybe it worth trying installing on a pristine sdcard to understand the source if issues. Also you may try a mainline kernel image too, and see if apt update && apt upgrade cause the same issues, tinker around with the desktop environment and see if you have issues there too.
-
Do you have the original firmware link to share? I mentioned in the previous post that, since the kernel is quite recent, maybe the original image has some updated firmwares that may benefit other users and other devices
-
Difficult to say what's wrong if you don't provide a log of the boot process and the details and photos of your board. Maybe you have a particular hardware but without any information about I can't say anything. Did you expand the .xz file before writing it to the sdcard? Are the leds in front of the box dimmed or bright? I suggest you to use a proper writer like balenaEtcher which does the extraction and verification of the burnt image
-
Well if you post the log file left in /tmp by the media framework installer maybe we can read what went wrong
-
Great, so I think that this dts should work for you with the original driver: /dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { openvfd { compatible = "open,vfd"; dev_name = "openvfd"; openvfd_gpio_clk = <&gpio2 0x16 0x00>; openvfd_gpio_dat = <&gpio2 0x15 0x00>; openvfd_gpio_stb = <&gpio2 0x14 0x00>; openvfd_chars = [00 04 03 02 01]; openvfd_dot_bits = [00 01 03 02 04 05 06]; openvfd_display_type = [06 00 00 00]; status = "okay"; }; }; }; }; It's just a base to start from, probably you need to change the chars and dot_bits order, but display_type and gpios should be right. Be sure that the log message on dmesg tells you the driver is using fd6551 controller (the enum is defined here) edit: quite interestingly, your original firmware is based upon kernel 4.19, cool! Did the original vendor provide an original pristine firmware? It could be interesting for some updated firmware binaries.
-
@ArkhanLK These are the steps I did: Installed the Armbian focal minimal image I published in the previous post on a sdcard Booted the image, run rk322x-config to configure the system for my board, then rebooted Downloaded the media framework tgz from the linked post on first page, unpacked it and run the installer script with sudo (probably you already know, but the script produces a log file in /tmp directory) Wait for a few minutes until the script finished, then rebooted the box Started kodi with start-kodi command, it booted and everything was smooth. Tried both to stream an mp4 movie from my NAS and also copied another movie on the local system; both movies worked very well with no issues at all. Just tried a few minutes, but everything was just right. Quit kodi, then run apt install --install-recommends armbian-focal-desktop armbian-focal-desktop-xfce lightdm lightdm-autologin-greeter armbian-config Run armbian-config and enabled desktop with autologin from System menu Installed mpv via apt, then run it with the command line of the post on the same movie of above: no problems Installed game data packager with apt install game-data-packare lhasa innoextract, then run it with game-data-packager -i quake to install quake Run quake from command line with glrun quake, it booted, acceleration was active, but there just were a lot of artifacts, but this is expected because of the old Mali drivers. As you see I did nothing particularly strange, maybe the step to install the desktop environment is better handler by armbian-config, but if you need the DE it is even better to use the stable Focal Desktop image.
-
Yes, I was talking about that one. From the plate you may guess it is an AP6334 clone, but instead the kernel detects it as an AP6330. No big deal though, AP6334 is just a bit better than AP6330. True, it can't because you got an fd6551 chip (like my box) and the gpio pins are different too. I don't have the board near me now, I will try to post a suitable dts tomorrow!
-
Hi @ArkhanLK , I don't know what you did but I just tried the Focal image I gave you some days ago + the media framework script and everything went fine. Installation was completed in a few minutes without any error, now I'm playing h.264 movie with Kodi without any issue. edit: tried also mpv under X.org (work fine) and quake via glrun (utterly wrong, but those are the known issues of the Mali driver)
-
@ArkhanLK I will try to take a look today if I have time
-
@chinhhut Yes, the overlay is set correctly, but you didn't even configure the board with rk322x-config. Also no logs = no help.
-
The Latest Focal Image Doesn't Boot On Nanopc T4
jock replied to H1dden's topic in Board doesn't start
I don't have a NanoPI T4, but surely adding verbosity=7 to /boot/armbianEnv.txt file will provide the full kernel log that may provide some hints. Use a spoiler section (the eye in the toolbar) to post the dmesg log to avoid lengthy posts that are difficult to read on phones. -
Don't worry, it was just a side consideration about the wifi chip. You may take a look to find the name of the led driver chip instead (that's the long one on the back of the board in the upper right corner, near the led panel)
-
@lucky62 don't know what's wrong with that, but consider that it is an heavy work in progress, much like an experiment, so anything can be wrong. With the kernel headers in place you should be able to compile the original kernel module too, but the makefile may require some adjustment and surely the dtb properties are defined in another way. If you don't have developer skills I would suggest to wait for something more proper; if you want to investigate further maybe go with original kernel module and ask the author for more details, because I had to guess some things that are not in the documentation digging in the source code myself.
-
Yeah, I'm moving on that front now, the driver is working but it is not really in a shape I really like for most things. Did you see the post where I gave instructions to @lucky62 on how to compile the driver to make it work at least for displaying time and turning on/off leds? That requires a bit of manual handling because there are several led driver chips (I have FD6551, @lucky62 has TM1628, can't read yours from the photo) supported by the driver. They work mostly with the same protocol, but each chip has its own differences and each board wires the led driver chip on different gpios, so you need to take a look into the original dtb. edit: just took a look into the logs you posted... very strange that from the photo your box apparently has an AP6334/BCM4334 clone but the chip declares itself as an AP6330/BCM4330 to the kernel. I may guess that the photo is of another board or chinese are also faking fake chips
-
My fault again, forgot the build directory in the symlink - fixed now.
-
I often clone repositories with git clone --depth 1 -b the-branch-name http://repository-url.com, that's handy because it download just the branch latest data.
-
You forgot to do the symlink, thus depmod -a is not run. You can run depmod -a manually, but if you create the symlink it will be run automatically. Usually I prefer modprobe to load modules, because it handles dependencies too, but insmod should be fine with openvfd since it has no dependencies at all. Yes you're right, my fault! I was missing /plugin/; line just after the header. I updated the post above with the correct dts. Anyway this syntax should suffice: dtc -@ -I dts -O dtb input.dts -o output.dtbo
-
@chinhhut It could be a number of reasons: the board is not perfectly stable, NAND is getting broken, you are hitting a bug which was in the previous image but should be fixed now. Please post the output of armbianmonitor -u after the issue happened for the full logs. Also you can try to append cpu-stability to overlays= line in /boot/armbianEnv.txt and verify if the issue happens again.
-
@lucky62 Here it is the linux kernel + dtb + headers for latest 5.10.37: https://drive.google.com/drive/folders/1OOpjb3L-bFcabKkQKO4GS-hTVzIvKeXo?usp=sharing Install all the three packages via dpgk -i and then reboot. Backup your dtb/dtbo changed files because the directory may be wiped out during the process! This is the kernel module source code modified by me: vfd.tgz And this is the OpenVFDService executable compiled as-is by me from Arthur's original source code: OpenVFDService I modified the kernel module to compile both manually and as a kernel-tree module, but also fixed some dtb nomenclature. To compile, first run this command to create a symlink that may be missing (just run this once): sudo ln -sf /boot/System.map-$(uname -r) /lib/modules/$(uname -r)/build/System.map Then to compile and install: make -j4 sudo make install make install will complain about missing signature, but don't worry, the module will load anyway. Then your dtbo should look like this: /dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { openvfd { compatible = "openvfd,tm1628"; gpio-clk = <&gpio2 0x13 0x00>; gpio-dat = <&gpio2 0x16 0x00>; gpio-stb = <&gpio2 0x12 0x00>; openvfd,chars = [00 04 03 02 01]; openvfd,dot-bits = [00 01 03 02 04 05 06]; openvfd,display-type = <0x00>; status = "okay"; }; }; }; }; Now I took the gpios from the dtb of the X88 you posted some time ago. I hope they are right. The openvfd,* properties are described on Arthur's page and documentation. Those are those which I'm using, but most probably you will need to change them to fit the led configuration of your box. The most evident problem is that the segments turn on wrong displaying unreadable numbers or maybe the indicators (usb/wifi/ethernet/...) are wrongly associated. Each character is controller by a byte, so each led of the 7 segment character is turned on and off by a bit of this byte. openvfd,chars is a map: the first byte is the indicators byte, then comes the first, second, third and fourth characters. On my configuration the indicator byte is the 00, then the first character is mapped to byte 04, second character to byte 03, and so on... openvfd,dot-bits is the map of the indicators: every bit in the indicator byte controls an indicator, there you map which bit is usb, which one is wifi, and so on... openvfd,display-type usually is 00 (normal) or 01 if your display translate by 180 degrees (ie: characters are flipped down and specular) Once you set up the dtbo and activate it in armbianEnv.txt, you can run the OpenVFDService executable: ./OpenVFDService & that will hopefully turn on the display and show you the current time
-
Yes, because it is clearly explained in the first post that this is work in progress. Again: in the first post it is explained what to provide to help people help you. Again: in the first post there are three images published. You tried just one. What about trying the other two and report if they work?
-
Dunno what are reading, first post of this thread explains everything in a series of simple steps. It looks also a little dumb to me that I have to post a link to, but here it is: https://forum.armbian.com/topic/17597-csc-armbian-for-rk3318-tv-box-boards/?do=findComment&comment=122715
-
You're wrong, read better. Plus, there are no DTB files to exchange or replace, there never have been.
-
You don't need the multitool to write an image on a sdcard. Instructions on how to run armbian from sdcard are, as usual, on the first page under the paragraph Quick installation instructions to boot from SD Card Instructions will tell you to run rk3318-config to further configure the board, no need to deal manually with dtbs.