Posts by jernej

Quote from PJBrs

So I took "unsupported" to mean that developers don't fix bugs for it. I take it that you mean that I'm mostly on my own with this one? Would you take any patches if I succeed?

Yes, yes and no, sorry.

Quote from PJBrs

Really? 'Cause what I would like to use is the tree with the best support for Mali-400 + cedrus. If you could give me a pointer to the best supported github branch for that, that would be very very helpful!

That's LibreELEC master. When I find any fix, I make PR. For example, changes in branch you used are already merged in LE master. I already deleted branches from my repo which were merged into LE.

Quote from PJBrs

I know you suggested to create a H2 device, but as far as I know H2 and H3 are actually fully compatible and the same, so I was wondering what difference that would make.

Scripts, which build final image, assume that device name is part of dtb file name. That's the reason your final build is missing dtb file.

Quote from PJBrs

I own a BananaPi M2 Zero (Allwinner H2+). I would like to run Kodi on it.

Boards with less than 1 GiB of RAM are not supported as stated in OP and it seems that there is an issue with current U-Boot on such boards and they don't boot. Not 100% sure, but that seems to be the pattern.

Quote from PJBrs

I checked out the cedrus_update branch.

Always use LibreELEC master branch.

Quote from PJBrs

Then I patched the source as follows:

You have to add new H2 device. Just copy H3 device folder and name it H2. Then create H2 section in U-Boot helper scritpt. But even if you do that, I'm not sure if it will be bootable due to possible issue in U-Boot itself.

.img.gz is same format as images linked in OP. It's complete image. Just extract it and burn it to SD card. For now you can ignore the rest.

Building image needs about 20 GiB of free disk space, less if you have already build addon (don't know how much exactly). But there is experimental feature, which cleans package as soon as it is build and installed - just add AUTOREMOVE=yes to the command line. With this, you should need much less free disk space.

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.

Quote from Vadim_0632

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.

Quote from Zoom

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

Quote from Vadim_0632

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.

Quote from Vadim_0632

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:

git bisect start
git bisect bad v2020.01
git bisect good d9110878895634cd9e8bf891c832d2a58b36863c

3. 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.

Quote from JORGETECH

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.

Quote from JORGETECH

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.

Quote from levitsky86

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?)))

Compile [LibreELEC.wiki]

Quote from Vadim_0632

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)

Quote from Vadim_0632

what are the parameters of ssh?

port? Name? pass ?

Accessing LibreELEC [LibreELEC.wiki]

Quote from JORGETECH

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.

Quote from JORGETECH

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.

Quote from JORGETECH

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.

Quote from Vadim_0632

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).