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.)

[pelwell]

Before (considering) undertaking this work, I'd like to clarify something.

I had considered the fact that the firmware leaves uart0 mapped to GPIOs 14 and 15 to be anomalous - it seems to go against the DT philosophy of only enabling that which is requested in the DTB. Are you saying that having a UART enabled at boot is the preferred behaviour?

[swarren]

DT isn't meant to prescribe a certain HW configuration; it's simply there to represent the actual HW setup. So, whether the GPIO pins are "pre-muxed" to the UART or not is entirely unrelated to DT.

Most pins on the GPIO expansion header are set up as GPIO in by default solely because there's no way to know ahead of time what the user will use those pins for. This means that if the RPi was to actively drive those pins to a particular output state at boot, then one/both of the following could happen:

• The FW might just happen to choose a default output value that was inconsistent with the user's desire for how their external circuit interpreted any input value on that signal. This could cause behavioral problems in the external circuit.
• The external circuit might actually use the signal as an input to the RPi, and hence both circuits would drive the signal at the same time, potentially to different values, which would lead to electrical issues.

The only way to prevent those potential issues is to have the RPi not actively drive the signals by default, until explicitly instructed (via HAT EEPROM content for example) how those signals will be used (or should be configured).

However, some of the GPIO expansion header signals have a known dedicated purpose. For example, two of the pins are used for the HAT EEPROM I2C bus. For pins with such a dedicated purpose, it is entirely safe to configure them at boot, since it's known which are input vs. output etc.

I would argue that the console UART pins fall into this category; they have a dedicated purpose. I don't sure if the HAT specification defines those pins with a fixed purpose, but the Raspbian images certainly use those pins for serial console by default without explicit acknowledgement-from/interaction-with the end-user, so at the very least they have a de-facto dedicated purpose.

Even if the user were to connect the UART pins to some other external device (i.e. not a host's serial port) in an external circuit, they'd have to do so with the full knowledge that a standard RPi SW stack would use the TX pin as an output, and toggle it by default with serial data, and hence they would have to design their external circuit to be compatible with this fact.

My expectation is that the FW would configure all fixed-purpose pins at boot but obviously leave all the undedicated pins at the SoC default (GPIO in w/ pull). IIUC, this is exactly what it does on RPi 0/1/2.

At least, that's the reasoning NVIDIA applied when choosing the default pinmux setup for the Jetson TX1 Developer Kit's GPIO expansion header, which happens to have the same pinout as the RPi 40-pin connector.

BTW, what do config.txt's init_uart_baud and init_uart_clock options do on the RPi 3? Do they still affect the PL01x UART? I suppose that is backwards compatible in a sense, but if you consider those options to semanticalyl be related to configuration of the console (rather than configuration of a particular UART HW module), then they should configure the mini UART.

[pelwell]

Thanks for the clarification.

Currently both init_uart_clock and init_uart_baud still apply to the PL01x. init_uart_clock is meaningless for the mini-UART since the source clock is the core clock, but I think it would be reasonable to pre-configure the mini-UART using the value in init_uart_baud.

[swarren]

pelwell, did you get a chance to think about this? I'd like to get the U-Boot support for RPi 3 upstream ASAP (i.e. within the next ~3 weeks, before the current merge window closes), and it'd be nice not to have to include all the extra pinmux and UART setup code if at all possible. Thanks!

[pelwell]

I'm optimistic I can look at this on Thursday, but probably not before.

[swarren]

Hmm. The existence of pi3-disable-bt-overlay.dts and pi3-miniuart-bt-overlay.dts will complicated this rather. How is code other than the DT-aware Linux kernel (e.g. consider U-Boot, bare metal code, RiscOS?) meant to know whether the mini UART or the regular UART is supposed to be used? I'm confused why there are overlays to promote all kinds of different HW setups rather than just standardizing on one working configuration.

[pelwell]

The overlays use DT aliases (serial0 and serial1) to indicate which UART is the primary in the sense that it has the console. The firmware already reads these aliases, using them to rewrite cmdline.txt replacing serial0 and serial1 with the appropriate UART for the platform, so it should simply be a matter of writing some initialisation code for the mini UART and calling it as necessary.

Some of our users rely on the more capable (larger FIFOs, 8+1 bits) UART for their own applications and are prepared to accept lower BT performance (or forego it completely). Other OSs are free to implement any policy they like - forcing a particular hardware configuration, for example - but as long as Linux has the flexibility why wouldn't we give users the choice?

[popcornmix]

@swarren there is a test firmware here:
https://dl.dropboxusercontent.com/u/3669512/temp/firmware_uart.zip

It includes this from @pelwell

This is my patch to fulfil Stephen Warren's request of initialising the
mini-UART on Pi3. It is smart enough to read the DT after the overlays
have been applied, and only initialise the mini-UART when the UARTs are
swapped.

It will appear in next official firmware update (probably in the next few days).

[swarren]

@popcornmix I'm afraid that firmware doesn't work for me; I just get a rainbow square on HDMI and nothing else. Switching back to the latest files in firmware.git/boot/ works fine, and I changed nothing else either changing to or from the FW in that .zip file.

[swarren]

The situation is a bit more complicated with that firmware than simply "doesn't work":

On the RPi3, in either 32- or 64-bit mode, with U-Boot hard-coded to use the mini UART, everything works, with or without U-Boot initializing the pinmux or baud rate of the mini UART. That last part is good since it means the enhancements work.

On the RPi 3 with U-Boot hard-coded to use the PL01x (and without any DT overlay specified in config.txt to request the FW/kernel do the same), I see the HDMI rainbow. I guess when the ARM touches the unclocked/reset PL01x, there's some system-/bus-level error which triggers the rainbow?

On the RPi2, with U-Boot hard-coded to use either the PL01x or mini UART, I see the HDMI rainbow.

On an RPi1 B+, with U-Boot hard-coded to use a PL01x, I see the HDMI rainbow.

On an RPi1 B+, with U-Boot hard-coded to use the mini UART, it seems like the system is rapidly repeatedly rebooting without fully achieving HDMI sync, since my HDMI monitor keeps repeating the "no signal" display in a way that I think means sync is appearing and disappearing. Or, perhaps the Pi is simply hanging with no HDMI output at all.

So I guess that firmware was tested on the RPi3 but not elsewhere, where the DT defaults or alias values for the UART selection are different?

[swarren]

Sorry, I think the issues I saw with the RPi2 and RPi1 B+ were because I'd forgotten to disable the config.txt options I used to make AArch64 booting work on the RPi3. I've now seen both of those boards work with the new firmware. But now I'm not convinced the new FW is actually enabling the mini UART in the aux module, setting its baud rate, and setting up the pinmux, although I swear this did work before. I think I'm going to give up on testing this tonight and come back some other time.

[sukantoghosh]

@pelwell @swarren How do I use mkknlimg on a non-kernel binary to ensure overlays get applied on RPI3 with my custom firmware?

$ ./linux/scripts/mkknlimg test.bin kernel7.img

• Is this a valid kernel? In pass-through mode.

Adding --dtok and --283x does help me get rid of the error, but I don't see the overlays get applied while booting (get no prints on uart0).
However if I simply concatenate the trailer attached at the end of raspberrypi/firmware/boot/kernel7.img with my test.bin I do see the overlays getting applied.

I tested this by adding pl011 support to @swarren rpi-3-aarch64-demo. (my changes here https://github.com/sukantoghosh/rpi-3-aarch64-demo/commits/pl01x_master)

My config.txt:

enable_uart=1
kernel_old=1
arm_control=0x200
dtoverlay=pi3-disable-bt
dtoverlay=pi3-miniuart-bt

[swarren]

I've tested PL011 on the RPi3 in 32-bit mode by running the RPi2 port of U-Boot on it. I did use the --dtok option to mkknlimg, but not --283x. A bit more info is at https://github.com/swarren/u-boot/blob/rpi_dev/arch/arm/mach-bcm283x/Kconfig#L47. I only used dtoverlay=pi3-miniuart-bt in config.txt. I wonder if the pi3-disable-bt overlay causes problems applying the other one for some reason? In this U-Boot configuration, don't use kernel_old=1. Using that option might also be why my rpi-3-aarch64-demo doesn't work with PL011; I think it prevents the FW from applying DT overlays.

[pelwell]

@sukantoghosh Because mkknlimg doesn't see any compatible string it recognises it is going into manual mode - you have to tell it which flags to set. You need:

• --dtok because you are building a DT-aware kernel
• --ddtk if you are on an rpi-4.4.y kernel or higher because it is a Dynamic Device Tree Kernel that builds *.dtbo instead of *-overlay.dtb (with a different local-fixups format)
• --283x tells the firmware to load bcm283*.dtb rather than bcm27*.dtb, but this isn't important if you are using device_tree=my_kernel.img (for example).

You don't need pi3-disable-bt and pi3-miniuart-bt. If you want to keep BT functionality then use the miniuart variant, otherwise just disable it.

[pelwell]

@swarren kernel_old=1 tells the firmware that your kernel image contains its own stub. The firmware will build a DT, but it has no way to tell the kernel where it is, so in the end it falls back to creating ATAGs at 0x100. You will also need to use kernel_address to indicate where the kernel should be loaded to. I agree that is is better to avoid kernel_old.

[sukantoghosh]

@swarren Placing kernel_old=1 doesn't prevent application of overlays. As I mentioned, if I copy the mkknlinfo trailer from the kernel7.img from raspberrypi/firmare.git/boot/ I got the PL011 working.

@pelwell I did try only --dtok and I didn't work. BTW I see that the prebuilt kernel7.img in firmware repo has some more tags. Not sure if they are making a difference here.

$ ./mkknlimg --dtok build.txt  kerneltest.img
DT: y
283x: n

$ ./knlinfo kerneltest.img 
Kernel trailer found at 1589120/0x183f80:
  KVer: "?"
  DTOK: true
  283x: false

$ ./knlinfo kernel7.img 
Kernel trailer found at 4057000/0x3de7a8:
  KVer: "Linux version 4.1.20-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #867 SMP Wed Mar 23 20:12:32 GMT 2016"
  DTOK: true
  270X: 01000000
  283X: 00000000
  283x: false

[TheSin-]

Yes I see the same results with mkknlimg, I do not get

  270X: 01000000
  283X: 00000000

is there an other options or build flag I need to get the addresses? for 270x and 283x ? I'd like to get as close to foundation kernel as I can.

[lurch]

Looks like those extra fields are only in the 4.4 tree (and above) version of the script, not the 4.1 tree
https://github.com/raspberrypi/linux/blob/rpi-4.4.y/scripts/mkknlimg#L127

[TheSin-]

those are y/n though not the same type of values, I'll run tests with the 4.4 tree today, Maybe if they are using the 4.4 version of the script on the foundation 4.1 kernels that is what happens when you use the 4.1 version of knlinfo, it doesn't know to put y or n. I'm just off to work but once I get there I'll run the 4.4 script on my kernel and check it with the 4.1 knlinfo see fi it looks the same. Thanks for the idea @lurch

[TheSin-]

yup @lurch was right, I used the 4.4 version of mkknlimg using --dtok --270x and with the 4.1 version of knlinfo I get

Kernel trailer found at 3340288/0x32f800:
  KVer: "Linux version 4.1.0-2-rpi2 ([email protected]) (gcc version 5.3.1 20160205 (Debian 5.3.1-8) ) #1 SMP Debian 4.1.20-1.20160324 (2016-03-24)"
  DTOK: true
  270X: 01000000
  283X: 00000000
  283x: false

so that is all they are doing I'll switch my builds to use the 4.4 version of the script so it matches, thanks for the help @lurch

Or maybe the version from 4.4 should get moved into the 4.1 tree?

[lurch]

thanks for the help @lurch

I have to confess that I only got the idea after getting an auto-notification email from GitHub saying that raspberrypi/linux#1195 had been closed.

[TheSin-]

think I should open a new ticket to ask for the mkknlimg form 4.4 to be copied into 4.1 branch? since the official kernel.img and kernel7.img which is 4.1 but is using the 4.4 mkknlimg tool with 270x enabled ? I want to release my 4.1.21 today but I'd like to get that resolved first if at all possible.

[TheSin-]

and now the current 4.1.21 kernel in the firmware repo is using the mkknlimg from 4.1 and not 4.4 like the hash before it ;) I guess nothing needs to get copied after all.

[itemir]

Quick question on the behavior of enable_uart. Is it only applicable to Raspberry Pi3 or is it also used for other platforms? Thanks in advance.

[pelwell]

It applies to all Pis and CMs, but the setting defaults to 1 (true, enabled) on devices where the main UART isn't used for Bluetooth.

[JamesH65]

Sorry about the necro...

Following a comment from @lurch above, I have written some basic UART documentation which, if the participants of this thread have time, I would like to have checked over. Don't worry about grammar etc, that will be sorted by our copy editors here, but content comments I am looking for. I reckon it's a bit skimpy so far, so if people could give pointers on where things could be expanded that would be great.

https://github.com/raspberrypi/documentation/blob/JamesH65-uart-docs/configuration/uart.md

[lurch]

@JamesH65 could you submit that as a "WIP" PR, so that we have somewhere suitable to leave comments? :)
Or are you looking for comments directly in this thread?

[JamesH65]

Hi @lurch, didn't realise you could not comment on a branch. I'll PR it.

[JamesH65]

See raspberrypi/documentation#592