jernej

Members
  • Content Count

    749
  • Joined

  • Last visited

1 Follower

About jernej

  • Rank
    Embedded member

Recent Profile Visitors

2266 profile views
  1. 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 https://www.waveshare.com/3.5inch-rpi-lcd-a.htm and the likes. As you can see, this one states that SPI interface is supported, while yours does not.
  2. I'll get box with DDR3 probably early next week, so I'll join the party.
  3. 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.
  4. Note that you are missing ATF binary, so Linux won't boot. of course, earlyprintk works everywhere if UART driver driver is available.
  5. 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.
  6. 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.
  7. Thanks, but I haven't any files. Somebody with a board and will to write/debug DRAM driver has to do it.
  8. 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: https://github.com/apritzel/u-boot/commits/eachlink-h6-mini-WIP It's only a matter of fixing this up.
  9. Note the comment PF6 - port F, pin 6. If A is 0, then F is alphabetically 5.
  10. It was never publicly available AFAIK. However, you can download i.MX8 documentation which has small overview of this core and registers description.
  11. There is also VP9 decoding IP core , which is present in Allwinner H6, NXP i.MX8 and I think Rockchip has it too. It may be connected to Hantro and Google, but I'm unsure who is the original author.
  12. First, don't mix GPU and VPU (read https://www.cnx-software.com/2013/12/10/most-embedded-gpus-do-not-support-hardware-video-decoding-acceleration-the-vpu-does/) Secondly, yes, working driver exist, but just fbdev version and gbm/wayland. I'm not sure if X11 driver is available at the moment. Thirdly, Firefox doesn't use any kind of HW accelerated video decoding on Linux as far as I know. So, what are you trying to reach, e.g. smooth video playback in web browser is not possible at the moment and probably not for a long time. However, if you just want to watch youtube videos, maybe combination of Kodi on LibreELEC + youtube plugin would work for you? Unfortunately, only H6 currently supported board is PineH64, but support for OrangePi 3 is also planned in the future. Why this works? No X11, so existing gbm mali driver is used and modified ffmpeg is used to support HW video decoding driver.
  13. Actually, it's the other way around. You can copy H6 HDMI audio patches from LibreELEC git. Analog audio needs much more work...