Serial console broken on RPi 3

[diederikdehaas]

Using the raspbian-jessie-lite image dd 2016-02-26 (and performing all updates after that), I can't get the serial console working on a RPi 3. When I put the image in a RPi 2, everything is fine.

By not working, I mean that I mostly get garbled output and I am unable to use my keyboard to interact with the system.

There is a forum thread about it and (apparently) someone found a workaround ... by crippling the performance of the RPi 3 by adding core_freq=250 to /boot/cmdline.txt which also reduces the CPU speed to 600 Mhz.

I don't consider that an valid option.

[XECDesign]

You can also get around the issue by adding force_turbo=1 to config.txt

[diederikdehaas]

It does indeed work 😄

Is there some side effect that causes that? Because logically I don't see the connection ...

[XECDesign]

Something to do with the source clock for the serial. I don't know the specifics.

[diederikdehaas]

Thanks 👍

Is this the official solution or is there another one in the pipe-line?
I'll leave it up to you to close the issue or not.

[XECDesign]

I think I saw someone say that it may have already been fixed in newer firmware, but I couldn't see that in the commit messages.

@pelwell Is this something that can be or has been fixed?

[pelwell]

There are some inescapable facts:

1. uart1, like the sdhost interface, uses the core clock. If the core clock changes then the baud rate will change.
2. Bluetooth uses uart0 because it has larger FIFOs and because it is immune to changes in core clock.

You can reduce clock rate fluctuations using force_turbo=1, but there is still the possibility of an enforced clock rate reduction because of an over-temperature situation. Between 80C and 85C the ARM overclock is disabled, then at 85C all other clocks (core, sdram, v3d, isp, h264) are also reduced to minimum.

It may be possible to ameliorate the issue by automatically reprogramming the uart clock divisor when the core clock changes, but that will depend on there being a suitable ratio between the overclock and the minimum. Therefore the only way to be sure that the baud rate doesn't ever change is to set core_freq to minimum to start with, which is 250MHz.

Setting core_freq to 250MHz does not limit the ARMs to 600MHz. Those clocks are all independent.

The main clocks are controlled by the config.txt settings arm_freq, core_freq, sdram_freq, v3d_freq, isp_freq and h264_freq. gpu_freq is an alias for the non-ARM clocks that haven't been set explicitly. Until the most recent firmware there was an oversight that meant that setting core_freq implicitly by setting gpu_freq wasn't being communicated to the Linux world, causing incorrect baud rates. The latest rpi-update firmware fixes that issue, but you can avoid it by using core_freq instead of gpu_freq.

[XECDesign]

Ah, thanks for the full explanation.

Related raspberrypi/firmware#553

[Mwt-Anthony]

I have same problems... I can't use my RPI3...
I used Razberry zwave card, and impossible to communicate with !
I try force-turbo but without success!

I put my sdcard into my RPI2 it work like a charm...

I hope problem can be solve quickly.
Thanks

[XECDesign]

Careful, that's force_turbo, not force-turbo.

[pelwell]

A user on the other thread has found that gpu_freq=300 works for them.

[josn0]

Phil (pelwell) is right. I started to retrieve all frequency settings on a earlier Pi (using 'vcgencmd get_config int | grep freq'), copying all to config.txt to overrule the new defaults, and the problem was gone. Then, to get performance back, I stepwise increased the settings until I reached the new defaults (also found with get_config). After I reached all new default settings, everything kept working. Then I commented-out the _freq settings until the problem re-appeared; that was with gpu_freq. So put that back and the problem was all over, without changing any settings. My theory is that, pre-kernel-boot, something needs to set some frequencies, reads them out of the config.txt, and if not present, uses the (old) defaults. I think that is done in the start.elf files. Alas, they are closed-source. But, by grep-ing them, I found the texts 'gpu_freq' and 'config.txt', which makes my assumption more plausible.

Another thing that is probably done there, is 'patching' the kernel's commandline parameters: file 'cmdline.txt' now contains 'console=serial,115200' instead of 'console=ttyAMA0,115200'. But whether the console is named 'serial' or 'ttyAMA0', if you check /proc/cmdline, both are changed to 'ttyS0'. I think that is also done in the start*.elf code.

If so, it is a pity that such non-transparent 'hacks' are buried in closed-source proprietary code. Please dont do that. I can understand that the start*.elf file need to be closed-source, because it needs to interact with the proprietary gpu, but then keep the code in there as small as possible and as transparant as possible. Put strange hacks somewhere else, like in the kernel code, that everyone can read.

[diederikdehaas]

'cmdline.txt' now contains 'console=serial,115200' instead of 'console=ttyAMA0,115200'. But whether the console is named 'serial' or 'ttyAMA0', if you check /proc/cmdline, both are changed to 'ttyS0'.

I haven't investigated it, but I noticed that too.

[ladyada]

verifying that the baud rate is ~72Kbps not 115Kbps - works great if I set my serial cable to 72000, note that prolific chipsets (PL230x) cannot do weird baud rates, try an FTDI or SiLabs chip :)

[pelwell]

@josn0 I was surprised that I couldn't find a standard DT mechanism for giving serial ports a chosen name. The PL011 driver attempts to renumber its own instances based on serial aliases, but it calls its instances ttyAMA instead of ttyS and other serial drivers don't seem to obey the same rule.

The reason for the cmdline rewriting by the firmware is to allow a single SD card image to work in any Pi until we have worked out a better mechanism in the kernel. I don't particularly like it but our options were limited and time was short.

@ladyada 72Kbps is 115200*(250/400), with 400 being the standard VPU overclock and 250 being the minimum used in overtemp or undervolt situations. I think you will see the power LED blinking off, indicating undervolt. I had to change my power supply to 2.5A model - I have any inline switch in the USB power cable and with the additional loss it adds the startup current for WiFi and Bluetooth is sufficient to drag the voltage down below the threshold.

[glynhudson]

I am trying to connect an Arduino @ 38400 baud to the Rpi3 via ttyAMA0 with no joy. Zero comms. Is this related this this thread or should I start another issue? I am using an SD card upgraded from Jessie that worked fine on RPi2. Serial console has been disconnected from terminal in the usual way