Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by guybrushthreepwood

  1. @JMCC


    Thanks for your great effort! It has taken me a while to come back because my image was Ubuntu based and, at least by what I know, installing Debian packages on Ubuntu isn't a good practice. I've therefore built a new image based on Ubuntu Buster (I don't know why Bullseye isn't an option: maybe it's still the testing branch and there is another way I'm not aware of to build it), still with tv-out enabled, just applying the same changes discussed before. I've then added the repositories for Debian Bullseye and this way I've been able to install all the needed dependencies for the two 'base' packages kodi-mainline and kodi-mainline-bin.

    Here come the issues, probably if not certainly due to my dirty approach of creating an 'hybrid' Buster/Bullseye system. As a remote I use my smartphone with Yatse: I can configure and connect it to my OPi PC just fine but then it works erratically: sometimes I can control it, sometimes not in spite of the fact the connection is always reported as being fine. With Kore, no issues at all.

    Another issue is tvheadend server. If I try to just install the kodi-pvr-hts package by apt-get it replaces JMCC's Kodi with the Matrix version from the repositories so I've tried to build it by myself but I've failed because of issues related to ffmpeg as anticipated both by JMCC and jernej. I could easily add support for my xBox One Tuner but without tvheadend it's just pointless.

    The worst problem so far is that, in spite of the fact that Kodi reports a successful connection to the Internet, I can't manage to install anything from the repositories, not the Official one nor the Kodi Nerds one I've tried to add. No connection to either of them. We're completely going off topic here though, I know and I apologize.

  2. @JMCC@jernej


    Thanks to the both of you! :)


    14 hours ago, JMCC said:

    But, before that, you must read the docs about kodi compilation at the xbmc GitHub.


    Already done! ;) I'm a bit familiar with that stuff, the problem is what comes before having something to compile... Have a nice day.



    12 hours ago, jernej said:

    Not sure what kind of hints you want


    Mainly on what does need to be patched but, as you both confirm to me, the answers are inside the sources. A nice day to you too.


  3. I can confirm that allwinner_tvout_manipulator works like a charm. I've downloaded the latest version, built it and solved the overlay issue. Thanks to yam1 for pointing it out! This should be the thread on the forum where it was mentioned with a detailed usage explanation too.

    Unfortunately, I can also confirm that the resolution can't be changed by just editing disp_mode in /boot/armbianEnv.txt because, no matter what value I input there, I get no changes at all nor the .fex approach which was valid for the older kernels applies (but I knew that since the opening post of this thread). I need to go deeper on that.




    Yes, you're completely right and this was the reason why I've written I was just playing. Bearing in mind what you've already told me in the previous posts, this is the fartest thing from an enjoyable Kodi experience and unfortunately I know that. Still a lot to do...

    'Just' a question... You've talked about the heavy need for patching, both on kernel side and on the sources for Kodi and ffmpeg and this has already been done for LibreELEC: does this mean that digging on the forum there I could scour some hints? I'm not asking for the links to the threads, just if it is actually the right place to search. If, instead, the answers are inside the sources for LibreELEC, then it is definitively beyond my knowledge unfortunately.

  4. @yam1


    Thanks for the modified version of the patch along with all the other advices. I knew the resistor thing (JMCC had already told me that in this thread) but what made me think was the fact that, maybe I hadn't noticed it being under X11 instead of CLI, it seemed to me the issue wasn't present while I was under Armbian 5.90 Xenial. I repeat, probably I haven't just noticed it.


    In the meantime, just to 'play' a bit, here is what I've done (everything made as root user):


    apt-get update && apt-get install kodi xorg xterm


    then, following this very well done guide, I've issued:


    xinit kodi $* -- :1


    and I've seen the Kodi interface again on my OPi PC! Just a quick and dirty approach, I know. There is much more work to do... Thanks to the all of you! :)

  5. I need to admit I hadn't bet a penny on this but I can confirm that just making that modification to jernej's patch was enough to get a working tv out on my OPi PC, currently on Armbian_21.02.0-trunk_focal_current with kernel 5.10.13-sunxi. The video is washed out (while it was perfect before with the ancient Armbian 5.90 Xenial, I don't know why) and the resolution is wrong so there is still plenty of work to do and even much more to come to get Kodi working in a satisfactory way (probably I wouldn't ever be able to achieve that goal) but by now at least a little result gained!


    EDIT: I attach a picture of the image. The quality is really bad while it was fine before as already said. Maybe it has something to do with the lines I've removed from the patch, I don't know. I've also tried to modify the resolution editing /boot/armbianEnv.txt setting disp_mode=576x480p60 but it seems the change isn't even taken into account.


    IMG_20210207_170635 - Copia.jpg

  6. Hello again. I've made some very little progress... I've tried to undestand at my best the advices given by yam1 here. What I've done is removing these lines from jernej's patch:


    static const struct regmap_config sun8i_mixer_regmap_config = {
    @@ -560,6 +585,15 @@ static const struct sun8i_mixer_cfg sun8i_h3_mixer0_cfg = {
     	.vi_num		= 1,
    +static const struct sun8i_mixer_cfg sun8i_h3_mixer1_cfg = {
    +	.ccsc		= 1,
    +	.mod_rate	= 432000000,
    +	.scaler_mask	= 0x3,
    +	.scanline_yuv	= 2048,
    +	.ui_num		= 1,
    +	.vi_num		= 1,


    which is downloadable here. What I believe to be the original patch yam1 is talking about should be this one but honestly speaking I haven't understood what to do with it so I've tried to build again with just the aforementioned modification. To my surprise, this time the build has gone fine and I've got an image (without desktop as adviced by jernej given that my purpose is using Kodi). I've had some issues transferring the image from my vagrant VM to the host but finally I've solved it thanks to the guide I've found here (something more learnt!). I haven't still had the chance to test that image so I can't say anything more than this but I'm quite doubtful it would work. At least, this way the patch has been taken up fine without causing an unsuccessful build like before, a small achievement!

  7. 15 hours ago, jernej said:

    I wouldn't recommend to do it yourself, except if you really want to learn how things work.


    I'd really like to, a lot! Unfortunately, I fear there aren't guides to be found online on this, just books which need to be studied from the beginning to the end and they're still not enough. What really matters is a lot of experience, the one you both have.

    You both aren't hijacking anything. Seeing people who know what they're talking about sharing their thoughts to find solutions is a pleasure. Gaining just one thousandth of your knowledge would make me pride. What I think is that you and all the developers are doing a great work which deserves to be praised.

  8. 12 minutes ago, JMCC said:

    Incorrect. You can have an excellent Kodi experience on Armbian, if it is compiled properly. We have it working for Rockchip and Odroid XU4 so far with the Legacy kernels. Sunxi Mainline is in the to-do list.


    I apologize. Yes, jernej hasn't actually said what I've instead said but just that there is a lot of work (optimizations) to do. I've said it my way which is the wrong way because linked with my very very limited knowledge, not Armbian fault nor its developers. You're absolutely right and I can only apologize.

  9. On 1/30/2021 at 11:18 PM, JMCC said:

    You are not missing anything. That is the normal process for kernel developing, things don't work at the first try normally.


    You already saw that the patch applied correctly, but the changes made by the patch are causing some compilation error. It worked when jernej applied it, but now there is something causing trouble.  So the next step is look at the logs under output/debug, see what failed, and try to fix it. Have fun!


    Thanks for your teaching as always! :) I've checked under output/debug and I've found what I thought to be a descriptive name: patching.log. I've started from there but unfortunately it just gives confirmation that the patch has been applied successfully. I've checked also output.log which doesn't make me gain any better insight. The relevant file is the .tgz with the timestamp in its name. I've extracted it and found a file called compilation.log. The answers (if I can find them), are almost certainly there... I'll search for them at my best (not that much unfortunately!) bearing in mind the modifications inside jernej's patch and yam1 advices and I'll get back should I succeed in finding anything relevant.


    EDIT: nothing relevant in the logs (at least not to me). I've also tried to follow yam1's hints but I couldn't get anywhere. I'm starting to think that, considering that Kodi wouldn't work well anyway, it isn't worth the effort. I give up: I would keep my OPi PC in a drawer for an unlikely to happen future project, no use for it under the current conditions. I'd like to thank all of you for your help and advices. I've learnt a lot! :)

  10. 4 hours ago, jernej said:

    H3 doesn't use panfrost but lima. If you want to run Kodi efficiently, you'll need to pick a lot of kernel and ffmpeg patches from LibreELEC, manually compile ffmpeg and use Kodi without desktop. Oh, and you need Kodi 19 RC1, that probably means compiling Kodi too.


    What a mess! I really fear all of this is beyond my knowledge but I don't give up... I was using LibreELEC before (your work too) with great satisfaction but, at least by what I've understood from my extensive research, tv out is impossible to get working there and my HDMI is gone because of the design flaw with the OPi PC. :(

    I would try to apply yam1 advices (though I don't still get the whole of them because of my aforementioned limits) at least to get a succesful build with working av out (though it seems I wouldn't ever get Kodi working again). Maybe I could also succeed in compiling Kodi and FFMpeg but I really don't know what patches to pick so I don't even dare to start on that. Isn't OPi zero H2 based? Maybe I recall it wrong...

  11. @JMCC


    Yes, exactly. What I had already understood thanks to the guide suggested by Werner and tried to explain in my previous post. Everything seems in its place but it keeps failing, certainly because I'm doing something wrong but I can't even imagine what.

    Here is the full log of my last build attempt but jernej's patch is applied fine according to this line:


    [ o.k. ] * [u][c] ad153ef6ee5be33531187f97d5fa0c07455dc795.patch


    In the end I get this:


    [ error ] ERROR in function compile_kernel [ compilation.sh:413 ]
    [ error ] Kernel was not built [ @host ]
    [ o.k. ] Process terminated


    and I can't achieve a successful build while if I just delete the patch everything goes fine. My compile.sh parameters are these:




    I don't know what I'm still missing and I apologize for all the time lost on this.

  12. Hello again. Reading the guide suggested by Werner, I've understood that my assumptions were somewhat (let's say totally) wrong. The CREATE_PATCHES=yes switch has something to do only when I've actually modified the code and eventually it generates all the necessary .patch files inside output/patch. The fact it says there isn't anything to patch doesn't mean it is ignoring jernej's patch but it hasn't anything to do because there isn't any modification to the code.

    If I continue reading that guide, it says that the right place to put the patch I'm trying to apply is actually userpatches/kernel/sunxi-current/ as I've already done. I don't know why it fails with the error described above then, it seems I'm not doing anything wrong...

  13. 10 hours ago, JMCC said:

    Simply open the commit in GitHub, and then at the address bar add ".patch" at the end.


    Great! You're teaching me a lot. So plain simple while I was trying to shoot an ant with a shotgun! ;)


    10 hours ago, JMCC said:

    The easiest way to check how the patches are applied is to add the option CREATE_PATCHES=yes to compile.sh. It will make the script pause twice, first after applying the u-boot patches and then after the kernel patches. You can see if your patch was applied correctly, and troubleshoot if not.


    As above, thanks!


    10 hours ago, Werner said:

    A little more detailed explanation about CREATE_PATCHES: https://zuckerbude.org/armbian-using-create-patches/




    You all are helping me a lot. I would try to understand better what's going on with the error described in my previous post and how to handle everything better. I really appreciate the efforts of you all! :)


    EDIT: adding CREATE_PATCHES=yes has given better control indeed. Previously I've put the patch inside userpatches/kernel/sunxi-current getting the error described above. Now, according to what seems to be suggested by the compile.sh script, I've moved it inside cache/sources/linux-mainline/orange-pi-5.10 getting exactly the same error. What is even stranger if possible is the fact that after hitting enter to resume the script execution it says (both cases) that there isn't anything to patch like if the patch is ignored but this shouldn't be the case given that as soon as I've deleted it the build ended successfully. I don't know.

  14. 13 hours ago, jernej said:

    first generate patch from that commit like this and then put it in appropriate folder according to documentation.


    Hi and first of all thanks for your help. :) I've downloaded the .patch file by wget inside userpatches/kernel/sunxi-current. It should be the right place but it is only my guess because I haven't understood what the documentation says about that. It seems that the patching process should be something separate than what's being done by the compile.sh script or by the way I couldn't get the output shown in the documentation in any way nor I've found other scripts, maybe one purposedly intended for patching. I've also tried to check the compile.sh script in search for an hint but I haven't found anything relevant there. Before starting another four hours build process, I'd like to be certain about what I'm doing.

    Thanks for giving me the direct link to the patch but, if I can ask, how can I generate that .patch file by myself? I've made a lot of research and it seems that what's needed is git format-patch using the commit-sha which in our case should be ad153ef6ee5be33531187f97d5fa0c07455dc795 but I'm still missing a lot and I'm not going anywhere. Still my fault. When it is only a matter of downloading some sources and compile them then I'm quite fine but this is too much for me, at least by now.


    EDIT: I've tried to build again with the modifications said above. In the end, I've thought that with just a few modifications, the compilation should have taken a lot less so I've tried but I've got this error:


    [ error ] ERROR in function compile_kernel [ compilation.sh:413 ]
    [ error ] Kernel was not built [ @host ]
    [ o.k. ] Process terminated


    I've checked the script compilation.sh (found in lib/) and at line 413 there is just the error printing but the conditional check that arises it is just at the line before:


    if [[ ${PIPESTATUS[0]} -ne 0 || ! -f arch/$ARCHITECTURE/boot/$KERNEL_IMAGE_TYPE ]]; then
                    exit_with_error "Kernel was not built" "@host"


    I'm surely on the wrong path and I haven't applied that patch as I should have done.

  15. @JMCC


    Thanks as always! Your help is precious... :) Following the very well laid down guides, I could easily set everything up. I've immediately tried to build an image but it failed when downloading two packages, them being https://redirect.armbian.com/_toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux.tar.xz and https://redirect.armbian.com/_toolchain/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf.tar.xz.

    Probably it was just a problem linked with my connection but those two errors were regularly repeating. I've manually downloaded the both of them by wget (from exactly the same addresses which were constantly failing inside the script) inside the folder cache/toolchains and this was just enough to get round the problem. It has taken a while (more than four hours on a 3rd gen i7, not exactly an up to date configuration!) but I've then been able to successfully build an image (not tried to flash it though).

    Now the only problem that remains is that I really don't know how to apply jernej's modifications. I'm not a programmer so it's my fault but I don't really know where to start from. Usually, I search and learn but I don't even know what to search for... :( I've made a couple of educate guesses and I've found something about "cherry picking" a commit but I couldn't go on: it goes beyond my knowledge. Thanks again and have a nice day! :)

  16. Small update: changing screen1_output_mode to 11 (indeed PAL as I recalled) didn't solve the problem with the screen margins. I've also tried to apply the other workaround suggested by many (here for example but even in the thread linked above by jernej) adding the kernel parameter:




    at the end of /etc/sysctl.conf (the only way I'm aware to do it but I may be wrong), still to no avail. No changes at all, even minimal, the reason probably being the fact that it seems my modification isn't just taken into account given that checking the resolution I still get 720x576.

    Better to leave this alone for the moment and check how to apply jernej's patch and get a latest image with tv-out (in spite of the fact I don't think it would be that easy, probably involving setting up a whole toolchain).

  17. I've tried the


    modprobe tv


    command and it ran fine so I've started to think about a wrong pinout and I can definitively confirm that the one given here is wrong while the right one is given here.

    Using that pinout everything went fine (at least for video output, I haven't still had the chance to check audio but I would come back with a confirmation about it too) so I can also confirm that all the changes outlined in my previous post (got from that other thread I've mentioned, not my own findings) are just enough to get tv-out working on an OPi PC on Armbian 5.90 Ubuntu Xenial 3.4.113-sun8i. The only 'issue' is that, as already reported by others, the image goes beyond the screen area, probably because the right resolution is 720x480 (I recall having read something like that but I don't remember where). I need to study the necessary modifications and apply them too. It may also be that I just need to set


    screen1_output_mode = 11


    as said here. If I recall well from my extensive research, 14 is NTSC while PAL is 11 so the problem could just reside there.

    I'd also like to apply jernej's patch to be able to get back to Armbian Focal 5.10.4-sunxi still with a working tv-out but I really don't know from where to start. I need to read back (and maybe elsewhere too) and see what to do. Still a lot of work to do for me but in the meantime I wanted to get back to avoid someone else using that wrong pinout and scrambling his mind without reason.

    A slight off topic to say that I couldn't succeed in finding any downloadable OpenElec image indeed all the links given here are dead including this one on MEGA wich contains only empty folders but it doesn't matter now. A nice day to all of you! :)

  18. I apologize for not coming back before but downgrading back to 5.90 has caused me issues with the WiFi connection (discussed in another thread I've recently started) and I couldn't go on with the 'quest' about tv out. I've made all the modifications suggested here to script.bin with the aid of bin2fex and fex2bin:


    disp_init_enable = 1
    disp_mode = 1
    screen0_output_type = 3
    screen0_output_mode = 5
    screen1_output_type = 2
    screen1_output_mode = 14
    fb0_format = 0
    fb0_width = 0
    fb0_height = 0
    fb1_format = 0
    fb1_width = 0
    fb1_height = 0
    hdmi_used = 0
    hdmi_power = "vcc-hdmi-18"
    tv_used = 1
    tv_dac_used = 1
    tv_dac_src0 = 0


    I've then rebooted but nothing. I've also added (as still suggested in that thread) a line with




    at the end of /etc/modules but still no signal on tv out. Now, maybe I'm missing something or the pinout I'm using (this one) isn't the right one. I don't know. Please note that I haven't installed any additional package: I just expect to get the CLI on my television and it could well be I'm being misleaded by this assumption. Have a nice day! :)

  19. Hello to everyone! :) I'm trying to solve the issue which is currently being discussed here and I've been forced to revert back to the ancient version in the title. The problem is that along with my OPi PC I use a cheap wireless adapter based on the MT7601. Here, I've found out that the support for these cards had been merged to upstream since 4.2 kernel versions indeed with Armbian Focal 5.10.4-sunxi it worked out of the box like a charm. Unfortunately, it isn't the case with the version I'm currently on, this adding another massive headache! ;)

    I've found this really interesting thread where it is discussed how to add support for the MT7601. Everything went fine apart from the fact that issuing the


    apt-get install linux-headers-sun8i


    command, I get the message that the package doesn't exist nor I was able to find a .deb package anywhere to install it by dpkg. The headers are definitively missing (I've checked) and I can't complete the driver compilation. Here I've found the headers for what should be the right arch (armhf) but for the 3.4.112 kernel version. I know it's an insane approach but I've tried to use them to build the driver. This way, I've been able to complete the procedure described in the aforementioned thread but when I try to issue the


    modprobe mt7601Usta


    command, I get:


    modprobe: ERROR: could not insert 'mt7601Usta': Exec format error


    this being certainly due to my insane choice before. I couldn't find any in spite of my extensive research but I ask "is there a way to get hold of those 3.4.113-sun8i headers?" or at least (probably even more intriguing, I have to say!) "how to build them from sources?". Regarding the latter question, I've gone through a lot of reading here, here and here but I couldn't find the answers I was looking for unfortunately. Here I've also found what I believe are the sources upon which I could try to build the missing headers exactly like the other user on the OrangePi forum had done but I don't even imagine how and where to start from.

    In the meantinme, I've scoured another WiFi adapter based on the RTL8192CU which is instead supported out of the box so I'm able to go on with my other 'quest' but I'd like to solve this one too if possible, even 'only' to learn something new. As always, thanks in advance to anyone coming with a suggestion! :)

  20. @JMCC


    Thanks for your suggestion. I would write the image to another sdcard ASAP and would get back with the results. So, do you confirm to me that AV out doesn't work on the newest versions? That's a pity... Maybe it's necessary to compile a kernel with the support for it but I don't know from where to begin should this be the case! :(

    Just another confirmation. I've found some discordant AV out cable pinouts, the most common to be found being this one:




    Is it actually the right one? I'd like to rule out issues with the cable otherwise it could well be that everything could be up and running while misleaded by just a wrong cable. Thanks again and have a nice day! :)

  21. Hello to everyone! : ) I've made a lot of digging around but I haven't found a final reply to my questions because all the informations I've found are quite old and probably outdated. I own an OPi PC which I was using with Libreelec but unfortunately the HDMI output broke because of the missing protections. By what I know, there isn't any mean of getting AV out working on Libreelec so I switched to Armbian for which it seems to be possible instead. I've installed it with no issues at all (version as per title) but all the guides I've found on this forum to enable AV out seem not to apply, probably because they're intended for much older Armbian versions nor I couldn't find other threads and/or guides online on the subject.

    I've also read the AV out at some point have been disabled because it drawed electricity with no use for it in the most of the cases but also another thread where it seems that for H3 it is enabled and working out of the box so, overall, a lot of contrasting answers.

    I don't know what to think and I'm COMPLETELY clueless. It could well be that it doesn't work not because it is missing all the necessary background but maybe 'just' the X11 environment given that I've just written the image to an sdcard, completed the first run wizard, enabled wifi and then installed the kodi package (which, indeed, I can't start because it complains about the inability to create a GUI).

    I know I'm making a dumb effort actually shooting in the dark but, in spite of my many attempts, I couldn't find conclusive answers nor any documentation in the forum or anywhere else. I hope to get at least an hint from someone and I thank you all in advance.

  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines