service or program addons don't show drivers to choose (tbs, crazycat, etc)..
Allwinner images don't support those driver addons as they could interfere with Cedrus driver (replaced it with other version).
Posts by jernej
-
-
I guess we should bring the board itself upstream first? Or do you mean upstream libreelec?
No, I mean upstream kernel. well, I don't think it matters. But mainlining board would be great too.
With the other branches, i don't get networking up. But therefore I have to look into the dts for the differences.
You mean other board images? Only Tanix TX6 image have enabled 100mbit ethernet.
Anyway, this board is peculiar from many different perspectives. It would be nice to know why. If you have time to investigate, that would be great.
So best would be to find a way, how this could be fixed within the driver?
Yes.
-
And this is the keymap for Eachlink H6 Mini remote control:
Maybe you can send it upstream?
Kodi works fine - but sadly it doesn't come up again as soon as i did a shutdown or disconnect. I get signal on HDMI. It's kind of a console ... i can see my inputs with keyboard and remote, but thats it. No network, just black screen.
Would i get kernel messages, if i drop the “quiet“ option?
What do you do after shutdown? After shutdown you can only power cycle the board to turn it on again. You can of course try with removing "quiet". I suggest you add "ignore_loglevel" to get even more output.
Btw, is it possible to set http://LibreELEC.tv/options at eachlink-h6mini · rellla/LibreELEC.tv · GitHub depending on the device?
By device you mean board? Devices in Allwinner project are actually SoCs. There is no way to set board specific kernel options. However, you can make SoC specific options. Just move that line in options file in appropriate device subfolder.
-
The bad news are, that LE doesn't work after reboot. May it happen that there is done some update and my kernel parameters are overwritten again?
By "reboot" you mean soft reboot, right? Usually that means that kernel crashed at shutdown. Uart output would help
It seems, that the hdmi option is enough for me to get it started the first time.
ok, good to know, thanks!
-
But i simply took the Tanix Image and added "mem=2048M video=HDMI-A-1:e" to the kernel options. It works fine now.
Are both needed? If you didn't check that yet, can you do that please?
Though I couldn't connect the UART because i have v1.2 which is missing the resistor. While soldering i damaged the pads
It happens. Jump wires FTW!
-
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.
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.
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.
-
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.
I checked out the cedrus_update branch.
Always use LibreELEC master branch.
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.
-
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?)))
