Jump to content

Blackenz

Members
  • Posts

    17
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi @Nick A! I will test it for sure. On another subject, i found my dmesg filled with these messages: These happen on sub second as you may notice. I am worried that this issue will eventually kill my EMMC... Anyone else seeing this behavior?
  2. Hi @Nick A, So i just happened to do exactly that. I used sicXnull's branch and tvbox is finally booting from the sdcard, running my custom image. Didn't have to apply your patch. Any thoughts on merging @sicxnull branch into armbian official codebase? Thanks for your help
  3. @Nick A using the @rafman image that he previously posted (Armbian-unofficial_24.11.0-trunk_X96q-v5-1_bookworm_current_6.6.44_mate_desktop.img.xz), on the same card, the tv box boots from the sdcard just fine. I am assuming that the image that is being generated by the compile.sh script from the oficial repo, has some kind of problem. Anyway, i will try pushing the button on the AV port, with my image, just to eliminate that possibility. Thanks
  4. Also tried Balena Etcher, and the result is the same... The box does not boot the sdcard. So, to help trying to diagnose my issues, these were the steps i have done: Copied your patch to "patch/u-boot/u-boot-sunxi/board_x96q", then ran: ./compile.sh Selected: "Do not change the kernel configuration" Then entered: CSC and chose "x96q" target. Used the current kernel. Chose bookworm > Image with console interface (server) > Minimal image with console interface. After the compilation is done, i flashed the the sdcard with USBImager and also with Balena Etcher. The result was the same. Tv box skips sdcard boot and boots to Android. Regarding the UART, i had to solder the pins so I don't exclude a bad soldering job... I will recheck the connections. Thanks
  5. Ok, so i had some time to do more tests... Well, in first place i kinda feel a bit stupid regarding the HDMI issue... Actually it was the cable that was not correctly connected... After diagnosing that issue, i tried to boot the image that i created again, but it seems that the board skips the boot from the sdcard and boots directly to the Android system which is still installed on the EMMC. I then tried @rafman image (Armbian-unofficial_24.11.0-trunk_X96q-v5-1_bookworm_current_6.6.44_mate_desktop.img.xz), and the board boots correctly (with no UART console messages. Is it supposed, or might i have a problem in my UART?) For all the tests i did i used USBImager, so i am excluding problems with the card flashing method. Is anyone else creating the images from Armbian main branch? Thanks
  6. Hi @Nick A! I think your solution has worked because, when compiling, i saw that the build scripts "saw" the patch on the "patch/u-boot/u-boot-sunxi/board_x96q" folder. The box seems to be booting now because i see the blue led coming up, though, i have no image on HDMI . I am running Kernel 6.6.44. Isn't HDMI supposed to be working? I'll try and see if UART is working. Once again, thank you for your hard work.
  7. Hi all! @Nick A i have the same x96 version as @Lancoly. I am trying to follow your instructions on building my image from Armbian official repo, though i am struggling to find some of the folders mentioned on your previous posts. From my understanding it seems that i have to apply the secure boot patch on the official sources, though i can't seem to find the folder "configs" in the armbian build root. This is the root folder of the git tree: I have found the "arm64-sun50i-h313-add-x96q-lpddr3-defconfig.patch" inside "patch/u-boot/u-boot-sunxi/board_x96q". Should i add the "CONFIG_SPL_IMAGE_TYPE_SUNXI_TOC0=y" here? How do i apply this patch? It seems that the structure of the build root has changed. Thanks for your help and effort on bringing Armbian to this great cheap Tv Box.
  8. Okay, so after a lot of digging i might found the reason why i am having a lot of trouble with this display and the orange pi. I extracted edid from x64 Ubuntu (which is partiatly working, since it is also not outputing in display native mode), and it seems that the native resolution is only beeing specified in the DisplayID Extension Block and not in the Base Blocks: cat /sys/class/drm/card0-HDMI-A-1/edid | edid-decode edid-decode (hex): 00 ff ff ff ff ff ff 00 4c 2d 52 70 58 4a 58 43 ff ff 01 03 80 77 22 78 2a c7 25 b1 4b 46 a8 26 0e 50 54 bf ef 80 71 4f 81 00 81 c0 81 80 a9 c0 b3 00 95 00 d1 c0 1a 68 00 a0 f0 38 1f 40 30 20 3a 00 a9 50 41 00 00 1a 00 00 00 fd 00 32 4b 1e b7 3c 00 0a 20 20 20 20 20 20 00 00 00 fc 00 4c 43 34 39 47 39 35 54 0a 20 20 20 20 00 00 00 ff 00 48 34 5a 54 31 30 31 31 34 38 0a 20 20 03 24 f0 02 70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 9e 02 03 3d f1 49 90 61 60 1f 04 13 12 03 5a 23 09 07 07 83 01 00 00 e2 00 4f e3 05 c0 00 67 03 0c 00 10 00 b8 3c 67 d8 5d c4 01 78 80 03 e6 06 05 01 8b 73 12 e2 0f 06 e5 01 8b 84 90 01 56 5e 00 a0 a0 a0 29 50 30 20 35 00 a9 50 41 00 00 1a 58 4d 00 b8 a1 38 14 40 f8 2c 45 00 a9 50 41 00 00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 71 70 12 79 00 00 03 01 28 33 b7 00 88 ff 13 9f 00 2f 80 1f 00 9f 05 28 00 02 00 09 00 6e c2 00 08 ff 09 9f 00 2f 80 1f 00 9f 05 54 00 02 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d6 90 ---------------- Block 0, Base EDID: EDID Structure Version & Revision: 1.3 Vendor & Product Identification: Manufacturer: SAM Model: 28754 Serial Number: <redacted> Model year: 2245 Basic Display Parameters & Features: Digital display Maximum image size: 119 cm x 34 cm Gamma: 2.20 DPMS levels: Off RGB color display First detailed timing is the preferred timing Color Characteristics: Red : 0.6943, 0.2929 Green: 0.2744, 0.6591 Blue : 0.1484, 0.0566 White: 0.3134, 0.3291 Established Timings I & II: IBM : 720x400 70.081663 Hz 9:5 31.467 kHz 28.320000 MHz DMT 0x04: 640x480 59.940476 Hz 4:3 31.469 kHz 25.175000 MHz Apple : 640x480 66.666667 Hz 4:3 35.000 kHz 30.240000 MHz DMT 0x05: 640x480 72.808802 Hz 4:3 37.861 kHz 31.500000 MHz DMT 0x06: 640x480 75.000000 Hz 4:3 37.500 kHz 31.500000 MHz DMT 0x08: 800x600 56.250000 Hz 4:3 35.156 kHz 36.000000 MHz DMT 0x09: 800x600 60.316541 Hz 4:3 37.879 kHz 40.000000 MHz DMT 0x0a: 800x600 72.187572 Hz 4:3 48.077 kHz 50.000000 MHz DMT 0x0b: 800x600 75.000000 Hz 4:3 46.875 kHz 49.500000 MHz Apple : 832x624 74.551266 Hz 4:3 49.726 kHz 57.284000 MHz DMT 0x10: 1024x768 60.003840 Hz 4:3 48.363 kHz 65.000000 MHz DMT 0x11: 1024x768 70.069359 Hz 4:3 56.476 kHz 75.000000 MHz DMT 0x12: 1024x768 75.028582 Hz 4:3 60.023 kHz 78.750000 MHz DMT 0x24: 1280x1024 75.024675 Hz 5:4 79.976 kHz 135.000000 MHz Apple : 1152x870 75.061550 Hz 192:145 68.681 kHz 100.000000 MHz Standard Timings: DMT 0x15: 1152x864 75.000000 Hz 4:3 67.500 kHz 108.000000 MHz DMT 0x1c: 1280x800 59.810326 Hz 16:10 49.702 kHz 83.500000 MHz DMT 0x55: 1280x720 60.000000 Hz 16:9 45.000 kHz 74.250000 MHz DMT 0x23: 1280x1024 60.019740 Hz 5:4 63.981 kHz 108.000000 MHz DMT 0x53: 1600x900 60.000000 Hz 16:9 60.000 kHz 108.000000 MHz (RB) DMT 0x3a: 1680x1050 59.954250 Hz 16:10 65.290 kHz 146.250000 MHz DMT 0x2f: 1440x900 59.887445 Hz 16:10 55.935 kHz 106.500000 MHz DMT 0x52: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz Detailed Timing Descriptors: DTD 1: 3840x1080 59.968497 Hz 32:9 66.625 kHz 266.500000 MHz (1193 mm x 336 mm) Hfront 48 Hsync 32 Hback 80 Hpol P Vfront 3 Vsync 10 Vback 18 Vpol N Display Range Limits: Monitor ranges (GTF): 50-75 Hz V, 30-183 kHz H, max dotclock 600 MHz Display Product Name: 'LC49G95T' Display Product Serial Number: <redacted> Extension blocks: 3 Checksum: 0x24 ---------------- Block 1, Block Map Extension Block: Block 2: CTA-861 Extension Block Block 3: DisplayID Extension Block Checksum: 0x9e ---------------- Block 2, CTA-861 Extension Block: Revision: 3 Underscans IT Video Formats by default Basic audio support Supports YCbCr 4:4:4 Supports YCbCr 4:2:2 Native detailed modes: 1 Video Data Block: VIC 16: 1920x1080 60.000000 Hz 16:9 67.500 kHz 148.500000 MHz (native) VIC 97: 3840x2160 60.000000 Hz 16:9 135.000 kHz 594.000000 MHz VIC 96: 3840x2160 50.000000 Hz 16:9 112.500 kHz 594.000000 MHz VIC 31: 1920x1080 50.000000 Hz 16:9 56.250 kHz 148.500000 MHz VIC 4: 1280x720 60.000000 Hz 16:9 45.000 kHz 74.250000 MHz VIC 19: 1280x720 50.000000 Hz 16:9 37.500 kHz 74.250000 MHz VIC 18: 720x576 50.000000 Hz 16:9 31.250 kHz 27.000000 MHz VIC 3: 720x480 59.940060 Hz 16:9 31.469 kHz 27.000000 MHz VIC 90: 2560x1080 60.000000 Hz 64:27 66.000 kHz 198.000000 MHz Audio Data Block: Linear PCM: Max channels: 2 Supported sample rates (kHz): 48 44.1 32 Supported sample sizes (bits): 24 20 16 Speaker Allocation Data Block: FL/FR - Front Left/Right Video Capability Data Block: YCbCr quantization: No Data RGB quantization: Selectable (via AVI Q) PT scan behavior: No Data IT scan behavior: Supports both over- and underscan CE scan behavior: Supports both over- and underscan Colorimetry Data Block: BT2020YCC BT2020RGB Vendor-Specific Data Block (HDMI), OUI 00-0C-03: Source physical address: 1.0.0.0 Supports_AI DC_36bit DC_30bit DC_Y444 Maximum TMDS clock: 300 MHz Vendor-Specific Data Block (HDMI Forum), OUI C4-5D-D8: Version: 1 Maximum TMDS Character Rate: 600 MHz SCDC Present Supports 12-bits/component Deep Color 4:2:0 Pixel Encoding Supports 10-bits/component Deep Color 4:2:0 Pixel Encoding HDR Static Metadata Data Block: Electro optical transfer functions: Traditional gamma - SDR luminance range SMPTE ST2084 Supported static metadata descriptors: Static metadata type 1 Desired content max luminance: 139 (1015.241 cd/m^2) Desired content max frame-average luminance: 115 (603.666 cd/m^2) Desired content min luminance: 18 (0.051 cd/m^2) YCbCr 4:2:0 Capability Map Data Block: VIC 97: 3840x2160 60.000000 Hz 16:9 135.000 kHz 594.000000 MHz VIC 96: 3840x2160 50.000000 Hz 16:9 112.500 kHz 594.000000 MHz Vendor-Specific Video Data Block (HDR10+), OUI 90-84-8B: Application Version: 1 Detailed Timing Descriptors: DTD 2: 2560x1440 59.950550 Hz 16:9 88.787 kHz 241.500000 MHz (1193 mm x 336 mm) Hfront 48 Hsync 32 Hback 80 Hpol P Vfront 3 Vsync 5 Vback 33 Vpol N DTD 3: 2560x1080 60.000000 Hz 64:27 66.000 kHz 198.000000 MHz (1193 mm x 336 mm) Hfront 248 Hsync 44 Hback 148 Hpol P Vfront 4 Vsync 5 Vback 11 Vpol P Checksum: 0x71 ---------------- Block 3, DisplayID Extension Block: Version: 1.2 Extension Count: 0 Display Product Type: Extension Section Video Timing Modes Type 1 - Detailed Timings Data Block: DTD: 5120x1440 59.976879 Hz 0:0 88.826 kHz 469.000000 MHz (aspect undefined, no 3D stereo, preferred) Hfront 48 Hsync 32 Hback 80 Hpol P Vfront 3 Vsync 10 Vback 28 Vpol N DTD: 2560x1440 119.997589 Hz 0:0 182.996 kHz 497.750000 MHz (aspect undefined, no 3D stereo) Hfront 48 Hsync 32 Hback 80 Hpol P Vfront 3 Vsync 5 Vback 77 Vpol N Checksum: 0xd6 Checksum: 0x90 When i connect the display to orange pi and check the modes in /sys/class/drm/card0-DP-1/modes , i can only find the modes that match the Block 0 and none from the DisplayID block from edid. So the question is, is kernel configured to check the DisplayID block from edid? Is kernel compiled with CONFIG_DRM_LOAD_EDID_FIRMWARE ? P.S. - I think i might be hitting a problem that might be above Armbian and maybe kernel / rockchip (?) related. If so, do you know where can i seek for further help? Once Again, Thank You for your support and hard work
  9. Hi @Efe Çetin So i finally got uart working and captured dmesg output. Could you take a look and see if something might say why the display isn't recognized when in native mode? I am connecting the display using the usb-c to display port cable, and it's native resolution is 5120x1440 Once again Thank You Very much for your help and effort uart-dmesg.out EDIT 1. - After digging a bit around i found this post on the radxa foruns which might be useful: https://forum.radxa.com/t/ubuntu-image-with-x11-and-resolution-2560x1440/12553/8 As they state there, compiling the https://raw.githubusercontent.com/amazingfate/radxa-rock5b-overlays/main/rk3588-add-hdptxphy_hdmi_clk.dts dts file and installing it as an overlay might fix the issue. Would this be applicable to OPI5? EDIT 2 - I tried the above solution using armbian-add-overlay with no success. 234849 bytes read in 27 ms (8.3 MiB/s) reading /overlay-user/rk3588-add-hdptxphy_hdmi_clk.dtbo 621 bytes read in 2 ms (302.7 KiB/s) Applying user provided DT overlayfailed on fdt_overlay_apply(): FDT_ERR_NOTFOUND Error applying DT overlays, restoring original DT reading /dtb/rockchip/rk3588s-orangepi-5.dtb
  10. It's a prolific pl2303hxa. The wiring is GND - GND, TX (pl2303hxa) - RX (OPi5), RX (pl2303hxa) - TX (OPi5). I know this converter is a bit old, but it was the only one i had lying around. Might be the problem?
  11. So as far as i understand, the uart in the red box should work out of the box, correct? Even considering @Efe Çetin typo i still get some garbage on the serial console:
  12. Hi @Efe Çetin After some busy weeks i finally had some more time to play around with de OPI5. After some more tests i found out that display port over usb-c is working but unfortunatetly it is not outputting the 5120x1440 resolution. The Samsung G9 display has a PIP functionality which splits the screen in 2 halves. When in this mode, the Pi5 can drive half of the display, with a 4k resolution (i might need to confirm the exact resolution values), through the USB-C to DisplayPort cable. The problems arise when the display is configured in native mode... I tried using xrandr to configure a custom resolution but had no success... Is there any other way i can try this? Another question is, i have a usb to serial adapter. Is the UART enabled by default in armbian? This would be a great way to capture dmesg output when the OPI5 cannot drive the display in its native resolution. Also, was not OPI5 supposed to support 8k60hz in HDMI? Thank You for Your support
  13. @Efe Çetin, i am certainly not a kernel developer nor i have the skills to help in this kind of development, but can i help anyother way? Maybe gather some logs? Thank You
  14. @Efe Çetin just tried my new build with the 2006-OrangePi5-dubious-cdn-dp-core-stuff-extracted-from-X.patch and the results are the same as trunk 0154 and 0158. No luck... The monitor turns on for brief moments without any output and after, maybe 30 seconds, turns off again. Any other sugestions? Once again, thank you for your hard work.
  15. Hi @Efe Çetin, so i just need to enable "CONFIG_ROCKCHIP_CDN_DP=y" in linux-rockchip-rk3588-legacy.config in order to include the patch? Thanks
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines