Jump to content

Exie

  • Posts

    12
  • Joined

  • Last visited

Profile Information

  • Location
    Melbourne, Australia

Recent Profile Visitors

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

  1. Exie

    NanoPi M4 /w TFT

    hmmm this feels like a long time ago. If you mean the screen in the picture here, I chickened out and set it up on a Raspberry Pi 4 :( I guess at least I know its working. I still have a NanoPiM4 here somewhere. Happy to try again and see if I can it running in Armbian. At least I have a known-good working distro I can refer to even if it is Rasperian.
  2. Update: I modified the device tree file via... # dtc -@ -I dtb -O dts -o rk3399-nanopi4-rev01.dts /boot/dtb/rockchip/rk3399-nanopi4-rev01.dtb # vi rk3399-nanopi4-rev01.dts ... add spidev section to spi@ff1c0000 .. ... update spi@ff1c0000 to status "okay" # mv /boot/dtb/rockchip/rk3399-nanopi4-rev01.dtb /boot/dtb/rockchip/rk3399-nanopi4-rev01.dtb.backup # dtc -@ -I dts -O dtb -o /boot/dtb/rockchip/rk3399-nanopi4-rev01.dtb rk3399-nanopi4-rev01.dts .. but after booting dmesg shows: [ 2.518765] rockchip-pinctrl pinctrl: pin gpio3-7 already requested by ff1c0000.spi; cannot claim for fe300000.ethernet [ 2.518777] rockchip-pinctrl pinctrl: pin-103 (fe300000.ethernet) status -22 [ 2.518786] rockchip-pinctrl pinctrl: could not request pin 103 (gpio3-7) from group rgmii-pins on device rockchip-pinctrl So I checked my device tree and it looks like its configured like so: spi@ff1c0000 { compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi"; reg = <0x00000000 0xff1c0000 0x00000000 0x00001000>; clocks = <0x00000008 0x00000047 0x00000008 0x0000015b>; clock-names = "spiclk", "apb_pclk"; interrupts = <0x00000000 0x00000044 0x00000004 0x00000000>; pinctrl-names = "default"; pinctrl-0 = <0x0000004c 0x0000004d 0x0000004e 0x0000004f>; #address-cells = <0x00000001>; #size-cells = <0x00000000>; status = "okay"; phandle = <0x00000105>; spidev { compatible = "spidev"; status = "okay"; reg = <0x00000000>; spi-max-frequency = <0x00989680>; }; }; So...... it sounds like its complaining about pin-103 ? but I cant see any reference to that in the spi specification. So I'm not 100% sure where the conflict is. For reference, it DID create a new device (/dev/spidev32766.0) ... which is not really what I was expecting. Given the voodoo magic that seems to drive this device, is there any useful reference we can use to line up exactly what ff1c0000 and ff1d0000 should be ? Some posts suggest that spi@ff1c0000 is mapped to the eMMC slot or something.
  3. Just a follow up on SPI ..... I found updating the device tree (dtb file) like so: # fdtput /boot/dtb/rockchip/rk3399-nanopi4-rev01.dtb /spi@ff1d0000 status -t s "okay" # fdtput /boot/dtb/rockchip/rk3399-nanopi4-rev01.dtb /serial@ff370000 status -t s "disabled" I found disabling the serial thing made it all stable so the device didnt lock up. This enabled the device in the tree like so: spi@ff1d0000 { compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi"; reg = <0x00000000 0xff1d0000 0x00000000 0x00001000>; clocks = <0x00000008 0x00000048 0x00000008 0x0000015c>; clock-names = "spiclk", "apb_pclk"; interrupts = <0x00000000 0x00000035 0x00000004 0x00000000>; pinctrl-names = "default"; pinctrl-0 = <0x00000050 0x00000051 0x00000052 0x00000053>; #address-cells = <0x00000001>; #size-cells = <0x00000000>; status = "okay"; cs-gpios = <0x00000035 0x0000000a 0x00000001>; phandle = <0x00000106>; spidev@0 { compatible = "rockchip,spidev"; reg = <0x00000000>; spi-max-frequency = <0x00989680>; status = "okay"; phandle = <0x00000107>; }; }; I can see the device here: root@nanopim4:~# ls -l /dev/spidev1.0 crw------- 1 root root 153, 0 Feb 28 11:46 /dev/spidev1.0 However loading the fbtft driver still doesnt seem happy, reporting the controller is busy.... [ 45.573108] fbtft: module is from the staging directory, the quality is unknown, you have been warned. [ 45.592470] fbtft_device: module is from the staging directory, the quality is unknown, you have been warned. [ 45.594705] spidev spi1.0: spidev spi1.0 10000kHz 8 bits mode=0x00 [ 45.594949] spidev spi1.0: Deleting spi1.0 [ 45.595969] fbtft_device: GPIOS used by 'fb_st7789v': [ 45.595985] fbtft_device: 'reset' = GPIO32 [ 45.595994] fbtft_device: 'dc' = GPIO56 [ 45.596013] spi spi1.0: fb_st7789v spi1.0 32000kHz 8 bits mode=0x00 [ 45.608977] fb_st7789v: module is from the staging directory, the quality is unknown, you have been warned. [ 45.618367] rockchip-spi ff1d0000.spi: spi controller is in busy state! So I'm not 100% certain its working, but I feel like I'm getting closer.
  4. Exie

    Exie

  5. @s_frit No problem. I did as you said, just using the amixer commands above, rebooted and the audio came out crystal clear. Nice work! I'm still learning about device tree overlays and what their role is, I watched some youtube videos but I think they went way over my head, especially when they went into SPI datasheets!
  6. @s_frit Just a follow up, the image I was using was a bit vandalised there. So I've removed my hats and gone back to a bare bones NanoPiM4 and flashed a new image onto the SD card. I'm using Armbian_5.76_Nanopim4_Ubuntu_bionic_default_4.4.174.img Which is one I build in a Virtualbox VM. After starting I used SCP to drop WAV file on it and tested. No audio as expected. I ran the aforementioned amixer commands, test again, and it works! As mentioned, quality is poor. So I ran it again, and as you suggested: root@nanopim4:~# cat /sys/kernel/debug/clk/clk_i2sout_src/clk_parent clk_i2s0 I tried your command, but no change, I then tweaked it a bit as I think I understood the intent, so it looked like this: root@nanopim4:~# echo clk_i2s1 >> /sys/kernel/debug/clk/clk_i2sout_src/clk_parent Tested again, and you are correct, good clear audio out the 3.5mm socket. Thanks for the tip, and hope it helps others. I'm not really using mine for audio, but its good to know it's there if I need it. Hopefully @perlian gets nice audio too now.
  7. Just a follow up, I decided to tinker with this problem for a bit as I had a working configuration and a non-working one. Eventually, it now works in the Armbian image. I think the trick was to install Alsa and then configure a bunch of settings. I did a diff with the config on the other image and heres's the settings I had to set: amixer set 'HPO L' on amixer set 'HPO R' on amixer set 'HPOVOL L' on amixer set 'HPOVOL R' on amixer set 'HPO MIX HPVOL' on amixer set 'OUT MIXL DAC L1' on amixer set 'OUT MIXR DAC R1' on amixer set 'Stereo DAC MIXL DAC L1' on amixer set 'Stereo DAC MIXR DAC R1' on After setting those, the above test case works on 3.5mm AND HDMI out. I hope this helps. PS. It could just be my ears, but there appears to be a significant drop in quality from HDMI to Analog. There may be further settings to improve this that I have not explored.
  8. @perlian may be onto something. I just compared the FriendlyElec image to the Armbian one. FriendlyElec worked, Armbian doesnt. To test I used this for 3.5mm audio jack: aplay -D default:CARD=realtekrt5651co test.wav I used this for HDMI: aplay -D default:CARD=rockchiphdmi test.wav I'm not smart enough to know what the difference is sorry. Using `aplay --list-pcms` shows both devices on both images. At a guess, the FriendlyElec one must load/configure some extra module or something.
  9. @Nao - Do you have any more details on how you got to this point ? I have made an image using the Armbian repo: https://github.com/armbian/build/ I then use the Device Tools to inspect the tree: # fdtdump /boot/dtb/rockchip/rk3399-nanopi4-rev01.dtb > device_tree.txt This shows: ... aliases { spi1 = "/spi@ff1d0000"; }; ... spi@ff1c0000 { compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi"; reg = <0x00000000 0xff1c0000 0x00000000 0x00001000>; clocks = <0x00000008 0x00000047 0x00000008 0x0000015b>; clock-names = "spiclk", "apb_pclk"; interrupts = <0x00000000 0x00000044 0x00000004 0x00000000>; pinctrl-names = "default"; pinctrl-0 = <0x0000004c 0x0000004d 0x0000004e 0x0000004f>; #address-cells = <0x00000001>; #size-cells = <0x00000000>; status = "disabled"; phandle = <0x00000105>; }; spi@ff1d0000 { compatible = "rockchip,rk3399-spi", "rockchip,rk3066-spi"; reg = <0x00000000 0xff1d0000 0x00000000 0x00001000>; clocks = <0x00000008 0x00000048 0x00000008 0x0000015c>; clock-names = "spiclk", "apb_pclk"; interrupts = <0x00000000 0x00000035 0x00000004 0x00000000>; pinctrl-names = "default"; pinctrl-0 = <0x00000050 0x00000051 0x00000052 0x00000053>; #address-cells = <0x00000001>; #size-cells = <0x00000000>; status = "disabled"; cs-gpios = <0x00000035 0x0000000a 0x00000001>; phandle = <0x00000106>; spidev@0 { compatible = "rockchip,spidev"; reg = <0x00000000>; spi-max-frequency = <0x00989680>; status = "okay"; phandle = <0x00000107>; }; }; I noticed it says its disabled, but if I enable it with: # fdtput /boot/dtb/rockchip/rk3399-nanopi4-rev01.dtb spi1 status -t s "okay" Then the device wont boot. If you dont mind sharing some of the commands you used to get the debug output and enable the interface, that'd be great.
  10. Exie

    NanoPi M4 /w TFT

    I just want to add a big thankyou for @Igor Building the kerneral in a Virtualbox machine was WAY easier than I imagined. It took nearly an hour to build on my laptop, but that compile.sh script did everything! It's really nice how it ties everything together and gave me the choice of making a full image or just a kernel or whatever and the ability to customise the image with whatever kernel modules I wanted. It was really easy and I've got my NanoPi booting with everything I asked for now, its working like a gem! Obviously a heap of work went into all the scripting for that, so thanks to everyone who contributed to make it easy for noobs like me.
  11. I'm no expert, but if it helps, I believe its available via the kernel. See: https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt In terms of how its displayed when you login to the terminal, you may like to look for a bash script here: /etc/update-motd.d/30-armbian-sysinfo It includes a bash function which looks for tools like /usr/bin/temper or /usr/bin/armbianmonitor and chops up the text ouput from them. In practical terms, you can find it in: root@nanopct4:~# cat /sys/class/thermal/thermal_zone0/type soc-thermal root@nanopct4:~# cat /sys/class/thermal/thermal_zone0/temp 41111 On my device, zone0 seems to be the CPU temp, and zone1 seems to be the GPU temp. If you wanted to do it programmatically, I'm sure Python and Java and other languages will have libraries you could use to read such data via API's if thats your preference.
  12. Exie

    NanoPi M4 /w TFT

    Thanks Igor, I dont think that patch is going to work, it looks like that branch is a fair way ahead of the 4.4.174 image I started with. Building from scratch is a bit daunting, but I have Virtualbox already, so have kicked it off, I used the Ubuntu 18.04 mini image, pulled the repo and its running the compile now. It's not clear how I will bake a full image and write it back to an SD card yet, I presume I'll need `dd` or something, but I'll see how I go.
  13. Hi Folks, I have a NanoPiM4 and loaded Ambian 5.75 onto an SD card, it boots great (Thanks Armbian!). How I've added the FriendlyElec 2.8 TFT module (240x320) and want to configure it. So I used the handy `armbian-config` to pick up the kernel headers and sources, and went to go an add fbtft and select the ST7789V driver. Only when I went to run `make menuconfig` I got: root@nanopim4:/usr/src/linux-source-4.4.174-rk3399# make menuconfig scripts/kconfig/mconf Kconfig net/Kconfig:83: can't open file "net/wireguard/Kconfig" scripts/kconfig/Makefile:28: recipe for target 'menuconfig' failed I've updated the armbian monitor stuff here: http://ix.io/1B9n Can anyone give me some tips to resolve this ? At worst I'll manually edit the config file and try building.
×
×
  • Create New...