• Posts

  • Joined

  • Last visited

Recent Profile Visitors

1068 profile views

p-i-u.de's Achievements

  1. I don't mess something up, the DTBO which is provided in this post brings up spidev0.1, I just try to help @martinayotte to get the cs-gpio kernel patch to work to help testing the patch with real hardware, that's all. With this you can have a SPI Bus and multiple GPIOs as chipselect so in other words use more than SPI Device on a single bus. As SPI Devices are common in the industrial field this would enhance the rockchip a lot.
  2. Also on my end using real hardware, there is no output. Let me know if I can help further. How did you compute the numbers 3 16 to match GPIO3_C0? This is something I didn't figure out yet, is there any document?
  3. I can do the test for you, as I've already set up everything, so just need the CS Pin number
  4. I used your original dtbo and cabled my device to GPIO1_B0 = MOSI, GPIO1_A7= MISO, GPIO1_B1 = CLK, GPIO1_B2 = CS unfortunately it does not work. the dtbo as you already mentioned brings up spidev under spidev0.1. One question from what source do you got your information about how to set up you dts file? I've read the Device Tree Documentation and also looked at the patch however from that information I do not know what parameters to set in the dts, I would like to help out on this topic so that's why I'm asking
  5. AFAIK, as that used for the internal SPI Flash ( I got a Rev 1.4 Board), however I can test tomorrow if it works with the default values
  6. I have built the custom kernel with this patch being applied, changed the target path to target-path = "/spi@ff1e0000"; as SPI1 is not usable on rock pi 4, compiled with dtc and moved it to /boot/dtb/rockchip/overlay/rockchip-spidev2-1.dtbo having this in /boot/armbianEnv.txt overlays=spidev2-1 Now when I reboot I get /dev/spidev0.1 So, what wonders me is, a) why does it come up as spidev0 and b) how do I know which gpio pin is used for CS? Otherwise I'm ready to test What do I miss?
  7. actually I meant to get the patch in the upstream kernel sources. I've currently setting up my build environment and will start a build. Will need a few days until I'm done with testing, as I can just use certain timeslice each day to not interfere with my other projects.
  8. I have a device to check,. Hmmmh should we do some advocacy work to get the patch into the mainline Kernel? As from the post to me it seems that has simply just forgotten
  9. to what I understood it seems to be possible https://patchwork.kernel.org/patch/9780471/ if you can tell me what work is to do maybe I can help
  10. Mainly, because I wasn't aware of them plus second I also want to access the gpio without being root and I develop in Java so need some native JNI library. Leaving just User Space IO where I'll have a look at. Actually the MRAA Library developed by Intel first exists since 2015 so it was there before the alternatives, the question should have been why did the others re-invent the wheel :-)
  11. I also plan to add Tinkerboard Support as I got this board, too. However I know what you mean by time constraints which is also a very limiting factor for me. What would you think are the most important boards to add? OrangePi, Odroid?
  12. What do you mean by R&D? Resources and Development? Note: the Github Repo is mine, which means I have done the modifications. Only problem though I'm not a C Coder and could need some help by an experienced C developer here and there
  13. As WiringPi was never meant to support other boards nor does the author like to support other boards and it is officially depreciated now (http://wiringpi.com/wiringpi-deprecated/). I want to ask why not put some efforts into libmraa https://github.com/intel-iot-devkit/mraa and put it into the Armbian repository. I have already a fork which fixes Rock Pi 4 on recent mainline 5.3 kernels with updated debian build scripts here: https://github.com/bootsy52/mraa, so debian packages could be simple built using dpgk-buildpackage. Why I think it is a good idea to supply libmraa with the Armbian repository Supporting multiple boards is a desired goal of the project Supporting a board is really easy, for Rock Pi for example this is just the files src/arm/rockpi4.c include/arm/rockpi4.h and an entry in src/arm/arm.c, that's it Instead of multiple forks of wiringPi and different sources of different versions (or even different gpio implementations) just have one common implementation for all boards with wiringPi you need additional bridges if you want to code in other languages like Java or Python for example, with MRAA you have out of the box bindings for Python, Java, Javascript, C/C++ and NodeJS support What do you think? @Igor
  14. I can confirm latest 5.3.11 buster server Image working fine on RockPI 4A with EMMC. Further more I used CP2102 successfully to connect via putty on serial console of RockPI at 1500000 https://www.amazon.de/Anpro-CP2102-Konverter-Stecker-eingebautem/dp/B0757FQ5CX
  15. Thanx for the tip, I've used what Linus Torvalds used in his spidev_test.c program so I thought that is the correct way (I'm not a C Coder)