I have connected an MCP2515 to the Raspberry Compute-Module and now it would be nice if I could make it work.
We use a distribution based on buildroot - but unfortunately we can't manage to load the devicetree-overlay for the MCP2515.
We activated device-tree in the linux-menuconfig plus we created overlay folder in /boot plus we activated dtoverlay in /boot/config.txt
What else should we take care of, to make CAN work on our system?
Thank you.
Related
I have build a linux image with yocto that has xfce as desktop environment,
But what i actually need is just a terminal and a browser.
Is it possible to remove the desktop environment and just create an application that has two options to open 'terminal' and 'browser' and make my image boots on it directly.
If this is possible would it reduce the image size or not, beacause i am looking for a minimum sie of the image.
If you want to remove your desktop env then add below line in your disto.bb or local.conf
DISTRO_FEATURES_remove += "x11 wayland"
I dont think without desktop env you cant run browser.
are you using imx6 and vivante graphics ?
We are using touchscreen with touch driver (ft5x06). Now to calibrate and test the touch device i downloaded tslib from github and installed to separate folder by following commands:
cd ~/tslib
./autogen.sh
./configure --prefix=/home/user2/Desktop/tslib_arm
make
sudo make install
now on my embedded board's Desktop has got a folder tslib_arm which consists of compiled code for tslib (like bin, etc,lib etc..)
when i run ts_calibrate(./ts_calibrate) from /home/user2/Desktop/tslib_arm/bin then the calibration screen is coming and calibrating. and if i run ./ts_test , it gives options like drag and draw, which are also working fine.
But after closing these apps (ts_calibrate or ts_test) and if we check the touch on the Desktop or any application or normal operation touch seems to be uncalibrated only.
Why is it so???
Do i need to copy this tslib_arm or any other files from tslib_arm folder to system's rootfs location????
That's because your "Desktop or any application" most probably doesn't directly implement and use the API that tslib offers (to read touch input samples).
tslib includes documentation on how to use the filtered input in your environment.
What should always work, is using the "ts_uinput" daemon program that comes with tslib (just like "ts_calibrate" does). It's a driver for tslib that creates a (second) touchscreen input event device for you in /dev/input/. All you need to do is tell your "Desktop or application" to use it. All desktop environments have options to choose which input device you want to use.
I like to disable and enable some pins in my RPi project.
These are GPIO 6, GPIO 5 and GPIO 26. I like to use these PINs in my own kernel driver.
For this project I connect a simple electric board via the GPIOs. The minimal system is build via yocto. I like to change the device tree file to disable/enable GPIOs.
I need to change or make my own dts file. For that I think I will need to:
find the original RPi dts
patch it or create my own dts
add it to the layer.conf
add file to the kernel recipe via append
How can I do this? or where can I find the sources?
Actually I am struggling to find the dts files for the RPi2 I am using. I was checking the "raspberrypi2-poky-linux-gnueabi" recipe results(and do not find any files).
I do not find any tutorial how to setup yocto + meta-raspberrypi + own dts. it would be great if we can figure out the necessary steps.
I'm not convinced this question has been well answered, so let me take a few minutes and document what I've done to add device tree overlays to my yocto builds.
This is a multi-problem process.
I'm going to make a few assumptions:
* You source your oe-init-build-env in a shell, and do your bitbake builds manually in a terminal (or you know how to do it with equivalent tooling)
* You know (or are already learning) the basics of device trees...
Start with your own meta layer. Mine is out on github.
You'll need to create an *-overlay.dts source file. You can start with a simple place holder, and stuff it (quite literally) anywhere on your system. We'll import it to your meta layer in the next step using bitbake to do some of the staging and what-not for us.
recipetool appendsrcfile -wm rpi /path/to/your-layer-meta virtual/kernel /path/to/your-overlay.dts 'arch/${ARCH}/boot/dts/overlays/your-overlay.dts
At this point, you should end up with a recipes-kernel/linux directory with an appropriate bbappend targeting the $MACHINE type of -wm (rpi, as above), ready to copy the device tree source file into the proper spot for bitbake to find it when it building the kernel. But it still won't be included in your kernel build.
We need to add the overlay reference to the KERNEL_DEVICETREE variable, in places that will cover the scopes of: linux, bootfiles, and the sdcard_image-rpi.bbclass from meta-raspberrypi.
In the linux bbappend created in step 3, add KERNEL_DEVICETREE += "overlays/your-overlay.dtbo" to make the linux kernel build include your dts as something to compile into a dtbo.
To make the sdcard_image-rpi.bbclass copy the file, you'll need to add KERNEL_DEVICETREE =+ "overlays/your-overlay.dtbo" to your image recipe.
To make the overlay active, you'll need to create a recipes-bsp/bootfiles/rpi-config_git.bbappend whereyou can append a do_deploy step to add the dtoverlay=your line to config.txt.
I use my layer for more than one project, so I felt OK with having the dts compile with every kernel but only copy it to images where my image recipe added it to the KERNEL_DEVICETREE. For further insurance that I don't get these things interferring in images I don't want them in, my rpi-config append has a test to see if I should add the dtoverlay line to the config.txt
Of course, this was all assuming you were going to use your own home-grown DTS without starting from a kernel-sourced one. The process would be largely the same, but you'd be able to patch the existing, or copy it, or whatever you want to do in your linux recipe.
I hope this helps! I know it's an old question.
First you need to find the kernel used on your yocto project, the recipe is linux-raspberry.bb or something like linux-*.bb. The preferred kernel is probably set in your local.conf or machine.conf: PREFERRED_PROVIDER_virtual/kernel ?= "linux-raspberry"
This is indirectly set via "meta-raspberrypi/conf/machine/include/rpi-default-providers.inc" which is included via "rpi-base.inc"
Once found, take a look at the recipe, clone the git repository of the kernel, on the right branch, and reset at the right SRCREV.
Once downloaded, the dts files are in /path/of/my/kernel/linux-raspberry/arch/arm/boot/dts/. You can find the name of the devicetree file used in the kernel recipe, local.conf or machine.conf, with the variable KERNEL_DEVICETREE = "..."
For the meta-raspberry and rpi2 selected, the dts files can be found in <path to build dir>/linux-raspberrypi2-standard-build/source/arch/arm/boot/dts/. The source dir is a linked dir to the git sources.
You can add a new dtb by creating dtsi/dts files (don't forget to add it in the Makefile).
Create a patch, add it to the kernel recipe:
SRC_URI += "file://0001-mypatch.patch"
and put the patch file like this in your meta
├── files
│ └── 0001-mypatch.patch
└── linux-raspberry.bb
Modify the KERNEL_DEVICETREE variable to add your new dtb.
Now you can bitbake your kernel/image, your new dtb will be created.
I'm trying to make transmission download on an external drive using a RaspberryPi with Raspbian installed on a sd card.
I followed various tutorials and finally I managed to set all the permissions in order to get transmission doing the job.
However, despite I set the complete and incomplete downloads directories in transmission-daemon/settings.json, the transmission web gui seems to have his own settings.
I did change it in the settings section of the web gui but I'd like to "bind" the default directories of the daemon and the web gui.
How should I proceed?
Note that in the web gui you can only set the final folder, not the "incomplete downloads" one so I'm afraid the sd card will fill up very quickly.
Thanks a lot.
Stop Transmission first. Change the settings.json file. Start Transmission.
I used Yocto to build a filesystem, using a .bbappend of core-image-minimal. Two questions:
how can i figure out which package is taking huge storage space on the rootfs?
I can't think of a way other than to look into the ${D} of every package and see how big its components are. There's gotta be a more systematic, and intelligent way to do that.
From what i can decipher from the manifest, there is nothing related to the size of the package that is being included.
Also, removing some of the packages I added using the IMAGE_INSTALL object, seems to remove the package but the end result of the built image doesn't show a change in its size!!
I compared the size of a particular .so on the build machine and on the installation device (a vm) and found that the size on the installation device was 20-30% of the original size seen on the build machine. Any explanation?
Thanks!
1) One way is to enable buildhistory, by adding the following to local.con
INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "1"
This will create a directory (git repo) buildhistory in your $BUILDDIR. There you'll be able to find e.g.
images/$MACHINE/eglibc/$IMAGE/installed-package-sizes.txt
That file will give you the sizes of all installed packages.
There are a lot more things you can learn from buildhistory, see buildhistory introduction
2) Where did you compare the particular .so-file? If it was from the package's ${B} (i.e. where the library is built), it's not surprising, as the installed .so-file will be stripped. The debug information is installed into -deb.rpm (as the debug info is usually useless on the target and the smaller size is of much higher importance).
With some looking inside the scripts/ subdir and some googling about some of the existing scripts, it turns out that the good people of Yocto do have these scripts properly functioning out of the box:
scripts/tiny/dirsize.py and ksize.py.
dirsize.py will give you a breakdown of pkg sizes for your rootfs; while ksize.py will give you the equivalent info for the kernel.