Date: Sun, 12 Nov 2017 08:36:23 -0800 From: Mark Millard <markmi@dsl-only.net> To: Kyle Evans <kevans@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, freebsd-arm@freebsd.org Subject: Re: head -r325700: BPI-M3 u-boot vs. FreeBSD kernel/loader and finding sinovoip-bpi-m3.dtb: fails [ -r324743 head worked] Message-ID: <6CFB609E-DE25-492D-96AC-782010FE6EF9@dsl-only.net> In-Reply-To: <CACNAnaE7G0LWGENXF6oaEug5t8A1Kp7Fz690P9%2Bo02-DphzF-A@mail.gmail.com> References: <8ECC1284-8843-420E-8496-9F33DF979A02@dsl-only.net> <CACNAnaE7G0LWGENXF6oaEug5t8A1Kp7Fz690P9%2Bo02-DphzF-A@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[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
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6CFB609E-DE25-492D-96AC-782010FE6EF9>