Raspberry Pi 3 model B Serial console does not use correct baudrate

[josn0]

Serial console seems to give a incorrect baudrate. Overriding frequencies to previous Raspberries in /boot/config.txt helps: everything works as normal. After some iterations, I found that setting 'gpu_freq=300' solves the problem, although that is the default setting on a rpi 3. Probably someone reads that value to initialise the baudrate generator, and uses the old default 'gpu_freq=250' if the value is not set. This is almost certainly done in the closed-source /boot/start*.elf files. All those files do contain the texts 'config.tst' as well as 'gpu_freq'. Please repair this issue..

[pelwell]

An issue with gpu_freq/core_freq handling was discovered and fixed in an rpi-update release made on the 29th, but that hasn't made its way to a Raspbian build yet. You can run "sudo rpi-update" to get the latest firmware, wait for a Raspbian update, or use a workaround: set the frequency using core_freq instead of gpu_freq.

[josn0]

Thanks for the response. I tried a rpi-update; it did not help. Then tried adding 'core_freq=300'; that did not help either. Put back my 'gpu_freq=300', which again solved the problem. So it seems the issue is not fixed correctly.

[pelwell]

It looks like there might be a clocking issue - we will investigate.

[pelwell]

My Pi3 serial port (ttyS0) has been rock solid with force_turbo=1 and a 2.5A power supply. I think you may be suffering from under-voltage. The gpu_freq=300 setting will have the effect of scaling back all of the non-ARM clocks, which will save power.

[TheDJVG]

@pelwell, I don't get if this issue will be resolved or not. I'm using a 2.5A power supply and force_turbo which makes it work again but I think some firmware needs to be updated to make it work the right way (without force_turbo) or am I missing something?

[pelwell]

See my answer in this thread:
RPi-Distro/repo#22

[gejanssen]

have the same problem. unfortunately the gpu_freq setting does not work.
Also the new firmware of today works partly.
booting is garbled and after that the login prompt is showing.
21���B�b�
�#)
��2l��L`~Bn�
�nn
�b�nb�Llbr���2nbBbl
Raspbian GNU/Linux 8 rpib3 ttyS0

rpib3 login: gej

now running version 30fe8178d61c1ff9bc168edaafdbcb101aa6245e (05-02)

[pelwell]

If the red power LED flickers then your power supply isn't sufficient. You need a good 2.5A supply. There are extra current demands at boot time, with WiFi and Bluetooth starting and increased parallelism thanks to systemd.

[gejanssen]

@pelwell The powersupply used is a 5A powersupply and the red led is not flickering.
Also found on another posting that if I use
force_turbo=1
arm_freq=1200
core_freq=250
and fixing the cpu frequence,
gej@rpib3:~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1200000
gej@rpib3:~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
1200000
gej@rpib3:~ $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
1200000
the serial works perfectly
also the bluethooth works
gej@rpib3:$ sudo hcitool scan
Scanning ...
10:3B:59:F5:65:6A GT-I9305N
gej@rpib3:$

[pelwell]

It's the core_freq=250 that makes the difference - if your maximum core freq is the same as the minimum core freq then it never changes.

[TheDJVG]

@pelwell Maybe I just don't get it but I'm trying to make it clear. I'm now using a power supply that can deliver up to 12A of current but I still need force_turbo to make the serial output work (= readable). Peak current is around 2.3A at boot. Is the need of force_turbo a workaround for an unresolved bug in the firmware or what is causing this? I don't have this problem with all the other models, that's why I'm asking and trying to understand.

[gejanssen]

I can confirm that only the core_freq=250 works.
gej@rpib3:$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
1200000
gej@rpib3:$
gej@rpib3:$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
600000
gej@rpib3:$ sudo hcitool scan
Scanning ...
C8:29:2A:1B:68:74 LGE DTV BCM20702A1
gej@rpib3:~$
At full load an minimal load the bluetooth and serial works.

[pelwell]

The answers are in the other thread (RPi-Distro/repo#22), but the short version is that the clock is also reduced if the chip is getting too hot. By setting the core VPU clock to the minimum value (250) you avoid this problem.

[swarren]

I pulled down the latest firmware, and I still see some issues re: serial console. Let me know if I should file this as a separate bug. I think it's within the realm of this bug though.

On the RPi 0/1/2, whatever is loaded as kernel.img can immediately start writing to the UART's TX FIFO, and that data will appear on the GPIO header pin at the expected baud rate.

However, on the RPi 3, the following steps are required before this works. I believe the firmware should provide the same guarantees/initial-conditions on all system, so none of these steps should be necessary:

1. Configure GPIO14/15 pinmux to be ALT5 to select the mini UART.
2. Write to the AUX block's ENABLES register to enable the mini UART.
3. Configure the mini UART for 8-bits (it defaults to 7).
4. Program the UART baud-rate divider.

For reference, see the most recent commit at https://github.com/swarren/u-boot/commits/rpi_dev.

(For the RPi 0/1/2, we do actually do step 4 too. However, Eric Anholt has submitted a patch to skip this so that U-Boot honors whatever the firmware programmed, which means it follows whatever the user requested via config.txt, which makes for a nicer user experience).

One particularly nice benefit of the firmware doing this is that step 4 can be skipped, which means U-Boot wouldn't have to query the core clock rate from the firmware in order to calculate the divider. (Assuming the core clock rate hasn't changed, but there really isn't anything we can do about that.)