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
Attachment:
signature.asc
Description: PGP signature
