jernej
-
Posts
1144 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by jernej
-
-
1 hour ago, ngocdungvn said:
Hope for the future, Tx6 can detect its full 4GB of RAM.
Check U-Boot output on serial. It should say something like 4 GiB of RAM detected, 3 GiB used. That won't change, since it's impossible to use that extra GiB due to HW limitations.
-
According to https://linux-sunxi.org/Tanix_TX6 there are two versions of the box, 2 GiB and 4 GiB of RAM. RAM size detection code on H6 should be pretty solid these days, but if you really think you have 4 GiB version, open the box and provide clear images of both board sides. That way we could count RAM chips and check markings on them to manually calculate RAM size and if it's incorrect, to get at least some idea what could be wrong.
P.S: Boards really do have 4 GiB of RAM, it's just that H6 can use only 3 GiB.
-
3 hours ago, rubenvb said:
only the "outdated" (mismatching with kernels >=5.11) in the LibreElec repos.
Yeah, LE currently uses 5.10 kernel because we are preparing stable release (no ETA, but hopefully soon). Only after that Linux will be updated to whatever current stable release will be at the time. However, v4l2 request api ffmpeg patches for Linux 5.13 can be found here. Note that they are untested and you still need corresponding kernel patches too.
-
I have troubles booting Tritium H5 myself, but from SD card. I just power cycle it until it works. Sometimes it seems that it helps if HDMI is unplugged, but that might be just red herring. However, once it's booted, all reboots, suspend/resume cycles via Crust work. I have no idea why it's behaving that way.
-
1 hour ago, Clonazepunk said:
Gigabits (GiB), not Gigabytes (GB)
That's not correct - distinction between bytes (B) and bits (b) is just upper and lower case. Prefix "Gi" means gibi and it means factor of 1024 * 1024 and second one is giga which means factor 1000 * 1000.
-
H616 ATF stuff should be upstreamed already, but I'm not sure if it is in any stable version.
-
2 hours ago, MX_Master said:
I need your help. guys. Any suggestions how to switch H6's ARISC (CPUS) clock to the PERIPH0 PLL? Is it possible this memory region is protected from uboot and linux kernel?
If I'm not mistaken, yes. You can always make a SPL hack, which do stuff with otherwise protected resources.
-
4 hours ago, EndlessEden said:Quote
passthrough on RK 4.4 kernel uses custom approach. Kodi would need adjustments to use it.
Any information on this? - Mainline has some better cpu performance, but GPU side of things with panfrost is not well integrated. My testing using kodi on non-legacy builds of armbian and even attempts at archlinux(arm), have shown me that VPU(VideoDecoder) seems to be a mess on the oss side of things, so proprietary drivers seem to be the only way to a functional experience.
I wouldn't say mess, just work in progress - with 5.13, MPEG2, VP8 and H264 will be all stable (no need to patch anything), with HEVC and VP9 being in development (most or all supported features reachable with out of tree patches).
Anyway, regarding passthrough - I can give you only a hint from source, since I don't have any intention of running BSP RK kernel: https://github.com/rockchip-linux/kernel/blob/develop-4.4/sound/soc/codecs/hdmi-codec.c#L126 You can set this with amixer - 0 means PCM, 1 means NLPCM and 2 means HBR NLPCM. I have no idea how to properly use it.
-
@tony013 Fix for RK3399 HDMI audio on mainline has been just merged in LE: https://github.com/LibreELEC/LibreELEC.tv/pull/5365
-
I was speaking about SoC capabilities with first part, not about Armbian setup. Second part is speaking about my experiments about passthrough on mainline.
-
Yeah, I realized that this topic is about BSP kernel after posting. There will be no more work done for it in LE, next RK release will use mainline. I believe deinterlacing also doesn't work here in Kodi, right?
-
In short, HW decoding on ARM boards is messy at this moment (check this summary). I'm not sure you'll get far with Kodi on Armbian. LibreELEC uses a lot of out-of-tree ffmpeg and kernel patches to achieve good Kodi overall performance (they are being gradually upstreamed, but that takes time), so I suggest you try that image first.
Note: Passthrough on RK3399 is possible - it uses similar peripherals and concept as Allwinner H6, for which I have experimental passthrough patches, even for HBR. But that also needs proper ALSA config, where I have issues...
EDIT: I'm talking about mainline kernels - passthrough on RK 4.4 kernel uses custom approach. Kodi would need adjustments to use it.
-
No, wifi is not yet supported, it needs some out of tree driver. I don't think anyone bothered to try it out (I'm big skeptic about these wifi modules...).
-
H6 doesn't support GPU devfreq yet - this feature is mysteriously elusive - all attempts to add this feature ended with GPU lock up. It's possible, because BSP can do that. Currently it runs with default rate, but you can adjust that with some DT magic, like I did that for A64. Note that you probably need to increase GPU power supply voltage too.
-
This board has 1 GiB of RAM - just multiply 4 x 512M x 4 bits and you get 8G bits which is 1G bytes. You would need 8 chips (512M x 4) to get 2 GiB.
-
It seems like 4 chips, right?
so, 4x 512M x 4 -> 2x 512M x 8 -> 1G x 8 -> 1 GiB
Your board has 1 GiB of RAM and DRAM driver properly detected it.
-
2 hours ago, Ricardo JL Rufino said:
In Datasheet say 2GB in the CPU area, and 2GB in the GPU area. Totalizing 4GB, or am I wrong?
GPU and CPU share same memory bus, so 2 GiB total.
If you really want to figure out amount of RAM, you should open your box and post detailed images of the board (both sides), so number and markings on RAM chips can be determined. From that, real amount of RAM can be calculated. It also helps verify DRAM settings (DRAM driver is not "one size fits all", it has to be properly configured).
-
Ah, you didn't add panel description to DT for Linux. So yes, Linux uses U-Boot FB. 32-bit colours are hardcoded in U-Boot here: https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/video/sunxi/sunxi_de2.c#L255 Fortunately for you, I added handling 16-bit colours (if you change constant), but I can't guarantee it will work. I only tested it in U-Boot for H3 and not in Linux.
EDIT: Apparently you have to change also this line: https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/video/sunxi/sunxi_de2.c#L405
-
7 hours ago, alexfreed58 said:
I understand that Linux inherits the FB from u-boot.
That may or may not be true. Linux has proper V3s display driver for a long time. However, U-Boot may still hand over its FB to Linux. In that case U-Boot FB is used for a very short time and it's replaced with Linux FB during boot. Now, I'm not sure if U-Boot FB memory is actually released or just stays reserved. Best way to check would be to disable display driver in U-Boot (via U-Boot config and rebuild) and compare free memory.
I don't know how to force 16-bit buffer. There is probably some kind of kernel parameter for that.
-
If you can manage to prepare appropriate edid binary, you can supply it to kernel according these instructions: https://wiki.archlinux.org/index.php/kernel_mode_setting#Forcing_modes_and_EDID If it works, you can in some cases also write that permanently into your screen. Wrong EDID is worst kind of issue. I never actually had such problems, so I'm not sure how to edit edid.
-
Everything seems to be in order, assuming edid is correct. Refresh rate is pretty strange - 65.681 Hz. Clocks are correctly set according to edid - 32 MHz. I have another waveshare HDMI screen (1024x600) where pixel clock is also 32 MHz and it works fine. Not sure what to suggest, except that you can try to override edid with your own.
-
Please provide EDID blob (most probably at /sys/class/drm/card0-HDMI-A-1/edid) and content of /sys/kernel/debug/clk/clk_summary
-
Can you give link to your exact model? Looking at waveshare site, 4.3" 480x272 LCD has only 40 pin connector - this will not work with anything but RPi. Or did you mean 4.3" 800x480 HDMI monitor? This one should work in theory. There is also 4.3" 800x480 DSI one which I'm not sure if it can work or not.
-
There is one more difference - usb@5101000 and usb@5101400 are missing
phys = <0x15 0x00>; phy-names = "usb";If that doesn't work, then I don't know.
I don't think anyone currently works on H616, so it probably won't change much in near future.
Orange PI Lite2 no more 1920x1080 - kernel 5.5.x
in Allwinner sunxi
Posted
Yes, I do
In short, if you only have 1024x768 resolution, that means that board was unable to read EDID data from monitor (it holds info which resolutions are supported by monitor and a few other things). It's a bit weird that this doesn't work. I would try with different HDMI cable and if your cable is long, I would try with a short one. It's also possible that DDC lines are fried due to ESD. Of course it could also be a driver bug, but I have never observed such issue on my boards.