On Mon, 21 Jan 2013, Peter Robinson wrote: > On Sun, Jan 20, 2013 at 10:50 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > On Sun, 20 Jan 2013, Jon wrote: > > > >> On Sun, Jan 20, 2013 at 8:34 PM, Jonathan Masters <jcm@xxxxxxxxxx> wrote: > >> > >> > - dtb. Need to get dtb built into 3.6 based F18 RC images in order to > >> > be ready for 3.7. Especially OMAP and Tegra. Dennis prefers built in > >> > standard package, ok with doing so in 3.7 kernel (kernel-dtb) and pulling > >> > back into RC images as an exception this one time. Saves reissuing 3.6 > >> > kernel package. Some testing done. Need to verify all targets have right > >> > bits in place and check 3.7 kernel upgrade. > >> > > >> > > >> Today I tried to get the pandaboard to boot using the 3.6 DTB from ausil > >> website, and was not successful loading the DTB from u-boot load addr. > >> I suspect for panda we might have to append the DTB to the zimage and run > >> mkimage on it. > >> That would be a great task for grubby or whatever part of the kernel > >> install that invokes mkimage. > > > > Please don't do that (the DTB append that is). This is a convenience > > for platform where it is impossible to update the bootloader in order > > to accommodate a DTB. A Pandaboard certainly does not fall into that > > category. > > > > And this DTB append is not something I'd advise Fedora to ever support > > unless there is absolutely no other way. Most of the Fedora ARM targets > > should have other ways. > > > > U-Boot has had native device tree on ARM for quite a while now. Please > > ensure that the U-Boot version on your Panda is sufficiently recent. > > It's the latest 2012.10 upstream release, it that sufficiently recent? Certainly. > But I agree on panda/beagle where we use the upstream I believe from > my reading the uboot should be supplying the DT blob so it should > "just work" the question is why isn't it and how do we tell if uboot > is supplying a DT blob? Well, you have to supply U-Boot with a DT blob. In an ideal world, the DT blob describes hardware and that doesn't change, so in theory you'd install the DT blob into the boot media alongside U-Boot and then you'd forget about both of them. A new kernel wouldn't need to care about either U-Boot or the DTB. In practice, things aren't as pretty as we'd like them to be, so mistakes and omissions in the DTB have to be fixed over time. This is why U-Boot is not providing a DTB on its own. However you need to tell U-Boot where to get the DTB. To do that, you load the DTB just as you would do with any regular image from whatever source, and then use the 'fdt addr' command to tell U-Boot where it is. From that point, U-Boot will be able to update the provided DTB with information such as the effective RAM topology, the ramdisk address and the kernel cmdline string before the kernel is booted. > I've done a lot of googling and reading but while there's a lot of > good resources for kernel driver developers for DT there's not really > a good resource that I've found for distro side and how to deal with > DT, how to check the uboot (or OFW or what ever other boot loader) > supplies a DT and whether it is good or not. Is there a way to see it > via /proc or /sys or some other means? With CONFIG_PROC_DEVICETREE=y in your kernel config, you'll be able to browse the DT content in /proc/device-tree/. > Commands to print it from uboot? There are subcommands to the U-Boot fdt command to do that. Try 'fdt help' at the U-Boot prompt. > Anything we need to specify in the kernel to ensure it attempts to > retrieve it first from the boot loader and a way to fail back if it > doesn't? The kernel doesn't retrieve anything. It expects the DTB to be available in memory, and its location passed to the kernel from the bootloader via register r2. With no DTB, the kernel is toast. That's why U-Boot needs to be told about the location of the DTB in order to pass that over to the kernel, possibly after some modifications of its own to the DTB. Nicolas _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
