• Content Count

  • Joined

  • Last visited

About whoman

  • Rank

Recent Profile Visitors

601 profile views
  1. 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.
  2. 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?
  3. 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.
  4. 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?
  5. 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?
  6. just ran it again after reboot and it comes back with disabled user1@renegade:~$ sudo cat /proc/device-tree/spi@ff190000/status disableduser1@renegade:~$
  7. 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
  8. Just to be clear, I believe device tree overlays are not working for me, and am wondering how I go about checking.
  9. 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
  10. 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
  11. Hello, I want to install openmediavault on my S905 based TV box, but for arm, the openmediavualt debian packages only support "Jessie". Does anyone know where I could find a S9xx images for Jessie The link to the images only shows the newest images "Stretch" https://yadi.sk/d/pHxaRAs-tZiei
  12. Hi dxs1, Unfortunately my kernel will do nothing different for audio output. the modules I have compiled are only for "midi sequencer" communication. They have nothing to do with audio output. Also, I could be mistaken but I'm pretty sure the amlogic drivers for sound output are already in the original kernel configuration, so that is likely not the cause of your issue. I'm personally using this strictly for video/image output, so I have no experience with audio output on the S905X. I would suggest creating a new thread, so that more people will see your thread title and can help with your problem.
  13. for "gst-aml-plugins1", compile did complete however "make install" placed the *.so and *.la files into /usr/local/lib/gstreamer1.0 So I had to manually copy the files to "/usr/lib/aarch64-linux-gnu/gstreamer-1.0/" now when I run gst-inspect, I get errors for the amlogic plugins: What is the problem with my compilation? Am I not linking something correctly?
  14. So I manually copied the three *.so files to /usr/lib and then ran "ldconfig", and everything finished compiling. I will report back once I have tried installing/testing the plugins
  15. So I found the correct version after some more searching "https://github.com/mdrjr/c2_aml_libs" and everything compiles except for the 'example' I'm guessing that since this is the example file I do not need it? so I commented it out of the Makefile, and finished with "make all" and "make install" however I still get this error when trying to compile GST plugins am I missing some basic step to enable /usr/bin/ld to find the libraries?