On Wed, Aug 14, 2013 at 10:44:22AM -0600, Stephen Warren wrote:
> On 08/14/2013 09:13 AM, Tom Rini wrote:
> > Hey all,
> >
> > Do we have a document yet talking about the best practices for how we
> > would like a hardware vendor to ship, store and possibly update a device
> > tree, on the hardware? "However they like" seems likely to invite
> > problems down the line with everyone trying their own thing. Thanks!
>
> I don't believe there's any written guidance, no.
>
> The initial guidance Grant gave (IIRC at the first Linaro Connect last
> year, or perhaps the ARM workshop in Prague, or perhaps also in various
> ARM kernel list threads?) was that the DTBs should be stored/accessed in
> exactly the same way as the kernel, which on many systems implies it's a
> file in /boot (although MTD partitions, ... are also possible kernel
> locations). The idea here was to explicitly make upgrading the DTB as
> easy as upgrading the kernel, and explicitly without having to upgrade
> any firmware, since that's a more dangerous process in most cases.
>
> Now perhaps that advice was only intended to apply very early on when DT
> was really new on ARM, and has "aged out" by now? If so, I don't recall
> that every being explicitly mentioned or communicated later.
[snip out a bit more of Stephen's answer]
Yes, this notion certainly is the opposite of what was suggested on the
cross-distro list, both as part of a "what should a bootloader provide
to get commodity distros to support the board" thread and the "where
should a device tree live in the filesystem" thread. Cc'ing them now
because this is one of those things that feels like it needs solving,
solving soon, and done in a way the least number of folks get surprised
about it.
--
Tom
Hi all,
I wanted to start a discussion on defining a unified feature set that
makes it simpler for the different distros to support ARM systems using
u-boot. I have based a lot of my thoughts on how calxeda ship their
systems configured as it works fairly well, recently i sent in a patch
implementing most of what I would like to see for the wandboard[1]
right or wrong we want things to be simple for the user and to largely
look like a linux system on x86 would. The user and distro should never
need to worry about memory locations
so this would mean similar partitioning. i.e. /boot on ext4 root and
swap on lvm or as raw partitions. people should be able to have
just / on ext4 also. Down the road xfs /boot support would be a nice to
have.
pxe boot suport, two reasons, one is to be able to easily network boot
the distro installer, the other is to use sysboot support post install
with a extlinux.conf file to specify the kernel, initrd and bootargs
bootz and raw initrd support. not having to wrap kernels and initrds
really is a must. raw initrd support means that its much simpler for a
user to rebuild an initramfs if needed and bootz means we do not need
to worry about making sure that we specify the correct addresses to
load the kernel to when calling mkimage.
when it comes to memory addressing a distro and user shouldn't need to
know anything. Ideally u-boot will auto allocate addresses based on the
size of loaded objects. starting with a base address internal to u-boot
you load a kernel, when loading an initramfs u-boot automatically
calculates an address that ensures it does not overlap with the kernel.
same for a fdt if loaded. I say auto calculated because what we think
today will be enough room may not be tomorrow, dynamically calculating
gives the flexibility for whatever may come.
fdt will be automatically loaded and provided fedora ships dtbs
in /boot/dtb-<kernelver>/ I am not sure where other distros provide
them, however u-boot should automatically load dtb and provide access
to a fdt in a ${fdt_addr} variable that can be used by pxe_cmd but still
allows the user to specify their own in extlinux.conf if desired.
ideally the devicetree files need to be decoupled from the kernel,
along the lines of what is being discussed in the kernel now[2].
Distros should agree on a single location for the dtbs to be
placed. /boot/dtb/ or /boot/dtbs/ are probably good locations. u-boot
can then look in the path with and without /boot
output and input should happen on all possible devices and not just the
serial console. If a user has a trimslice with only a HDMI monitor and
usb keyboard they should be able to see the menu listing their possible
kernels and be able to choose which one they want to boot.
longer term being able to edit the boot arguments should also be an
option with the menu functionality.
"""
# extlinux.conf generated by anaconda
ui menu.c32
menu autoboot Welcome to Fedora. Automatic boot in # second{,s}. Press
a key for options. menu title Fedora Boot Options.
menu hidden
timeout 60
#totaltimeout 9000
label Fedora (3.9.9-302.fc19.armv7hl) 19 (Schrödinger’s Cat)
kernel /vmlinuz-3.9.9-302.fc19.armv7hl
append console=ttyAMA0,115200
root=UUID=04f8c4be-2890-4d26-bb79-e5555060a142 ro rhgb quiet
LANG=en_US.UTF-8 initrd /initramfs-3.9.9-302.fc19.armv7hl.img
label Fedora (3.9.4-301.fc19.armv7hl) 19 (Schrödinger’s Cat)
kernel /vmlinuz-3.9.4-301.fc19.armv7hl
append console=ttyAMA0,115200
root=UUID=04f8c4be-2890-4d26-bb79-e5555060a142 ro rhgb quiet
LANG=en_US.UTF-8 initrd /initramfs-3.9.4-301.fc19.armv7hl.img """
the above is an example of a extlinux.conf file on a fedora 19 system
that works with the u-boot as shipped by calxeda on thier highbank
energy cards. some of the valid extlinux options written out by
anaconda cause noise on ARM as they are not implemented longer term it
would be good to deal with them correctly.
"""
Ignoring unknown command: ui
Ignoring malformed menu command: autoboot
Ignoring malformed menu command: hidden
Fedora Boot Options.
1: Fedora (3.9.9-302.fc19.armv7hl) 19 (Schrödinger’s Cat)
2: Fedora (3.9.4-301.fc19.armv7hl) 19 (Schrödinger’s Cat)
Enter choice:
"""
is the output on boot, the user can then enter 1 or 2 to select a
kernel to boot. if nothing is selected the first option is booted after
the timeout expires.
What this gets us in the end is that with a unified kernel, device tree
and u-boot implementing the system specific knowledge, supporting new
ARM systems is along the same lines as supporting new x86 systems. Get
the drivers and platform support in the mainline kernel and as long as
the Distro enables it it will just work in the next OS release. The one
part then that we as Distro's need to do is to ensure we install
u-boot into the disk correctly for the board in question if it is a
system that does not ship with some kind of storage for u-boot. If it
is a system with NOR, Nand, SPI storage for u-boot it is then entirely
in the vendors hand, and assuming that they implement everything, all
distros will be able to simply support them. Giving users and vendors
more choice in what to run on their hardware.
I may not be entirely clear here and there may be things I am missing,
I feel it is a good place to start the discussion.
Regards
Dennis
[1] http://lists.denx.de/pipermail/u-boot/2013-July/159522.html
[2] https://lwn.net/Articles/560523/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
As part of the unified features in u-boot thread I said that I would
work to get distros to agree to a common location that u-boot will be
able to assume exists for it to transparently load dtbs from for us.
I would like to propose /boot/dtb/
I think it needs to be in /boot/ to allow for booting from systems
with / and /boot on separate partitions. I believe Ubuntu and hence
Debian put them in /lib somewhere today. Fedora puts them
in /boot/dtb-<kernel version>. im not sure where the other distros put
them.
I think that until they are decoupled from the kernel Fedora would
have /boot/dtb be a symlink to the latest installed kernel. once its
decoupled it would be the location where the dtbs are installed.
Can We all agree to implement ensuing that dtb files will be available
in /boot/dtb/
Regards
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlIAG/wACgkQkSxm47BaWfcq2ACdFrw5/68I9+A2ls2htra3fMcN
rN4An1dlK4H8vm4jlJEEYcdp26tRDgJ9
=SXTs
-----END PGP SIGNATURE-----
