Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: graphic drivers and simplefb



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@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index