I've been trying to get it work for the last few years with little success.

The (part1) instructions for iscsi initiator on elinux (can't post a link as it is down) now work, and it appears that it would be fairly trivial to flip the options so that it is built into the kernal.

asandford wrote:
The (part1) instructions for iscsi initiator on elinux (can't post a link as it is down) now work, and it appears that it would be fairly trivial to flip the options so that it is built into the kernal.

I can't change the UART clock. I've tried everything and i can't figure what is the problem.
I'm on kernel 4 from a few weeks ago. I've readed this thread (and many others!) and updated to the latest version.

asandford wrote:
The (part1) instructions for iscsi initiator on elinux (can't post a link as it is down) now work, and it appears that it would be fairly trivial to flip the options so that it is built into the kernal.

If you see an incorrect value here, it is probably because you have an explicit setting in your cmdline.txt (I see you have bcm2708.uart_clock=3000000, but that should be ignored because you are on a Pi 2).

< goes away and reads the code for the loader >

Nope - it won't be ignored, and that may be the problem. The firmware has an explicit check for bcm2708.uart_clock in cmdline.txt, and if found it won't supply its own version (either the default of 3MHz or the init_uart_clock value), even though in the Pi 2 case it should be looking for bcm2709.uart_clock.

1) Remove your explicit bcm2708.uart_clock=3000000 from your cmdline.txt - there is no reason to have it there. If this doesn't do the trick, try temporarily disabling DT ("device_tree=" in config.txt); if that fixes the problem, you need step 2.

2) Your firmware may just predate the change that propagates the init_uart_clock value to the DT - it was added in the July 16th release (d1f47370bc1f16416f2276cf41ac008bf1f802d6). Check the build date on your kernel, and rpi-update if it predates this.

3) I will fix the firmware to either check for the presence of bcm2709.uart_clock on a Pi 2 build (even though it won't help in the Device Tree case), or to remove this check altogether.

>1) Remove your explicit bcm2708.uart_clock=3000000 from your cmdline.txt - there is no reason to have it there. If this doesn't >do the trick, try temporarily disabling DT ("device_tree=" in config.txt); if that fixes the problem, you need step 2.

In kernel 3.17, if i remove this parameter from "cmdline.txt" , it doesn't work (the frecuency stay fixed at 3000000).
In kernel 4.1, it doesn't work with or without this parameter (or bcm2709.uart_clock).

>2) Your firmware may just predate the change that propagates the init_uart_clock value to the DT - it was added in the July 16th >release (d1f47370bc1f16416f2276cf41ac008bf1f802d6). Check the build date on your kernel, and rpi-update if it predates this.

After a comment from Dom I found the other thread where you mention MIDI, so now I understand what you are trying to do and why, which for the benefit of other readers is to use the UART as the basis of a MIDI interface.

MIDI requires a 31.25Kbaud configuration, but this isn't a permissible value to the Linux UART infrastructure so we have to get creative. The workaround is to lie to Linux about the UART clock rate and the desired baud rate so that when it comes to calculate the divisor it ends up with a value that gives us the baud rate we really want. Let's use some real numbers:

The clock is controlled by the firmware, using the init_uart_clock value or the default of 3000000, so we need to set init_uart_clock to 2441000 (which is close enough for an integer divider). In 4.0 and later builds the UART configuration now comes from Device Tree, and can be altered using the uart0_clkrate parameter. The firmware uses this parameter to inform the kernel about any init_uart_clock setting, so what we need to do is override this value to continue to report 3000000, even though the real value is 2441000. Can't we just add:

to config.txt? Well we can, but it won't work. The reason is that settings calculated by the firmware are applied after the user settings - safe, but inflexible - so uart0_clkrate ends up at 2441000.

I have a small patch to the firmware that changes the order of DT construction so that user settings are applied later. With this change I can get the desired behaviour, i.e. the kernel thinks the UART clock is 3MHz but it is really 2.441MHz, so when we request 38400 baud we actually get ~31250 baud.

If we don't find any gotchas this change will make it into the next firmware release, but if you are keen to get it working sooner and get some confidence that the real fix will work for you, you can hack it now:

to config.txt and reboot. That magic shell pipeline decompiles the DTB, cuts out the declaration of the uart0_clkrate parameter, and then recompiles it. Booting with this DTB will prevent the firmware from changing the clock rate value as seen by the UART, leaving it as the default 3MHz.

Unlike with other updates, my v1 B model (256M ram) boots "beyond the rainbow", but it does not find device mapper and thus cannot mount the encrypted root partition [1],[2]. A v2 B of a friend which i setup myself seems to work fine with the same setup. Any idea what fux up dm in my case (reports it can't find /dev/mapper/control)? Cheers!

modprobe: chdir(4.1.5+): No such file or directory
Unlocking the disk /dev/mmcblk0p2 (xxx)
Enter passphrase: /dev/mapper/control: open failed: No such device
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

Edit: w/ the working kernel mention above, the output is as follows (connection to dropbear is supposed to be closed upon successful decryption, see pages cited above).

If you can produce a simple, precise sequence of steps to get from a known starting point (an apt-get update+upgrade followed by an rpi-update, for example) to this failure, preferably one that doesn't require encrypting the filing system, then there is a chance somebody here might be able to help you.

You could also go back to the authors of the guides you've followed and see if they have any ideas.

Thanks for your reply. However, the problem is indeed the encryption and the latest version of the kernel so I am afraid neither the authors of the guides mentioned above nor an example not using encryption might help. I have to get in contact with "Hexxeh" i guess. Thanks anyway for the time your have spend on understanding my prob!

Hi PhilE, Can i beg a little of your time on the same problem?
I'm trying to get MIDI going via the UART as well.
I've gone thru all of the steps you mentioned here, as well as a couple of other bits and pieces for I2C etc gleaned from other places.
Here's the lie of the land currently...

I use my Raspberry Pi 2 B with RPi_Cam_Web_Interface where I ansteuere the camera with servos (pan, tilt).
With the update to kernel 4.1, control my servos, which are driven via the servo Blaster no longer works.
No longer supported servo Blaster, or has been changed a bit to the I2C drivers.

AFUDirk wrote:I use my Raspberry Pi 2 B with RPi_Cam_Web_Interface where I ansteuere the camera with servos (pan, tilt).
With the update to kernel 4.1, control my servos, which are driven via the servo Blaster no longer works.
No longer supported servo Blaster, or has been changed a bit to the I2C drivers.

servoblaster will need an update to work with 4.1. You could use pigpio instead.

Did Richard Hirst wrote to, he is very busy, but I would try to find the time to make an update for Servblaster.
pigpio is indeed determined not to use 1 to1?
I do not have sufficient knowledge, RPi_Web_Cam_Interface to rebuild so, make it work with pigpio.