5

As of June 2016 Raspbian already has the necessary modifications. You only need to enable the overlay in config.txt (step 6 onwards). I finally got this working as follows: Rebuild the kernel with i2c_gpio module. You must edit the bcm2708_defconfig or bcmrpi_defconfig and add the line CONFIG_I2C_GPIO=m before running the make defconfig. Install kernel and ...


5

This works for me on MacOS Mojave, Create a file called qemu_script.sh and copy-paste the code below nano qemu_script.sh give execution perms and execute, $ chmod +x qemu_script.sh $ ./qemu_script.sh Code: #!/bin/sh brew install qemu export QEMU=$(which qemu-system-arm) export TMP_DIR=~/tmp/qemu-rpi export RPI_KERNEL=${TMP_DIR}/kernel-qemu-4.14.79-...


4

I doubt you can disable device tree anymore, that was intended to be a temporary directive to smooth the introduction of device tree. Just add the device tree SPI entry. Do not use gpio load spi. That is deprecated. As long as there /dev/spidev* entries you can use SPI. To summarise remove device_tree= from /boot/config.txt add dtparam=spi=on to /boot/...


4

You only need to think about adding Device Tree support under following conditions: you know how to write operating systems you are currently in the process of writing an operating system your operating system has to run on multiple different ARM devices, not only the Raspberry Pi your devices do not offer ACPI and have peripherals which cannot be ...


4

by scruss » Wed Feb 15, 2017 3:27 am They're under ‘5 Interfacing Options’ now. https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=174529


3

You are still using "versatilepb". If you want to emulate a Raspberry Pi, use "raspi" The precompiled DTB files can be downloaded from the foundation firmware github. Direct link for the Pi Zero DTB here.


3

As far as I am aware this is not possible from device tree. Linux only has a weak understanding of GPIO. I think the best you will be able to do is use the new gpio directive in /boot/config.txt (not to be confused with the wiringPi shell command called gpio). Try gpio=20=pu See https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=208748 for ...


3

Enable SPI by adding the line dtparam=spi=on to /boot/config.txt. This will enable the main SPI device (two slave selects). crw-rw---- 1 root spi 153, 0 Oct 18 21:01 /dev/spidev0.0 crw-rw---- 1 root spi 153, 1 Oct 18 21:01 /dev/spidev0.1 To also enable the auxiliary SPI device (three slave selects) add the line dtoverlay=spi1-3cs to /boot/config.txt. crw-...


2

This page in the documentation (section 3.5) states: As of Linux 4.4, the RPi kernels support the dynamic loading of overlays and parameters. Compatible kernels manage a stack of overlays that are applied on top of the base DTB. Changes are immediately reflected in /proc/device-tree and can cause modules to be loaded and platform devices to be created and ...


2

After searching in google for several painful hours days, I found the solution. Here is my device tree overlay: /dts-v1/; /plugin/; / { compatible = "brcm,bcm2708"; fragment@0 { target = <&spidev0>; __overlay__ { status = "disabled"; }; }; fragment@1 { target = <&spi0>; ...


2

I resolved my issues more or less. The answer is that the module(driver) doesn't handle very well the IO and all the functionality of the DT(pull up/down). this is what I did: /dts-v1/; /plugin/; /{ compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709"; // we use pin ctrl and no GPIO ctrl so has to not have a driver claim the GPIO and then ...


2

Indeed in Pi3 using stretch (and even jessie) the hardware watchdog is enabled by default


2

As mentioned here the solution I found to building the 4.14.85 kernel was to simply clone the Raspberry Pi Linux repository with git clone --depth=1 --branch rpi-4.14.y https://github.com/raspberrypi/linux and then apply the incremental kernel patches in reverse, until reaching the 85-86 patch. patch -R -p1 < ../patches-linux/patch-4.14.85-86


2

The theoretical limit for USB is 127 devices. But, that is not really true. First of all, the limit of 127 may not be 127, but 96. Yes it looks like a USB 1.1 hub in your log and the 96 limit is for USB 3 (and USB 3 only, AFAIK), but still, you're on a pi4 which has USB 3. Second, it means 127 endpoints, not 127 devices. And a real device can have multiple ...


1

DMA uses the bus address for the data being read/written. I don't know about the device tree side of things.


1

You are NOT using "different 'dtoverlays'". Libraries do NOT "use … 'dtoverlays'" they may use resources initialised by overlays. Device Tree is a mechanism for configuring the hardware and modules which are loaded - more specifically for modifying the default settings by the default dtb. I typically include ~6 in my configuration. Provided the ...


1

I share my updated version of the script for Raspbian-buster-lite guest on Ubuntu host. #!/bin/sh QEMU=$(command -v qemu-system-arm) TMP_DIR=qemu-rpi RPI_KERNEL=kernel-qemu-4.19.50-buster RPI_KERNEL_FILE=$TMP_DIR/$RPI_KERNEL PTB=versatile-pb.dtb PTB_FILE=$TMP_DIR/$PTB IMAGE_BASE=2019-09-26-raspbian-buster-lite IMAGE=$IMAGE_BASE.zip IMAGE_FILE=$TMP_DIR/$...


1

It MIGHT have something to do with:- active_low Set if the power control device requires a high->low transition to trigger a power-down. Note that this will require the support of a custom dt-blob.bin to prevent a power-down ...


1

Most of what you find that seems to a "secret sauce" function are probably protected from full documentation or modification by the Broadcom License If you use a hex editor to page through the boot.elf file, you'll see many low level function names. If you know how to hand disassemble into ARM Op Codes, you'll find out what all these things do. However, ...


1

The sysfs kernel interface to the GPIO has limited capability. See https://www.kernel.org/doc/Documentation/gpio/sysfs.txt for details. Broadly speaking you can set a GPIO to be an input or an output. For an output you can set the level high or low. For an input you can read the level and request to be interrupted at a particular edge transition. You ...


1

However, I failed to found more detailed documentation, most of which only describes plain read/write operation. I believes your problem is with unavailability of detailed documentation. Please read Mastering the Raspberry Pi written by Warren Gay(Appress Publication Technology in Action-TIA series). In this book it is clarified. I believes this book is ...


1

No, pins 3/5 (GPIO 2/3) have hard-wired 1k8 pull-ups to 3V3 fitted (so they can function as the I2C bus). You can not disable these pull-ups in software. You will have to physically unsolder the resistor. See Raspberry Pi schematics.


1

spi_bcm2708 is deprecated. The current SPI drivers are spi-bcm2835 (main SPI) and spi-bcm2835aux (auxiliary SPI).


1

Device tree does not create the I2C devices (just to be contrary device tree does create the similar SPI devices). Add the following line to /etc/modules and reboot. i2c_dev For a quick test you could just modprobe i2c_dev. EDITED TO ADD I'm confused now as your lsmod does show i2c_dev.


1

I encountered the same problem. I could not get the DS18B20 w1-gpio to work on any pin other than pin 4 (the default). After many trials and errors I discovered that in the file /boot/overlays/README, it referenced default "4". I then tried quotation marks around the pin number, and it worked! Answer: Add quotation marks: "21", to get the DS18B20 w1-gpio ...


1

I spent some time trying to avoid having an external pull-up resistor by using the internal pull-up feature of the Pi. Whenever I did not have an external pull-up, I got those 00-xxxxxxx devices. Furthermore, the names of these 00- devices were often changing. I finally concluded that the internal pull-ups (60k vs recommended 4.7k) did not source enough ...


Only top voted, non community-wiki answers of a minimum length are eligible