After the nightly image 20210511 was written to the EMMC module, rock pi 4 stopped loading at all, even from the sd card
Only physical removal of the module and formatting it through an adapter helped
I'm not sure I understand what you're trying to say. Provide a (uart) log, I guess thats more helpful.
It's Working
Thanks for reporting back.
Release 21.02.3 with kernel 5.10.21 boots right from emmc without special treatment.
Writing image with usb-emmc adapter is sufficien
Armbian has a lot of patches, I didn't check them. For emmc I just did what the vendor does arm64: dts: set emmc max frequency to 150000000 for ROCK Pi 4 · radxa/kernel@db9dfc2 · GitHub.
but I only found lot of additional/changed
check again - there is one
Both audio and emmc adaptions will be available in nightlies which are still building for RK3399 they will be available soon. As I've said before: all this is just guesswork, since I'm not having a rock pi4 board yet - none of them is a problem for rockpro64 board.
I could not boot from the EMMC module on the Rock Pi 4: Could not mount / flash / SYSTEM, as I understand it, you need to change the paths after uploading the image to the EMMC?
Nope. no paths have to be changed - but Rock pi4 needs special handling of emmc. It will be available from next nightlies - so presumably from tomorrow on. Please check and report back.
For all other issues which seem to be Rockpi 4 related: radxa will send me a board - which might take some time to arrive.
I have a NanoPi M4. can you send me the dbt file for the M4 please?
I compared vendor with mainline kernel for anyting which could belong to hdmi audio - all I could find, that could help was, that dmac clock is higher in vendor kernel.
Please take a spare SD card, flash the latest nightly (no update) on it and replace the device tree with the with this one: https://mega.nz/file/vHZ21D5R#…dUVYUJezmP6fPfo , where I increased that clock:
scp rk3399-rock-pi-4a.dtb root@<ip of device>:login via ssh:
ssh <ip of device>move devicetree to flash partition:
mount -o remount,rw /flash/
mv /storage/rk3399-rock-pi-4a.dtb /flash/and
reboot. It does make zero difference on my boards (never had audio issues with no bit-/or sample-rate) - but it might make a difference for rockpi4 (dram maybe slower). Do not enable passthough (this is experimental and will go away before final LE10 release) and don't touch any audio settings. If everything went OK
cat /sys/kernel/debug/clk/clk_summary | grep dmacshould look like that:
aclk_dmac1_perilp 0 1 0 297000000 0 0 50000
aclk_dmac0_perilp 1 2 0 297000000 0 0 50000Please check if it makes any difference for you for audio output.
by the way, when will LibreELEC 10 be able to boot from EMMC?
If you're using a detachable emmc module, feel free to flash the image there - its working great witch rockpro64. (and upstream device tree for rockpi4 has emmc enabled as well)
Perhaps this is not a problem with all RK3399 SoCs, but only Rock Pi 4B on the new kernel.
Yeah, looks like. I can't hear any cracking on neither my RK3399 TV box nor on rockpro64. Its kind of hard to do some remote guesswork - can you upload a audio record to get a feeling, what is actually meant with "cracking" and also link to the stream which you played at that time?
Just tried it again with my rockpro64 and various sample rates: I really can't hear anything cracking. Can you verify it doesn't happen with older LE (vendor kernel based) release or android? if it happens there also: parts of HW might be broken (due to overclocking or something)
Thanks for the logs, I will have a look at them. No worries for the "missing" lines - they are not related to CEC - actually its debugging stuff, which shouldn't have logged by default in LE 9 as well
From a quick glance: I see a lot of
Tx, Error (1), Max Retriesmessages in LE 9 logs as well - I guess you already tried a different HDMI cable?
yeah, there seems to be a 2160p resolution issue with the file, but if you switch to 1080p resolution it comes back to business as usual (I tried various frame rates, but 2160p is broken right now). easyb do you also have a similar problem on your end?
Its not "broken".
The reason you are seeing "green flickering" (I guess) is, that the dram bandwith required to display 4k is to high.
The vendor kernel raised the dram frequency applied correct dram timings - this does not exist in upstream kernel (yet) and the dram frequency will be stuck at ~ 300 MHz with standard timings which propably do not match the those required for the dram chips in your box - so everything will be (very) slow.
The only way around that is currently, to completely(!) erase the emmc, so that dram init is done from sd card, where we initialising the dram with 786 MHz (with standard timings, though). There will be an update for that sooner or later for LE for selected devices.
Overall: Its recommanded to use SBC boards, which do not have android pre-installed, so that the complete boot process is done from SD card oob
I can see, I was not so clear regarding describing the situation. So, let me rephrase it again:
Thanks, seems clearer now.
So - the only difference, I can see between the two cec-ctl monitor logs is ,that my TV annouces it went to standby with
Received from TV to all (0 to 15): STANDBY (0x36)what is completly missing in your log - this way the HDMI controller "knows", that the device will be re-requesting the same address at some later point.
Time to time I can see in dmesg ouput LOW_DRIVE status but I cannot figure when the message appears. I checked source code and patches a found that it could be this part of code responsible for that in file
This is a required patch for some other TVs - without it, CEC wasn't working at all for them. I don't think its releated to this problem. But it would be interessting, if your are seeing this message when switching your TV off.
Interesting is that LE 9.2.6 worked properly without any issue. I can setup 9.2.6 again and check the messages, if you wish...
That could be helpful.
I'm not sure, if your TV has that option - could you also try to search for CEC devices (should be somewhere in the settings menu of your TV) after you switched it on again and paste the cec-ctl -m
Better don't compare it to Rockchip, Amlogic or Allwinner - they needed 4+ years and are partly not even there yet
you should know better.
I tend to disagree (except about AML part)
Me too (what a suprise).
I'm not really aware what Rpi currrently supports - but reading the comments suggest, it doesn't support 4k@60, and no proper h264 decoding (beside sw) - which is sort of essential these days. Both is well working on RK/AW. No differences for HDR (everything is still 8-bit output, but sends HDR infoframes).
That it takes longer is kind of in the nature of things (I can only speak for RK) - RPi is kind of a single use-case SoC, while other SoCs have way more HW compontents to support - media stuff is not always (never) 1st priority.
It looks like your TV doesn't announce that he went to standy - so HDMI controller doesn't "know", that the TV disappeared from CEC bus.
After reading your report again: With "power cycle" you mean: cut off power completly? This way it can't (currently) work, since HDMI controller will continue to poll the old CEC address endlessley, while your TV will ask for a new (maybe even the one it had before) when you switch it on again. If this is possible it would be better to put TV in standby first and cut off power after that.
The only way arround that (I can think of), is to ask TV to "search" for CEC devices again and reconnect.
Never had any audio issues on RK3399. Could someone provide a sample?
Please check Beelink A1 TV BOX image, which is suitable for rockbox as well.
For the HW side there are no differences which couldn't be captured by the device tree.
The reason why images won't boot is, that there is a SoC Id check in (vendor) ATF, which will fail on RK3318.
If I find time, I'll try to find a way around this and will add RK3318 support.
