Page MenuHomeFreeBSD

Aux uart gets wrong clock speed on RPi4
Needs ReviewPublic

Authored by db on Apr 8 2020, 3:59 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Dec 11, 2:56 PM
Unknown Object (File)
Nov 15 2024, 4:34 PM
Unknown Object (File)
Nov 14 2024, 9:32 PM
Unknown Object (File)
Nov 13 2024, 11:58 PM
Unknown Object (File)
Nov 13 2024, 6:57 PM
Unknown Object (File)
Nov 5 2024, 4:37 AM
Unknown Object (File)
Nov 2 2024, 3:02 AM
Unknown Object (File)
Sep 30 2024, 2:57 AM

Details

Reviewers
None
Group Reviewers
ARM
arm64
Summary

Ths uart uses clock from VPU on the VC4 GPU which is locked
to either 500 or 250Mhz depending on RPi4 or lower. Check which
model is running to set appropriate clock speed.

Test Plan

I've tested under RPi3 and RPi4. Baud rate is correct now on both.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 30516
Build 28263: arc lint + arc unit

Event Timeline

Fixed typo in www.raspberrypi.org/documentation/configuration/uart.md

If we start using the root compatible properties I would prefer to have it stored in a variable in sys/dev/ofw/ofw_fdt.c and both accessible by the kernel and userland (via sysctl under hw.fdt.compatible/compatibles, the first one will return the first string in the prop and the second all the strings).

sys/dev/uart/uart_dev_mu.c
548

Why not comparing the full "raspberrypi,4-model-b" string ?

sys/dev/uart/uart_dev_mu.c
519

I can't believe I did that. Fixed.

548

Sure. I don't have strong feelings on it.

Thinking about it I guess since I saw a ',' in that string I thought there might is a slight chance it might end up with an embedded space. I'd also prefer the full string. I'll change.

In D24339#535434, @manu wrote:

If we start using the root compatible properties I would prefer to have it stored in a variable in sys/dev/ofw/ofw_fdt.c and both accessible by the kernel and userland (via sysctl under hw.fdt.compatible/compatibles, the first one will return the first string in the prop and the second all the strings).

The uart is attached before cpufreq is attached. I had wrongly assumed it would be the other way around.

In D24339#536095, @db wrote:
In D24339#535434, @manu wrote:

If we start using the root compatible properties I would prefer to have it stored in a variable in sys/dev/ofw/ofw_fdt.c and both accessible by the kernel and userland (via sysctl under hw.fdt.compatible/compatibles, the first one will return the first string in the prop and the second all the strings).

The uart is attached before cpufreq is attached. I had wrongly assumed it would be the other way around.

This doesn't change what I said.

Update to correct RPi baud rate on mu serial port

Add a command to ofw_fdt.c to retrieve Manufacturer model name
modified uart_dev_mu.c to use this new command then added
a sysctl hw.manufacturer to retrieve this model name from user land.
hw.model is already in use.

Tested on both RPi3 and RPi4

sys/dev/ofw/ofw_fdt.c
153

that should be in hw.fdt.model

463

What's the point of this function ?

Add model and compatible strings
add string sysctl's for both under hw.fdt
lookup model and compatible once and store

I don't understand the need to add new methods to ofw_if. The new methods are just extracting standard properties from a standard dtb in memory; if new functions are needed at all, why aren't they just a couple new convenience functions in ofw_subr.{c,h}?

It might be a good idea to get Nathan Whitehorn's input on this before committing.