Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221221105402.6598-1-markuss.broks@gmail.com>
 <CAMj1kXGUC7dsSwVEUsAMeAoqDYtbqrM7SDOJTXbPfi-LrcSk9g@mail.gmail.com> <97639381-2558-4cf5-75b0-7f80f0393b16@gmail.com>
In-Reply-To: <97639381-2558-4cf5-75b0-7f80f0393b16@gmail.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Tue, 10 Jan 2023 15:32:41 +0100
Message-ID: <CAMj1kXE-GMxemfDA=CLvLUZeN7fHv6Ds2L2a2swYea8Q9U+b8g@mail.gmail.com>
Subject: Re: [PATCH v3 0/3] Add generic framebuffer support to EFI earlycon driver
To:     Markuss Broks <markuss.broks@gmail.com>
Cc:     linux-kernel@vger.kernel.org,
        Jami Kettunen <jami.kettunen@protonmail.com>,
        Jonathan Corbet <corbet@lwn.net>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        Helge Deller <deller@gmx.de>, Borislav Petkov <bp@suse.de>,
        "Paul E. McKenney" <paulmck@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Will Deacon <will@kernel.org>,
        Randy Dunlap <rdunlap@infradead.org>,
        Muchun Song <muchun.song@linux.dev>,
        Damien Le Moal <damien.lemoal@opensource.wdc.com>,
        Kim Phillips <kim.phillips@amd.com>, linux-doc@vger.kernel.org,
        linux-efi@vger.kernel.org, linux-serial@vger.kernel.org,
        linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 23 Dec 2022 at 15:58, Markuss Broks <markuss.broks@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@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.