dimtass

Members
  • Content Count

    3
  • Joined

  • Last visited

  1. Hi @balbes150, sorry for late response, but I'm on long holidays and I'll be back in a couple of months. Currently my access to internet is limited. Anyway, I can't test the HDMI right now, but in yocto recipes there are two kind of images/distros. The one is console only and the other is with graphics support. Therefore, depending the image build you're triggering there are different things that are build in the background. That means that there might be some patches or a DT for u-boot/kernel that are different depending the image. Therefore, you need to find the proper build chain and add any extra configuration is needed. I can't be sure if that's the reason, though, as I've only tried console images my self (with Yocto). In the meantime, I will have access again to that hardware before the end of this year, but not any time soon.
  2. Thanks balbes150, nice one. I get Igor's concerns going the binary way. I've tested the Yocto meta-tegra layer a few weeks ago and I got a bootable image. @balbes150 This is the layer here: https://github.com/madisongh/meta-tegra This is the yocto recipe that makes the kernel: https://github.com/madisongh/meta-tegra/blob/master/recipes-kernel/linux/linux-tegra_4.9.bb This is the defconfig file for nano (tegra210): https://github.com/madisongh/meta-tegra/tree/master/recipes-kernel/linux/linux-tegra-4.9/tegra210 This is the recipe for u-boot: https://github.com/madisongh/meta-tegra/blob/master/recipes-bsp/u-boot/u-boot-tegra_2016.07.bb And that's the fw_env file: https://github.com/madisongh/meta-tegra/tree/master/recipes-bsp/u-boot/files/tegra210 This is where partitioning happens: https://github.com/madisongh/meta-tegra/blob/master/classes/image_types_tegra.bbclass I know that Yocto has this mixed bash/python scripting language, but I think it's quite straight forward to understand. Maybe you could use this as a guide to build the kernel and the bootloader.
  3. Hi all, I've come upon a weird thing and I wanted to verify that I don't so something wrong. I've build a custom kernel module which is a PWM led device with an SPI interface. If I use the spidev, then everything works fine and I'm able to control the led. But when I'm using a custom device-tree and load the module then when I'm calling the `spi_write()` function then I'm getting an error (-22). The external device is actually an arduino nano that implements an I2C IIO light measurement device, using a dual light dependent resistor. Also I'm using the SPI channel to drive a led using PWM. It's very straight-forward and everything seems to be working, except the SPI driver. You can find the sources here. Also the SBC I'm using is the nanopi-neo. I thought that I was doing something wrong, but I've also tried with one of the mainline standard drivers, like the leds-dac124s085 driver and I get the same error. The device tree I'm using is this one and my armbianEnv.txt content is this: ... overlay_prefix=sun8i-h3 overlays=usbhost1 usbhost2 i2c0 spi-add-cs1 spi-ardled ... Of course, I've added my `sun8i-h3-spi-ardled` in the /boot/dtb/overlay folder and u-boot loads it without errors. When the kernel boots, I can see the led device and when I'm trying to write the PWM value in the brightness, with this command: echo 10 > /sys/bus/spi/devices/spi0.0/leds/ardled-0/brightness Then the driver prints this in the dmesg [Jan 2 14:19] ardled: loading out-of-tree module taints kernel. [ +0.002445] Arduino PWM LED ardled-0 registered [Jan 2 14:20] ardled set: 10, ret: -22 [ +0.000015] bus_num: 0 bits_per_word: 16 chip_select: 0 mode: 0 max_speed_hz: 1000000 [ +0.000014] leds ardled-0: Setting an LED's brightness failed (-22) The same goes with also the default mainline `leds-dac124s085` driver which also uses SPI to drive 4 leds, instead of one. Also, I've probed the SPI mosi and clk and there's no any activity when the SPI is used in the modules. But, I can see the proper signals when I'm using the spidev. No need to say, that when I'm using spidev or the module I'm only loading the proper overlay in the armbianEnv.txt and not both of them. Does anyone knows why spidev works but any other SPI driver doesn't? Thanks. P.S. Also, I've found out that armbian-config installs an older version of the linux-kernel. The kernel version is: Linux nanopineo 4.14.91-sunxi But the kernel sources are older: /usr/src/linux-headers-4.14.84-sunxi Therefore, I had to cross-build the modules using the armbian sources on my workstation in `armbian/build/cache/sources/linux-mainline/linux-4.14.y`