From: Tom Rini <trini@konsulko.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: u-boot@lists.denx.de, Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Subject: Re: [PATCH] bmips: Add Inteno XG6846 board
Date: Wed, 20 Sep 2023 14:55:47 -0400 [thread overview]
Message-ID: <20230920185547.GP305624@bill-the-cat> (raw)
In-Reply-To: <CACRpkdYqO1nH51VxjbpnPjaPy7eHaMDCSP5tWBDB1SB3R0cCcQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]
On Wed, Sep 20, 2023 at 08:51:07PM +0200, Linus Walleij wrote:
> On Wed, Sep 20, 2023 at 4:22 PM Tom Rini <trini@konsulko.com> wrote:
>
> > > + * This is a diet version of the device tree from Linux,
> > > + * suitable for U-Boot.
> > > + */
> >
> > We shouldn't need a diet version of the tree. If it's reasonably done
> > and stable in the kernel, we can even move towards just passing the
> > U-Boot tree along to Linux.
>
> The device tree is not stable in the kernel.
> It exists in OpenWrt and the creators of the bmips target are
> kind of absent for the moment. The reason it is not in Linux
> is that the "switch ethernet" driver and bindings need to be
> upstreamed before the device trees can be upstreamed.
>
> But I can try to bring in more of it for sure :)
Just like ARM the goal is just to drop in the kernel dts here.
> > > +++ b/board/inteno/xg6846/xg6846.c
> > > @@ -0,0 +1,6 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (C) 2023 Linus Walleij <linusw@kernel.org>
> > > + */
> > > +
> > > +#include <common.h>
> >
> > So basically just an empty object file. Can we just _not_ have
> > something here, if we perhaps don't set SYS_BOARD? I assume if there's
> > just nothing here the link rules fail.
>
> Admittedly my knowledge of U-Boot internals are not the
> best and this is a bit of a copy and paste job from
> board/comtrend/ar5387un/ar-5387un.c which looks like
> this and sets a bad example I suppose.
Yeah, I didn't know we had someone doing that already here, whoops.
> I guess you are asking me to modify U-Boots build system to
> make the whole .c and Makefile inside a board subdir optional
> so we can delete all such empty boardfiles?
Well, it'd sure be nice if we could avoid having a dummy C file. If
it looks like a nightmare once you take a peek, we can just live with
it.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2023-09-20 18:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-20 7:42 [PATCH] bmips: Add Inteno XG6846 board Linus Walleij
2023-09-20 14:22 ` Tom Rini
2023-09-20 18:51 ` Linus Walleij
2023-09-20 18:55 ` Tom Rini [this message]
2023-09-21 14:00 ` Daniel Schwierzeck
2023-09-21 15:53 ` Tom Rini
2023-09-21 17:25 ` Tom Rini
2023-09-25 13:56 ` Linus Walleij
2023-09-25 14:22 ` Tom Rini
2023-09-21 14:03 ` Daniel Schwierzeck
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=20230920185547.GP305624@bill-the-cat \
--to=trini@konsulko.com \
--cc=daniel.schwierzeck@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=u-boot@lists.denx.de \
/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.