Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 03/18/2013 12:04 PM, Pavel Machek wrote: On Mon 2013-03-18 17:57:46, Russell King - ARM Linux wrote: On Mon, Mar 18, 2013 at 06:49:32PM +0100, Pavel Machek wrote: What I wanted to say is that kernel build traditionaly produced something useful, something bootloader can actually boot. Currently, make uImage produces u-boot image. Please keep that capability. Unfortunately, there is a fundamental problem with uImage. It encodes the load address, and that is utterly incompatible with the goal of having a kernel image which boots on multiple platforms. uImage isn't going anywhere for the time being, but you will find that: a) recent kernels will just wrap the zImage without a DTB, so appended DTBs can't be used with it b) it won't work with MULTIPLATFORM-enabled kernels, unless you provide make with a LOADADDR= argument to tell it where the uImage is to be loaded - which is platform specific. (b) fundamentally can't be solved in kbuild. If you want to use uImage with multiple platforms from the same zImage, then you need to generate multiple uImage files with different load addresses. That's purely - and solely - down to the dysfunctional uImage format. I know. uImage is not perfect. But solution should be adopt a better format (ARM FIT?), not drop support for making useful images altogether as Olof proposed before. Raw zImage /is/ the useful format that should be adopted. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Mon, Mar 18, 2013 at 05:36:53PM +0100, Pavel Machek wrote: On Fri 2013-02-22 08:00:44, Olof Johansson wrote: On Wed, Feb 20, 2013 at 07:37:10PM -0600, Joel A Fernandes wrote: Any comments on this approach? Is it better to merge mkfitsrc.sh with mkuboot.sh? I know this was discussed quite extensively yesterday, but here is my take on it: Given the recent complications from multiplatform, we really saw a strong reason to _not_ do the final boot wrapping in the kernel build system. Produce the zImage and the DTB files, and have a surrounding script that bundles the two in a format that your particular device needs. Most distros have scripts to handle the make install step of a kernel build. That's where this belongs, not in the actual build step. Not sure I agree here: Lets try and stop this again here. I think perhaps the KVM tool example is instructive here. For the various reasons that close association with the kernel can be helpful for things (the exposure and ease of being found), it would be nice if the tooling to expand single kernel image into single bootable image was with the kernel. But it's not a requirement. And it's not even necessarily the best for the tooling either. So, lets drop the idea of getting this into the kernel and if people really do wish to extend FIT such that we can easily spit out a FIT image that works on omap* and tegra* or what have you, and add a FIT parser to GRUB, great, get to work. No need to be tied to the kernel for this. -- Tom signature.asc Description: Digital signature
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Stephen, In message 51475997.2060...@wwwdotorg.org you wrote: Raw zImage /is/ the useful format that should be adopted. This one size fits all approch does fit everywhere. There are a number of users (including _big_ commercial ones, with _large_ numebrs of systems in the field) that have simple requirements like: - how can I find out if the image I just loaded to RAM in OK (OK maning some checksum is correct, or some crypto-key could be verified, or ...) ? - how can I find out which version of image is installed on this device in the flash? Can I print something like an ID string, or a build timestamp, etc? etc. etc. zImage may work well in many cases, but there are also many cases where in image format that allows for additional meta-data is mandatory. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Minds are like parachutes - they only function when open. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Fri, Feb 22, 2013 at 02:56:33AM -0500, Jason Kridner wrote: The desired FPGA use case is DT updates after booting the kernel. This has nothing to do with FIT images. And if the FPGA tools generate the DTB, then it is certainly not tied to the kernel. Completely unrelated, but do you have any pointer for how to do this? Hot plugging a 'dtb fragment' into the kernel would be really handy.. This doesn't answer the full question on how FPGA tools generate DTB, but it is a huge problem for BeagleBone add-on hardware that we have In all my cases I hand code the DT's for the FPGA IP, they get quite big, the one I'm looking at now has over 17 DT nodes inside the FPGA already. This is why we are re-using the DT framework to describe the chip, not building a C coded PCI driver to do the same work. some mechanism to dynamically load DT fragments. Pantelis posted some work in that direction[1] and has continued development of his patches and we've been using those extensively with BeagleBone kernel development[2]. Yes, I saw this. They look really interesting, I think the notion of hot plugging a DT fragment into the main DT is useful for many applications.. Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 02/21/2013 05:39 PM, Russell King - ARM Linux wrote: On Thu, Feb 21, 2013 at 05:10:36PM -0700, Stephen Warren wrote: On 02/21/2013 02:18 PM, Nicolas Pitre wrote: ... Someone will want to use a previously unsupported feature of some HW and then write the DT bindings for that feature for the first time. E.g. Tegra's one-wire controller isn't that commonly used, so we have no binding for it yet despite it being maybe a couple years after starting DT work for Tegra. The AC'97 was only recently supported. Now I agree that this probably will settle down eventually. However, HW will have been widely distributed well before the DT bindings are feature-complete and bug-free. Any solution needs to take that into account, rather than only attempting to solve the situation after the hardware is obsolete and hence the bindings are stable. Tell me then - how is it possible for my laptop to boot correctly with its ACPI data which describes its hardware, and that ACPI data hardly ever has to be updated. Many PC systems have been doing this for years, with various degrees of success - but generally once you have a working system it stays working and never needs to have its ACPI data updated. I'm not too familiar with ACPI or even low-level x86/PC architecture, so forgive me if I'm talking crap, but I suspect there are quite a few reasons for the differences here: * PC systems in general are rather simpler and more standardized. Even where differentiation can exist, it's encapsulated behind simple self-contained interfaces. * As an example, most random expansion devices on a PC are PCIe or USB based, even built-in stuff such as WiFi cards etc. On ARM, there are no standards, so anything goes. Hence, PC expansion cards are much more self-contained and interact with other devices less, whereas on ARM you have a whole spaghetti slew of chips, GPIOs, regulators, interrupts, ... * I think ARM designs are exposed to a wider audience earlier on in their maturity cycle. On x86, there are a number of standards for ACPI etc., and the first people to interact with boards and implement these standards are BIOS and board vendors, and then the boards get out to the general public, and they at least basically all confirm to those standards and work. However, on ARM, we're developing those standards well after the fact; after the HW has shipped and been in use, retro-fitting the standards etc. So, we're being exposed to a much earlier point in the whole cycle than we can even see on x86. I bet x86 CPU, chipset, BIOS, and board vendors see the kind of change in ACPI tables that we're seeing in DT right now. * I imagine there are fewer different sets of people (CPU vendors, BIOS vendors) having to work on defining ACPI standards than there are ARM SoC vendors and Linux developer who're working on DT standards. * x86 is very mature, so there's a lot more incremental development and compatibility. ARM and DT-on-ARM are very new, so it's still the wild west. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, 21 Feb 2013, Tom Rini wrote: FIT isn't required. FIT is just trying to offer a nice usability thing to folks. Usability is often counter-balanced by maintenance costs. A point of device trees is a single image works in a lot of places. FIT gives you a single file works in a lot of places. The whole _point_ for bringing DT into the ARM land was to decouple the the various platform specific stuff from the kernel, and even allow existing distros to work on yet-to-be-created devices unchanged, just like X86 PC class machines. Now you're suggesting that the kernel and the DT information should be glued together again. That looks like a move backward to me. Yet, having that platform stuff in plain C code as we had before, given it is maintained properly, is still the most efficient way to achieve that usability wise. So let's stop kidding ourselves and be coherent please: either we move device specifics away from the kernel, or we keep them together. In other words, the DT should ideally come preinstalled with the bootloader on a given board/device for distros to not even have to care about it, or we put that data back inside the kernel and dispense ourselves from all the added DT overhead entirely. But an hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message. uboot dug _itself_ into this hole. It's uboot's problem. A whole lot of people dug this particular hole. Joel is trying to offer up a solution that maybe makes things easier for everyone. Or it gets rejected here too and distros will come up with their N different ways to try and provide easier experiences to the end user. Nothing being perfect, it is probably unreasonable to think that every board will start shipping with complete and correct DT description, etc. But so is the state of FIT support right now. That solution to make things easier for everyone should actually make that DT vs kernel separation more effective and provide better mechanisms for gluing the various DTBs to their respective boards, and not to glue them to the kernel to populate a distro filesystem with them. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/21/2013 12:25 PM, Nicolas Pitre wrote: On Thu, 21 Feb 2013, Tom Rini wrote: [snip] uboot dug _itself_ into this hole. It's uboot's problem. A whole lot of people dug this particular hole. Joel is trying to offer up a solution that maybe makes things easier for everyone. Or it gets rejected here too and distros will come up with their N different ways to try and provide easier experiences to the end user. Nothing being perfect, it is probably unreasonable to think that every board will start shipping with complete and correct DT description, etc. But so is the state of FIT support right now. That solution to make things easier for everyone should actually make that DT vs kernel separation more effective and provide better mechanisms for gluing the various DTBs to their respective boards, and not to glue them to the kernel to populate a distro filesystem with them. I very much agree here. And in the end, what I really really want to avoid is every distribution (or similar grouping of stuff) coming up with N different ways to solve the problem of how do I get the user the right device tree to go with $whatever board they happen to be running. If the clever solution everyone comes up with is some other container that's not FIT, that's fine, patches welcome and happily reviewed for whatever the solution is. I just don't want people thinking this is a problem that hasn't been thought of before. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJlvxAAoJENk4IS6UOR1W92YQAJZkRAllCkYqUr9sopAxElwV lyuv7GJ2NHT9E39jS0muWk9+t104a0iIQY71Va0UgxFt2lATW9HwffHG3nORK/qF H7lgzfRGgHUjxkZk5D1jlJI6B6mdWtGcC3aN8f6NVZ2wVH7jxDWoi2hxiP68P/in xBNNpHmhwuBwUZ9o1A1W+0rGP8/qOIW/q8GVRLtO2Dw94fEKiWUF6V5VBsIFdeuO Vg3p4vuuvaaF0i1cPlZQAvfykvPoGF6UB1s5MdsuHxTEuRoQa5UdakcwFRnN5I/C pXdK8m4JtJQt4cDj4Jq4FogPzkdbI8VkJ1/8fYpjWnhn1DSawsMinVODRQ+9cy4u aR0t901gQPu13HKqlTZ4kViAhSCGcoVxzzDCpQm3P2YuaLvJJX/uS4eFo8HAX+Jl KfGsf4EXFtRygJtCng4TDdS4WYp6L0VtJVzx4cEzO6syEO5Kz7KgC6SRcfI1pNfm u5RQarknuSJBTW7x5yBYpMu1Zypl3wEqQxaroF8MtQV3qE4bQpwhtljc8h4huVZ0 sMdyAeS9T4gkVp4+H553n8nHrbDCcIdutaCRrcIVDY0dldE/CITpagthK6znMCoP YHHzCkoG+M+9wSueE5GNWvxmWwL3dUYBest/rfa/Eqx5H0o1aSyGyjZeSM9IgnZo YCtEaoq6gT2VDTIl7tCK =vnlO -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote: So let's stop kidding ourselves and be coherent please: either we move device specifics away from the kernel, or we keep them together. In other words, the DT should ideally come preinstalled with the bootloader on a given board/device for distros to not even have to care about it, or we put that data back inside the kernel and dispense ourselves from all the added DT overhead entirely. But an hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message. Just to thread jack a bit here.. We've been using DT on production embedded stuff sice about 2.6.20ish on PPC and now ARM. We treat the dtb as a kernel version specific file, much like an initrd and ensure that the kernel only ever boots with its proper dtb. This is based on experience that the dtbs change depending on the state of the drivers in the kernel, what gets mainlined and when, etc. Embedding this stuff into the bootloader is *not* desirable for my embedded scenarios. We don't use FIT (or uboot) but we do the same thing: a single image is constructed with the proper dtb, kernel and initrd, and that is what the bootloader boots. Why? This is an embedded appliance product. We need to be able to deliver firmware upgrades that *work*. We can't brick the board because the bootloader and kernel get out of sync. The boot loader has to be *simple*, it has to boot every past, present and future kernel or we start taking risks that a firmware flash will end up bricking it. People making dev boards and distros for them certainly have different requirements, but we've decided that the single image approach is the best for appliance style products. Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 11:27:24AM -0700, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote: So let's stop kidding ourselves and be coherent please: either we move device specifics away from the kernel, or we keep them together. In other words, the DT should ideally come preinstalled with the bootloader on a given board/device for distros to not even have to care about it, or we put that data back inside the kernel and dispense ourselves from all the added DT overhead entirely. But an hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message. Just to thread jack a bit here.. We've been using DT on production embedded stuff sice about 2.6.20ish on PPC and now ARM. We treat the dtb as a kernel version specific file, much like an initrd and ensure that the kernel only ever boots with its proper dtb. This is based on experience that the dtbs change depending on the state of the drivers in the kernel, what gets mainlined and when, etc. Just be aware that on ARM at some point, the DT files will be moved out of the kernel source and held in an independent git tree; there won't be any intention of kernel version dependence - if there is then kernel maintanence has failed - and the use of DT has failed too. The stated point of DT is that it describes the hardware. If there's a dependence on the kernel version, then it's doing more than describing the hardware - it would be describing the kernel implementation as well. Embedding this stuff into the bootloader is *not* desirable for my embedded scenarios. We don't use FIT (or uboot) but we do the same thing: a single image is constructed with the proper dtb, kernel and initrd, and that is what the bootloader boots. Note that the combined zImage plus DTB today on ARM is just a stop-gap for boot loaders which provide only an ATAG based booting solution. It's not there as a long term kernel facility. It will probably be going away when the DT files are moved out of the kernel source tree. Why? This is an embedded appliance product. We need to be able to deliver firmware upgrades that *work*. We can't brick the board because the bootloader and kernel get out of sync. The boot loader has to be *simple*, it has to boot every past, present and future kernel or we start taking risks that a firmware flash will end up bricking it. If the DT file describes the hardware properly, then you shouldn't need to update it. Or if the DT file contains a bug (eg, because it doesn't describe how things are wired) then it's wrong whatever. But whatever. There's absolutely no problem storing the DT file separately from the boot loader, and also separately from the kernel itself (this is something that has been stated will be the normal way that DT will be dealt with when DT on ARM was first mooted.) If that's not the case, then we're really just playing one huge game with DT, causing lots of pointless churn for no benefit to people like you, and we might as well stop kidding ourselves that DT gives us any advantages what so ever. We might as well go back to putting this data right back into the kernel in C file form. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, 21 Feb 2013, Tom Rini wrote: On 02/21/2013 12:25 PM, Nicolas Pitre wrote: On Thu, 21 Feb 2013, Tom Rini wrote: [snip] uboot dug _itself_ into this hole. It's uboot's problem. A whole lot of people dug this particular hole. Joel is trying to offer up a solution that maybe makes things easier for everyone. Or it gets rejected here too and distros will come up with their N different ways to try and provide easier experiences to the end user. Nothing being perfect, it is probably unreasonable to think that every board will start shipping with complete and correct DT description, etc. But so is the state of FIT support right now. That solution to make things easier for everyone should actually make that DT vs kernel separation more effective and provide better mechanisms for gluing the various DTBs to their respective boards, and not to glue them to the kernel to populate a distro filesystem with them. I very much agree here. And in the end, what I really really want to avoid is every distribution (or similar grouping of stuff) coming up with N different ways to solve the problem of how do I get the user the right device tree to go with $whatever board they happen to be running. DT installation must be outside of the distribution's responsibilities. It should be the OEM's responsibility, just like BIOS updates for PCs which don't come from Fedora/Debian/Ubuntu. Obviously, having the dts files in the kernel tree does confuse people in that regard, but that must not deter people from doing the right thing. If the clever solution everyone comes up with is some other container that's not FIT, that's fine, patches welcome and happily reviewed for whatever the solution is. I just don't want people thinking this is a problem that hasn't been thought of before. Ideally, there should be no such containers. You should simply pick any kernel, or install your distro of choice, and run that on any DT ready hardware. A distro could list the minimum version of a DTB some particular boards were tested with, just like they sometimes do for some PC BIOSes. That said, maybe some provision for DTB versioning would be a good idea if not done already. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Tom Rini wrote:
On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Tom Rini wrote:
[snip]
uboot dug _itself_ into this hole. It's uboot's problem.
A whole lot of people dug this particular hole. Joel is trying
to offer up a solution that maybe makes things easier for
everyone. Or it gets rejected here too and distros will come up
with their N different ways to try and provide easier experiences
to the end user.
Nothing being perfect, it is probably unreasonable to think that
every board will start shipping with complete and correct DT
description, etc. But so is the state of FIT support right now.
That solution to make things easier for everyone should actually
make that DT vs kernel separation more effective and provide better
mechanisms for gluing the various DTBs to their respective boards,
and not to glue them to the kernel to populate a distro filesystem
with them.
I very much agree here. And in the end, what I really really want to
avoid is every distribution (or similar grouping of stuff) coming up
with N different ways to solve the problem of how do I get the user
the right device tree to go with $whatever board they happen to be
running.
DT installation must be outside of the distribution's responsibilities.
It should be the OEM's responsibility, just like BIOS updates for PCs
which don't come from Fedora/Debian/Ubuntu. Obviously, having the dts
files in the kernel tree does confuse people in that regard, but that
must not deter people from doing the right thing.
The guidance that has been given in the past is that the kernel zImage
and DTB /must/ be stored in the same location, whether that means the
/boot filesystem, flash partitions, or whatever, so that if required,
the kernel and DTB can be updated at the same time, and using the same
process, so it's guaranteed to be easy enough to update the DTB if you
already know how to update the kernel.
Has that guidance changed?
Also, how can the OEM provide a DTB? The distro is responsible for
installing all the filesystem content. There's no defined way of passing
a DTB from some pre-bootloader firmware into the bootloader and through
to the kernel; the only way to get a DTB to the kernel right now is for
the bootloader to load it itself (either as part of a single file, or as
a separate file) and pass it to the kernel. So, there's really no way
for an OEM to provide a DTB in a BIOS-like fashion.
Why shouldn't the OEM just provide their *.dts files, and people can
either compile them and put them into /boot, or distros can package them
and the package will install them into /boot. That's extremely simple
and while each distro will have to create their own packaging script,
that's something they already know how to do, and a package that just
dumps a file onto a disk is extremely simple, so people wouldn't have to
go inventing distro-specific solutions.
If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
just executed that, and there was a standard boot.scr that worked on all
boards by use of e.g. bootz, ${soc}, ${board}, then that could be
distro-agnostic too. And life would be simple, without the need for any
extra build tools at all.
If the clever solution everyone comes up with is some other container
that's not FIT, that's fine, patches welcome and happily reviewed for
whatever the solution is. I just don't want people thinking this is a
problem that hasn't been thought of before.
Ideally, there should be no such containers. You should simply pick any
kernel, or install your distro of choice, and run that on any DT ready
hardware. A distro could list the minimum version of a DTB some
particular boards were tested with, just like they sometimes do for some
PC BIOSes. That said, maybe some provision for DTB versioning would be
a good idea if not done already.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, 21 Feb 2013, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote: So let's stop kidding ourselves and be coherent please: either we move device specifics away from the kernel, or we keep them together. In other words, the DT should ideally come preinstalled with the bootloader on a given board/device for distros to not even have to care about it, or we put that data back inside the kernel and dispense ourselves from all the added DT overhead entirely. But an hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message. Just to thread jack a bit here.. We've been using DT on production embedded stuff sice about 2.6.20ish on PPC and now ARM. We treat the dtb as a kernel version specific file, much like an initrd and ensure that the kernel only ever boots with its proper dtb. This is based on experience that the dtbs change depending on the state of the drivers in the kernel, what gets mainlined and when, etc. For embedded appliance product you may do as you wish. Nobody will interfere in the way you develop and support your own products (as long as you honor the applicable licenses of course). But here we're discussing ARM Linux distributions having to deal with different hardware devices. It simply doesn't make sense to bundle every hardware specific data with the kernel in that context. Embedding this stuff into the bootloader is *not* desirable for my embedded scenarios. We don't use FIT (or uboot) but we do the same thing: a single image is constructed with the proper dtb, kernel and initrd, and that is what the bootloader boots. No one is advocating to embed the DT stuff in the bootloader. The DTB may be buggy and/or incomplete and being able to update it safely i.e. independently from the bootloader is necessary. Why? This is an embedded appliance product. We need to be able to deliver firmware upgrades that *work*. We can't brick the board because the bootloader and kernel get out of sync. The boot loader has to be *simple*, it has to boot every past, present and future kernel or we start taking risks that a firmware flash will end up bricking it. People making dev boards and distros for them certainly have different requirements, but we've decided that the single image approach is the best for appliance style products. Absolutely. And in your case, DT is not bringing any benefit over the previous situation where everything was compiled into the kernel. I suspect you're not using the multi-platform support either which is one of the major endeavor on ARM right now. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Stephen,
In message 5126778a.4040...@wwwdotorg.org you wrote:
If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
just executed that, and there was a standard boot.scr that worked on all
boards by use of e.g. bootz, ${soc}, ${board}, then that could be
distro-agnostic too. And life would be simple, without the need for any
extra build tools at all.
If the world was so simple, we could eventually do that. But it ain't
so. Just consider the typical diskless system that boots over the
network, using DHCP + TFTP, where the server will provide a single
file only. Or systems that require sub-second boot times, where you
don't want to spend time in running boot scripts. etc.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
We see things not as they are, but as we are. - H. M. Tomlinson
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 02/21/2013 12:57 PM, Wolfgang Denk wrote:
Dear Stephen,
In message 5126778a.4040...@wwwdotorg.org you wrote:
If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
just executed that, and there was a standard boot.scr that worked on all
boards by use of e.g. bootz, ${soc}, ${board}, then that could be
distro-agnostic too. And life would be simple, without the need for any
extra build tools at all.
If the world was so simple, we could eventually do that. But it ain't
so. Just consider the typical diskless system that boots over the
network, using DHCP + TFTP, where the server will provide a single
file only.
I use TFTP routinely to boot my boards, and load separate zImage and DTB
files from the server without issue, using the exact same filenames as
when I load them from a /boot directory on eMMC or SD.
Or systems that require sub-second boot times, where you
don't want to spend time in running boot scripts. etc.
Admittedly this is conjecture, but surely the actual IO time to load a
zImage vastly vastly dwarfs the time take to parse an ext2load or
fsload command to do so, so running scripts to do this isn't relevant.
And besides, there's always some script, whether it's a boot.scr file or
built into the U-Boot environment.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 07:08:20PM +, Russell King - ARM Linux wrote: We've been using DT on production embedded stuff sice about 2.6.20ish on PPC and now ARM. We treat the dtb as a kernel version specific file, much like an initrd and ensure that the kernel only ever boots with its proper dtb. This is based on experience that the dtbs change depending on the state of the drivers in the kernel, what gets mainlined and when, etc. Just be aware that on ARM at some point, the DT files will be moved out of the kernel source and held in an independent git tree; there won't be any intention of kernel version dependence - if there is then kernel maintanence has failed - and the use of DT has failed too. Yes, I've read that in this thread. I have to say that is a scary thought, if the seperate DT's get all fragmented like uboot is then it is just going to be a huge PITA. The stated point of DT is that it describes the hardware. If there's a dependence on the kernel version, then it's doing more than describing the hardware - it would be describing the kernel implementation as well. Again yes, but.. My experience has been a bit different, *pragmatically* the DTs are configuring Linux to work with that hardware, and the Linux expectations can leak into that. The DT changes seem to tail off as the HW and drivers mature, our PPC stuff doesn't change much at all these days, but the our ARM DT is churning like crazy.. I think this pattern is very likely to repeat every time a new SOC is introduced. Until everything is mainlined and agreed on the DTs for that SOC will churn. Some of this seems to be caused by the complexity of the OF standard, the flexibility it allows and the fact it is being pushed into areas the standard doesn't cover. With more than one way to do everything stuff gets done wrong, or people change their minds, or whatever. Note that the combined zImage plus DTB today on ARM is just a stop-gap for boot loaders which provide only an ATAG based booting solution. It's not there as a long term kernel facility. It will probably be going away when the DT files are moved out of the kernel source tree. Thats fine for me, we don't use that mechanism. Why? This is an embedded appliance product. We need to be able to deliver firmware upgrades that *work*. We can't brick the board because the bootloader and kernel get out of sync. The boot loader has to be *simple*, it has to boot every past, present and future kernel or we start taking risks that a firmware flash will end up bricking it. If the DT file describes the hardware properly, then you shouldn't need to update it. Or if the DT file contains a bug (eg, because it doesn't describe how things are wired) then it's wrong whatever. .. or Linux changes how it interprets the DT. .. or Linux requires additional HW blocks to be described in the DT. If that's not the case, then we're really just playing one huge game with DT, causing lots of pointless churn for no benefit to people like you, and we might as well stop kidding ourselves that DT gives us any advantages what so ever. We might as well go back to putting this data right back into the kernel in C file form. Well, when we switched PPC to DT it was a huge improvement in these areas: - Describing and binding I2C devices - .. MDIO Phys - Passing ethernet MAC addresses into drivers - Routing and binding GPIOs to linux drivers (like I2C, MDIO, resets etc) - Passing HW specific options into buried drivers, eg options for I2C hwmon devices, LED configuration for phys, etc All of which had OF mechanisms, but no good C mechanism (at the time at least) I also noticed a decrease in churn, the PPC DT descriptions have been more stable that the prior C versions. The C versions often tended to need small revisions as the kernel changed. Further, our boards are almost always very different than the eval/dev platforms provided by the vendor. The splitting up and modularizing of the kernel code that has come along with DT has made it much simpler to support our specific boards. So, I strongly disagree that DT is bringing no benefit to my kind of application. Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Stephen, In message 51267e0a.3060...@wwwdotorg.org you wrote: so. Just consider the typical diskless system that boots over the network, using DHCP + TFTP, where the server will provide a single file only. I use TFTP routinely to boot my boards, and load separate zImage and DTB files from the server without issue, using the exact same filenames as when I load them from a /boot directory on eMMC or SD. You may do this in a development environment; I do the same routinely here. But there are users out there who commission large installations like that; they simply do not want to have multiple files for each system (and not even for each configuration). And besides, there's always some script, whether it's a boot.scr file or built into the U-Boot environment. Not really - especially not when booting using Falcon mode. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you can't beat it or corrupt it, you pretend it was your idea in the first place. - Terry Pratchett, _Guards! Guards!_ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
Jason == Jason Gunthorpe jguntho...@obsidianresearch.com writes: Hi, Jason We've been using DT on production embedded stuff sice about 2.6.20ish Jason on PPC and now ARM. We treat the dtb as a kernel version specific Jason file, much like an initrd and ensure that the kernel only ever boots Jason with its proper dtb. This is based on experience that the dtbs change Jason depending on the state of the drivers in the kernel, what gets Jason mainlined and when, etc. Jason Embedding this stuff into the bootloader is *not* desirable for my Jason embedded scenarios. We don't use FIT (or uboot) but we do the same Jason thing: a single image is constructed with the proper dtb, kernel and Jason initrd, and that is what the bootloader boots. Jason Why? This is an embedded appliance product. We need to be able to Jason deliver firmware upgrades that *work*. We can't brick the board Jason because the bootloader and kernel get out of sync. The boot loader has Jason to be *simple*, it has to boot every past, present and future kernel Jason or we start taking risks that a firmware flash will end up bricking Jason it. I'm having the exact same experience (and handle it in the same way). I know this was not the intention of DT, but unfortunately this is how things have turned out so far. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote: On Thu, 21 Feb 2013, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote: So let's stop kidding ourselves and be coherent please: either we move device specifics away from the kernel, or we keep them together. In other words, the DT should ideally come preinstalled with the bootloader on a given board/device for distros to not even have to care about it, or we put that data back inside the kernel and dispense ourselves from all the added DT overhead entirely. But an hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message. Just to thread jack a bit here.. We've been using DT on production embedded stuff sice about 2.6.20ish on PPC and now ARM. We treat the dtb as a kernel version specific file, much like an initrd and ensure that the kernel only ever boots with its proper dtb. This is based on experience that the dtbs change depending on the state of the drivers in the kernel, what gets mainlined and when, etc. For embedded appliance product you may do as you wish. Nobody will interfere in the way you develop and support your own products (as long as you honor the applicable licenses of course). I was specifically responding to your statement that 'a hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message.' We have been making good use of such an arrangement, and it is defintely not 'the wrong message' for certain applications. In fact, as I said, it is probably the *right* message for embedded users. Even if I was a distro user, the idea that my dt and kernel would be decoupled is very scary. Realize that today, my Kirkwood systems require a different DT for at least 3.7 and 3.8 kernels, and quite possibly different again for 3.9!! This will eventually settle on kirkwood, but I bet the same pattern will repeat on the next new SOC. I would have thought keeping the device tree data and kernel together is preferred for most cases as it is more inline with Documentation/stable_api_nonsense.txt. Making the DT a strong stable API boundary sounds really hard to me, and if the churn on ARM so far is indication, it may not be realistic.. But here we're discussing ARM Linux distributions having to deal with different hardware devices. It simply doesn't make sense to bundle every hardware specific data with the kernel in that context. Distros already ship huge kernels with modules for every hardware out there. Shipping all the DTs as well doesn't seem like a problem. I am thinking something like /lib/device-tree/`uname -r`/... Where (taking a PC analog) the bootloader is told to grab: /boot/vmlinuz-3.9 /boot/initrd.img-3.9 /lib/device-tree/3.9/ti/omap/foo-bar-board The kernel build can be nice and uniform, while the distro can provide scripts/tools to bundle the kernel zimage, kernel modules, initramfs stuff and dtb into something bootable - be it FIT, uimage, bootz script, grub script or whatever. Embedding this stuff into the bootloader is *not* desirable for my embedded scenarios. We don't use FIT (or uboot) but we do the same thing: a single image is constructed with the proper dtb, kernel and initrd, and that is what the bootloader boots. No one is advocating to embed the DT stuff in the bootloader. The DTB may be buggy and/or incomplete and being able to update it safely i.e. independently from the bootloader is necessary. Sorry, what did you mean by: 'the DT should ideally come preinstalled with the bootloader on a given board/device' ? My point was simply that any scenario where the bootloader grabs a DTB that is not strongly associated with the kernel it is going to boot is not desirable. People making dev boards and distros for them certainly have different requirements, but we've decided that the single image approach is the best for appliance style products. Absolutely. And in your case, DT is not bringing any benefit over the previous situation where everything was compiled into the kernel. I Strongly disagree, see my prior email to Russell. DT is a very big improvement over the old way of C coding the same data. Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, 21 Feb 2013, Stephen Warren wrote:
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
DT installation must be outside of the distribution's responsibilities.
It should be the OEM's responsibility, just like BIOS updates for PCs
which don't come from Fedora/Debian/Ubuntu. Obviously, having the dts
files in the kernel tree does confuse people in that regard, but that
must not deter people from doing the right thing.
The guidance that has been given in the past is that the kernel zImage
and DTB /must/ be stored in the same location, whether that means the
/boot filesystem, flash partitions, or whatever, so that if required,
the kernel and DTB can be updated at the same time, and using the same
process, so it's guaranteed to be easy enough to update the DTB if you
already know how to update the kernel.
Where were such guidance given?
I don't think this is wise anyway. The DT content for a given piece of
hardware should stabilize quickly, while the kernel can be updated for
years. So there is no need for making the DTB update into the same
process as the kernel.
And as I stated earlier, the distros will care about kernel updates, but
they shouldn't have to care about DTB updates.
The only reason why we do have to update DTBs frequently is because the
whole thing is still being developed and established. But frequent DTB
updates are not the end goal, and therefore we shouldn't design
installation and update mechanisms around the current state of affairs
which is not meant to persist.
Has that guidance changed?
Consider this as my plea to have it changed.
Also, how can the OEM provide a DTB? The distro is responsible for
installing all the filesystem content.
And that's probably not a good idea either.
There's no defined way of passing
a DTB from some pre-bootloader firmware into the bootloader and through
to the kernel;
That doesn't have to stay that way, does it? Maybe those efforts put on
things like FIT or the like could be applied to this problem instead?
Yet that depends how you define a pre-bootloader and a bootloader.
Some people call UEFI the bootloader and grub or u-boot running on top
as the second stage bootloader. I've heard people talking about
making u-boot into a _user_ of the DTB in addition to the kernel, which
would make some sense. In that case, the second stage bootloader could
be somewhat generic as well. But if that layer is generic, then there
must be some kind of standard adaptation layer or API provided by the
first stage bootloader to the second stage bootloader. Passing on
some hardware configuration payload would be part of that API.
Sidenote: there is noise about using ACPI instead of DT on ARM servers
for example, so that's another reason why distributions should not
engage into this responsibility too much.
And obviously the DTB has to be tied to the machine specific boot layer.
And the method to retrieve it would, obviously, be machine specific at
that point. This doesn't have to come frfom the filesystem used by the
final operating system.
the only way to get a DTB to the kernel right now is for
the bootloader to load it itself (either as part of a single file, or as
a separate file) and pass it to the kernel. So, there's really no way
for an OEM to provide a DTB in a BIOS-like fashion.
That will have to change.
Why shouldn't the OEM just provide their *.dts files, and people can
either compile them and put them into /boot, or distros can package them
and the package will install them into /boot. That's extremely simple
and while each distro will have to create their own packaging script,
that's something they already know how to do, and a package that just
dumps a file onto a disk is extremely simple, so people wouldn't have to
go inventing distro-specific solutions.
Because that shouldn't be the distro's business. Because the distros
shouldn't have to be aware of all possible DTBs around and gather them
on their install media and figure out during installation which one to
use, or configure the bootloader so it knows which one to pass back to
the kernel, when the OEMs may as well just ship the right one with their
hardware without the distro to care at all. Because a distro should be
installable on some future hardware that didn't exist when that distro
was put together. Because, ideally, you should be able to pop out the
disk (or SD card) from device X and put it into device Y and just boot
without changing anything.
The device tree data is describing hardware, it should be tied to the
hardware, not to the distribution. Hardware doesn't change, kernels and
distros do.
If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
just executed that, and there was a standard boot.scr that worked on all
boards by use of e.g. bootz, ${soc}, ${board}, then that could be
distro-agnostic too. And life would be simple, without the need for any
extra build
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, 21 Feb 2013, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote: For embedded appliance product you may do as you wish. Nobody will interfere in the way you develop and support your own products (as long as you honor the applicable licenses of course). I was specifically responding to your statement that 'a hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message.' We have been making good use of such an arrangement, and it is defintely not 'the wrong message' for certain applications. In fact, as I said, it is probably the *right* message for embedded users. No it is not. FIT is about bundling a multi-platform kernel with a bunch of DTBs together in a single file. I don't think you need that for your embedded system. The wrong message here is to distribute multiple DTBs around, whether it is with FIT or on a distro install media. Even if I was a distro user, the idea that my dt and kernel would be decoupled is very scary. That was still the design goal for DT. Realize that today, my Kirkwood systems require a different DT for at least 3.7 and 3.8 kernels, and quite possibly different again for 3.9!! Understandable, given that Kirkwood is being ported to DT right now. But if DT had been used from the start when we introduced Kirkwood support to Linux back in 2008 you most likely wouldn't have to change the DTB on your board at all today. This will eventually settle on kirkwood, but I bet the same pattern will repeat on the next new SOC. Possible, although new SOCs do start with DT from the start which is much easier than trying to retrofit it to existing code without breaking things. And given that patterns emerge, there is no need to redesign new bindings for every new SOC. I would have thought keeping the device tree data and kernel together is preferred for most cases as it is more inline with Documentation/stable_api_nonsense.txt. Making the DT a strong stable API boundary sounds really hard to me, and if the churn on ARM so far is indication, it may not be realistic.. The DT is meant to describe hardware. As far as I know, the hardware I own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). Distros already ship huge kernels with modules for every hardware out there. Shipping all the DTs as well doesn't seem like a problem. But it is! Even shipping multiple kernels _is_ a problem for them. Hence this multi-platform kernel effort. Otherwise why would we bother? According to your logic, distros could package and distribute BIOS updates for all the X86 systems out there. After all, if they did, they would guarantee even better support on the hardware they target and not have to carry those ACPI quirks in the kernel, no? Ask them if they find this idea rejoicing. You might be surprised. I am thinking something like /lib/device-tree/`uname -r`/... Where (taking a PC analog) the bootloader is told to grab: /boot/vmlinuz-3.9 /boot/initrd.img-3.9 /lib/device-tree/3.9/ti/omap/foo-bar-board And what is the advantage over not having to carry all those files at all on your filesystem? The kernel build can be nice and uniform, while the distro can provide scripts/tools to bundle the kernel zimage, kernel modules, initramfs stuff and dtb into something bootable - be it FIT, uimage, bootz script, grub script or whatever. Or they may simply not bother if the bootloader that comes with the hardware already does the right thing which is even better. Embedding this stuff into the bootloader is *not* desirable for my embedded scenarios. We don't use FIT (or uboot) but we do the same thing: a single image is constructed with the proper dtb, kernel and initrd, and that is what the bootloader boots. No one is advocating to embed the DT stuff in the bootloader. The DTB may be buggy and/or incomplete and being able to update it safely i.e. independently from the bootloader is necessary. Sorry, what did you mean by: 'the DT should ideally come preinstalled with the bootloader on a given board/device' ? When you acquire some hardware, it should come with a DTB and bootloader pre-installed, ready to boot any distribution (as long as its kernel supports the SoC of course). Your hardware vendor should offer DTB updates on its website. The DTB should not be compiled into the bootloader so DTB updates can be done independently from risky bootloader updates. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote: On Thu, 21 Feb 2013, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote: For embedded appliance product you may do as you wish. Nobody will interfere in the way you develop and support your own products (as long as you honor the applicable licenses of course). I was specifically responding to your statement that 'a hybrid mixed solution like FIT is IMHO the worst of both worlds and sending a wrong message.' We have been making good use of such an arrangement, and it is defintely not 'the wrong message' for certain applications. In fact, as I said, it is probably the *right* message for embedded users. No it is not. FIT is about bundling a multi-platform kernel with a bunch of DTBs together in a single file. I don't think you need that for your embedded system. The wrong message here is to distribute multiple DTBs around, whether it is with FIT or on a distro install media. Actually we do this on PPC, the boot kernel image runs on three similar hardware platforms, the image has three DTBs built into it and the right one is selected at runtime. The kernel boot image does this (call it a second stage boot loader), not the primary boot loader. I strongly disagree with the idea that keeping the DTB seperated from the kernel is appropriate for all users, or even most users. To me that only seems appropriate for certain kinds of hardware, eg general purpose computing devices that are designed to primarily run a Linux distro. An embedded SOC eval board, a development platform, an embedded appliance - these are cases where the kernel and DTB should generally be more tightly coupled. This is more or less how PPC has evolved, big commerical PPC systems like Apple's and IBM's stuff all provide a DTB to the kernel - and this is actually a bit different then the DT's people are writing for SOCs, it is firmware generated and includes a full description of all the probed hardware - including pluggable PCI cards and other stuff. The hardware is also left configured so there is less for Linux to do and less that needs to be described in DT. While embedded focused PPC stuff seems to tend to keep the kernel and DT together. This will eventually settle on kirkwood, but I bet the same pattern will repeat on the next new SOC. Possible, although new SOCs do start with DT from the start which is much easier than trying to retrofit it to existing code without breaking things. And given that patterns emerge, there is no need to redesign new bindings for every new SOC. Disagree. We are already seeing patching now for 2nd generation DT bindings to fix flaws in bindings that were introduced earlier. I hope the rate will slow down, but the need will probably never go away completely. :( This is already standing on top of the work that was done to establish DT patterns for embedded PPC.. The DT is meant to describe hardware. As far as I know, the hardware I own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). .. and the patching I mention above are largely driven by either a change in understanding of how OF should describe the hardware, or a change in understanding of how the driver should treat the hardware. The recent patching for the tegra PCI-E bridge is instructive in this regard, Theirry learned how to drive the chip in a way that creates a single PCI domain - this necessitates a change in how the DT models that hardware block. There are lots of ways to model the same hardware in DT. Distros already ship huge kernels with modules for every hardware out there. Shipping all the DTs as well doesn't seem like a problem. But it is! Even shipping multiple kernels _is_ a problem for them. Hence this multi-platform kernel effort. Otherwise why would we bother? Multiple *kernel packages* is a big problem, one *kernel package* is generally not. It is already the case on x86 that a kernel package can't boot out of the box. The distro builds a box-specific initramfs on boot that minimally includes enough modules to access the root fs storage. Grabbing a box specific DT as well is a tiny additional step. Bear in mind, that like for storage, when the kernel is installed the system is *already running*. This means it knows what storage modules are needed, and similarly it knows the content of the DTB it is using. It can do three things with this: - See if /lib/device-tree/.. contains a compatible DTB, if so use the version from /lib - Save the DTB to /boot/my-board-dtb and use it - Realize that it is OEM provided and comes from the firmware, do nothing So things can very much be fully automated. According to your logic, distros could package and distribute BIOS updates for all the X86 systems out there. After all, if they did, they would guarantee even better support on
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Nicolas, In message alpine.lfd.2.03.1302211624561.6...@syhkavp.arg you wrote: No it is not. FIT is about bundling a multi-platform kernel with a bunch of DTBs together in a single file. I don't think you need that Actually this is neither the only, nor even the primary purpose of FIT images; these have a much wider scope of usage scenarios. The DT is meant to describe hardware. As far as I know, the hardware I own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). There is other hardware available (for example FPGA based) where this does not apply. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de GUIs are virtually useless. Learn tools. They're configurable, scriptable, automatable, cron-able, interoperable, etc. We don't need no brain-dead winslurping monolithic claptrap. -- Tom Christiansen in 371140df@csnews -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Fri, Feb 22, 2013 at 12:18:48AM +0100, Wolfgang Denk wrote: The DT is meant to describe hardware. As far as I know, the hardware I own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). There is other hardware available (for example FPGA based) where this does not apply. Agreed.. We do that here as well, the DT is also used to describe the functionality inside FPGA(s). We do things like declare a GPIO controller inside the FPGA, then stack the bitbang MDIO/I2C on top of that, then declare a bunch of devices on those busses. DT makes this extremely straightforward. However, it is critical that the DT, kernel and FPGA are matched together - we always arrange things so that the DTB, kernel and FPGA config are bundled together and update atomically during firmware upgrade. Xilinx's Zynq is a great example of this kind of stuff, FWIW. IIRC Xilinx has a DT generator from their IP tools, so you can literally go into their design software, configure the hardware IP blocks, and get back a FPGA config and a DT to go with it. Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 02/21/2013 03:05 PM, Nicolas Pitre wrote: On Thu, 21 Feb 2013, Jason Gunthorpe wrote: ... Distros already ship huge kernels with modules for every hardware out there. Shipping all the DTs as well doesn't seem like a problem. But it is! Even shipping multiple kernels _is_ a problem for them. Hence this multi-platform kernel effort. Otherwise why would we bother? According to your logic, distros could package and distribute BIOS updates for all the X86 systems out there. After all, if they did, they would guarantee even better support on the hardware they target and not have to carry those ACPI quirks in the kernel, no? Ask them if they find this idea rejoicing. You might be surprised. Well they ship x86 CPU firmware updates according to the boot log on one of my systems at least... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 02/21/2013 04:11 PM, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote: ... The DT is meant to describe hardware. As far as I know, the hardware I own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). .. and the patching I mention above are largely driven by either a change in understanding of how OF should describe the hardware, or a change in understanding of how the driver should treat the hardware. The recent patching for the tegra PCI-E bridge is instructive in this regard, Theirry learned how to drive the chip in a way that creates a single PCI domain - this necessitates a change in how the DT models that hardware block. While I certainly don't disagree with the sentiment of your email, Tegra PCIe is a bad example. There is no finalized DT binding yet for the Tegra PCIe HW. Thierry is in the process of defining it for the first time. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 02/21/2013 02:18 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Stephen Warren wrote:
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
DT installation must be outside of the distribution's responsibilities.
It should be the OEM's responsibility, just like BIOS updates for PCs
which don't come from Fedora/Debian/Ubuntu. Obviously, having the dts
files in the kernel tree does confuse people in that regard, but that
must not deter people from doing the right thing.
The guidance that has been given in the past is that the kernel zImage
and DTB /must/ be stored in the same location, whether that means the
/boot filesystem, flash partitions, or whatever, so that if required,
the kernel and DTB can be updated at the same time, and using the same
process, so it's guaranteed to be easy enough to update the DTB if you
already know how to update the kernel.
Where were such guidance given?
IIRC, it's been discussed a number of times on the Linux ARM kernel
mailing list and at the various ARM workshops at kernel summit and/or
Linaro Connect. It has been a while, so maybe the advice was simply
supposed to age out, but I certainly haven't seen any explicit
indication that the advice was temporary or rescinded.
The only reason why we do have to update DTBs frequently is because the
whole thing is still being developed and established. But frequent DTB
updates are not the end goal, and therefore we shouldn't design
installation and update mechanisms around the current state of affairs
which is not meant to persist.
It will always be under development.
People will make mistakes and want to fix them.
Someone will want to use a previously unsupported feature of some HW and
then write the DT bindings for that feature for the first time. E.g.
Tegra's one-wire controller isn't that commonly used, so we have no
binding for it yet despite it being maybe a couple years after starting
DT work for Tegra. The AC'97 was only recently supported.
Now I agree that this probably will settle down eventually. However, HW
will have been widely distributed well before the DT bindings are
feature-complete and bug-free. Any solution needs to take that into
account, rather than only attempting to solve the situation after the
hardware is obsolete and hence the bindings are stable.
There's no defined way of passing
a DTB from some pre-bootloader firmware into the bootloader and through
to the kernel;
That doesn't have to stay that way, does it? Maybe those efforts put on
things like FIT or the like could be applied to this problem instead?
Perhaps. But where can the DTB be stored?
a) In the system's boot flash alongside U-Boot, or at least some
first-/early-stage firmware that can determine where in RAM it was
loaded to, and pass it to some later-stage software in a standard fashion.
b) In a filesystem, alongside the kernel.
c) In some other flash device, or partition.
There often isn't any such flash device/partition for (c), so that
option is out as a /general/ rule.
(a) would require a firmware upgrade process in order to upgrade the
DTB. Using this option is very explicitly against the guidance I was
talking about a few paragraphs up.
So that just leaves (b). And in this case, you may as well use U-Boot's
(or any other bootloader) ability to load foo.dtb just like it loads zImage.
Yet that depends how you define a pre-bootloader and a bootloader.
Some people call UEFI the bootloader and grub or u-boot running on top
as the second stage bootloader. I've heard people talking about
making u-boot into a _user_ of the DTB in addition to the kernel, which
would make some sense.
For better or worse, that is true for upstream U-Boot on Tegra. The DTB
is built into U-Boot in this case, and is a different DTB than what's
passed to the kernel, because U-Boot has historically not used identical
DT bindings to the real reviewed bindings as defined by the kernel's
Documentation/devicetree/bindings. It's getting better, but there is
still some way to go. The same is probably true for Exynos5, but I
haven't investigated the situation there in detail.
...
Sidenote: there is noise about using ACPI instead of DT on ARM servers
for example, so that's another reason why distributions should not
engage into this responsibility too much.
Hmmm. That sounds a lot like making most of my last 2 years' work
redundant:-( It'd be a big pity to have that all wasted.
...
If U-Boot always searched a disk for e.g. /boot/boot.scr or similar and
just executed that, and there was a standard boot.scr that worked on all
boards by use of e.g. bootz, ${soc}, ${board}, then that could be
distro-agnostic too. And life would be simple, without the need for any
extra build tools at all.
No, life isn't that simple. First, not everyone wants to use U-Boot.
Sure.
And even if U-Boot was universally used/loved, there is no way you could
have a boot.scr that would work for every board.
I disagree
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 02/21/2013 05:28 PM, Jason Gunthorpe wrote: On Fri, Feb 22, 2013 at 12:18:48AM +0100, Wolfgang Denk wrote: The DT is meant to describe hardware. As far as I know, the hardware I own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). There is other hardware available (for example FPGA based) where this does not apply. Agreed.. We do that here as well, the DT is also used to describe the functionality inside FPGA(s). We do things like declare a GPIO controller inside the FPGA, then stack the bitbang MDIO/I2C on top of that, then declare a bunch of devices on those busses. DT makes this extremely straightforward. However, it is critical that the DT, kernel and FPGA are matched together - we always arrange things so that the DTB, kernel and FPGA config are bundled together and update atomically during firmware upgrade. Xilinx's Zynq is a great example of this kind of stuff, FWIW. IIRC Xilinx has a DT generator from their IP tools, so you can literally go into their design software, configure the hardware IP blocks, and get back a FPGA config and a DT to go with it. The desired FPGA use case is DT updates after booting the kernel. This has nothing to do with FIT images. And if the FPGA tools generate the DTB, then it is certainly not tied to the kernel. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 02/21/2013 05:11:06 PM, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote: No it is not. FIT is about bundling a multi-platform kernel with a bunch of DTBs together in a single file. I don't think you need that for your embedded system. The wrong message here is to distribute multiple DTBs around, whether it is with FIT or on a distro install media. Actually we do this on PPC, the boot kernel image runs on three similar hardware platforms, the image has three DTBs built into it and the right one is selected at runtime. The kernel boot image does this (call it a second stage boot loader), not the primary boot loader. I strongly disagree with the idea that keeping the DTB seperated from the kernel is appropriate for all users, or even most users. To me that only seems appropriate for certain kinds of hardware, eg general purpose computing devices that are designed to primarily run a Linux distro. An embedded SOC eval board, a development platform, an embedded appliance - these are cases where the kernel and DTB should generally be more tightly coupled. This is more or less how PPC has evolved, big commerical PPC systems like Apple's and IBM's stuff all provide a DTB to the kernel - and this is actually a bit different then the DT's people are writing for SOCs, it is firmware generated and includes a full description of all the probed hardware - including pluggable PCI cards and other stuff. The hardware is also left configured so there is less for Linux to do and less that needs to be described in DT. While embedded focused PPC stuff seems to tend to keep the kernel and DT together. At least on the Freescale side of embedded focused PPC stuff, we have not kept the kernel and DT together. It's actually U-Boot that the dts files in the kernel tree are tied to, since they contain assumptions about how U-Boot lays out the memory map (there are some inherent limits to the device tree just describes the hardware, barring some radical changes in the form device trees take), which things U-Boot will fill in/modify, and what U-Boot looks for to find out where to make the modification. Usually U-Boot is the only relevant loader for a particular board, but not always -- hence adder875-redboot.dts and adder875-uboot.dts. Even when U-Boot is the only relevant loader, there are sometimes changes from one version or configuration of U-Boot to another that cause problems (e.g. the device trees that come in 32b and 36b variants). -Scott -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 04:11:06PM -0700, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote: No it is not. FIT is about bundling a multi-platform kernel with a bunch of DTBs together in a single file. I don't think you need that for your embedded system. The wrong message here is to distribute multiple DTBs around, whether it is with FIT or on a distro install media. Actually we do this on PPC, the boot kernel image runs on three similar hardware platforms, the image has three DTBs built into it and the right one is selected at runtime. The kernel boot image does this (call it a second stage boot loader), not the primary boot loader. If that's something that PPC does, great. It's not something that we have any support for on ARM, nor do we have any intention at present to add support for it. The stop-gap for ATAG-passing boot loaders, where you can append a DTB object to the zImage, and have the zImage update the DTB with information from the ATAG stuff will only work with a _single_ DTB. I strongly disagree with the idea that keeping the DTB seperated from the kernel is appropriate for all users, or even most users. To me that only seems appropriate for certain kinds of hardware, eg general purpose computing devices that are designed to primarily run a Linux distro. Actually, this is not really even our decision. This direction was rather set by Linus T. himself when he found out what has been going on in OMAP, with all the massive amounts of data which are present in the kernel. He has said that he doesn't want that data carried in the kernel source. Hell, this is not the first time he's objected; he's threatened to delete all our defconfig files because they're getting too many. So, like it or not, we're going to face the same problem with DTBs that we face with the sprawing code we have in the kernel, and which we've had with the defconfigs. Linus _will_ at some point get pissed off with them and threaten to delete them. And it won't matter what you think one bit when Linus makes that decision. Nor what we think. Because he'll either complain and give an ultimatum, or he'll just do it. Disagree. We are already seeing patching now for 2nd generation DT bindings to fix flaws in bindings that were introduced earlier. I hope the rate will slow down, but the need will probably never go away completely. :( This is where pressure back to people to stop them behaving like this is important - and it _isn't_ being helped by having the DTBs as part of the kernel - it makes it _too_ easy for this kind of stuff to happen without proper controls. Multiple *kernel packages* is a big problem, one *kernel package* is generally not. It is already the case on x86 that a kernel package can't boot out of the box. The distro builds a box-specific initramfs on boot that minimally includes enough modules to access the root fs storage. Grabbing a box specific DT as well is a tiny additional step. You're confused there. You're comparing the wrong things. On x86, the modules needed for the rootfs are generally held in an initramfs, because that provides an easy way to collect together the parts of the system that are needed to find the rootfs. However, that's not what we're talking about when we're talking about DTB. An initramfs doesn't describe the hardware. So you're comparing apples and oranges and expecting us to take you seriously for doing so. What you should be comparing in this instance is DTB with ACPI. ACPI describes the hardware on which you're booting your x86 kernel. It says what devices are present in the system (which may change while the kernel is running - think laptops which gain ports when you dock them.) You don't see x86 distros including large chunks of ACPI data on their DVDs... That's all provided by the motherboard OEM. Bear in mind, that like for storage, when the kernel is installed the system is *already running*. This means it knows what storage modules are needed, and similarly it knows the content of the DTB it is using. It can do three things with this: - See if /lib/device-tree/.. contains a compatible DTB, if so use the version from /lib - Save the DTB to /boot/my-board-dtb and use it - Realize that it is OEM provided and comes from the firmware, do nothing So things can very much be fully automated. You've a chicken and egg problem there. If the kernel is already running on a DT-based system, then it has already been provided with a DTB. That DTB is available from the kernel itself, and can be saved. But what's the point if _that_ kernel was already able to get it from somewhere - probably provided via the board firmware in the first place. See? At the point where you have your first kernel running for the install, you must already be using the right DTB file which must have come from somewhere. The egg(DTB) must come before the chicken(kernel). According to your
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 04:45:37PM -0700, Stephen Warren wrote: Well they ship x86 CPU firmware updates according to the boot log on one of my systems at least... Correction: CPU microcode updates. That's updating the microcode in the CPU which runs the x86 instruction set. It's done to fix problems discovered with execution of the CPU instruction set. That's entirely separate from ACPI or DT blobs provided by the OEM. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 05:10:36PM -0700, Stephen Warren wrote: On 02/21/2013 02:18 PM, Nicolas Pitre wrote: Where were such guidance given? IIRC, it's been discussed a number of times on the Linux ARM kernel mailing list and at the various ARM workshops at kernel summit and/or Linaro Connect. It has been a while, so maybe the advice was simply supposed to age out, but I certainly haven't seen any explicit indication that the advice was temporary or rescinded. And this is why Linaro Connects are a bad idea. They give the illusion of decisions being taken and finalize, taking the decision process out of the open source community. It can be viewed as corporate takeover of open source. (I realise that comment is going to get peoples backs up - but unfortunately you can't call an apple a pear.) What is the really sad thing is that at no point do the Linaro Connects really come back to the community (such as this mailing list) and say this is what was discussed, and this is what we think, can we get agreement. Instead what happens is that stuff gets discussed behind closed doors, work starts, patches come out, and then it gets discussed openly. And... as for the meeting notes system... I looked at the ARM booting stuff on Linaro's website - it contains no real useful information, it looks like it's fallen by the way side. So what's the point of having a page or two on it? Someone will want to use a previously unsupported feature of some HW and then write the DT bindings for that feature for the first time. E.g. Tegra's one-wire controller isn't that commonly used, so we have no binding for it yet despite it being maybe a couple years after starting DT work for Tegra. The AC'97 was only recently supported. Now I agree that this probably will settle down eventually. However, HW will have been widely distributed well before the DT bindings are feature-complete and bug-free. Any solution needs to take that into account, rather than only attempting to solve the situation after the hardware is obsolete and hence the bindings are stable. Tell me then - how is it possible for my laptop to boot correctly with its ACPI data which describes its hardware, and that ACPI data hardly ever has to be updated. Many PC systems have been doing this for years, with various degrees of success - but generally once you have a working system it stays working and never needs to have its ACPI data updated. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
And I'm just about to set my mailer up to automatically drop the uboot mailing list from future replies. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Fri, Feb 22, 2013 at 12:27:18AM +, Russell King - ARM Linux wrote: Actually we do this on PPC, the boot kernel image runs on three similar hardware platforms, the image has three DTBs built into it and the right one is selected at runtime. The kernel boot image does this (call it a second stage boot loader), not the primary boot loader. If that's something that PPC does, great. It's not something that we have any support for on ARM, nor do we have any intention at present to add support for it. Like I said, we do it as part of our boot structure, the mainline kernel doesn't really get affected by this. I'm only trying to describe my experience with real systems, in the field with DTB today. So, like it or not, we're going to face the same problem with DTBs that we face with the sprawing code we have in the kernel, and which we've had with the defconfigs. Linus _will_ at some point get pissed off with them and threaten to delete them. I see what you are saying (and I've seen the thread you are talking about). It is already the case on x86 that a kernel package can't boot out of the box. The distro builds a box-specific initramfs on boot that minimally includes enough modules to access the root fs storage. Grabbing a box specific DT as well is a tiny additional step. You're confused there. You're comparing the wrong things. No, I'm not - I'm drawing an analog. The initramfs and dtb are both sensitive to the machine's hardware and the distro scripts can already handle the existing hardware sensitivity fine. The fact the dtb is 'first' and the intitramfs is 'last' in the boot cycle doesn't matter at the point the distro script is run. However, that's not what we're talking about when we're talking about DTB. An initramfs doesn't describe the hardware. So you're comparing apples and oranges and expecting us to take you seriously for doing so. You are mincing details. When the distro scripts put a 'insmod megaraid' in the initramfs scripts so that it can access the disk that has the rootfs it is getting pretty damn close to 'describing the hardware'. Hence the analog I've drawn. In any event, if the distr boot scripts mess up the initramfs or provide the wrong dtb, the system doesn't boot. What you should be comparing in this instance is DTB with ACPI. ACPI describes the hardware on which you're booting your x86 kernel. It says what devices are present in the system (which may change while the kernel is running - think laptops which gain ports when you dock them.) If we are being pedantic, ACPI does a heck of a lot more than describing hardware. DT is closer to the old static x86 Intel MP table. But it doesn't matter, ACPI, and even Intel MP are part of a full-featured x86 boot firmware. In that sort of model lots of stuff like pinmux, low level CPU setup, memory region allocation, etc is done by the firmware. The embedded scenarios I am talking about have very simple firmware and boot the kernel on 'bare metal' where Linux is expected to take care of nearly everything on its own. As I've said, I think bare metal embedded is different from something with a full featured firmware and what I'm trying to say is that they deserve different treatments for their DTB. For this reason, I'm not sure that equating ACPI as part of a full featured firmware boot to DT in a bare metal scenario is entirely appropriate. Bear in mind, that like for storage, when the kernel is installed the system is *already running*. This means it knows what storage modules are needed, and similarly it knows the content of the DTB it is using. It can do three things with this: - See if /lib/device-tree/.. contains a compatible DTB, if so use the version from /lib - Save the DTB to /boot/my-board-dtb and use it - Realize that it is OEM provided and comes from the firmware, do nothing So things can very much be fully automated. You've a chicken and egg problem there. If the kernel is already running on a DT-based system, then it has already been provided with a DTB. That DTB is available from the kernel itself, and can be saved. But what's the point if _that_ kernel was already able to get it from somewhere - probably provided via the board firmware in the first place. As Steven Warren pointed out, the bootloaders have the ability to network boot a kernel, dtb, and initramfs in one go. So the install instructions for such systems simply point to the correct combination of all three from the install media, served over tftp or whatever. Saving the DTB is for the case where the install media/distro does not have a DTB for this system. In this case the initial boot would have been done with an 'out of tree' DTB that should be saved for the next boot. Don't forget that a distro initrd still has to contain enough modules to access the install media, so it is very possible that the initial distro installation on a virigin system will still
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote: The desired FPGA use case is DT updates after booting the kernel. This has nothing to do with FIT images. And if the FPGA tools generate the DTB, then it is certainly not tied to the kernel. Completely unrelated, but do you have any pointer for how to do this? Hot plugging a 'dtb fragment' into the kernel would be really handy.. I'm thinking something like adding a tree below a PCI controller describing a PCI device and sub nodes, similar to what Thierry was doing for his Avionics. How would interrupt maps and phandles be managed across the main dtb and the 'hot plugged' dtb? Regards, Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 06:19:15PM -0600, Scott Wood wrote: While embedded focused PPC stuff seems to tend to keep the kernel and DT together. At least on the Freescale side of embedded focused PPC stuff, we have not kept the kernel and DT together. It's actually U-Boot that the dts files in the kernel tree are tied to, since they contain Sorry to be unclear, I only ment that the dt sources themselves are in the kernel, not say, in the uboot repository or otherwise. out where to make the modification. Usually U-Boot is the only relevant loader for a particular board, but not always -- hence adder875-redboot.dts and adder875-uboot.dts. Even when U-Boot At least on ARM Kirkwood these sorts of differences are minimized by having Linux know how to reprogram the SOC's address map registers when it starts up .. Although that is helped by having all the boot loaders put the address map control registers at the same address ;) Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On 02/21/2013 08:22 PM, Jason Gunthorpe wrote: On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote: The desired FPGA use case is DT updates after booting the kernel. This has nothing to do with FIT images. And if the FPGA tools generate the DTB, then it is certainly not tied to the kernel. Completely unrelated, but do you have any pointer for how to do this? Hot plugging a 'dtb fragment' into the kernel would be really handy.. Look at Introducing Device Tree Overlays on devicetree-discuss and lkml. I'm thinking something like adding a tree below a PCI controller describing a PCI device and sub nodes, similar to what Thierry was doing for his Avionics. How would interrupt maps and phandles be managed across the main dtb and the 'hot plugged' dtb? Generally you don't describe the devices on PCI unless there are non-discoverable aspects like a sideband gpio. Rob -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
Dear Jason, In message 20130221232821.ga2...@obsidianresearch.com you wrote: own seems to be rather static and stable, and unlike software there is no way I can change it (soldering irons don't count). There is other hardware available (for example FPGA based) where this does not apply. Agreed.. We do that here as well, the DT is also used to describe the functionality inside FPGA(s). We do things like declare a GPIO controller inside the FPGA, then stack the bitbang MDIO/I2C on top of that, then declare a bunch of devices on those busses. DT makes this extremely straightforward. However, it is critical that the DT, kernel and FPGA are matched together - we always arrange things so that the DTB, kernel and FPGA config are bundled together and update atomically during firmware upgrade. Agreed. Xilinx's Zynq is a great example of this kind of stuff, FWIW. IIRC Indeed - Xilinx's Zynq, Altera's SoC FPGA, and others. Such highly flexible hardware configurations require a new level of software support that by far exceeds the classic static setups of more PC-like systems where the only change you would expect is adding or removing some PCI cards or the like. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 9:22 PM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote: The desired FPGA use case is DT updates after booting the kernel. This has nothing to do with FIT images. And if the FPGA tools generate the DTB, then it is certainly not tied to the kernel. Completely unrelated, but do you have any pointer for how to do this? Hot plugging a 'dtb fragment' into the kernel would be really handy.. This doesn't answer the full question on how FPGA tools generate DTB, but it is a huge problem for BeagleBone add-on hardware that we have some mechanism to dynamically load DT fragments. Pantelis posted some work in that direction[1] and has continued development of his patches and we've been using those extensively with BeagleBone kernel development[2]. It would be great if the FPGA folks would get on-board in supporting the dynamically loadable DT overlay fragments by reviewing and supporting upstream acceptance of the code. [1] http://lwn.net/Articles/531569/ [2] http://github.com/beagleboard/kernel/tree/3.8 I'm thinking something like adding a tree below a PCI controller describing a PCI device and sub nodes, similar to what Thierry was doing for his Avionics. How would interrupt maps and phandles be managed across the main dtb and the 'hot plugged' dtb? Regards, Jason ___ U-Boot mailing list u-b...@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
