Overlay to remap Pi 3 UART

[PhilE]

Another few corrections:

1) There's a stray space in

Code: Select all

sudo nano /boot/ cmdline.txt

2) If you want Bluetooth to work then don't disable the hciuart service - just edit hciuart.service as you describe. If you don't want Bluetooth then don't edit the service, just disable it. Pick one.

3) Although I am normally reluctant to recommend that people rpi-update, on this occasion I think it is better to rpi-update to get the sane behaviour w.r.t. the serial port aliases. The alternative is that people follow your instructions (using serial1) and then have to change it when they install the next Raspbian release. So I suggest that on this occasion you add "sudo rpi-update" (with a suitable caveat - use my name if you want) after "sudo apt-get upgrade", and then use the following cmdline.txt (I'm assuming you want kgdb enabled):

Code: Select all

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 kgdboc=serial0,115200 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

[abelectronicsuk]

Another few corrections:

1) There's a stray space in

Code: Select all

sudo nano /boot/ cmdline.txt

2) If you want Bluetooth to work then don't disable the hciuart service - just edit hciuart.service as you describe. If you don't want Bluetooth then don't edit the service, just disable it. Pick one.

3) Although I am normally reluctant to recommend that people rpi-update, on this occasion I think it is better to rpi-update to get the sane behaviour w.r.t. the serial port aliases. The alternative is that people follow your instructions (using serial1) and then have to change it when they install the next Raspbian release. So I suggest that on this occasion you add "sudo rpi-update" (with a suitable caveat - use my name if you want) after "sudo apt-get upgrade", and then use the following cmdline.txt (I'm assuming you want kgdb enabled):

Code: Select all

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 kgdboc=serial0,115200 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

thank you for the updates, i have amended the post.

[PhilE]

You still haven't addressed point 2, and I think making the rpi-update + serial0 optional without any indication why is confusing, but it is your blog and I will say no more.

[abelectronicsuk]

You still haven't addressed point 2, and I think making the rpi-update + serial0 optional without any indication why is confusing, but it is your blog and I will say no more.

I am sorry i haven't explained the fix correctly, i have removed the post and will wait until the foundation have the fix in the full operating system for the uart problems and then the post wont be needed.

[Arjan]

I've pushed the new overlay (pi3-disable-bt) to the rpi-4.1.y source tree. You can download a pre-built version here.

Hi PhilE,

When using this https://github.com/vanvught/rpidmx512/b ... 35_pl011.c then it is working on the RPi 3, but it seems that BT is still active and is conflicting with the PL011. Hence the PL011 is not stable to use.

What needs to be done on baremetal to properly enable the PL011 on the GPIO header?

Many thanks advance,
Arjan

[PhilE]

At some point you may have to get into a more precise definition of "baremetal", but for now have you disabled the hciuart service (sudo systemctl disable hciuart)? On a Raspbian system that is configured to use the pl011.

[Arjan]

At some point you may have to get into a more precise definition of "baremetal",.

My definition of baremetal : Not using Linux, using your own OS (https://github.com/vanvught/rpidmx512/b ... /vectors.s), low-level programming, directly on the hardware, no restrictions.

What other low-level steps are needed to completely disable BT?

Thanks, Arjan

[PhilE]

On a baremetal system Bluetooth isn't something you disable, it is something you don't enable. The modem will remain silent until something sends it an HCI initialisation sequence.

Make sure that the pl011/UART0 function is only mapped to GPIOs 14 & 15. But if you are using a baremetal system then you won't be using Device Tree, so the overlays and kernel pinctrl should be completely irrelevant.

If you boot a Pi3 using device_tree=bcm2709-rpi-2-b.dtb then it will behave like a faster Pi2. No WiFi, no Bluetooth, pl011 on 14 & 15 as before. Since this is only a DT change then your baremetal system should see no difference between a Pi2 and a Pi3 either.

[anat]

Is it possible to disable only BT but enable Wifi?

Anat

[pfavr]

Is it possible to disable only BT but enable Wifi?

Yes, by using the pi3-disable-bt overlay, see this thread: viewtopic.php?t=138223

[dradford]

Make sure that the pl011/UART0 function is only mapped to GPIOs 14 & 15. But if you are using a baremetal system then you won't be using Device Tree, so the overlays and kernel pinctrl should be completely irrelevant.

Well, you can still use device tree in bare metal if you want. Frankly, the way everything keeps moving round from one revision to the next, I think you pretty much have to if you want your code to run on all devices without change.

If you boot a Pi3 using device_tree=bcm2709-rpi-2-b.dtb then it will behave like a faster Pi2. No WiFi, no Bluetooth, pl011 on 14 & 15 as before. Since this is only a DT change then your baremetal system should see no difference between a Pi2 and a Pi3 either.

Does that mean the dtb modifies the hardware setup in some way that we can't do ourselves? Or is it just applying different defaults to gpio pins?

[PhilE]

The dtb can do things not normally possible because it creates device nodes that get turned into platform devices. But the overlay mechanism gives this power to users.

In this case the differences between Pi2 and Pi3 are:
* the Arasan MMC interface is enabled, and mapped to GPIOs 48-53,
* uart1 (the mini/aux UART) is enabled, and mapped to GPIOs 14-15,
* uart0 (the PL011) is mapped to GPIOs 32-33,
* and GPCLK2 is mapped to GPIO 43.

In addition, the PWR and ACT LEDs on the Pi3 are driven from the VPU via a GPIO expander.

[Arjan]

The dtb can do things not normally possible because it creates device nodes that get turned into platform devices. But the overlay mechanism gives this power to users.

This is for Linux-space. Correct?

When doing baremetal programming, we are already a superuser. And we can do the same things that is going on in a dtb. Correct?

On my SDcards, I do not have any overlay files at all. And the Arasan MMC interface code is working fine on the RPi 3 as well.

[PhilE]

Yes, I was talking about Linux.

The dtb, although loaded and manipulated by the firmware, is interpreted and acted upon by the ARM. Since in baremetal programming you make up the rules, you can do anything that DT could, whether you choose to use it or not.

[Massi]

The mini UART (ttyS0) does not support parity. I will create an overlay that uses ttyS0 for the BT modem, which may work for low baud rates and data volumes. Using it will also require the systemd script (/lib/systemd/system/hciuart.service) to be edited.

wow very nice!
what is the performance loss for BT using the mini uart?
and does this require the core_freq=250 option for the BT to work reliably?

[PhilE]

> what is the performance loss for BT using the mini uart?

That's going to be hard to quantify - it will depend on the Pi3's load - what and how much it is doing. The problem is that the FIFOs are smaller than those of UART0, which were already tiny by modern standards.

You'll probably find that dropping the UART speed in /lib/systemd/system/hciuart.service helps - 460800 is a good starting point, and you might even want to go lower. This should improve the reliability at the expense of limiting the maximum throughput.

> and does this require the core_freq=250 option for the BT to work reliably?

It would be best. If you keep your Pi3 adequately powered and cooled then force_turbo=1 would probably also be OK.

[mddnh]

Does force_turbo=1 ensure the core_freq is constantly kept at its highest value (no dynamic scaledown, ever)?

I ask because I'm trying to figure out if I could get good use out of Bluetooth, a reliable UART, and the new high quality audio (which appears to require force_turbo=1, although it sounded fine to me when running force_turbo=0 with a core_freq=250).

Thanks!

[karrika]

While the UART device tree is being changed there is one thing that would be nice. For HAT boards using non standard baud rates it would be great to be able to set the initial speed from the eeprom. There are two common special cases MIDI (31250) and DMX (250000). For console emulation Atari ComLynx is also at 31250 and 62500. All these require a special hardware HAT so it would be only natural to be able to have a uart dts "speed" parameter in the eeprom for the initial setting.

[Arjan]

There are two common special cases MIDI (31250) and DMX (250000).

With respect to DMX512, I am setting the UART clock using the mailbox -> https://github.com/vanvught/rpidmx512/b ... dmx.c#L720

Maybe you can do similar from Linux space.

Arjan
http://www.raspberrypi-dmx.com/

[karrika]

There are two common special cases MIDI (31250) and DMX (250000).

With respect to DMX512, I am setting the UART clock using the mailbox -> https://github.com/vanvught/rpidmx512/b ... dmx.c#L720

Maybe you can do similar from Linux space.

Arjan
http://www.raspberrypi-dmx.com/

Thank you. Actually I can set the speeds by editing /boot/config.txt but what I wanted to ask if just plugging in the DiscoHAT board could set up the correct DMX speed for the UART to make the HAT board plug-and-play. I need to disable the console and set up the UART for DMX.

Or write instructions for the user what he/she needs to do.

[PhilE]

The Device Tree management code in the firmware sets the UART0 clock (using the uart0_clkrate dtparam) before merging any user dtparams and overlays, including any HAT overlay. This means that you can override the real clock rate in order to lie to the kernel using an overlay fragment:

Code: Select all

fragment@<whatever> {
    target = <&clk_uart0>;
    __override__ {
        clock_frequency = <3686400>;
   };
};

That should cause the kernel to generate a MIDI-compatible 31.25KHz when asked for 38.4KHz, but only if init_uart_clock=3000000. This is not the default on Pi3, which uses 48MHz because it expects to use UART0 for the Bluetooth modem (a 3MHz clock limits the UART to 115200 baud).

It should still be possible to create a portable overlay but it needs a bit more work. You would have to create a new fixed-factor clock (like clk_uart1), configured with the appropriate scaling from clk_uart0, and then change the clocks property of the uart0 node to say "<&scaled_clk &clk_apb_p>", where scaled_clk is the label on your new fixed-factor clock.

[clemaez]

Hi,

All of this sound interesting but definitely ultra-technique and I'm kind of lost among all the informations found on this thread.
Then I will ask for help with my setup:

I have a RaspberryPi 3 with a fresh raspbian 2016-03-18 Jessie + Adafruit GPS ultimate hat + Adafruit 10-DOF IMU.
If I understand correctly, the new Bluetooth device on the RPi3 is "mapped" to GPIO 14&15 i.e TXD&RXD for UART bus.
The problem here is that Adafruit GPS ultimate hat also use GPIO 14&15 for data.
Conclusion: we have a conflict because only 1 device can use TXD&RXD.

Am I understanding the problem correctly ?

Obviously my goal is to get the Adafruit GPS ultimate hat working. Ideally I would get bluetooth working too but my project does not require bluetooth so it's not an important feature for me. (But who know... maybe I can require it later, so keep it working)

Again, if I understand well the RPi3 has 2 UART bus, one is powerful, the other one is less powerful and of course the Bluetooth device is "mapped" to the powerful UART bus, right ?
So because bluetooth is less important for my project I would ideally map the bluetooth device to the less powerful UART bus, then map the powerful UART bus to GPIO14&15 that way my Adafruit GPS ultimate hat can be used normally with gpsd (at least that's the plan !)

The question are: how to achieve this plan ? Once GPIO14&15 are mapped to my Adafruit GPS ultimate hat, where are received data: /dev/ttyS0 ? /dev/ttyAMA0 ?

I'm asking because I'm lost, I don't know if I need "dtoverlay=pi3-miniuart-bt" or/and "core_freq=250". Should I edit hciuart.service ? or should I simply follow the tutorial available at https://www.abelectronics.co.uk/kb/arti ... port-usage ?

Thanks in advance for those who will take the time to explain and answer with understandable wording for a non-expert like me

Regards,
Clément

[PhilE]

If I understand correctly, the new Bluetooth device on the RPi3 is "mapped" to GPIO 14&15 i.e TXD&RXD for UART bus.
...
Am I understanding the problem correctly ?

Not quite.

The Bluetooth modem is connected to two different GPIOs - 32 & 33 - pins that don't come out on the 40-pin header. What has changed is that UART0/ttyAMA0 that used to be selected on 14&15 is now selected on 32 & 33, and a different UART1/ttyS0 is now selected on 14&15. That means that you will need to use ttyS0 to talk to the GPS. A better idea might be to use /dev/serial0 which is always set up to point to the UART on 14&15 (the primary UART).

A limitation of UART1 is that the clock varies with the VPU core clock, so you need to set core_freq=250 on the default Raspbian 2016-03-18 firmware, or if you rpi-update (or get the next Raspbian when it is available) then you need to add enable_uart=1 to config.txt (which will also set cpu_freq=250 if ttyS0 is the primary UART).

[clemaez]

It's all understood now
I did rpi-update and dist-upgrade and added enable_uart=1, then now GPS works like a charm.

Thanks you

[minipada]

I am having trouble with the serial also. I have it working but the console doesn't show up. I can transmit by serial otherwise (check with /dev/ttyUSB0 in both ways) but I just have no console. Did I miss something ?

Thanks