Hi Heiko pt., 28 lip 2023 o 21:00 Heiko Stuebner <heiko@xxxxxxxxx> napisał(a): > > Hi Javier, > > Am Samstag, 22. Juli 2023, 01:06:54 CEST schrieb Javier Martinez Canillas: > > Heiko Stübner <heiko@xxxxxxxxx> writes: > > > Am Dienstag, 18. April 2023, 14:11:53 CEST schrieb Javier Martinez Canillas: > > >> Heiko Stübner <heiko@xxxxxxxxx> writes: > > >> > Am Dienstag, 4. April 2023, 14:52:02 CEST schrieb Peter Geis: > > >> >> On Tue, Apr 4, 2023 at 3:55 AM Heiko Stübner <heiko@xxxxxxxxx> wrote: > > >> >> > Am Montag, 3. April 2023, 19:59:37 CEST schrieb Javier Martinez Canillas: > > >> >> > > This baud rate is set for the device by mainline u-boot and is also what > > >> >> > > is set in the Pinebook Pro Device Tree, which is a device similar to the > > >> >> > > PinePhone Pro but with a different form factor. > > >> >> > > > > >> >> > > Otherwise, the baud rate of the firmware and Linux don't match by default > > >> >> > > and a 'console=ttyS2,1500000n8' kernel command line parameter is required > > >> >> > > to have proper output for both. > > >> >> > > > >> >> > The interesting question is always if this will break someone else's setup. > > >> >> > I've never really understood the strange setting of 1.5MBps, but on the > > >> >> > other hand it _is_ a reality on most boards. > > >> > > > >> >> The 1.5M baud is default because the clock structure on rockchip > > >> >> devices does not allow a clean 115200 baud. By attempting to force > > >> >> 115200, it will always be slightly off (either low or high depending > > >> >> on how the driver decided to round). If this actually causes any > > >> >> problems is the subject of much debate. > > >> > > > >> > thanks so much for this piece of clock-detail. As I wrote, I never really > > >> > understood the why _before_ but also never cared that much to dive > > >> > into it and find out. > > >> > > > >> > So your explanation closes one knowledge gap in my head. > > >> > > > >> > Thanks a lot :-) > > >> > > >> Did you make a decision about this? I guess the clock explanation is yet > > >> another argument in favour of switching the PPP to a 1.5 Mbps baud rate ? > > > > > > Sorry, but no decision made here. Either way it's breaking for someone, > > > which makes this quite hard. > > > > > > > Another ping on this patch. > > > > > The rate accuracy is the one side, the two-boot issue is the other side. > > > And mainline u-boot (and levinboot - whatever that is) provides a 3rd side. > > > > > > People starting with the phone probably won't replace the bootloader > > > in a first step but instead might play with a system image or newer kernel. > > > So if the uart will break for everyone using the default bootloader from > > > the factory that is somewhat bad. > > > > > > > Probably won't replace the DTB shipped with the firmware either? If one is > > replacing the firmware provided DTB witch the one in the mainline kernel, > > probably such person is also using mainline u-boot? > > Not necessarily. > > I.e. putting an extlinux.conf on an sd-card with a kernel-image and dtb > is not rocket science ;-) > > > > > I don't have a Pinephone Pro myself, so I really hoped for some Acks > > > or similar to appear in the meantime. > > > > > > > For someone like me who is only using mainline u-boot, linux, etc then > > having a consistent uart baud rate across all components is really useful. > > > > Otherwise I either have serial console for u-boot or the kernel, but can't > > have both working so is annoying. > > > > It would be good to have a definite answer on this. Since every time that > > I try to hack on my PPP, I end changing my DTS and remember this patch :) > > So far people only reported "breaks my setup". I'm in a pickle here ;-) . > Without anybody saying "I want to also move into this direction" I really > feel I should not merge a patch that breaks other peoples setups. Well, I'd prefer 1.5M baud rate as it is more consistent with other Rockchip boards and it makes for a much more usable terminal experience when logged in, it also doesn't affect boot times when serial is enabled with a high loglevel and console on serial as 115200 does. Though I'm just fine with using kernel's cmdline to set a baud rate. *shrugs* Best Regards, Maya Matuszczyk pt., 28 lip 2023 o 21:00 Heiko Stuebner <heiko@xxxxxxxxx> napisał(a): > > Hi Javier, > > Am Samstag, 22. Juli 2023, 01:06:54 CEST schrieb Javier Martinez Canillas: > > Heiko Stübner <heiko@xxxxxxxxx> writes: > > > Am Dienstag, 18. April 2023, 14:11:53 CEST schrieb Javier Martinez Canillas: > > >> Heiko Stübner <heiko@xxxxxxxxx> writes: > > >> > Am Dienstag, 4. April 2023, 14:52:02 CEST schrieb Peter Geis: > > >> >> On Tue, Apr 4, 2023 at 3:55 AM Heiko Stübner <heiko@xxxxxxxxx> wrote: > > >> >> > Am Montag, 3. April 2023, 19:59:37 CEST schrieb Javier Martinez Canillas: > > >> >> > > This baud rate is set for the device by mainline u-boot and is also what > > >> >> > > is set in the Pinebook Pro Device Tree, which is a device similar to the > > >> >> > > PinePhone Pro but with a different form factor. > > >> >> > > > > >> >> > > Otherwise, the baud rate of the firmware and Linux don't match by default > > >> >> > > and a 'console=ttyS2,1500000n8' kernel command line parameter is required > > >> >> > > to have proper output for both. > > >> >> > > > >> >> > The interesting question is always if this will break someone else's setup. > > >> >> > I've never really understood the strange setting of 1.5MBps, but on the > > >> >> > other hand it _is_ a reality on most boards. > > >> > > > >> >> The 1.5M baud is default because the clock structure on rockchip > > >> >> devices does not allow a clean 115200 baud. By attempting to force > > >> >> 115200, it will always be slightly off (either low or high depending > > >> >> on how the driver decided to round). If this actually causes any > > >> >> problems is the subject of much debate. > > >> > > > >> > thanks so much for this piece of clock-detail. As I wrote, I never really > > >> > understood the why _before_ but also never cared that much to dive > > >> > into it and find out. > > >> > > > >> > So your explanation closes one knowledge gap in my head. > > >> > > > >> > Thanks a lot :-) > > >> > > >> Did you make a decision about this? I guess the clock explanation is yet > > >> another argument in favour of switching the PPP to a 1.5 Mbps baud rate ? > > > > > > Sorry, but no decision made here. Either way it's breaking for someone, > > > which makes this quite hard. > > > > > > > Another ping on this patch. > > > > > The rate accuracy is the one side, the two-boot issue is the other side. > > > And mainline u-boot (and levinboot - whatever that is) provides a 3rd side. > > > > > > People starting with the phone probably won't replace the bootloader > > > in a first step but instead might play with a system image or newer kernel. > > > So if the uart will break for everyone using the default bootloader from > > > the factory that is somewhat bad. > > > > > > > Probably won't replace the DTB shipped with the firmware either? If one is > > replacing the firmware provided DTB witch the one in the mainline kernel, > > probably such person is also using mainline u-boot? > > Not necessarily. > > I.e. putting an extlinux.conf on an sd-card with a kernel-image and dtb > is not rocket science ;-) > > > > > I don't have a Pinephone Pro myself, so I really hoped for some Acks > > > or similar to appear in the meantime. > > > > > > > For someone like me who is only using mainline u-boot, linux, etc then > > having a consistent uart baud rate across all components is really useful. > > > > Otherwise I either have serial console for u-boot or the kernel, but can't > > have both working so is annoying. > > > > It would be good to have a definite answer on this. Since every time that > > I try to hack on my PPP, I end changing my DTS and remember this patch :) > > So far people only reported "breaks my setup". I'm in a pickle here ;-) . > Without anybody saying "I want to also move into this direction" I really > feel I should not merge a patch that breaks other peoples setups. > > > Heiko > > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-rockchip
