BTW, what reason do you have for running rpi-update? Nobody should run that unless they have a specific need to get a new kernel and new firmware to solve a problem they're working on with the RPF developers.

Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Hi PhilE,
I did not understand that you were the developer. However, thank you for your support. I finally found a free time slot in order to go on with my project. So I read the link that you provided for instantiating a I2C device https://www.kernel.org/doc/Documentatio ... ng-devices. There are many methods and the most appropriate seems the last one "Instantiate from user-space" as you suggested.
The command you provided seems sufficient to do the job:

However, what about the address? Which are free addresses and how to find them? Is it necessary to delete this file only when the device is not used anymore?

What is better to write ASoC driver as for sound/soc/bcm/hifiberry_dac.c or to write a configuration file simple_card.txt and use DeviceTree? In particular, I found this https://github.com/raspberrypi/linux/bl ... au1701.txt in the same folder.
I'm sorry, I know C language, but it is my first time about using I2C and I2S and writing kernel module or driver.
Thank you again

Hi, just updated to the latest firmware (following discussion here: viewtopic.php?f=107&t=1315780) and having some issues with my wifi dongle which runs as a host. Intermittently it won't come up. Plugged an HDMI cable in and voila, turns out it's throwing up during boot:

This has nothing to do with this topic and as you noticed by posting it here nobody has 'heard' you.
Please create a new topic.
BTW: that seems to be a screen with HDMI output, so I would expect it to work without much trouble.
Make sure to give details about exactly what problems you have.

It is possible to add things to the command line from overlays, but I made a change on November 9th that caused the cmdline.txt settings to appear after additions from the overlays, allowing the user to override some settings from overlays by editing cmdline.txt. This change was prompted by the vc4-kms-v3d overlay and its CMA settings, but it seemed like the right thing to do anyway.

The complication comes from the fact that the command line is merged into the DT as one of the set of magic firmware-provided properties. The way the November change was implemented was by moving the bulk merge of these properties after the merging of the overlays, but this had the unintended consequence of disabling the uart baudrate hack. A more fine-grained approach is required - watch this space.

This disables DMA support. You will see a small decrease in performance and an increase in CPU load, but it will be useful to me to know if this solves your SD card problems.

Had a chance to try this today and it does look like it's working - I'm about 5/6 boots in with no fails. Thanks for your reply, if you need any more data points, let me know.

For now, I'd like to avoid any decrease in performance (although I've yet to see how slow this change is). I used rpi-update to get to this point from kernel 3.18.11 and update the firmware to fix a problem with the device tree ignoring some GPIOs (see: viewtopic.php?f=107&t=131578). How recently was this kernel bug introduced? Is there some point between there and here where the DT issues are fixed but this bug isn't present?

BCM2835 has two SD/MMC interfaces - one from Arasan (that I will call MMC) and a low-power version designed by the VPU team in Broadcom (SDHOST). MMC has been the standard RPi SD controller since day one, but there have a been a number of problems with certain cards leading to data corruption that have been attributed to the hardware block and its integration. It also has a restrictive clock divider that prevents you from achieving a full 50MHz bus speed on a non-overclocked VPU.

The bcm2835-sdhost driver was first released at the end of March 2015. It uses the Broadcom SDHOST interface instead which requires slightly more CPU assistance but can hit 50MHz on a stock VPU (core_freq=250). The block has a few quirks, but it doesn't seem to have the same data corruption problems as the MMC block. Switching to sdhost for SD cards also has the benefit of freeing up MMC for potential SDIO applications (e.g. connecting an network interface to a Pi without using USB).

Until November the way to activate the sdhost driver was using a DT overlay ("sdhost"), but current kernel releases use sdhost by default. On the whole the results have been positive, but as you have seen there a few card varieties (and some CM eMMC) that have been problematic. For those affected, the "mmc" overlay can be used to revert to using the MMC interface until the problems have been resolved.

@jofemodo A change to restore the special uart0 clock-rate behaviour will be in the next rpi-update firmware release. There are a number of other changes waiting to go in so you shouldn't have to wait long.

PhilE wrote:@jofemodo A change to restore the special uart0 clock-rate behaviour will be in the next rpi-update firmware release. There are a number of other changes waiting to go in so you shouldn't have to wait long.