whoman

Members
  • Content Count

    25
  • Joined

  • Last visited

About whoman

  • Rank
    Member

Recent Profile Visitors

646 profile views
  1. Hello Everyone! I cannot get Gstreamer to use video acceleration on my ROC-RK3328-CC (Libre Renegade) rockchip-gstreamer from Rockchip's github page just wont let me compile the vpudec plugin I have tried both stretch and buster with 4.4 legacy kernel (currently on buster), but I seem to be missing one peice. Here's what I do: -Install a current Armbian Renegade Legacy image, and install all the tools necessary to compile everything. -Git Clone and compile: Gstreamer, plugins-base, plugins-good, plugins-bad, plugins-ugly, plugins-libav -Git Clone and compile: libmali, mpp, rockchip-gstreamer, rockchip-gstreamer-extra during mpp compilation, I get the following warning: [ 71%] Building CXX object mpp/legacy/CMakeFiles/rockchip_vpu_static.dir/vpu_api_legacy.cpp.o /home/onev/video/mpp/mpp/legacy/vpu.c: In function ‘VPUClientInit’: /home/onev/video/mpp/mpp/legacy/vpu.c:104:14: warning: this statement may fall through [-Wimplicit-fallthrough=] type = VPU_DEC; ~~~~~^~~~~~~~~ /home/onev/video/mpp/mpp/legacy/vpu.c:105:5: note: here case VPU_DEC: ^~~~ [ 71%] Building C object mpp/legacy/CMakeFiles/rockchip_vpu_static.dir/vpu_mem_legacy.c.o When I run './autogen.sh' for rockchip-gstreamer it says that vpudec will not be compiled due to unmet dependencies. configure: *** Plug-ins with dependencies that will be built: rockchipmpp configure: *** Plug-ins with dependencies that will NOT be built: rkximage vpudec So I look at the configure.ac file, and I see it only has one dependency, and that is rockchip_vpu version 0.3.0 - [rockchip_vpu < 0.3.0] So I check my /dev folder and both vpu_service and rkvdec devices are present. lsmod shows neither modules are loaded, so I first do rkvdec: sudo modprobe rkvdec and that works, as lsmod now shows the rk_vcodec module is loaded. next I do the vpu_service module: sudo modprobe rockchip_vpu and that returns to prompt with no error message, but the module is still not listed by lsmod (nothing for vpu) So just for the heck of it, I edit the configure.ac to allow vpudec to compile without checking the dependency, and of coarse there's a bunch of errors. This suggests that I'm missing something, possibly a library I'm overlooking? Or perhaps its that the Rockchip Ayufun branch (which is the branch armbian installs) of the official rockchip branch of the kernel, doesn't have the latest updates from the rockchip branch? Does anyone have any ideas about what I'm missing here? Any hints would be sincerely appreciated
  2. It turns out that it's been renamed to 'hantro-vpu' starting with 5.3. I got the kernel module compiled but now I realize there's a bunch of patches that update everything for this name changed that were not applied while using the armbian build tool. I'll open up a new thread regarding that since it's a different issue.
  3. So after looking through the device tree, I see that it's called 'video-codec' however modprobe cant find the module... I only see it in these locations: /sys/devices/platform/ff350000.video-codec /sys/bus/platform/devices/ff350000.video-codec /sys/firmware/devicetree/base/video-codec@ff350000 it doesn't appear that I have the kernel module. Any ideas where I can find the source code for the 'video-codec' kernel module?
  4. Hello Everyone! What is the kernel config option that I need to set to enable the VPU driver? Background: I'm using the most current RK3328 RENEGADE armbian image (debian non-desktop) on my ROC-RK3328-CC (Libre Renegade). I've compiled a brand new kernel with the armbian build tool. first, I cloned and compiled gstreamer and it's plugins from Github. Everything works fine but no video acceleration... So then I clone, compile, and install libmali, mpp, gstreamer-rockchip and gstreamer-rockchip-extra, and although the new pluggins are now available to gstreamer (specifically mppvideodec), whenever I try to use mppvideodec, I recieve the following error: mpi: mpp version: 14cae9c4 author: Johnson Ding [mpp_platform]: fix wrong device getting problem mpp_rt: NOT found ion allocator mpp_rt: found drm allocator hal_h264d_api: Assertion vcodec_type & ((1 << VPU_CLIENT_RKVDEC) | (1 << VPU_CLIENT_VDPU1) | (1 << VPU_CLIENT_VDPU2)) failed at hal_h264d_init:104 hal_h264d_api: hal_h264d_init hard mode error, value=0 hal_h264d_api: Assertion 0 failed at hal_h264d_init:154 mpp_device: mpp_device_init failed to find device for coding 7 type 0 Caught SIGSEGV After searching for a while, I came across this bug report in Chinese which suggests that I don't have the RK3328 VPU driver installed: https://translate.googleusercontent.com/translate_c?depth=1&hl=en&pto=nl&rurl=translate.google.com&sl=zh-CN&sp=nmt4&tl=en&u=https://github.com/rockchip-linux/mpp/issues/52&usg=ALkJrhiZFAGMkTKx7lz28OCXBQAmjeA8mw I checked the kernel config (I'm using the armbian build tool to compile the newest kernel), and I do see "V4L platform devices" however this doesn't seem to be anything rockchip specific. Since the default Armbian desktop versions seem to have video accel already enabled, I am hoping someone might be able to give me a hint as to what process I should follow in order to properly build the correct vpu-codec kernel driver for the RK3328 I see that in the RK3328 Media Script (Rock64, Renegade) post by JMMC, he has a precompiled DEB package for librockchip-vpu0... Is this what I'm missing here? If so, can anyone point me to the source so I could build my own? So 2 questions: 1. Is there a kenrel option I should be setting in order to compile the VPU driver? 1. if not, which VPU driver code should I be compiling for mpp to work? Thanks so much for your time in reading this.
  5. I have got this working now... I could only find 2 GPIO pins on the ROC-RK3328-CC that were usable: Labeled "GPIO" - Pin 32 - GPIO0_A0 - Accesible as GPIO 0 Labeled "CLK0" - Pin 22 - GPIO0_A2 - Accesible as GPIO 2 Looking at this table, you can see that BCM 24 and 25 are routed to GPIO 102 and 103 on the ROCK64. https://github.com/Leapo/Rock64-R64.GPIO/wiki/GPIO-Modes So I replaced 102 and 103 with 0 and 2, on the line begining with "BCM_to_ROCK =" I then added 0 and 2 to the line beginning with "ROCK_valid_channels", so that it would pass the sanity checks in the code Now the SPI LED screen is working perfectly. Thank you so much martinayotte! Your help and insight not only helped me get this working, but also helped me learn about device tree overlays and the hardware addressing in the device tree. And because of this new knowledge, I was able to create my own UART1 overlay, and it's working perfectly.
  6. I found this pin mapping table which refers to the Rock64, however looking at the GPIO pin numbers, it looks like it very likely is the same board pin numbers for the ROC-RK3328-CC. https://github.com/Leapo/Rock64-R64.GPIO/wiki/GPIO-Modes I will try it out tomorrow afternoon and report back with the results. Thanks everyone.
  7. Wow thank you so much for your insight! I changed RK3399 to RK3328 I changed ff1c0000 to ff190000 I removed all fragments relating to SPI1/2/3 /dts-v1/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/aliases"; __overlay__ { spi0 = "/spi@ff190000"; }; }; fragment@1 { target = < 0xffffffff >; __overlay__ { #address-cells = < 0x01 >; #size-cells = < 0x00 >; spidev { compatible = "spidev"; status = "disabled"; reg = < 0x00 >; spi-max-frequency = < 0x989680 >; }; }; }; __fixups__ { spi0 = "/fragment@1:target:0"; }; }; And now the device tree appears to be read and applied(?), however I'm getting this error regarding the fixup.scr: Applying kernel provided DT overlay rockchip-spi-spidev.dtbo 2698 bytes read in 21 ms (125 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND Edit: Taking a look at the fixup.scr, it appears the values for SPI0 are hardcoded to ff1c0000. Made the changes, and I tried creating the file using this command: mkimage -A arm -T script -C none -d rockchip-fixup.script rockchip-fixup.scr Image Name: Created: Sat Feb 15 23:09:39 2020 Image Type: ARM Linux Script (uncompressed) Data Size: 2478 Bytes = 2.42 KiB = 0.00 MiB Load Address: 00000000 Entry Point: 00000000 Contents: Image 0: 2470 Bytes = 2.41 KiB = 0.00 MiB and SUCCESS!! $ sudo cat /proc/device-tree/spi@ff190000/status okay Thank you sooooo much for your help with this! I sincerely appreciate you. Now that SPIDEV is enabled on SPI0, I need to determine how to specify the SPI pins for "Reset" and "DataCommand" to Luma.OLED. By default it expects them on BCM 24 and BCM 25, and Luma.OLED allows you to specify which pins to use with the command line argument: you can select other pins and pass a bcm_DC and/or a bcm_RST argument specifying the new BCM pin numbers So I have no idea what the BCM equivilants would be for SPI0 on the RK3328. The only references I have with pin specifications for the libre renegade board are these two: https://roc-rk3328-cc.readthedocs.io/en/latest/_images/hw_expansion_interface.png and this one: I'm using Rock64.GPIO which contains the following Arrays, however I can't figure out how to decypher which BCM pin numbers would translate to the SPI0 RST and DC pins on my ROC-RK3328-CC. # Define GPIO arrays ROCK_valid_channels = [27, 32, 33, 34, 35, 36, 37, 38, 60, 64, 65, 67, 68, 69, 76, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 96, 97, 98, 100, 101, 102, 103, 104] BOARD_to_ROCK = [0, 0, 0, 89, 0, 88, 0, 60, 64, 0, 65, 0, 67, 0, 0, 100, 101, 0, 102, 97, 0, 98, 103, 96, 104, 0, 76, 68, 69, 0, 0, 0, 38, 32, 0, 33, 37, 34, 36, 0, 35, 0, 0, 81, 82, 87, 83, 0, 0, 80, 79, 85, 84, 27, 86, 0, 0, 0, 0, 0, 0, 89, 88] BCM_to_ROCK = [68, 69, 89, 88, 81, 87, 83, 76, 104, 98, 97, 96, 38, 32, 64, 65, 37, 80, 67, 33, 36, 35, 100, 101, 102, 103, 34, 82] Any ideas?
  8. The overlay files are definitely there... /boot/dtb/rockchip/overlay$ ls -l total 36 -rw-r--r-- 1 root root 2455 Jan 4 15:31 README.rockchip-overlays -rw-r--r-- 1 root root 2698 Jan 4 15:31 rockchip-fixup.scr -rw-r--r-- 1 root root 218 Jan 4 15:31 rockchip-i2c7.dtbo -rw-r--r-- 1 root root 218 Jan 4 15:31 rockchip-i2c8.dtbo -rw-r--r-- 1 root root 267 Jan 4 15:31 rockchip-pcie-gen2.dtbo -rw-r--r-- 1 root root 1314 Jan 4 15:31 rockchip-spi-jedec-nor.dtbo -rw-r--r-- 1 root root 1266 Jan 4 15:31 rockchip-spi-spidev.dtbo -rw-r--r-- 1 root root 384 Jan 4 15:31 rockchip-uart4.dtbo -rw-r--r-- 1 root root 491 Jan 4 15:31 rockchip-w1-gpio.dtbo Could it be that the current libre renegade armbian image doesn't have a current (up to date) fixup.scr? Thank you again for your time, I really appreciate it.
  9. So I decided to add uart4 overlay as well (after SPI, I'll be trying to enable UART): verbosity=1 overlay_prefix=rockchip rootdev=UUID=69320d26-57b1-49ed-b3d0-c1402e101ae0 rootfstype=ext4 overlays=spi-spidev uart4 param_spidev_spi_bus=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u and now somehow both are showing up in the debugger however both error out.... Applying kernel provided DT overlay rockchip-spi-spidev.dtbo fdt_overlay_apply(): FDT_ERR_NOTFOUND 384 bytes read in 24 ms (15.6 KiB/s) Applying kernel provided DT overlay rockchip-uart4.dtbo fdt_overlay_apply(): FDT_ERR_BADMAGIC Error applying DT overlays, restoring original DT I then tried placing uart4 before spidev-spi, and the error messages switched, which suggests its not the files themselves... perhaps its the fixup.scr? Applying kernel provided DT overlay rockchip-uart4.dtbo fdt_overlay_apply(): FDT_ERR_NOTFOUND 1266 bytes read in 24 ms (50.8 KiB/s) Applying kernel provided DT overlay rockchip-spi-spidev.dtbo fdt_overlay_apply(): FDT_ERR_BADMAGIC Error applying DT overlays, restoring original DT would it be beneficial to post the contents of the rockchip-fixup.scr?
  10. So I had a spare arduino nano and looked up how to use that as a USB TTL debugger... here's the output (I don't see anything noting the spidev overlay) U-Boot 2017.09-armbian (Jan 07 2020 - 22:21:19 +0100) Model: Firefly ROC-RK3328-CC DRAM: 1022 MiB MMC: rksdmmc@ff520000: 0, rksdmmc@ff500000: 1 Card did not respond to voltage select! mmc_init: -95, time 10 *** Warning - No block device, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Firefly ROC-RK3328-CC misc_init_r boot mode 0. Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2940 bytes read in 14 ms (205.1 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 0 103 bytes read in 11 ms (8.8 KiB/s) 7108882 bytes read in 197 ms (34.4 MiB/s) 20722176 bytes read in 531 ms (37.2 MiB/s) 48336 bytes read in 21 ms (2.2 MiB/s) 2698 bytes read in 21 ms (125 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 ## Loading init Ramdisk from Legacy Image at 04000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 7108818 Bytes = 6.8 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to 3d84c000, end 3df138d2 ... OK reserving fdt memory region: addr=1f00000 size=72000 Loading Device Tree to 000000003d7d7000, end 000000003d84bfff ... OK Starting kernel ... Same result on status... user1@renegade:~$ sudo cat /proc/device-tree/spi@ff190000/status disableduser1@renegade:~$ does this mean the dtbo isn't being loaded? my full /boot/armbienEnv.txt: verbosity=1 overlay_prefix=rockchip rootdev=UUID=69320d26-57b1-49ed-b3d0-c1402e101ae0 rootfstype=ext4 overlays=spi-spidev param_spidev_spi_bus=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u what could I be missing here?
  11. just ran it again after reboot and it comes back with disabled user1@renegade:~$ sudo cat /proc/device-tree/spi@ff190000/status disableduser1@renegade:~$
  12. Thank you for the info... I'll see about ordering a USB TTY debugger when I run that command, there's no output. It just goes straight back to the prompt. I verified that the directory and file do exist: ls -l /proc/device-tree/spi@ff190000/ total 0 -r--r--r-- 1 root root 4 Feb 13 20:19 '#address-cells' -r--r--r-- 1 root root 16 Feb 13 20:19 clock-names -r--r--r-- 1 root root 16 Feb 13 20:19 clocks -r--r--r-- 1 root root 40 Feb 13 20:19 compatible -r--r--r-- 1 root root 6 Feb 13 20:19 dma-names -r--r--r-- 1 root root 16 Feb 13 20:19 dmas -r--r--r-- 1 root root 12 Feb 13 20:19 interrupts -r--r--r-- 1 root root 4 Feb 13 20:19 name -r--r--r-- 1 root root 4 Feb 13 20:19 phandle -r--r--r-- 1 root root 16 Feb 13 20:19 pinctrl-0 -r--r--r-- 1 root root 8 Feb 13 20:19 pinctrl-names -r--r--r-- 1 root root 16 Feb 13 20:19 reg -r--r--r-- 1 root root 4 Feb 13 20:19 '#size-cells' -r--r--r-- 1 root root 9 Feb 13 20:17 status
  13. Just to be clear, I believe device tree overlays are not working for me, and am wondering how I go about checking.
  14. Thank you for moving to the correct place. Is serial output the only way to get the u-boot debug info? Would I need to use a USB TTY device to view this? I assumed the u-boot info was written to some log file. Is that incorrect? What I'm looking for is something that would tell me if the fixup.scr was being executed properly, and any other dt overlay information. At this point I just want to make sure the device tree overlays are actually working Although this is for a different board, this is what I'm talking about (just did a cut and paste from an unrelated thread): Thanks again for your time
  15. Hello everyone! I'm trying to use a small SPI LED screen with my ROC-RK3328-CC. I've scoured all over this website as well as the internet for information on enabling SPI on my ROC-RK3328-CC (libre renegade), and I'm sorry to say after trying so many things, I still cannot get it enabled. I'm currently using this image: Armbian_19.11.7_Renegade_buster_current_5.4.8.img I've added the following 2 lines to /boot/armbienEnv.txt overlays=spi-spidev param_spidev_spi_bus=0 and after reboot, nothing. nothing for dmesg|grep spi and no spidev devices in /dev I've also tried manually changing status to "okay" for fragment@1 and fragment@2 within the dtbo, but still nothing. Did I miss a step in the process of enabling this device tree overlay? I read through the armbiean device tree overlay documentation online and in my overlay folder, but can't seem to figure out what else I might need to do to enable SPI one thing I'm not sure about his how to get detailed u-boot logging like I see so many people post on this forum. is there a file which this gets logged to? Is there a flag I need to set somewhere to enable u-boot logging to a file? Any advice would be much appreciated. Thanks for your time