Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Dec 2017 12:25:10 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Daniel Braniss <danny@cs.huji.ac.il>
Cc:        Ian Lepore <ian@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: ubldr question
Message-ID:  <CANCZdfoNGhK%2BK8K2DWXa-HKUYkMz%2BR7U=VBZG_cio3-bN3=J-g@mail.gmail.com>
In-Reply-To: <D27D8237-ED2D-4DA3-8EBC-707ECDAC897A@cs.huji.ac.il>
References:  <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> <D27D8237-ED2D-4DA3-8EBC-707ECDAC897A@cs.huji.ac.il>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 17, 2017 at 12:19 PM, Daniel Braniss <danny@cs.huji.ac.il>
wrote:

>
>
> > On 17 Dec 2017, at 19:02, Ian Lepore <ian@freebsd.org> wrote:
> >
> > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote:
> >> Hi,
> >> in the past there was CONFIG.TXT and/or UENV.TXT where I could
> >> override the
> >> default .dtb file set by uboot, but now it seems these files are
> >> either not read, or the
> >> command has changed.
> >>
> >> So, apart from stoping the loader, and typing =E2=80=98env set fdtfile
> >> xxx.dtb=E2=80=99
> >> is there another way?
> >>
> >> cheers,
> >>      danny
> >>
> >
> > You should be able to "saveenv" after making your change.
> >
> > The uEnv.txt that used to be supported was to make it possible to
> > programatically change the boot behavior from freebsd userland.  That
> > feature got lost when the uboot ports were all rewritten to use a
> > default environment (boot scripts and all) for freebsd that is
> > basically identical to what linux uses.  It's a lot less work for the
> > port maintainers, but we lost some functionality along the way.
> >
> > =E2=80=94 Ian
>
> thank sIan,
> that did it, now if uboot could figure out what SOC it booted from and
> choose the appropriate
> dtb file would be great!
>

It's already supposed to do that since we have a different u-boot for each
board (or in some cases family of boards). The SoC is insufficient to know
which DTB to load (otherwise we'd just have the tables in the kernel and
not bother with the added complication).

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoNGhK%2BK8K2DWXa-HKUYkMz%2BR7U=VBZG_cio3-bN3=J-g>