[PATCH v3 0/3] Add generic framebuffer support to EFI earlycon driver

Ard Biesheuvel ardb at kernel.org
Tue Jan 10 14:32:41 UTC 2023


On Fri, 23 Dec 2022 at 15:58, Markuss Broks <markuss.broks at gmail.com> wrote:
>
> Hi Ard,
>
> On 12/23/22 16:42, Ard Biesheuvel wrote:
> > (cc Andy)
> >
> >
> > On Wed, 21 Dec 2022 at 11:54, Markuss Broks <markuss.broks at gmail.com> wrote:
> >> Make the EFI earlycon driver be suitable for any linear framebuffers.
> >> This should be helpful for early porting of boards with no other means of
> >> output, like smartphones/tablets. There seems to be an issue with early_ioremap
> >> function on ARM32, but I am unable to find the exact cause. It appears the mappings
> >> returned by it are somehow incorrect, thus the driver is disabled on ARM.
> > The reason that this driver is disabled on ARM is because the struct
> > screen_info is not populated early enough, as it is retrieved from a
> > UEFI configuration table.
>
> I believe I must be hitting some other bug then, since my driver should
> not use `struct screen_info` when the arguments are specified manually
> (e.g. in device-tree or in kernel command line options), and it still is
> broken on ARM when they are.

Define 'broken'

> I got it to work on ARM when I moved the
> early console initialization later into the kernel booting process, but
> that mostly defeats the purpose of early console driver, I believe. I've
> been thinking that it could be some stuff not getting initialized early
> enough indeed, but I've got no clue what could it be.
>

This is likely due to the fact that the ARM init code sets up the PTE
bits for various memory types, and using them beforehand is likely to
result in problems.


More information about the dri-devel mailing list