Issues attempting to use Raspberry Pi 4 serial console on mainline

[Nathan Chancellor]

On Wed, Jul 22, 2020 at 05:46:22PM +0200, Nicolas Saenz Julienne wrote:
> Hi Nathan, Peter,
> 
> On Wed, 2020-07-22 at 15:41 +0100, Peter Robinson wrote:
> 
> [...]
> 
> > On Wed, Jul 22, 2020 at 2:27 PM Nicolas Saenz Julienne
> > > For reference I just booted linux-next with this setup:
> > > 
> > > boot partition:
> > >         ...Latest firmware files taken from the RPi firmware repo [1]...
> 
> Natan, it seems I lied here and been using an outdated firmware version. I've
> just validated what Peter comments below, and the last working firmware release
> with this setup is Feb12[1]. Given your use case I'd just use that and forget
> about it.

Excellent, that worked perfectly with the settings that I had initially.

> > >         Image                   #Copied from linux build
> > >         bcm2711-rpi-4-b.dtb     #Copied from linux build
> > >         config.txt
> > >         cmdline.txt
> > > 
> > > config.txt:
> > >         kernel=Image
> > >         enable_uart=1
> > >         arm_64bit=1
> > > 
> > > cmdline.txt:
> > >          console=tty console=ttyS1,115200 text root=/dev/nfs
> > >          nfsroot=10.42.0.1:/home/nico/netboot/root,vers=3 rw ip=dhcp
> > > rootwait
> > >          elevator=deadline
> > > 
> 
> [...]
> 
> > > 
> > > The issue with the mini UART is its clock, which is derived from VPU's, which
> > > is itself controlled by RPi's firmware. Changes might happen behind the
> > > kernel's back, and the mini UART divisors will not be updated accordingly.
> > > This is an area the we could do better, but no one found a good solution yet.
> > > That said, for now, when using the upstream kernel, VPU's clock should be
> > > stable as we forbid the firmware from performing frequency scaling on that
> > > clock.
> > 
> > There has actually been a regression in the firmware here, prior to
> > mid April if the enable_uart=1 I always had clean output on the serial
> > console, since that date on the rpi3/3b+/4 I get a whole bunch of
> > junk, revert to an older firmware (I've been using April 1st ) and it
> > all goes back to being fine. I've not had time to actually report it
> > yet, and it's still a problem with the latest firmware but a quick
> > look it likes similar to this issue reported in late April:
> > 
> > https://github.com/raspberrypi/firmware/issues/1376
> 
> Thanks for pointing it out! I missed that bug report. I'll try to get the gist
> of it.
> 
> Regards,
> Nicolas
> 
> [1] https://github.com/raspberrypi/firmware/releases
> 

Same goes for me as Peter, let me know if you need any information or
debugging info.

Cheers,
Nathan