I am looking for help getting serial communication to work via the UART on either a Raspberry PI 3 B or a 3 B + that is running Fedora 29. The kernel recognizes the UART as /dev/ttyS1 on these systems. Data flows, but it is corrupted at random intervals. This happens at any baud rate. With these same two computers, everything works fine if I run Debian, which I really don't like. So it is not a hardware issue. I am thinking it is more of a device tree problem.
I also have UART to USB adapters that the kernel recognizes ad /dev/ttyUSB0. When using these under Fedora there is no corrupted data.
I would mention that I also have Fedora running nicely on a Quad Core i.MX6 based Hummingboard2. On that UART, there is no corrupted data issue.
For my project, I really would like to use Fedora and have good communication via the Raspberry PI UART. Is anyone here successfully using the UART on the Raspberry PI 3 B or 3 B +?
One final thing to mention, I do not have the console enabled on /dev/ttyS1. If I do enable it, I get the corrupted data when trying to log in or look at console output via a serial connection.
Any help would be greatly appreciated even if it just to tell me what to go read.
In Peter's blog post (1), he mentions that there now experimental CPU frequency support for the Raspberry Pi.
I can't get my Raspberry Pi 3 B+ to scale beyond 600MHz. How do I enable the experimental CPU frequency support in /boot/efi/config.txt ?
I'm running Fedora 29 4.19.10-300 kernel. Thanks!
(1) - https://nullr0ute.com/2018/12/raspberry-pi-improvements-in-fedora-29/
I've recently installed Fedora in a Raspberry Pi 2 model B, but it
keeps rebooting a few minutes after boot.
This Pi was previously running with OSMC, based on Debian, without
problem. I've tried several SD cards and a couple of power supplies
with no success.
Some times, I see kernel crashes on the screen, but too fast to take a
photo, as the console is constantly printing text. Other times there is
no message, just a sudden reboot.
Anyone has experienced similar problems? How can I further debug the
after booting my Helios4 with Fedora 29 (thanks to Dennis Gilmore) I
want to try booting with CentOS:
�d PHY - Version: 2.0
Detected Device ID 6828
board SerDes lanes topology details:
| Lane # | Speed | Type |
| 0 | 6 | SATA0 |
| 1 | 5 | USB3 HOST0 |
| 2 | 6 | SATA1 |
| 3 | 6 | SATA3 |
| 4 | 6 | SATA2 |
| 5 | 5 | USB3 HOST1 |
High speed PHY - Ended Successfully
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR Training Sequence - Start scrubbing
DDR3 Training Sequence - End scrubbing
mv_ddr: completed successfully
Trying to boot from MMC1
U-Boot 2018.09 (Nov 27 2018 - 11:54:11 +0000)
SoC: MV88F6828-A0 at 1600 MHz
DRAM: 2 GiB (800 MHz, 32-bit, ECC enabled)
Cannot find I2C: -19
MMC: mv_sdh: 0
Loading Environment from MMC... *** Warning - bad CRC, using default
SCSI: MVEBU SATA INIT
Target spinup took 0 ms.
Target spinup took 0 ms.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs
Warning: ethernet@70000 (eth1) using random MAC address - 86:e8:ea:f8:32:d9
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:2...
Retrieving file: /extlinux/extlinux.conf
567 bytes read in 58 ms (8.8 KiB/s)
Ignoring unknown command: ui
Ignoring malformed menu command: autoboot
Ignoring malformed menu command: hidden
Ignoring unknown command: totaltimeout
CentOS-Userland-7-armv7hl-generic-Minimal-1810 Boot Options.
Enter choice: 1: CentOS-Userland-7-armv7hl-generic-Minimal-1810
Retrieving file: /initramfs-4.14.82-201.el7.armv7hl.img
42850136 bytes read in 7130 ms (5.7 MiB/s)
Retrieving file: /vmlinuz-4.14.82-201.el7.armv7hl
6640128 bytes read in 1166 ms (5.4 MiB/s)
append: ro root=UUID=16be0dd0-8df3-423e-9166-0d9591ac921c
Retrieving file: /dtb-4.14.82-201.el7.armv7hl/armada-388-helios4.dtb
18868 bytes read in 1163 ms (15.6 KiB/s)
## Flattened Device Tree blob at 00100000
Booting using the fdt blob at 0x100000
Loading Ramdisk to 0d722000, end 0ffff758 ... OK
Loading Device Tree to 0d71a000, end 0d7219b3 ... OK
Starting kernel ...
nothing more .....
Must I first update the kernel to more actual version ?
Is there a command that gets me the uboot information I see displayed on
the serial console at boot time. For example:
U-Boot SPL 2016.09.01 (Oct 19 2016 - 13:46:44)
U-Boot 2016.09.01 (Oct 19 2016 - 13:46:44 +0000) Allwinner Technology