permheaddamage as I said, secure boot is totally out of my league, but there are people on IRC (#linux-sunxi at OFTC) who researched it and are probably able to help you.
Posts by jernej
-
-
Well, it still might not be completely secured, but it's up to you if you want to play with it further or not. I don't have any experience with TOC0 booting...
-
Correction, your board uses LPDDR3 RAM, which is slightly different than DDR3. At least enough that you can't interchangeably use images. Fortunately, Beelink GS1 also uses LPDDR3.
In any case, either there is issue with writing images (did you unzip it before flashing?) or your board is secured and it would need special crafted image. I think you can determine if board is secured via FEL, but I forgot how already. Check linux-sunxi.org for clues.
-
There is no support for DDR4 for H6. This seems to be one of the rare boards which pairs H6 and DDR4.
-
I don't remember seeing this issue then, did you change anything? In any case, it seems that either HDMI audio might be initialized 2 times or some component is reusing name, which it shouldn't.
-
They use completely different image format. LE SD creator uses raw image whereas phoenixcard uses proprietary AW format.
In any case, try to use some other tool to write LE image like Etcher, since some users had issues with LE SD creator.
-
The HW spec looks very much like Beelink GS1, except for the wifi chip.
Then try that image? Zidoo won't gain official support.
-
Yeah, increasing loglevel will certainly increase message output. I think kernel issues should be printed even with default value, but it's worth a try.
-
just remove quiet from extlinux.conf
-
-
If there is some kind of kernel side issue, then the only way to get any kind of usable log is to solder UART pins and connect serial adapter to it. With that, you can monitor kernel complaints real time and with hard crashes, this is often the only way to get report. Are you able to do that?
-
-
difference is only if CEC protocol is completely implemented in software (algorithm in kernel determines when pin goes to 1 or 0, determined by timer) or in hardware (driver only reads what message was received or sends one out). Obviously, you want hardware to do as much as possible, as that leaves CPU to do better things. Also, time sensitive events, like when pin has to go to 1 or 0, are completely done in hardware and thus not dependent on CPU load which might introduce some lag.
So, it's interesting to me that software implementation works better than hardware. Usually, it's other way around. Only explanation for that is 32k clock accuracy, which is used by HW CEC implementation for timing events. But I don't see a reason why that would be a problem. Maybe you can confirm that indeed dedicated crystal is used by executing devmem 0x01f00004 w. It should have value 1.
Best way to determine what happened would be to first find PR on github which broke HW CEC. That could be done via git bisect.
-
-
It should be able to play 4k HEVC files. In theory 4k H264 should work, but not smoothly. Note that 10-bit formats are not supported in HW. OrangePi PC has only 1 GiB of RAM, most probably that's the issue.
What do you mean by "board restarts"? Are you sure whole board restarts (there should be LibreELEC logo shown) or only Kodi restarts (only Kodi logo is shown)? Please enable Kodi debug logging, execute pastekodi via ssh after the issue is triggered and provide link here. It should provide enough information to see what the issue is.
-
-
I have no idea what could be wrong with CEC. As you said, not much changed. Ideally, you should try to bisect changes and figured out which PR caused the issue. Most likely it will be a kernel update.
You can check if changing board name to "xunlong,orangepi-pc" at https://github.com/LibreELEC/Libr…r-H3.patch#L191 mitigates the issue.
-
Can you confirm that this is really Tanix TX6 with H6 chip and not Tanix TX6s with H616? First is supported, later is not. If in doubt, you can open the box and look under cooler.