static dtb location

[Dennis Gilmore]

-----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. 

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.

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.

Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJSsjxsAAoJEH7ltONmPFDRRwMP/3qFR4UseLGl/GpEQZ3yWVdb
GI9zKnrXIZrc0CMvpmAEdQMn/fPxKK6LP1kIBGD2HxFISMc2rsK2mJd5od1ABJPv
0/jjZTYIV3m1dAsGrUzeIURnYAph1MUeKy4pVZ83tYfezTsS7vCrj7B/QE+aLcMn
4u+Hq1WRX1aOV1XjekLOjsewVTdc0WH6bIxOjLGzu32VEZi2CM3B+BcGmU348ufw
9MIVKsOxn02ABcU/CS4OPPpFVrkQ+Uy4twGexHkAelQSBbzcpZv9f85qkNqshMBM
PFhT+IG2DI02J1p8EPwIcpvCFtPZrg31sKbQAPlU2x5ebIEmh8pLtqBth+lAkEKP
p9soLsRz9EZEe3EApU+Vl7k4pa01rubg5x97Ms+yMQ8+Gb7mKX4NlKAhvZ8SYyvf
waecY1h+gpFhf6L0HgoJqVZDqo28cUj1Ub4WDCKjWbtTZe+QWB+B/PYpK0J5THcT
zZgzBry9lIeDrFbQsGasky6WwRGcNrHwYLDpJYXE4ze+R+cI/T7zGPK0eUqPNlCi
yA088UTZwyrRQj38RSYVQtfP7oWy5uicwkLYKkP8vp3Ii6pQwCZEUqDxDsONATkq
XIXdnYzLXFab1a+j/+1n9gWImzC67oCeAbP1GDh+Lw9D5dhkiFCWJbKn7p3zr3te
171Dsn+iqoGeF9TApLUH
=1tTG
-----END PGP SIGNATURE-----