static dtb location

[Josh Boyer]

On Wed, Dec 18, 2013 at 7:23 PM, Dennis Gilmore <dennis at ausil.us> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> El Wed, 18 Dec 2013 18:36:27 -0500
> Josh Boyer <jwboyer at gmail.com> escribió:
>> On Wed, Dec 18, 2013 at 6:26 PM, Dennis Gilmore <dennis at ausil.us>
>> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > Hi all,
>> >
>> > Back in August I started a thread[1] on the cross-distro list at
>> > linaro on standardising the location of dtb files. While tehre was
>> > not a lot fo input there was a consensus to use /boot/dtb/ as the
>> > location. since the dtb generation is still tied to kernel
>> > building. I would like to have us have the most recently installed
>> > kernel link its dtb directory to /boot/dtb/ I am working on a
>> > change for Fedora 21 to get u-boot that we provide loading the dtb
>> > automatically and there is no way that ive worked out to have
>> > u-boot work out the path as they exist today.
>>
>> Can you provide a little more context to those of us that don't have a
>> clue as to what you're talking about?
>>
>> Looking in koji, it seems the arm kernels install dtbs in:
>>
>> /boot/dtb-{kver}.armv7hl/
>>
>> Are you asking to have them installed in /boot/dtb/ instead?  If so,
>> wouldn't /boot/dtb/{kver}/ work, much like we do for modules in
>> /lib/modules/{kver} ?
>>
>> I'm not really understanding what you mean by "link its dtb directory
>> to /boot/dtb/".  If you mean making /boot/dtb a symlink to the
>> dtb-{kver} directory on each kernel install, that seems a bit
>> suboptimal.  There's no guarantee that kernel will boot, or that the
>> dtbs contained in the directory are working.  Blindly changing the
>> symlink seems wrong, plus there is a lot of headache on kernel
>> uninstall to restore it to something (which might not be the previous
>> kernel at install time).
>
> I need to hard code into u-boot a set of locations to try and load the
> dtb from i.e. /boot/dtb/ /dtb/
>
> bootcmd_disk=load ${boot_ifc} ${bootdevice}
> ${fdt_addr} /boot/dtb/${fdt_file}; load ${boot_ifc} ${bootdevice}
> ${fdt_addr} /dtb/${fdt_file};run bootcmd_disk_sysboot1; run
> bootcmd_disk_sysboot2;
>
> ${fdt_file} is a variable inside of u-boot that defines the dtb file to
> load.
>
> I want to make /boot/dtb a symlink to the dtb-{kver} directory.  I
> realise that its not really perfect until the kernel defines them as an
> ABI which seems to be the long term goal. In practice there has been a
> few times where you can not mix and match dtb and kernels. high bank
> for instance has a dtb built from 3.10 i think, there was a point a
> firmware update was needed toreplace the dtb because of an
> incompatability. in the f20 cycle i used the 3.12 dtb with 3.11 on my
> wandboard quad because it enabled more hardware support.

It would be rather difficult to do that sanely from a packaging
perspective.  You can blindly move the symlink on install, but what do
you do on uninstall?  You're basically left with leaving it alone
entirely because you have nothing to really determine what to point it
back to.  Which means you could wind up with a broken link if you try
to boot a kernel and it fails and then you uninstall that kernel.

> at some future date I expect that the dtbs will be detached from the
> kernel and packaged up separately. at which point things would be just
> fine. Maybe we should preempt that and split off the building of them
> today, either by having a kernel-dtb sub package, or pulling them out
> into their own package completely.

Splitting it out is probably the best way forward.  I'd suggest
building them in u-boot itself if you don't want to hassle with a
separate package, given that it is the thing that has the dependency.

> The other way to deal with it is much more invasive. It would mean
> adding a fdt line in extlinux.conf pointing at the dtb for the specific
> board and writing something so anaconda can work out when and how to
> add a fdt line, its not needed on some devices but would be needed on
> others. grubby would need some patching to update the fdt line
> correctly.

If splitting it out isn't feasible, then fixing the bootloader scripts
might be the second best solution.  It's more work overall, but the
correct solution isn't always the easiest.

josh