It must be the dtb files. Yes, the console is perfect with 9.99.69 with (ahem) .17 good dtb files ... ;-)
Thing is, if this is true - how does it work? And, has this discussion about cpu speed coupled with UART speed been incorrect? On Wed, Jul 8, 2020 at 11:58 PM Frank Kardel <kar...@netbsd.org> wrote: > You are looking at the console port running at 115200 at boot time, right? > > My 9.99.69 console output starts being garbled when > machdep.cpu.frequency.target is being set to 1400. > > That would match the other comments here. > > As you didn't update the dtb files could that be the difference? I think > we got an upgrade of > > the dtb files between .17 and .69. > > Best regards, > > Frank > > On 07/08/20 22:50, Michael Cheponis wrote: > > I have been running 9.99.17 on RPi3+ and did ./build.sh current, which > produced 9.99.69 -- and it works perfectly, no garbling. I just copied > src/sys/arch/evbarm/compile/obj/GENERIC/netbsd.img to /boot/KERNEL7.IMG and > rebooted. > > # sysctl -a|grep freq > machdep.cpu.frequency.target = 1400 > machdep.cpu.frequency.current = 1400 > machdep.cpu.frequency.min = 600 > machdep.cpu.frequency.max = 1400 > machdep.cpu.frequency.available = 600 1400 > > So I'm now more confused than ever. > > > > On Wed, Jul 8, 2020 at 9:03 AM Michael van Elst <mlel...@serpens.de> > wrote: > >> kar...@netbsd.org (Frank Kardel) writes: >> >> >The next message is the setting of the maxiimum frequency which hoses the >> >RPI3B serial port speed. Do we have a clock setting/source issue here? >> >> It's a hardware limitation, the UART frequency is coupled with the >> CPU frequency. >> >> You can either run with a fixed CPU frequency or configure the other UART >> as serial port. The latter then causes problems with the bluetooth >> controller. >> >> -- >> -- >> Michael van Elst >> Internet: mlel...@serpens.de >> "A potential Snark may lurk in every >> tree." >> > >
