• Posts

  • Joined

  • Last visited

 Content Type 


Member Map




Everything posted by jernej

  1. This board has 1 GiB of RAM - just multiply 4 x 512M x 4 bits and you get 8G bits which is 1G bytes. You would need 8 chips (512M x 4) to get 2 GiB.
  2. It seems like 4 chips, right? so, 4x 512M x 4 -> 2x 512M x 8 -> 1G x 8 -> 1 GiB Your board has 1 GiB of RAM and DRAM driver properly detected it.
  3. GPU and CPU share same memory bus, so 2 GiB total. If you really want to figure out amount of RAM, you should open your box and post detailed images of the board (both sides), so number and markings on RAM chips can be determined. From that, real amount of RAM can be calculated. It also helps verify DRAM settings (DRAM driver is not "one size fits all", it has to be properly configured).
  4. Ah, you didn't add panel description to DT for Linux. So yes, Linux uses U-Boot FB. 32-bit colours are hardcoded in U-Boot here: Fortunately for you, I added handling 16-bit colours (if you change constant), but I can't guarantee it will work. I only tested it in U-Boot for H3 and not in Linux. EDIT: Apparently you have to change also this line:
  5. That may or may not be true. Linux has proper V3s display driver for a long time. However, U-Boot may still hand over its FB to Linux. In that case U-Boot FB is used for a very short time and it's replaced with Linux FB during boot. Now, I'm not sure if U-Boot FB memory is actually released or just stays reserved. Best way to check would be to disable display driver in U-Boot (via U-Boot config and rebuild) and compare free memory. I don't know how to force 16-bit buffer. There is probably some kind of kernel parameter for that.
  6. If you can manage to prepare appropriate edid binary, you can supply it to kernel according these instructions: If it works, you can in some cases also write that permanently into your screen. Wrong EDID is worst kind of issue. I never actually had such problems, so I'm not sure how to edit edid.
  7. Everything seems to be in order, assuming edid is correct. Refresh rate is pretty strange - 65.681 Hz. Clocks are correctly set according to edid - 32 MHz. I have another waveshare HDMI screen (1024x600) where pixel clock is also 32 MHz and it works fine. Not sure what to suggest, except that you can try to override edid with your own.
  8. Please provide EDID blob (most probably at /sys/class/drm/card0-HDMI-A-1/edid) and content of /sys/kernel/debug/clk/clk_summary
  9. Can you give link to your exact model? Looking at waveshare site, 4.3" 480x272 LCD has only 40 pin connector - this will not work with anything but RPi. Or did you mean 4.3" 800x480 HDMI monitor? This one should work in theory. There is also 4.3" 800x480 DSI one which I'm not sure if it can work or not.
  10. There is one more difference - usb@5101000 and usb@5101400 are missing phys = <0x15 0x00>; phy-names = "usb"; If that doesn't work, then I don't know. I don't think anyone currently works on H616, so it probably won't change much in near future.
  11. @XFer012Check USB changes here You can ignore others. Note the changes in number of phys in usbphy nodes.
  12. @XFer012Above DT change will most probably lock up CPU - CPU is changing clock from which it is running. Much safer bet is to change CONFIG_SYS_CLK_FREQ in U-Boot to the frequency you want. There CPU is first switched to alternate (slow) clock source and once main CPU clock is adjusted, it's switched back.
  13. You can try with (but no guarantee) in cpu0 node: assigned-clocks = <&ccu CLK_CPUX>; assigned-clock-rates = <1080000000>; Safe default is set in SPL (one of the first things that's is done). Note that everything is done by community without any plan. I just told you current pattern regarding these things. It could be that someone would prepare such patches soon or no one would find it interesting enough to work on it.
  14. Check ohci, ehci and usbphy nodes in my DT: and You should make a patch which adds these changes to DT, add patch to build system and build image. You can probably get away with making DT overlay too. Note that these are developer level instructions - I don't plan to write more detailed steps.
  15. that gets sorted out usually very late, when a lot of other features are already working. Those messages don't indicate alpha stage. Disabling just means that regulator was enabled at boot but Linux doesn't need it. "using dummy regulator" means that voltage regulator is not needed (vcc- regulators might get specified later but most of the time are not needed). syscon value message is imo useless and will probably get removed sooner or later. In short - several of these messages will probably stay in later, more complete kernel.
  16. It's possible to make it work if you enable all USB nodes in DT. It seems like some HW quirk.
  17. That's true. However, each platform must also define fdtoverlay_addr_r in default environment. Patches for amlogic and allwinner exist on ML, but I'm not sure for others.
  18. That's from BSP kernel sources and can't be used as-is on mainline, which is what Armbian uses.
  19. Ultimate check would be to read markings from RAM chips, check datasheet and calculate the size. If you can provide those markings and number of chips, I can do it pretty easily.
  20. @Hemin@KY69 Note that if U-Boot detects only 2 GiB of RAM, you'll have problems once Linux tries to use that extra 1 GiB (writing to address 0 will be same as writing to address at 2 GiB - wrap around). So I highly recommend that U-Boot output is inspected on serial console. SPL should report 4 GiB and U-Boot should report 3 GiB.
  21. This happens on all SoCs with DE2 or newer (A83t or newer SoC). Most SoCs have only one capable plane which can display YUV formats and it's always below current framebuffer, so that "workaround" (which imo is not workaround, but just part of configuration) is always needed in your use case. Note that having video plane below UI plane is actually desired for video players - UI plane has alpha channel which makes window with video transparent.
  22. Good summary, let me clear some things. Having proper uAPI by no means makes libva-v4l2-request obsolete. If this lib is updated to latest uAPI, it still could serve as intermediate layer for all apps that don't support new interface but they support VA-API. Before you talked about libva-v4l2-request, which implements VA-API, so I wouldn't say it's irrelevant to ARM HW accel. libvdpau-sunxi implements VDPAU, but that works only on BSP kernels and it is not relevant for mainline. Further clarification: Kodi 19.0 (released recently) is highly recommended for all this - it doesn't require any out of tree patch for video decoding (LE uses patch for HW deinterlacing). Additionally, with version 19.0, there is single binary for all 3 windowing systems (gbm, X11, wayland). Depends on build options. Not sure if this version is available on Armbian but PPA exists, so I guess it should not be hard to test. H264, MPEG2 and VP8 should be good in mainline, although api can still change until codec is promoted to uAPI. HEVC still needs out-of-tree patches for any serious work. Maybe you can update your text, so we have current state overview in single post.
  23. oh, there is plenty of bugs left to fix... but for normal use should be enough.
  24. It's not a hack but missing clock initialization. I submitted fix to U-Boot: Currently non-working features are scaling on video plane, YUV formats and resolutions > 1080p.
  25. If someone has too much time, here is extremely basic and hackish H616 display driver (HDMI up to 1080p only): (take branch as-is, USB works too)