Re: [PATCH v2 03/18] PCI: designware: Configuration space should be specified in 'reg'
On Thu, May 29, 2014 at 11:03:36AM -0500, Kumar Gala wrote: Just because the kernel doesn’t handle this is NO reason to change the way the DT works. The OF specs do not specify how to process a config type ranges entry, and we all mutually agreed that the only sane interpretation for such a thing would be to describe an ECAM memory space so generic code could potentially make use of it. Since designware is not ECAM it should not use config ranges. This has come up multiple times now, and the above is the consensus. 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: [PATCH 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
On Tue, May 06, 2014 at 07:03:51PM +0530, Kishon Vijay Abraham I wrote:
+Example:
+pcie@5100 {
+ compatible = ti,dra7xx-pcie;
+ reg = 0x51002000 0x14c, 0x5100 0x2000;
+ reg-names = ti_conf, rc_dbics;
+ interrupts = 0 232 0x4, 0 233 0x4;
+ #address-cells = 3;
+ #size-cells = 2;
+ device_type = pci;
+ ti,device_type = 3;
+ ranges = 0x0800 0 0x20001000 0x20001000 0 0x2000 /*
Configuration Space */
Configuration space should not show up in the ranges, please don't
copy that mistake from other drivers, put it in reg.
+ interrupt-map-mask = 0 0 0 0;
+ interrupt-map = 0x0 0 gic 134;
The HW cannot decode INTA/B/C/D?
+#define PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI 0x0034
+#define PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI 0x0038
+#define INTABIT(0)
+#define INTBBIT(1)
+#define INTCBIT(2)
+#define INTDBIT(3)
+#define MSI BIT(4)
+#define LEG_EP_INTERRUPTS (INTA | INTB | INTC | INTD)
Oh, it can, it would be wise to export this from the driver. Look at
the latest patches from Srikanth Thokala for the Xilinx PCI driver to
see how this should look
+static int dra7xx_pcie_establish_link(struct pcie_port *pp)
+{
+ u32 reg;
+ int retries = 1000;
+ struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
+
+ if (dw_pcie_link_up(pp)) {
+ dev_err(pp-dev, link is already up\n);
+ return 0;
+ }
+
+ reg = dra7xx_pcie_readl(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD);
+ reg |= LTSSM_EN;
+ dra7xx_pcie_writel(dra7xx-base, PCIECTRL_DRA7XX_CONF_DEVICE_CMD, reg);
+
+ while (--retries) {
+ reg = dra7xx_pcie_readl(dra7xx-base,
+ PCIECTRL_DRA7XX_CONF_PHY_CS);
+ if (reg LINK_UP)
+ break;
+ usleep_range(10, 20);
+ }
+
+ if (retries = 0) {
+ dev_err(pp-dev, link is not up\n);
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
It would be really nice to see the link bring up process live in the
PCI core, every driver seems to have its own take on this.
The PCI-E spec requires a 100ms delay after link bring up (aka hot
reset) before sending any configuration TLPs.
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: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On Tue, May 07, 2013 at 09:15:00AM -0400, Eduardo Valentin wrote: But broadly the direction seems that drivers should have minimal dependencies so, eg, the thermal maintainer compiling for x86 should be able to compile test/static analyze your driver.. Well, I do not see much of this attempt actually. Do you have some link / evidene that shows someone who actually cares about compiling drivers for targets that they are not used for? On this specific driver, I actually have had exactly the opposite advice [1]. I am not convinced people actually want to do that. There was a discussion a bit ago, but I can't find a link.. The context was subsystem maintainers are being asked to look after more code with the DT transition moving things out of arch/arm and at least one complained they couldn't even compile test on x86... But again, I can't find a link and you are right, there are lots and lots of 'depends ARCH..' style things in kConfig already. Lets just call it something to think about. Thats the idea behind this config option. It follows the same design as CONFIG_ARCH_HAS_CPUFREQ, for instance. That is entirely contained inside arch/arm and doesn't involve drivers. It actually goes outside arch/arm. Hm, must have missed that, seemed like all it did was control including drivers/cpufreq/Kconfig within the ARM kconfigs.. And unicore32 copied the name, but did the same thing. 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: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On Tue, May 07, 2013 at 12:34:13AM +0300, Aaro Koskinen wrote: On Mon, May 06, 2013 at 05:00:56PM -0400, Eduardo Valentin wrote: Introduce HAS_BANDGAP config entry. This config is a boolean value so that arch code can flag is they feature a bandgap device. Maybe it could be mentioned that omap-thermal already depend on this? At least for a random reviewer it was not immediately clear why this is added, especially since there were no users for it in subsequent patches. I looked (very briefly), and it seemed like omap-thermal is self contained and doesn't need arch support? I get the impression it is desired to minimize driver kconfig dependencies to the minimum required to compile to increase build testing coverage, so maybe it would be appropriate to drop this entirely? 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: [RESEND][PATCH 1/3] arm: dts: introduce config HAS_BANDGAP
On Mon, May 06, 2013 at 08:23:13PM -0400, Eduardo Valentin wrote: I get the impression it is desired to minimize driver kconfig dependencies to the minimum required to compile to increase build testing coverage, so maybe it would be appropriate to drop this entirely? Well, it is also desired to compile things to the correct target right? There is some of that too.. But broadly the direction seems that drivers should have minimal dependencies so, eg, the thermal maintainer compiling for x86 should be able to compile test/static analyze your driver.. Thats the idea behind this config option. It follows the same design as CONFIG_ARCH_HAS_CPUFREQ, for instance. That is entirely contained inside arch/arm and doesn't involve drivers. 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 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 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 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
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, 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
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 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
