On Thu, Apr 05, 2018 at 10:10:57AM -0300, Jared McNeill wrote: > [...] > > The serial port will only attach as console if you have chosen it to be the > console (stdout-path). I want to solve this problem the right way, not > relying on device attach order, because device order hacks become > unmanageable when you are dealing with multiple SoC families, shared > drivers, and GENERIC kernels.
if we want a kernel that supports multiple SoC families that's probably true. > > We need a solution that covers these use cases: > > - Console is UART (may or may not have display capabilities) > - Console is FB (laptop, tablet, etc where UART is difficult to access) > - Console device can be either UART or FB (like a dev board, where we > support both with WSDISPLAY_MULTICONS) > > Currently the armv7.img/arm64.img configs use 'console=fb' to get correct > behavior in these 3 cases. This setup has been working well so far, but > there is definite room for improvement. I just want to make sure that the > existing functionality doesn't get broken. The problem is that 'console=fb' relies on the fact that u-boot did set up a /chosen/framebuffer node. But in my case it doesn't because it doens't support my graphic setup. But, in my case, I could change stdout-path in my device tree, and implement 'console=serial0' in bootargs to reset it to serial port at boot time. If I want to start with serial console and then switch to graphics, I can change my kernel config to have the serial port probed sooner, for the time being. Would that be OK with you ? -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --