levitsky86 It's best if you compile both, image and addon. Order is not important, because already build stuff is reused. But no, addon won't be included in image automatically. You have to install it manually from zip package.
Posts by jernej
-
-
Unfortunately, I have a second board Orange Pi PC2... and it is not supported))
It will be very soon. Test image is already linked few posts (pages) back.
-
I suspect you would have issues with any H6 board, since 99% things is same across all boards. While I don't have one plus, I have several other H6 boards and have no problems whatsoever. I'll leave it in.
-
So, all the builds I've been testing for a couple of month won't detect the correct resolution neither connected to the Full-HD display through HDMI-DVI adapter, nor to HD-ready TV directly. 1024x768 max. Is it possible to force 1080p somehow? The issue persists on Armbian as well.
Kernel mode setting - ArchWiki
Use variant drm.edid_firmware=edid/your_edid.bin
-
This is a serial console boot image armbian (Orange Pi - Orangepi)
Older U-Boot is used, which is not an option here due to Python3 issues. I suspect Armbian will have same issue once they update U-Boot.
Can I somehow specify the screen resolution at boot time?
I want to try with other parameters ... 720... 480 ...
Kernel mode setting - ArchWiki
Use variant drm.edid_firmware=edid/your_edid.bin
-
dhanar10 there is one very effective but very tedious method - bisection. With it, you can find which commit in U-Boot exactly breaks boot. This will take about 10 steps.
Do following:
1. checkout U-Boot sources from git: U-Boot / U-Boot · GitLab
2. start bisection in u-boot folder:
Codegit bisect start git bisect bad v2020.01 git bisect good d9110878895634cd9e8bf891c832d2a58b36863c3. create image with hash git bisect suggest to you and test it. For easier testing, I suggest you set PKG_SHA256 to empty string.
4. if it works, enter git bisect good or if it doesn't git bisect bad
5. repeat 3-4 until git gives you message "first bad commit is ..."
6. report this bad commit here.
It seems only boards with 512 MiB RAM are affected, which are not supported here anyway. So if you can find anything, I'll look into it, but otherwise it will stay as it is. U-Boot revert is not an option.
-
Vadim_0632 DRAM size is autodetected. Can you provide image of top and bottom side of the board so I can read RAM chip markings? It could be bug in DRAM initialization code or manufacturer silently replaced chips with higher capacity. You can add mem=1G
kernel arguments to force DRAM size to 1 GiB.
Ignoring ssh shouldn't matter. Kernel ignores any argument it doesn't recognize. ssh argument is picked up by LE script.
-
When you say "linux-next", are you talking about Torvald's mainline kernel?
No, linux-next is continuous integration test tree, which picks changes (almost) every work day from all subsystem maintainter trees: kernel/git/next/linux-next.git - The linux-next integration testing tree This is as bleeding edge as it can be. Changes included in this tree land in Torvald's tree during merge window at latest.
I really want to test this board and give feedback since Armbian is already working great on it.
Main reason PR is not merged in LE yet is that I don't have that board and PR author didn't rework it to my liking yet.
-
Unfortunately I am not that skilled at all, so I don't know how should I run that. Perhaps there is any guide for noobs?)))
-
serial console.... no login input...
you will get that by appending systemd.debug-shell=1 to the kernel arguments and maybe you'll also need to remove console=tty1 (not sure if that is still needed or not)
what are the parameters of ssh?
port? Name? pass ?
-
So those come from armbian and mainline kernel, as I expected.
Well, I wouldn't say that. If patches would be present in mainline already, there wouldn't be need to have them. I also don't see such patch in Armbian, so I suspect it's original work from PR author. Anyway, soon PR will need a rebase becasue patches pulled from linux-next will break it.
As far as I understand I could fetch the commits from that pull request,
You could also pull directly from PR author's github. That way you don't need to pick commits.
do I need to also make an specific "target" for the Orange Pi Lite 2? Where are the target files for the supported devices located in the git repo?
There is no specific board handling done in build system, except in scripts/uboot_helper, but that's already handled in PR. Even SoC specific handling will slowly get away, at least from patch perspective. Wifi chip is already supported in mainline and package which provides broadcom wifi firmwares already supports it.
-
what could be wrong?
I have no clue, you should provide logs, best if you connect to serial console or ssh and get some info like dmesg. You can force enable ssh with adding ssh to the end of APPEND line in extlinux.conf. Do you by any chance use HDMI converter, like VGA to HDMI?
-
levitsky86 Plugins are currently hit or miss, depends if Kodi was just updated in nightly images. Only certain method is to build addon yourself. That should be easy with [tt]PROJECT=Allwinner ARCH=arm DEVICE=H3 scripts/create_addon pvr.iptvsimple[/tt
-
rellla Please check with serial console what's going on, note that you should remove "quiet" kernel argument from extlinux.conf. Eachlink H6 is known to have issues with mainline U-Boot and Linux - with DRAM initialization and with HDMI plug in detection. There are workarounds available as described on Armbian forum, but it would be good to know which one of these two issues you experience (or both).
-
JORGETECH There is PR open allwinner: add initial support for H6 orangepi-lite2 board by prabuselva · Pull Request #3961 · LibreELEC/LibreELEC.tv · GitHub which should work. Maybe I asked too much from the author...
-
dhanar10 can you please test if adding #CONFIG_SYS_RELOC_GD_ENV_ADDR is not set to projects/Allwinner/bootloader/config and test with U-Boot 2020.01?
-
lima driver (used for mali450) doesn't support devfreq yet, but it's worked upon. Currently it's expected that reasonable defaults will be set either by bootloader or DT (if possible).
-
Is there current problems with video decoding on the OPI3?
No. Press "o" during playback and check which codec it is and if it is HW or SW decoded. Chances are that you're using unsupported codec and it's decoded in software. That can happen with YouTube plugin now that more and more video streams are VP9 coded. While H6 technically supports HW decoding VP9, it will take a while before it becomes implemented.
