-
Posts
852 -
Joined
-
Last visited
Everything posted by jock
-
I spent some time on openvfd driver, and it works on my box. I forked Arthur's repository to make my own modifications, because I wanted to add some more standard things like the capability to use the linux triggers to make the indicators blink on mmc access or during ethernet/wifi transfer, etc... and the ability to invoke the driver module specifying the right entry in the dtb. The thing requires some bits in the dtb and can be compiled directly on the board, but you need the kernel headers to do that. If I have time tomorrow I can push the deb packages for a newer kernel + kernel headers and some source code to let you compile an work in progress version.
-
@Luis If the led blinks, the kernel should be up and running. The problems may be only related to HDMI output. Some users reported events like this in the past, but we got not enough feedback. We tested quite a lot of boards and never had such issues with HDMI so far, so can't be more specific. Actually the same HDMI timings and source code is shared with LibreELEC, so can't really say if there is really something wrong with your board or with the kernel code. The only suggestions I can give you is to experiment changing the HDMI cable and TV/monitor to see if something changes. Often lousy HDMI cables cause lot of troubles. If the board is working, you can connect it to your network via ethernet cable and access it via ssh (username: root and password: 1234) That would be a proof that the board is running, from there you may post the results of armbianmonitor -u
-
Hello, I neither have the boards you have nor the AP6212 wifi chip in any of my boards, but I can tell you that bluetooth is generally quite a beast. I have had experience with AP6330 and AP6334 (a clone, actually) and spent countless hours trying to sort things out. First of all, the bluetooth adapter on the same chip of the wifi, but is actually a separate device. The wifi part is connected to the system via SDIO bus, but the bluetooth is connected via a simpler UART serial port. The dmesg logs you provided are not showing anything related to the bluetooth hardware part, but just some software modules/components, you should provide the complete dmesg log (please put them in a spoiler section), because things happen in out-of-order fashion when device are initialized. Anyway, if you are very very lucky, running hciattach is everything you need: /usr/bin/hciattach /dev/ttyS0 bcm43xx 1500000 the program will not put itself in background, and you need to keep it running if you want to access bluetooth device. In case it works, you may want to create a systemd service or a script that runs at boot. Change ttyS0 with the serial port your bluetooth adapter is internally connected. You may need to put the right firmware file in /lib/firmware/brcm, I don't know which one is required so you have to discover it by yourself. Maybe it is already there. In case this does not work, debugging may take ten minutes to several hours/days and unfortunately requires quite a knownledge to deal with.
-
Hello, as @lucky62 said, 5 minutes is too much time. Usually after 10/15 seconds you already have some logging on the HDMI monitor. In the first thread page, at the bottom, there is a list of useful things you can provide to help in debugging. Just to be sure, did you try the Focal desktop image with mainline or legacy kernel? Trying the other options can add further hints that may help understanding.
-
@ArkhanLK you're too kind Well the media framework was compiled with a Focal of one year ago or so... maybe the packages have been updated in the meantime and now they are not compatible anymore - that's the only thing I can think about. Actually nothing is really tied to lightdm, armsoc is a general driver for X.org and maybe something changed in X.org with latest Focal packages that made it not work anymore. It is very curious rkmpp does not install though, as far as I remember it had no very important dependencies. Did you install the packages via apt-get install or via dpkg? The script uses apt-get install to solve automatically the dependencies and that would be the only sensible way. To be honest, the box is quite capable to run x264 and x265 1080p streams in Kodi with ffmpeg + rkmpp. I should try lubuntu, Armbian is historically tied to xfce but I'm not very fond of. Also it is always suggested to disable window compositing for xfce because the desktop will feel very sluggish with it on, but the media framework should disable it by itself.
-
Well that's very strange the Multitool does not detect the NAND: it would be worth investigating, but that would many of trials and time. The serial adapter would be very useful to read the messages log and would give important hints about, but NAND memories are always often very annoying, Anyway, if you are not interested at all in NAND, you can run rkdeveloptool ef to erase the NAND completely, so the board will always boot from sdcard. Once there you can do follow two different stategies: Put the multitool on a sdcard and see if the NAND is detected requires zero effort. If NAND is detected, you think that you can follow the "Upgrade NAND bootloader" procedure from first page to upgrade the first-stage bootloader on NAND to the latest version, then run again the multitool and install armbian directly on NAND Otherwise just put armbian on sdcard, plug the sdcard into the sd slot and run Armbian from sdcard. I suggest you to give a shot to the first point, at least to see if NAND is detected from Multitool: it may seem an useless try, but actually when you erase the NAND, the board is forced to look for the proprietary first-stage bootloader from the Multitool, which is surely the most up-to-date. I have noticed that the bootloader can have an effect on NAND detection, so you may give a try at least to be aware of this. If you report here I'm interested too in the result. Second option is very straightforward: you don't actually need the multitool at all and the kernel should detect (after configuring the board with rk322x-config) the NAND that you can use as a normal storage device (but only if you use an image with legacy kernel!).
-
Hi @beretas, thanks for sharing all those infos and photos! Your board should be very well supported, but unfortunately the flash memory seems to be a NAND, which is limiting somehow. I can't find any reference about the queenston manufacturer, I guess that's another chinese copycat company. The RAM memory of your board is one gigabyte. Each memory chip is 2 gigabits (and not gigabytes), you have 4 of them, so it's a total of 8 gigabits, which is 1 gigabyte. Memories are always reported in terms of bits by datasheet manufacturers because of the DRAM production process (1 bit = 1 transistor). The NAND is unknown: the product name is easily a fake one, taken from a common samsung 32 gigabytes chip and printed there to fool someone. Once you boot the multitool or armbian you will have some probably real values.
-
Please be more specific: did you upgrade via apt or install a new pristine image using the multitool from scratch? Do you have a serial adapter with some logging output? Do the multitool boot from sdcard or it does not boot anymore too? Are you running legacy or mainline kernel? Are the front led blinking or steady? And are they bright or dim? What is your board and what CPU, RAM, flash memory does it mount? (photos are welcome)
-
Here it is! It's still weird you have building issues with Focal too, in a step (write uboot) that is mostly just bash scripting...
-
MXQ 4K RK322x - Multitool can't burn to emmc?
jock replied to gnusmag45's topic in TV Boxes's Rockchip CPU Boxes
Discussion goes on here -
Hmmm... yes, it is indeed contradictory... The "native" building should be referred to building armbian on the board itself, but there is an "x64" there which adds more contradiction confusion. By the way, I'm using Focal to build Focal, Buster and Bullseye images and it works fine. Historically the supported distribution for x86-64 building was the latest Ubuntu LTS. There is only a bug in the build system that I don't know if it has been fixed yet, but you may need to install some packages manually (like libfdt), but then it should go on without any more issues
-
Well, that's odd and unfortunate. If you have a USB male-to-male cable try to connect it to the USB OTG port (without connecting the power cable, just the USB cable) and see if your computer shows the device in maskrom mode. As usual, the serial adapter is useful for debug. It is very odd, because an empty eMMC will always trigger the sdcard boot, so I wonder what really happened when you did the flash erase...
-
Hi @gnusmag45, I'm sorry you are having issues with your board. I hope the multitool still boots after you erased the flash Unfortunately your board has an eMCP, which is a chip that contains both the eMMC and the DDR memory. I never had the chance to test a board with such chip by myself, so it is totally guesswork. The multitool has a dtb which is usually very compatible because it does not use any "advanced" features of the board, and also uses lower operating frequencies to maximize compatibility at the expense of performance. Something does not work for your board although. I edited the device tree of the multitool to provide more current strength to the eMMC pins and also some other configuration that may be of some benefical effect for your board. This is the dtb: rk322x-box-emcp.dtb. Put it in the root directory of the multitool, then edit the the file extlinux/extlinux.conf and change the existing rk322x-box.dtb with this rk322x-box-emcp.dtb. Save the conf file and try again to boot the multitool. Check if after some reboots the flash memory is detected consistently, maybe make a backup to "stress" it and see if the backup is completed correctly, but don't install any armbian image yet. I suggest you to first try to burn an Armbian image directly on the sdcard and boot armbian from sdcard. This may let you upload a full set of logs (via armbianmonitor -u) to the internet and let us inspect them before proceeding to install the image on the eMMC. Also check if the eMMC is correctly detected within Armbian after some reboots: it is important that the kernel detects it otherwise even if you install Armbian on eMMC it won't boot anyway.
-
Hello @ArkhanLK, be aware of this: so everything else is a moving target. The tools may work differently on other distributions, with subtle bugs or even build failures, so it is preferable to support a single distro and support it well. Personally, I have my 100Gb Ubuntu Focal 20.04 Server virtual machine to do such jobs.
-
A really dumb question Amlogic Vs RockChip vs Allwinner
jock replied to masteripper's topic in TV Boxes's General Chat
Yes, I remember I had to build separate binaries using an amlogic toolchain when I dealt with my S905 tvbox something like 3 years ago or so. Following the existing source code in armbian repository mainline u-boot worked. Some code is in my github repository (for reference: https://github.com/paolosabatino/armbian-build/blob/c9b10fb6abd51e7fbc537b8f74ac9ae36c24d9af/config/sources/families/meson-gxbb.conf#L62), I don't update it from a long time probably it is still working or requires minor adjustment. I should have left the amlogic toolchain somewhere on a hard disk of mine, yet I don't know what is the support status for newer socs. -
@Tucano2000 After half a day realized that your question was related to the backup image your posted on yandex Sorry, today I was a bit sleepy and I misunderstood the post. I will check tomorrow, but the dtb and dts already contain most of the useful data!
-
A really dumb question Amlogic Vs RockChip vs Allwinner
jock replied to masteripper's topic in TV Boxes's General Chat
I'm not that into amlogic (you know ) but yeah, mainline support is very good or excellent for most things and some "niche" things are slowly materializing too, like the hardware video decoding. I was mostly referring to opensource endorsement that was not good in the past. I'm happy they changed their mind! edit: I'm not sure, but do the eMMC clk pin trick work on amlogic too? I guess all manufacturers follow the same pattern a way or another. I'm pretty sure that emptying the eMMC of an S905 board made it boot from sdcard with no hassle! -
A really dumb question Amlogic Vs RockChip vs Allwinner
jock replied to masteripper's topic in TV Boxes's General Chat
Amlogic has quite good performance/price ratio: their low-end S905X3/X4 are very good chips for the price, and quite updated too (Cortex A55). Rockchip and Allwinner have nothing comparable yet for the price. Allwinner is far behind. Rockchip recently introduced the long-awaited RK356x series which at least is on par with raw performance to S905X3 and has a nice set of features, but the price is clearly higher and support is still going on. RK3328 is not as good as S905X3, either from CPU and GPU sides, but the RK3399 is still quite good SoC. Amlogic has the best chip on paper with S922 (and similar ones), but in the past they did some double-cross with frequencies and temperatures so people is reasonably skeptic on the real performances. Despite lagging behind, Allwinner chips are at least very cheap with decent raw performance (H6 at least), but the company is a bit silly. About linux and community support, Amlogic is the worst one by far, being quite obscure about their hardware and generally not very supportive of opensource. Rockchip is the best one, a lot of their drivers are production ready in the mainline kernel. Recently although I saw quite a stop in their "proprietary" kernel and u-boot public forks. I don't know why they stopped, but I hope it's just a temporary reorganization: the effort they did in supporting opensource was very appreciated by the community and mainline kernel is very advanced on supporting their chips and peripherals. Allwinner in the past was a total wreck, a lot of work by community has been done to reverse engineering things with excellent results and I think they now opened a bit more publishing especially documentation. My two cents. -
??? If the source of the backup was working, reinstalling the same backup will work the same.
-
Hmm, if Multitool does not boot I'm afraid the ddrbin (the very first piece of code) does not like the DDR memories and is just stopping the whole thing from booting. The serial adapter will tell you and the only way out, in this case, is forcing maskrom mode.
-
I mean: did you try again, after bricking the board, to run the multitool from sdcard? You need a serial adapter (USB-to-TTL or RS-232-to-TLL) for that, boards usually have debug serial pads in rows of 3 of 4 holes where the serial adapter wires can be soldered to send and receive characters. Looking at the board photos, I think the four vertical pads in the left-bottom corner of the first photo are probably the serial pads. Commonly they are GND, Tx, Rx and 3v3, but the order changes. 3v3 must not be used, but if you connect the adapter GND to the GND of the board, Rx of the adapter to Tx of the board and Tx of the adapter to Rx of the board you can send and receive message on your computer. This is pretty a must have.
-
@Tucano2000 Ah, installing the rk3328 firmware was indeed a bad move. Despite that, I looked at the firmware parts you put on the remote drive and they look like being corrupted/empty to me. Tried to open dtb, resource and kernel with an hex editor and they are filled with dummy bytes. Did you try to put the multitool on a sdcard and try to boot it? If the bootloader you installed on eMMC is corrupted, the SoC will try to boot from sdcard (but not USB) and the multitool will allow you to recover or install armbian again. If the multitool does not boot, I'm afraid your only option is finding the eMMC clock pin and shorting it to ground to force maskrom mode. I have no such board, so I have no experience with that unfortunately. If you have a serial adapter it may be worthy connecting it to understand what's going on.
-
Yeah, you're right, the emmc-nand overlay also enables the DDR mode... I forgot I added that thing there too. Need to fix that in rk322x-config to be more clear about.
-
Thanks a lot, this makes the job worth it You're right, that's not just me behind this, so I share the greetings with all the people that helped in this thread! You can still use Focal Legacy and configure icewm desktop manager even if the image comes preinstalled with xfce, performance should be the same as debian. Unfortunately I didn't try on debian. Roughly it should be possible to make it run on, but the package names to resolve the library dependencies changes, so the media packages should be adapted. It was a bit hard to find and fix dependencies, I'm no .deb specialist at all. Also Debian Buster comes with some very old packages that should be recompiled and installed manually... it's a bit of headache You can extract the script and install each .deb packages manually using apt-get (apt-get install ./the-package.deb), but I don't really know if it brings you anywhere. The new developments on the mainline kernel brings new life to hardware decoding and acceleration, but things are still settling down, as you may notice with the release of the first beta versions of LibreELEC 19 and Kodi Matrix: actually I managed to get hardware acceleration work fine on mainline kernel, but the process still requires patching and manual compilation of ffmpeg and Kodi, so there still is some time to wait for. Ah, no there is not any tutorial I know about for that, but IMHO it does not really worth it. CPU and GPU can be overclocked easily editing the device tree, finding the opp tables (OPerating Points), and modifying frequency and voltages. I don't recommend it, the improvement is very modest at the expense of much greater heat production. Unfortunately the CPU is a Cortex-A7, a very old 32 bit only architecture made to do cheap tv boxes. The SoC has dedicated hardware decoding blocks, which are nice, but the hardware specs are minimal for the current standards. It is perfect for some home server things although (network router, NAS, VPN endpoint, dns cache/hole, etc...) edit: about the boot issue, follow the @RaptorSDSadvice to remove the emmc word from overlays= line in /boot/armbianEnv.txt, or just select emmc-nand in rk322x-config.
