• Content Count

  • Joined

  • Last visited

 Content Type 


Member Map





Everything posted by jernej

  1. Mali is only 3D accelerator, so I'm not sure what you mean exactly by that. If you mean HDMI output, that's entirely different thing, but it works. However, without any kind of acceleration. Mali T720 is not supported at all at this moment, however it will be soon.
  2. @hexdump @balbes150 Can one of you upload picture to show what would be appropriate cooling solution? Is it possible to have semi-decent cooling in the original box?
  3. @hexdump Yes, I force pushed minutes ago. I added a fix which always resets AC200 before first usage. This fixes the bug with non-working network after reboot.
  4. No, I'm not. I'm just following Lima PRs in Mesa repo. Because it's missing a lot of fixes and improvements? Why not use mesa master directly? I see backporting as a waste of time (Arch user here :)).
  5. Well, driver is what it is. More important bit is mesa and there was significant advancement. But you have to use mesa master, 19.1 is not so good. What do you mean by that? Development is done in mesa master branch now, everything else is deprecated, including lima fork, where initial development was done.
  6. @hexdump try with CONFIG_DWMAC_SUN8I=m Currently unsolved issue is that you have to make sure that AC200 EPHY driver initializes before network driver. With making network driver a module, and AC200 built-in, you make sure that this is the case.
  7. @hexdump You can try LE test image with working ethernet (if you don't reboot):
  8. I don't really know which lima patches are strictly needed, but most of them should be in 5.2 (I''m no lima expert either).
  9. I'm probably missing something, but why are lima patches still there? They should not be needed with 5.2 anymore and they even shouldn't apply.
  10. @hexdump can you upload your dmesg & config when you'll have time? Maybe I can find something.
  11. @hexdump that should be working tree. Albeit I didn't test exactly this branch, from what I can see, it has all patches that are needed. Did you include mdio and emac node in Tanix TX6 DT?
  12. @hexdump With latest two patches here: ethernet now works! However, this is very early work, so it contains one ugly hack in PWM driver. In order to use it, you have to enable following drivers: CONFIG_AC200_PHY=y CONFIG_MFD_AC200=y CONFIG_COMMON_CLK_PWM=y CONFIG_PWM_SUN4I=y CONFIG_NVMEM_SUNXI_SID=y and some more obvious, like I2C. Note that SID will gain H6 support only in Linux 5.3. You also need two patches from linux-next for H6 ethernet driver. Now I have to clean it up, which will probably take as much time as I needed to write this. P.S. eMMC doesn't work for me for some reason. But that is low on my TODO list. If you manage to fix it, please let me know.
  13. - HDMI works fine if you use OrangePi 3 patches, which set GPIO PH7 high, to enable DDC bus. - I'm working on ethernet phy driver, it's close to being ready, I just need to debug it - not sure about USB hub as I don't use them
  14. @hexdump I think axp_dummy is really just that, dummy driver. However, at some point I saw that it may call to AR100 to do voltage switching instead, but I think that's not the case here. I'm really not specialist in DVFS, so I can't answer your questions regarding that. No, I didn't do much regarding PHY driver. I just researched the topic in kernel. AFAIK we will have big pain to get it mainlined. There is no other PHY in kernel which has similar initialization sequence. We'll see. These days I was focused on implementing "half DQ" support in H6 DRAM driver for Tanix TX6 mini. Why would someone use that in media center oriented box is beyond me. It brings (much?) lower memory bandwitdh. I guess they really wanted to lower the price of the box, because they also used XR819 wifi. But yes, I received my TX6. I'm trying to add support for it to LE, but in the process I broke all other already supported boards. It has something to do with GPU, frequency and voltage regulator. In the process I also found regressions in AXP805 mainline driver (I didn't send patches yet). P.S.: These days it's very hot here, so I'm a bit slow with all this stuff. Fortunately, next days will not be so hot.
  15. I'm not sure for what is the purpose of that 26-pin header. Official documentation still says you have to connect HDMI and gives you HDMI settings. I imagine pin header is meant for screen management, like screen rotation and similar. Anyway, 1024x600 is too big for SPI screen, refresh rate would be abysmal. For example, if you running SPI at 40 MHz, using 24-bit colors and utilize every cycle for pixel data, you would have 2.7 FPS. On top of that, CPU would have to SW render it, which is another slowdown. That guide links to another, which explicitly states it for and the likes. As you can see, this one states that SPI interface is supported, while yours does not.
  16. You linked HDMI version of the screen. Which SPI screen do you have?
  17. I'll get box with DDR3 probably early next week, so I'll join the party.
  18. In case of Allwinner port of U-Boot, ATF (bl31.bin) gets packaged into itb file (u-boot.itb), along with U-Boot proper (u-boot.bin) and dtb file. You should just combine sunxi-spl.bin-arm32 (make sure is padded to 32K or 24K, I'm not sure ATM) and u-boot.itb. BTW, I'm not sure if mainline Linux works with BSP ATF binary. Just compile latest official ATF release (mainline H6 ATF is not board specific, so it should work). Not sure, I don't use earlyprintk. If it's not CPU mode issue (Linux expects that it's already in 64-bit mode) it may be DT issue. Anyway, I wouldn't bother with Linux at this stage. Fixing mainline DDR3 DRAM driver would help a lot with other issues.
  19. Note that you are missing ATF binary, so Linux won't boot. of course, earlyprintk works everywhere if UART driver driver is available.
  20. yeah, DRAM drivers usually nobody wants to write due to that. And that driver is also responsible for stability of whole system. You can achieve something similar with using libdram as it is done in commit you noticed. However, it has at least two downsides. As commit message says, it's legally non-redistributable, because you mixing GPL code (SPL) and closed source code (libdram) in single binary. Second downside is that libdram is 32-bit, which complicates compiling SPL and other parts. You would need two different configuration files and combine everything by hand. I don't think using BSP SPL as a whole is possible with mainline U-Boot.
  21. My approach was (not in that order): - disassemble DRAM blob from Allwinner - compare disassembled code to existing code and minimize differences - read documentation of similar controllers (some Zynq variants seems to have similar controller) - read explanation of how DRAM actually works on the net - compile SPL and U-Boot as 32-bit binary, which allows loading it through USB quickly (FEL boot) - prepare SPL/U-Boot binary using libdram for later register comparison - add a lot of debug prints in driver to see what is actually doing and compare values to those from libdram I didn't wrote it from scratch, so this is similar situation. Since testing and comparing is everything, I can only help with reverse engineering libdram and comparing existing code to that. One person already accepted the challenge on LibreELEC forum for writing this driver (also Tanix TX6 box), but it's always nice to have bigger team working on this.
  22. Thanks, but I haven't any files. Somebody with a board and will to write/debug DRAM driver has to do it.
  23. That's expected because Tanix TX6 uses DDR3 memory which is not supported yet by U-Boot. All currently supported boards use LPDDR3. Anyone wants to do some low level hacking? I would, but I don't have such board. Previous unsuccessful attempt can be found here: It's only a matter of fixing this up.