[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netbsd-port-arm
Subject:    Re: graphic drivers and simplefb
From:       Manuel Bouyer <bouyer () antioche ! eu ! org>
Date:       2018-04-05 13:21:19
Message-ID: 20180405132118.GA21351 () mail ! soc ! lip6 ! fr
[Download RAW message or body]

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 <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--
[prev in list] [next in list] [prev in thread] [next in thread]