KubaF
Posts: 2
Joined: Sun May 13, 2018 9:44 pm

enable_uart=1 does NOT set core_freq=250

Sun May 13, 2018 10:07 pm

The documentation at Mini UART and CPU core frequency says
The Linux console can be re-enabled by adding enable_uart=1 to config.txt. This also fixes the core_freq to 250Mhz
But the core freq change does not seem to happen, because just having

Code: Select all

dtoverlay=pi3-miniuart-bt
enable_uart=1
in my /boot/config.txt results in hciuart.service failing to start (Initialization timed out). But changing the config to

Code: Select all

dtoverlay=pi3-miniuart-bt
core_freq=250
makes it start succesfully.

Is the documentation wrong, or my observation? How can i debug it or verify further? Could the doc and/or the dto be fixed?

The rest of my /boot/config.txt in case it is relevant:

Code: Select all

dtparam=i2c_arm=on
dtparam=spi=on
dtparam=audio=on
dtoverlay=dwc2
dtoverlay=w1-gpio

uname -a

Code: Select all

Linux raspberrypi 4.14.30+ #1102 Mon Mar 26 16:20:05 BST 2018 armv6l GNU/Linux

ls -l /dev/serial*

Code: Select all

lrwxrwxrwx 1 root root 7 May 13 18:12 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 May 13 18:12 /dev/serial1 -> ttyS0

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2072
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: enable_uart=1 does NOT set core_freq=250

Mon May 14, 2018 8:17 am

You need to read that section of the documentation together with the preceding paragraph:
Also, when the Linux console uses the mini UART (Raspberry Pi 3, Raspberry Pi Zero W), as a consequence of the UART being disabled, the console is also disabled.

The Linux console can be re-enabled by adding enable_uart=1 to config.txt. This also fixes the core_freq to 250Mhz (unless force_turbo is set, when it will fixed to 400Mhz), which means that the UART baud rate stays consistent.
In other words, in order to use the mini UART for the serial console it must be explicitly enabled with "enable_uart=1", which has the side effect of forcing the core clock to 250MHz.

Your use case is the opposite - using the mini UART for Bluetooth via the pi3-miniuart-bt overlay - which is covered by the overlay documentation:

Code: Select all

[email protected]:~ $ dtoverlay -h pi3-miniuart-bt
Name:   pi3-miniuart-bt

Info:   Switch Pi3 Bluetooth function to use the mini-UART (ttyS0) and restore
        UART0/ttyAMA0 over GPIOs 14 & 15. Note that this may reduce the maximum
        usable baudrate.
        N.B. It is also necessary to edit /lib/systemd/system/hciuart.service
        and replace ttyAMA0 with ttyS0, unless you have a system with udev rules
        that create /dev/serial0 and /dev/serial1, in which case use
        /dev/serial1 instead because it will always be correct. Furthermore,
        you must also set core_freq=250 in config.txt or the miniuart will not
        work.

Usage:  dtoverlay=pi3-miniuart-bt

Params: <None>

KubaF
Posts: 2
Joined: Sun May 13, 2018 9:44 pm

Re: enable_uart=1 does NOT set core_freq=250

Sun May 20, 2018 4:27 pm

Thank you for the explanation, you were right that I needed to read more carefuly and with context.

Now I finaly realize that simply setting enable_uart=1 (without *-bt overlays) moves the Linux console through the mini UART to the GPIO pins, for some reason I thought that the mini UART is only internal. This way I can let Bluetooth use the better UART and still have USB TTL console.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2072
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: enable_uart=1 does NOT set core_freq=250

Sun May 20, 2018 4:39 pm

Yes, you've got it. This is a subject that often causes confusion - the goal was to get the best performance out of the system while still giving control to the users, but this had led to a subtle interconnection between the enable_uart and core_freq settings and various uart- and bluetooth-related overlays.

andrum99
Posts: 510
Joined: Fri Jul 20, 2012 2:41 pm

Re: enable_uart=1 does NOT set core_freq=250

Sat Dec 01, 2018 11:52 am

PhilE wrote:
Mon May 14, 2018 8:17 am
You need to read that section of the documentation together with the preceding paragraph:
Also, when the Linux console uses the mini UART (Raspberry Pi 3, Raspberry Pi Zero W), as a consequence of the UART being disabled, the console is also disabled.

The Linux console can be re-enabled by adding enable_uart=1 to config.txt. This also fixes the core_freq to 250Mhz (unless force_turbo is set, when it will fixed to 400Mhz), which means that the UART baud rate stays consistent.
In other words, in order to use the mini UART for the serial console it must be explicitly enabled with "enable_uart=1", which has the side effect of forcing the core clock to 250MHz.

Your use case is the opposite - using the mini UART for Bluetooth via the pi3-miniuart-bt overlay - which is covered by the overlay documentation:
So does that mean that whichever use you have for the mini uart, the core frequency must be locked to 250MHz, and if the mini uart is disabled then it doesn't matter what the core frequency is?

The OP has also pointed out that enable_uart=1 on its own is not enough to lock the core frequency to 250MHz. Under what circumstances does enable_uart=1 lock the core frequency to 250MHz?
Also, when the Linux console uses the mini UART (Raspberry Pi 3, Raspberry Pi Zero W), as a consequence of the UART being disabled, the console is also disabled.

The Linux console can be re-enabled by adding enable_uart=1 to config.txt. This also fixes the core_freq to 250Mhz (unless force_turbo is set, when it will fixed to 400Mhz), which means that the UART baud rate stays consistent.
This doesn't actually make sense. The first paragraph says the Linux console uses the mini uart, but that the UART is disabled so the console is disabled. If the console is disabled, then the Linux console cannot be using the mini uart.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 2072
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: enable_uart=1 does NOT set core_freq=250

Sat Dec 01, 2018 12:23 pm

So does that mean that whichever use you have for the mini uart, the core frequency must be locked to 250MHz, and if the mini uart is disabled then it doesn't matter what the core frequency is?
Correct - unless you are using one of the other core-clock-dependent peripherals such as I2C or SPI.
Under what circumstances does enable_uart=1 lock the core frequency to 250MHz?
When mini-UART is the primary/console UART. Yes, these rules aren't simple, but they are necessary to get the desired behaviour in the must common use case without penalising other use cases, and without requiring config changes when moving cards between different Pis.
This doesn't actually make sense. The first paragraph says the Linux console uses the mini uart, but that the UART is disabled so the console is disabled. If the console is disabled, then the Linux console cannot be using the mini uart.
It means that because the console had been configured to use a UART which is disabled, the effect is to disable the console that would have been provided on a serial line on GPIO pins 14 and 15.

If I tell you to use a locked door, you end up stuck behind the door you are trying to use, even though you can't use it.

andrum99
Posts: 510
Joined: Fri Jul 20, 2012 2:41 pm

Re: enable_uart=1 does NOT set core_freq=250

Sat Dec 01, 2018 3:45 pm

Thanks PhilE. The reason for mentioning this was with a view to updating the docs. Now you have provided clarification I will submit a PR with the required documentation updates.

Return to “Device Tree”