Date:   Mon, 19 Oct 2020 12:08:40 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Michal Suchánek <msuchanek@...e.de>
Cc:     linux-arm-kernel@...ts.infradead.org,
        Rob Herring <robh+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: dts: sun8i: h2+: Enable optional SPI flash on
 Orange Pi Zero board

On Mon, Oct 12, 2020 at 07:03:25PM +0200, Michal Suchánek wrote:
> > > > 
> > > > > Also the boards that do not have the flsh are either broken or
> > > > > obsolete.
> > > > 
> > > > Making general statements without arguments doesn't really make it true
> > > > though. Plenty of boards to have flash and are neither broken nor
> > > > obsolete.
> > >
> > > Cannot parse this.
> > 
> > "Plenty of boards do not have flash and are neither broken nor obsolete"
> The product description of Orange Pi Zero clearly states there is a
> flash memory: http://www.orangepi.org/orangepizero/
> 
> When you order an Orange Pi Zero it comes with a flash memory. That is
> not what the device tree describes. The device tree is supposed to
> descrbe the hardware. If it does not it is broken.
> 
> If you have a board without a flash memory I do not know what it is but
> it is clearly not an Orange Pi Zero because it comes with one.

If you're buying it today, yes. If you take a random Orange Pi Zero that
has been sold at any point in time, you cannot make that statement.

> > > > 
> > > > > So most of the time enabling the flash chip is the right thing.
> > > > > 
> > > > > Or do we need two DTBs like sun8i-h2-plus-orangepi-zero.dts and
> > > > > sun8i-h2-plus-orangepi-zero-no-spi-nor.dts
> > > > 
> > > > No, you need sun8i-h2-plus-orangepi-zero plus an overlay for the
> > > > SPI-NOR.
> > >
> > > The flash is part of the board.
> > 
> > Not always though.
> No, it always comes with one. You must be speaking of a different board
> then.
> > 
> > > There is no need for an overlay.
> > 
> > Overlays are here to deal with the "not always though" situation...
>
> There are no overlays in the kernel. Please show me tho code in the
> kernel for handling overlays.

You're the one that mentioned the kernel here, but here you are:
https://elixir.bootlin.com/linux/v5.9.1/source/include/linux/of.h#L1455

And a driver using it:
https://elixir.bootlin.com/linux/v5.9.1/source/drivers/gpu/drm/rcar-du/rcar_du_of.c#L44

> > > And overlays don't exist.
> > 
> > If you want to believe that, please go ahead.
> > 
> > But there's support for it in libfdt, and you can either apply them
> > directly through the U-Boot command line, or bundle them in a FIT image.
>
> And as you state the user ususally does not know which version of the Pi
> they have. How are they supposed to know that they should apply an
> overlay through u-boot commandline (if they even get to see one)

Documentation?

> bundle them in a FIT image (if they are even using a FIT image).

That would be the distro's job, not the user's.

> I am doing neither. I boot a standard distribution kernel from EFI
> grub.
> 
> I understand that it would be nice to support two almost identical
> boards with a single device tree. However, if an error about missing
> flash memory is not acceptable, and the kernel does not support
> enabling the flash memory dynamically we need two device trees then.

You keep moving the goalposts, but U-boot is perfectly able to apply an
overlay automatically at boot without the user's intervention. We're
already making it select various DTs for the pine64 and pine64+ to have
a single image for both, or for the pinephone variants.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)

Powered by blists - more mailing lists