jock
-
Posts
852 -
Joined
-
Last visited
Everything posted by jock
-
AFAIK there is no such tool for rk3188
-
Where did you read you had to try dozen of combinations? Where did you download the image? If you paid attention to instructions, you would have been pointed to the right forum thread where other people could already have helped you.
-
In the previous post you stated your box is an rk3188 box, this is the thread for rk3318. If your box is an rk3318, please provide as many as possible of the things described in the first post (logs, photos, original dtb), otherwise it is impossible to help. HDMI issues are common if cable is cheap, or the monitor less non usual resolution (like 1920x1200, for example)
-
Of course it is opensource: https://github.com/paolosabatino/multitool
-
Black screen after first reboot? Do you mean the thing solved by cpu-stability overlay? Note that the multitool is happy even if you put compressed gz/xz/zip/lzma/bz2 images in the images folder: it will decompress them on-the-fly. The FAT partition, right after flashing the multitool, should be a bit less than 2Gb. 800 Mb is strangely small
-
Maybe. You can tell us, we surely don't know Definitely weird, this never happened on any box. I can assure you that there are plenty of boxes around without anything attached to HDMI and ssh is indeed accessible, even after first boot. There is no HDMI check of sort and never has been anyone.
-
Hello. Can't read from the board photos if your flash is NAND or eMMC; in case of NAND (multitool tells you), you can't flash mainline kernel and expect it works. Mainline kernel will work from sdcard though. In case you have eMMC, as usual we don't have the crystal ball and without the logs from the serial adapter can't guess anything.
-
Hello. The experimental image is not really recommended unless you have problems with the stable images. Don't use it if you don't really need it! I'm not sure I understood the question, but the box boots fine even if you don't plug any HDMI cable. If you don't want to "disable" the HDMI to not let it work at all, I guess the most straightforward way is to disable the HDMI node in the dtb. Tinkering with the dtb is not recommended too, if you don't want a console access (but keep the ssh access), I guess it is better to disable the systemd getty services
-
Ask who? ARM? Good luck then... they somehow cooperate now providing limited documentation, but often in the past have been very troublesome for opensource community; they started sharing things after people already reverse engineered GPUs by themselves (not before). Anyway, Mali GPU is not part of the game in video decoding, that's a job of the VPU, which is already working very well with opensource drivers. The "only" problem is that making the driver does not magically let things work everywhere, there is the missing glue that connects applications to the hardware decoding capabilities and also browsers are huge and complex piece of software. Also mixing hardware decoded frames coming from the VPU into a CPU-rendered page and displayed via VPU is yet another complex task not yet completed: you can clearly see the many parts of the SoC in need to cooperate. I would not go for the legacy/proprietary kernel, I would rather push over the mainline kernel which is probably getting better and better support with time; proprietary kernel is stuck and rockchip does not provide updates anymore, but this requires exploring ffmpeg recent introductions and experimental code too. For example, firefox has a vaapi capability to do hardware video decoding (introduced very recently for linux BTW), but yet there is no vaapi driver for rockchip (nor for amlogic or allwinner) yet; so until someone writes a proper vaapi driver, no hardware decoding in browsers for now. I don't even consider Chromium since the last Google idea to lock-out their APIs for their own opensource browser. Another fact is that the box is generally slow, so desktop experience is not great. I think there is something missing in the DRM part because Allwinner H3 chips have generally better desktop experience despite they are just the same as rk3229. Anyway good luck for your project, I think that it has the numbers to convince some people in the high towers to make some political changes and let involved companies contribute!
-
Hello. At the bottom of the first post there are some useful things you can share to help you. In particular, serial logs and photos of the board are important, because H96 Max is just the market name, but the board hardware often differs.
-
I didn't look into the nodes you added, but if you just did copy-and-paste from one dts to the other, it won't work that way because of the phandle references.
-
@avlevglad you solved easily the problem. Legacy kernel received much less attention and indeed the audio codec part is missing in the dtb. Legacy dtb requires a full refresh starting from the mainline dtb, but honestly it is becoming less important as multimedia things are progressing in the mainline kernel.
-
That's true, each "piece" (the right jargon is "part") gives you 1 gigabit. In total it is 8 gigabits, which is 1 gigabyte. Yes, you can, but it is the worst thing you can do: it will kill the flash memory in no-time. Flash memory sectors have a limited number of writes, after then they wear out. Using flash memories (either they are NAND, eMMC or SSDs) for swap is not a wise idea in general. Swap is already configured in Armbian as zswap, which is smarter for flash based device because memroy pages which are "unneeded" are just compressed directly in RAM, so they occupy less memory. Android, for example, does the same thing. In case a process crashes due to out of memory, dmesg will tell you that a process has been killed because of an Out Of Memory (OOM) event. It is much more probable that your board is just not stable, so you can try adding cpu-stability to overlays in /etc/armbianEnv.txt
-
You think wrong. According to the official specs of the DRAM chips, those parts are 1 gigabit each, so 8 chips turns out to be 1 gigabyte.
-
A general introduction post I did some time ago you may find useful: https://forum.armbian.com/topic/14752-device-tree-translation/?tab=comments#comment-106284 I once did a really long post explaining how device tree works in general, but can't find it out right now... -
Currently you can't have Armbian on sdcard and Android in eMMC using the provided stable images. You need to alter the images in peculiar way to get the proprietary boot binaries in the right places.
-
I have a very similar problem on my box too. The cpu-stability overlay increases the voltage of the lower frequency operating points, so the voltage regulator has to span a shorter delta when increasing frequency. With the overlay I solved and now the board is rock-solid.
-
I have already experienced stability issues when lowest frequency is set to 400 Mhz, just can't remember if it was on rk322x (probably) or rk3318. If you still have such issues, there is the cpu-stability dtb overlay you can add to overlays but beware that it will increase temperature by 1-2°C at lower frequencies. Userland applications must not cause any kernel panic in any condition. If they do so it is because something is wrong in the kernel (a bug in a driver, an error in the dtb, ...). There may be the chance they are messing with some device internal they should not do, like writing directly to phisycal memory or MSR registers, but in normal conditions they are not allowed to do so. Surely php, nginx and mariadb don't tinker with low level things at all. Of course, if the board is not stable you may get plenty of kernel panics, but indeed they are not software related.
-
Are you sure there is no audio device? What does dmesg say? And aplay -L ?
-
@RaptorSDS No particular updates recently. If you're on legacy kernel, it is the same 4.4.194 kernel as it was long ago. Mainline kernel still should be a subversion of 5.10 Can't say anything about, I just see a kernel panic but can't say if it is related to emmc. Maybe it is just a "common" stability issue of the board due to crap quality.
-
Running android from eMMC and Linux from sdcard is very possible, LibreELEC does that, but also the multitool works that way also. Armbian images are not provided in that way for very specific reason: support is more difficult since we can't know what kind of software (bootloader version, ddrbin, etc...) booted the box extended boot features (like USB boot or network boot) are impossible to implement plenty of outdated binary blobs are involved (you don't know what happens in that code) limited speed for DDR ram memories in mainline kernel Since Armbian is intended for general and stable usage and work is done towards the mainline kernel, the "dual boot" choice has been dropped almost instantly.
-
@ArkhanLK Glad you're finding the box useful and thanks for reporting! Netflix and friends usually have other issues related to Digital Rights Management, but never really dig into. I know that on LibreELEC you need to download the Widevine plugin. @jaum20 It should be already enabled, but honestly I never checked the coaxial SPDIF output. Will check right now edit: just checked on both mainline and legacy kernel and it is working fine up to 192khz! Maybe you need to tell pulseaudio to use SPDIF (IEC958) from the speaker icon in the upper right corner
-
CH340-fan-control - USB fan control script
jock replied to Dan MacDonald's topic in Reviews, Tutorials, Hardware hacks
I'm very rusty in electronics, but it should be easier than you might image, as long most SBC expose PWM pins. What you need is a NPN transistor (or even better a logic-level mosfet) and a resistor. The PWM pin controls the base of the transistor (the resistor goes in the middle between), the emitter of the transistor goes to ground and the collector of the transistor goes to the negative of the fan. The positive of the fan goes straight to power source. Correctly dimensioning the thing is the challenge, but if you use a logic-level mosfet in place of the transistor you don't need to do any calculation and you may omit the resistor too (but it's better to place it anyway, a 470ohm should be suitable there). -
Well 4 gigabits are actually 512 megabytes. I guess they are just faking specs as they do often.
-
Do chinese box makers now use gigabits to advertise tv boxes? That's even worse that what I could imagine... BTW technical DRAM datasheets always reported gigabits sizes (that's roughly the number of transistors in the DRAM bank...) and never report gigabyte sizes (nor gibibytes)