head -r325700: BPI-M3 u-boot vs. FreeBSD kernel/loader and finding sinovoip-bpi-m3.dtb: fails [ -r324743 head worked]

[Mark Millard]

[Kyle's Makefile update is not a fix
for what I reported.]

On 2017-Nov-12, at 7:43 AM, Kyle Evans <kevans at freebsd.org> wrote:

> On Nov 12, 2017 1:06 AM, "Mark Millard" <markmi at dsl-only.net> wrote:
> On a BPI-M3 in u-boot:
> 
> => printenv
> . . .
> fdt_addr_r=0x43000000
> fdtcontroladdr=bbf42f68
> fdtfile=sinovoip-bpi-m3.dtb
> . . .
> 
> But for -r325700 /boot/dtb/sinovoip-bpi-m3.dtb
> was not found (unlike for -r324743 where the
> BPI-M3 had been before):
> 
> No valid d™evice tree blob found!
> 
> Interesting- I had a similar issue, but it was presumably due to having locally updated the u-boot port to use u-boot-master.
> 
> IIRC, I worked around this for the time being by adding a LINKS entry in the same makefile:
> 
> sinovoip-bpi-m3.dtb sun8i-a83t-sinovoip-bpi-m3.dtb
> 
> Or was it sunxi-? I believe it matched a .dts in gnu/, so I would double check that- not at a usable machine at the moment.

[I was not using anything based on u-boot-master.
I was using: sysutils/u-boot-sinovoip-bpi-m3 which
has not been updated.]

It was sun8i- but that change does not fix
my example, quoting a different message. . .
[The wording was not explicit about the .dtb were
what I hard linked, not source code files.]

QUOTE
I also learned that apparently Linux has progressed
its naming from:

sun8i-a83t-sinovoip-bpi-m3.dt*

to:

sun8i-a83t-bananapi-m3.dt*

(Hard linking those names to sinovoip-bpi-m3.dtb
did not help prior to the loader.conf addition.)
END QUOTE.

And, in fact, as I reported u-boot reported the
name in fdtfile:

fdtfile=sinovoip-bpi-m3.dtb

but the FreeBSD code did not pick it up:

/usr/src/sys/boot/uboot/fdt/uboot_fdt.c has
fdt_platform_load_dtb that has:

        s = getenv("fdt_file");
        if (s == NULL)
                s = ub_env_get("fdtfile");
        if (s == NULL)
                s = ub_env_get("fdt_file");
        if (s != NULL && *s != '\0') {
                if (fdt_load_dtb_file(s) == 0) {
                        printf("Loaded DTB from file '%s'.\n", s);
                        rv = 0;
                }
        }

In -r324743 the message from fdt_load_dtb_file printed
to the console and then the above "Loaded DTB . . ."
message printed there. So this code block was making
the binding before.

I suspect that was from the ub_env_get("fdtfile")
finding fdtfile above. But in -r325700 it does not
work for some reason.

There is earlier code:

        s = ub_env_get("fdt_addr_r");
        if (s == NULL)
                s = ub_env_get("fdtaddr");
        if (s == NULL)
                s = ub_env_get("fdt_addr");
        if (s != NULL && *s != '\0') {
                hdr = (struct fdt_header *)strtoul(s, &p, 16);
                if (*p == '\0') {
                        if (fdt_load_dtb_addr(hdr) == 0) {
                                printf("Using DTB provided by U-Boot at "
                                    "address %p.\n", hdr);
                                return (0);
                        }
                }
        }

that overall apparently ignores
the:

fdt_addr_r=0x43000000

for some reason, even in the older -r324743.


> Either way, this alone caused a recent -HEAD to boot. This is what I currently boot on my bpi-m3: https://github.com/kevans91/freebsd/tree/clkng

I'm not sure that it would for -r325700+ . What broke
may have happened between your test and my test. So,
knowing what you booted with might help narrow the
range if you ended up trying something after -r324743
--but after the static-images-are-broken issue was
fixed [/sbin/init working again].

===
Mark Millard
markmi at dsl-only.net