Jump to content

zeekoe

Members
  • Posts

    19
  • Joined

  • Last visited

Everything posted by zeekoe

  1. No dtb.back on debian it seems... Thanks for your help!
  2. Yay! For others with similar problems: downgraded kernel with armbian-config (System > Other) to 5.10.60 Restored device tree (which is probably only needed if you messed it up in the first place; armbian-config > System > Dtc) to spi@ff130000 { compatible = "rockchip,rk3288-spi\0rockchip,rk3066-spi"; clocks = <0x07 0x43 0x07 0x154>; clock-names = "spiclk\0apb_pclk"; dmas = <0x1f 0x0f 0x1f 0x10>; dma-names = "tx\0rx"; interrupts = <0x00 0x2e 0x04>; pinctrl-names = "default"; pinctrl-0 = <0x28 0x29 0x2a 0x2b 0x2c>; reg = <0x00 0xff130000 0x00 0x1000>; #address-cells = <0x01>; #size-cells = <0x00>; status = "okay"; max-freq = <0x2faf080>; phandle = <0x95>; spidev@0 { compatible = "rockchip,spi_tinker"; reg = <0x00 0x00>; spi-max-frequency = <0x2faf080>; spi-cpha = <0x01>; }; spidev@1 { compatible = "rockchip,spi_tinker"; reg = <0x01>; spi-max-frequency = <0x2faf080>; spi-cpha = <0x01>; }; }; Note that phandle is different. I know not much about device tree, but this seems to be a sequence number.
  3. Thanks for your reply. While thinking further, I can vaguely remember that this error/warning was not new. So it might as well not be related to my problem. I found this: That could be my real problem. Might be of help to others, too, that fail after upgrade. I think I messed up the device tree thingy, if I get it restored, will post here again...
  4. Hi Aligmsten, Thanks for pointing into the right direction. Is it possible that you elaborate a little bit more on how to specifically disable spidev@1? $ dmesg |grep spi [ 1.943067] rockchip-spi ff130000.spi: cs1 >= max 1 [ 1.943091] spi_master spi2: spi_device register error /spi@ff130000/spidev@1 [ 1.943133] spi_master spi2: Failed to create SPI device for /spi@ff130000/spidev@1 $ uname -a Linux <hostname> 5.15.48-rockchip #22.05.3 SMP PREEMPT Wed Jun 22 07:34:52 UTC 2022 armv7l GNU/Linux $ cat /boot/armbianEnv.txt verbosity=1 bootlogo=false overlay_prefix=rockchip overlays=spi2 spidev2 rootdev=UUID=<something> rootfstype=ext4 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u I tried using armbian-config > System > Dtc, commenting out the spidev@1 parts: spi@ff130000 { compatible = "rockchip,rk3288-spi\0rockchip,rk3066-spi"; clocks = <0x07 0x43 0x07 0x154>; clock-names = "spiclk\0apb_pclk"; dmas = <0x1a 0x0f 0x1a 0x10>; dma-names = "tx\0rx"; interrupts = <0x00 0x2e 0x04>; pinctrl-names = "default"; pinctrl-0 = <0x23 0x24 0x25 0x26 0x27>; reg = <0x00 0xff130000 0x00 0x1000>; #address-cells = <0x01>; #size-cells = <0x00>; status = "okay"; max-freq = <0x2faf080>; phandle = <0x92>; spidev@0 { compatible = "rockchip,spi_tinker"; reg = <0x00 0x00>; spi-max-frequency = <0x2faf080>; spi-cpha = <0x01>; }; #spidev@1 { # compatible = "rockchip,spi_tinker"; # reg = <0x01>; # spi-max-frequency = <0x2faf080>; # spi-cpha = <0x01>; #}; }; It told me the file was wrong. Then I deleted the spidev@1 part. Now I don't have the errors anymore, but no /dev/spi*. For the record: all worked perfectly before for months, with the same configuration. After a reboot (and probably an update) it stopped working. I never had spidev2.1 though, but it just skipped it silently and I worked happily with spidev2.0.
  5. For those who like to monitor temperature. Connect SDA & SCL to pins 3 and 5, connect 3.3V and GND. Connect all address wires of the DS1621 to ground. # sudo apt install i2c-tools # echo ds1621 0x48 >/sys/class/i2c-adapter/i2c-1/new_device# cat /sys/devices/platform/ff140000.i2c/i2c-1/1-0048/hwmon/hwmon0/temp1_input Optional, use lm-sensors: # sudo apt install lm-sensors # sensors Optional, temperature logging: Create a file logtemp.sh with the following contents: #!/bin/bash echo "`date +%Y-%m-%dT%R`;`cat /sys/devices/platform/ff140000.i2c/i2c-1/1-0048/hwmon/hwmon0/temp1_input`" >>/home/USER/temp Add an entry to /etc/crontab: 0 * * * * USER /home/USER/logtemp.sh And restart cron or your box for logging every hour. Thanks to https://www.electronicsfaq.com/2013/08/ds1621-with-raspberry-piarchlinuxarm.html Hope it's useful for someone!
  6. Recently, my sound stopped working, perhaps after an update. After some searching I found out that for me, the card order had been changed. flac -d file.flac -o - |aplay -D hw:1,2 confirmed me on that. So where you read hw:0,2 before in this thread it should become hw:1,2. That is, if your aplay -l output is like this: **** List of PLAYBACK Hardware Devices **** card 0: rockchiptinkerc [rockchip,tinker-codec], device 0: ff890000.i2s-i2s-hifi i2s-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: OnBoard [USB Audio OnBoard], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: OnBoard [USB Audio OnBoard], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: OnBoard [USB Audio OnBoard], device 2: USB Audio [USB Audio #2] Subdevices: 1/1 Subdevice #0: subdevice #0 Hope that helps for someone else.
  7. Thanks a lot for checking. I did some (hardware) measurements, all seemed well. Then tried just another time, having reconnected everything, and... it all seems to work now. :-? Really don't know why. Sorry for all the fuss... (Now on to wrestling with jackd to get input and output to work simultaneously, will report the settings back when I get it, won't be tonight...) edit: jackd settings found. Can't seem to set them like this in qjackctl, but can set them manually in .jackdrc: ~$ cat .jackdrc /usr/bin/jackd -v -dalsa -Chw:OnBoard,1 -Phw:OnBoard,2 -p2048 -n4 the -p and -n are trial-and-errored to prevent xruns The headphone jack input is on subdevice OnBoard,1 and the headphone jack output is on subdevice OnBoard,2 This is for ARMBIAN 5.60 stable Debian GNU/Linux 9 (stretch) 4.14.70-rockchip
  8. Downloaded what I think is the latest nightly with mainline: papier@tinkerboard:~$ uname -a Linux tinkerboard 4.19.12-rockchip #5.67.181227 SMP PREEMPT Thu Dec 27 02:25:07 CET 2018 armv7l GNU/Linux papier@tinkerboard:~$ arecord -l I think at first opening of audacity I saw an onboard D2, but I didn't see it ever after. Same results: D0 silence, D1 mild noise independent of the input. I did see spikes however when turning on/off the (70's/80's) stereo set nearby. Does it help if I upload a new armbianmonitor output?
  9. Thanks. That would mean a full install right, not like switching channels and apt upgrading? Maybe I can try later this week. If I can find a spare SD somewhere (really, I don't have that much of them laying around :))
  10. Sorry, clicked them away once and now I don't know what was there. http://teune.email/armbianmonitor.txt That's with mainline kernel BTW. Edit: I just tried switching, but the docs point me here where I just see two repos. I can see a linux-u-boot-tinkerboard-next package which may or may not do the trick, and armbian-config just seems to let me switch kernel versions, not mainline to next and vice versa. Could it help me trying to switch to next? If so, is there a place with slightly more documentation on how to do it?
  11. And another sound related question from me: does anyone have the input working? I have: * Silence on onboard D0 * mild noise on onboard D1 All unrelated to what I do on the input. If I don't ground the input (I connected a 6,5mm jack to it; one of my use cases is a guitar looper), I get 50Hz noise on my audio out. Capture 0 and Capture 1 volume on alsamixer don't seem to have effect on that. The fact that I need to ground the input, gives me the feeling that "something" is working. I also tried with a regular TRRS head set to check if my weird setup is the problem, same: silence on D0, mild noise on D1. Note that I checked D0 and D1 with audacity over ALSA over SSH. Audacity also had a "default" that did record something. Even with no microphone connected. Then I discovered it recorded the microphone of the laptop on which I run audacity. Still I think D0 and D1 *are* from the tinker board, because when running audacity on the laptop itself (not over SSH) all other inputs are completely different. Does anyone have sound in working? I think it worked before, the first time I checked it, with the TRRS head set. But I'm not sure. Maybe I was too rough on the TRRS connector of the tinker board? It looks very OK though. I'm puzzled.
  12. @Solskogen could you tell what you tried? Did you e.g. read my post of August 24 (click "Reveal contents").
  13. https://github.com/bitbank2/ArmbianIO/pull/14 Note that there's still a bug somewhere: after exactly 38 codes received, I get nothing through in the JAVA method. The poller is still running though; I get "Code timeout" messages every three seconds (from C) and "Tick" messages every second (from the JAVA main sleep thread). This translates generally to: after 38 times of executing the call back after creating it, it doesn't execute the callback anymore. I tried removing & re-adding the callback periodically, and in that case the callback is executed again. Does anyone know why this is? I don't think I changed anything to the C code that could've caused this. But my C isn't very wonderful.
  14. Great, thanks. I'll need to take a little time to polish it a bit and then I'll create the pull request
  15. Thanks for this wonderful lib! I attached a TSOP34838 to my Tinker Board, and am using ArmbianIO to decode the IR signals. At first in JAVA. This worked better than I thought. However to get the signal when it's done sending (and not ~87 ms later) I needed to change the C library. Apart from that, I think it's more stable under heavier load. My initial try is here: https://github.com/bitbank2/ArmbianIO/compare/master...zeekoe:master @Larry Bank Is this a direction you'd like to go with the library, or do you like to keep it more light-weight? If it is, I can clean up stuff a bit. An option would be putting the variable timeout mechanism inside the callback, and the decoding mechanism outside. Note that it currently supports at least one specific remote with 800/1600 microsecond codes and 90 ms wait time. I plan to extend it for another remote I have with 600/1200 microsecond codes. Both seem to be RC5 (-ish). edit: aha, I knew I read about manual IR decoding for NEC codes somewhere, just didn't remember it was here and written by you . Well, I took a slightly different approach, making use of the interrupt thingy and it seems to work reasonably reliable. Let me know what you think of it. But if you didn't go that way, perhaps I would need to move on to a hard-polling mechanism too, if I want perfect reception...
  16. Thanks. About the solution, isn't the main problem the missing manual configuration? (the load-module module-alsa-sink device=hw:0,2 sink_name=tinker_output part)? That's not there after a clean install.
  17. Woohoo! On 4.14.52-rockchip (mainline) I got it working immediately with this fix! A small tweak; instead of rebooting, killing pulseaudio worked for me. Note that on the "debian server" image pulseaudio isn't installed by default. pulseaudio -k mplayer <some song> Now let's go replacing my old bulky media server with my fancy new tinker board
  18. Well supported in mainline, that's what I like to hear, thanks. As for audio, does that also mean the 3.5mm jack? It surprises me reading the other thread about audio. I might take the plunge, this board deserves a broader user base.
  19. Hi all, For some time I've been following development. I think of buying a Tinker board. My wishes: - Being able to act as a web server (e.g. Apache/PHP) + do some scripting - Use the GPIO's (root mode no problem) - Decent audio out (no audiophile quality needed, but RPi is too bad for my purpose) - Long term software support that's as open as possible Especially the latest reason is where my doubts are. Of course no guarantees can be made, but what would be the odds of Armbian (or a fork) supporting this board in, say, 5 years? I don't really trust ASUS' OS for this. Spending some time to configure stuff (like the audio now, as I understand) is no problem for me. What do you guys think? Thx!
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines