I agree with Dirk, it doesn't work to address EnOceanPi in FHEM via ttyS0, therefore I kept it on ttyAMA0 and tried to change everything towards have HCIUart service running on ttySo, but that's not working properly.

I would be extremely interested in any developments on this issue. I use Raspberry Pi's as LAN gateways: they interface the EnoceanPi HAT to a control software called IP-Symcon using ser2net ethernet-to-serial protocol. Now I am sitting on four Pi-3's which are essentially bricked. I tried to follow the solution indicated in Frederick Vandenbosch's blog, but it is unclear to me whether I should activate the UART or not. Any help would be greatly appreciated!

When testing the Raspberry Pi 3 before release, this is the behavior the Pi exhibited when the starting .elf file didn't support the Raspberry Pi 3. When I received the necessary files which did, it operated properly.

Almost all boot problems on the Raspberry Pi I find are down to out of date SDCard images or the device not writing to the SDCard properly or the SDCard failing.

It appears, there are a few options, and as usual the information is splattered all over the place since raspberrypi.org use their forum comments as documentation, and so people have to read dozens (sometimes hundreds) of comments to understand the changes, since the first few comments are invariably wrong or have outdated information. And others have written blog posts all over the place, and many are outdated since the information has changed in releases and some people don't go back and edit their posts and mark the changes..

I have tried to summarize. It could be wrong too. If it is, please let me know and I will edit this post and label it as edited. Once it is fleshed out, if people prefer, I'll write it up as a blog post/document when can have revisions and can have user comments, but the blog post ends up being the first thing read. So reduces the confusion.

As far as I can tell, this is the latest information, these apply to recent software images only.

Main issue: There are two serial interfaces on the Broadcom chip that the Pi uses. One works fine, the other has a speed dependent on the core clock speed. The core clock speed is usually dynamic and changes on the fly. When the core clock speed is high, the CPU performance can be high.

One serial interface goes to Bluetooth, the other goes to the 40-pin connector. Which one goes where? That is selectable at boot; the Broadcom chip can internally reroute it. By default, the varying one goes to the 40-pin connector and that is clearly a problem if you wish to make use of it in any way.

There are 4 options:

Option 1. Have the serial interface (UART) functioning correctly, but no Bluetooth capability

--> Swap the UARTs around. To do this, add the following to /boot/config.txt: dtoverlay=pi3-disable-btdtoverlay=pi3-miniuart-bt

and type the following to disable the Bluetooth (since it is now on the changeable speed UART): sudo systemctl disable hciuart

Option 2. Have the serial interface functioning and have Bluetooth functioning very well, but have the clock speed of the processor fixed (to a low speed [250MHz] or a high speed [500MHz?])

--> Add the following to /boot/config.txt: enable_uart=1

It will affect the CPU performance because it controls the speed of the L2 cache, and will reduce the analog audio quality (references are here and here respectively)

For the high clock speed (which will require a fan and heatsink realistically) to get back the CPU perf and audio quality, also add the following to the same file: force_turbo=1

Option 3. Have a broken serial interface (varying speed) but have Bluetooth capability

--> Do nothing. This is the default setting

Option 4: Have the serial interface (UART) functioning correctly, also have Bluetooth working but slowly

--> Swap the UARTs around. To do this, add the following to /boot/config.txt: dtoverlay=pi3-miniuart-bt

and then set the core frequency to a low, fixed value by adding the following to /boot/config.txt: core_freq=250. It will affect the CPU performance. If you want

higher performance then do not add the core_freq=250 line and instead have the line force_turbo=1 but this requires a fan and heatsink.

The serial interface (i.e. UART) can be used for HATs/hardware etc., or can be used with a USB-Serial adapter to access a Linux shell (also known as a console session) using a PC and PuTTY, and it also dumps out startup text during boot. If you've got hardware connected (like Enocean Pi) then you don't want that startup text output during boot or Linux shell access because the hardware will be like "what was that?!" when it sees it.

For options 1 or 2 or 4, if you want the console session on the UART (i.e. you don't have hardware connected and just want to connect your USB-Serial to your PC and see the Linux shell), ensure you have the following in the text line within the file /boot/cmdline.txt:

console=serial0,115200

That line should be there by default.

If you have hardware connected that needs the serial port then remove the text console=serial0,115200

Is this understanding correct (looking at the Pi experts to help here like rew to keep me honest..)?

thank you for your very detailed instructions which are highly appreciated. I have put both "dtoverlay=pi3-miniuart-bt" and "enable_uart=1" into /boot/config.txt, and I have specified sudo systemctl disable hciuart. To no avail, regrettably. The EnoceanPi seems to be still unreachable via ser2net. However, my ser2net.conf reads: "7970:raw:0:/dev/ttyAMA0:57600 8DATABITS NONE 1STOPBIT". Might that be incorrect? (Sorry for the potentially stupid question!).

Yes. I had commented out the entire cmdline.txt line, not quite understanding the implications. I then followed your (correct) advice to just remove the offending in-line statement, and that did the trick!

Wow, I wonder what weird serial I/O adventures are in front of me w.r.t. the Pine A64+. Allwinner as opposed to Broadcomm but A53-based too. reading these RPi3 blogs has been interesting, einschließlich der tech-sprechen!

As far as I understand, this is not possible, only one UART can be assigned to the connections available on the 40-way connector. I don't know of a way to access two simultaneously from that connector.

Practical solutions are to either try to use a different interface to connect to your device if possible, (e.g. I2C), disable console (not a good solution in my opinion but others may disagree), or use an I2C or SPI to UART bridge chip (but you will then need to create some driver code if it doesn't already exist for your chosen bridge chip).