Hi Tom,
On Fri, 3 Dec 2021 at 07:55, Tom Rini <tr...@konsulko.com> wrote:
>
> On Thu, Dec 02, 2021 at 08:58:54AM -0700, Simon Glass wrote:
>
> > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so
> > there are only three ways to obtain a devicetree:
> >
> > - OF_SEPARATE - the normal way, where the devicetree is built and
> > appended to U-Boot
> > - OF_EMBED - for development purposes, the devicetree is embedded in
> > the ELF file (also used for EFI)
> > - OF_BOARD - the board figures it out on its own
> >
> > The last one is currently set up so that no devicetree is needed at all
> > in the U-Boot tree. Most boards do provide one, but some don't. Some
> > don't even provide instructions on how to boot on the board.
> >
> > The problems with this approach are documented in another patch in this
> > series: "doc: Add documentation about devicetree usage"
> >
> > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board
> > can obtain its devicetree at runtime, even it is has a devicetree built
> > in U-Boot. This is because U-Boot may be a second-stage bootloader and its
> > caller may have a better idea about the hardware available in the machine.
> > This is the case with a few QEMU boards, for example.
> >
> > So it makes no sense to have OF_BOARD as a 'choice'. It should be an
> > option, available with either OF_SEPARATE or OF_EMBED.
> >
> > This series makes this change, adding various missing devicetree files
> > (and placeholders) to make the build work.
> >
> > Note: If board maintainers are able to add their own patch to add the
> > files, some patches in this series can be dropped.
> >
> > It also provides a few qemu clean-ups discovered along the way. The
> > qemu-riscv64_spl problem is fixed.
>
> Note that I can't run-time test this as the last patch fails to apply
> and is dependent on non-trivial missing changes ("/* The devicetree is
> typically appended to U-Boot */" doesn't exist at all in lib/fdtdec.c
> and that's part of the unchanging context where things fail to apply).
That code is the penultimate patch ("fdt: Drop remaining preprocessor
macros in fdtdec_setup()"). Did that patch apply OK? It is based on
-next and is at dm/ofb-working if you want to compare.
>
> So, here's my first bit of confusion. Today, I build for rpi_arm64 and
> no dtb files are built. I run this on my Pi 3 and everything works.
> With your series, I see all the dtbs have been built, and dts/dt.dtb and
> u-boot.dtb have a Pi 4 dtb in them. Should this even run now?
Yes, so long as OF_BOARD is enabled, which it is in this series. This
is basically the same as the situation with rpi3, except it uses
OF_EMBED (need to fix...)
If we get as far as the std passage stuff then it will print out the
source of the DT when it starts. If you like I could move three
patches into this series:
f88bd6a431a (HEAD -> ofb6) dm: core: Allow getting some basic stats
8121102a004 passage: Report the devicetree source
c9c791ddedf passage: Record where the devicetree came from
5a0b7505498 (dm/ofb-working, dm-public/ofb-working) fdt: Don't call
board_fdt_blob_setup() without OF_BOARD
Booting with rpi3 and rpi4 I get (see the "devicetree:" bit):
U-Boot 2022.01-rc3-00154-gf88bd6a431a (Dec 03 2021 - 08:32:41 -0700)
DRAM: 992 MiB
RPI 3 Model B (0xa02082)
Core: 61 devices, 11 uclasses, devicetree: embed
MMC: mmc@7e202000: 0, sdhci@7e300000: 1
Loading Environment from FAT... Unable to read "uboot.env" from
mmc0:1... In: serial
Out: vidconsole
Err: vidconsole
U-Boot 2022.01-rc3-00154-gf88bd6a431a (Dec 03 2021 - 08:33:43 -0700)
DRAM: 3.9 GiB
RPI 4 Model B (0xc03111)
Core: 197 devices, 13 uclasses, devicetree: board
MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... Unable to read "uboot.env" from
mmc0:1... In: serial
Out: vidconsole
Regards,
Simon
