All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kiper <dkiper@net-space.pl>
To: "Mislav Stublić" <Mislav.Stublic@logicbricks.com>
Cc: "grub-devel@gnu.org" <grub-devel@gnu.org>
Subject: Re: [PATCH] loader/i386/linux: Add device tree support
Date: Thu, 7 Oct 2021 15:26:37 +0200	[thread overview]
Message-ID: <20211007132637.3d2desyqo6ooyn3w@tomti.i.net-space.pl> (raw)
In-Reply-To: <6DF2B90AE826754EAEE52A5F86D6E41C7B776F39@mail.xylon.local>

Hi Mislav,

First of all, please do not top post and wrap your long lines...

On Thu, Oct 07, 2021 at 09:23:14AM +0000, Mislav Stublić wrote:
> Hi,
>
> There is a lot of duplication as I have used existing implementation
> as a reference (arm, aarch64 and fdt). But refactoring existing
> implementation atop of implementing x86 didn’t seem realistic as those
> modules are quite different... at least when I first looked at this.
> My biggest question is how to unify existing memory allocation
> procedures as those are different, at least  in a sense x86 has
> relocator and the setup around it (or can/should this unification be
> avoided). Also, it seems there is a lot of divergence in UEFI
> implementations for which I'm not sure it can be avoided without
> bigger refactor of both UEFI and x86 code. But I would need to think
> some more on your suggestion, maybe it's not so complicated.

I am not sure you understand what I want. I do not ask you to unify UEFI
device tree code with non-UEFI device tree code. This can be difficult (but
not impossible). So, I want to have two device tree implementations: one
for UEFI platforms and another for non-UEFI platforms (when you start
working on this there is a chance we will see how to merge both into one;
though let's start with two implementations for simplicity). Then every
architecture/CPU implementation should use the former or the latter.
Does it sound OK for you?

Daniel

> Mislav
>
> > -----Original Message-----
> > From: Daniel Kiper [mailto:dkiper@net-space.pl]
> > Sent: Wednesday, October 06, 2021 2:29 PM
> > To: Mislav Stublić
> > Cc: grub-devel@gnu.org
> > Subject: Re: [PATCH] loader/i386/linux: Add device tree support
> >
> > Hi Mislav,
> >
> > On Tue, Sep 21, 2021 at 03:37:45PM +0000, Mislav Stublić wrote:
> > > Hi,
> > >
> > > This implements device tree support for x86. Unfortunately I haven't
> > > been able to test this on latest master but I have tested against 2.04
> > > and it works fine. I will test on master later but I wanted to get
> > > some initial comments if this is going in the right direction. What I
> > > haven't tested is firmware DTB loading support which only calls
> > > grub_efi_get_firmware_fdt from kern/efi implementation as I don't have
> > > hardware to test this scenario.
> >
> > I skimmed through your patch and it seems to me you are duplicating at
> > least some code from grub-core/loader/arm/linux.c. I would do this a bit
> > differently. First of all I would factor out non-UEFI device tree code
> > from grub-core/loader/arm/linux.c to a separate module. This should be
> > a separate patch. Then I would try to unify the interface for UEFI and
> > non-UEFI device tree code (again, separate patch). Of course if needed.
> > Then the last patch should add device tree support to the x86. If you
> > have any questions drop me a line.
> >
> > Anyway, thank you for taking a stab at this.
> >
> > Daniel


      reply	other threads:[~2021-10-07 13:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-21 15:37 [PATCH] loader/i386/linux: Add device tree support Mislav Stublić
2021-09-21 19:05 ` Vladimir 'phcoder' Serbinenko
2021-09-22  9:55   ` Mislav Stublić
2021-10-06 12:29 ` Daniel Kiper
2021-10-07  9:23   ` Mislav Stublić
2021-10-07 13:26     ` Daniel Kiper [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211007132637.3d2desyqo6ooyn3w@tomti.i.net-space.pl \
    --to=dkiper@net-space.pl \
    --cc=Mislav.Stublic@logicbricks.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.