From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Thu, 18 Oct 2007 15:29:28 -0400 Subject: [U-Boot-Users] FDT intentions in u-boot In-Reply-To: <4717657E.1090606@ripcode.com> References: <1192605168.3174.17.camel@p60635-ste.ids.de> <5CBE65F7D9232C47861CB09B0954861C87BD52@MAIL.infinitychannel.local> <471623F4.7000809@ge.com> <4717657E.1090606@ripcode.com> Message-ID: <4717B418.40904@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Zach Sadecki wrote: > Jerry Van Baren wrote: >> Zach Sadecki wrote: >>> I have some confusion about FDT and what the intentions are for its >>> support and usage in u-boot. [snip] >>> What is the intent for future support? Creation of a device tree from >>> scratch? That seems to be what the original (open firmware) intention >>> of FDTs were. (Allowing a bootloader to pass a implementation specific >>> hardware list up to an operating system.) And the current Linux >>> implementation is a little backwards from that (let kernel compiler give >>> you a device tree which you then have to give to the bootloader to pass >>> back up to the kernel during boot). It would seem to make more sense >>> (in my limited understanding of FDT) to allow the bootloader to be able >>> to generate this itself without dependence on a prior kernel compilation >>> for that particular hardware... >> >> There is no intention to create blobs from scratch in the boot loader >> (u-boot). If you look at some of the SOC (8[3456]xx) blobs, you would >> see that that would be a nightmare, your fingers would be bloody stubs >> by the time you typed it all in, and then you would find you had a >> syntax error and have to start all over. >> >> (I think that is the link, the filters at work don't let me browse it.) > What I meant was not typing it in by hand, but setting it up in your > board.h file so that it can be generated during compile or during boot. > But if you can embed it into the u-boot image itself, maybe this is > unnecessary. It seems as I look deeper into the code it does support > this to some extent (ft_build.c), but I think that it might not be as > thorough as it would need to be to work. Hmmm /me thinks you are confusing libfdt and The Other Way of supporting FDT blobs with the reference to ft_build.c. While it is theoretically true that you could generate the blob from nothing, modifying and augmenting a static initial blob makes more sense. I would not advocate embedding the FDT blob in u-boot but, if I were to do so, I would use the dtc to generate an assembly language output (actually, a lot of define byte statements) and then compile that in the u-boot build. A better approach IMHO (subject to change) is to burn the FDT blob into a separate flash area so it can be updated later without rebuilding u-boot or downloading it via TFTP. Obviously, this would be an engineering tradeoff and /your/ best choice for your situation is quite likely different from someone else's choice for their (different) situation. >> On the other hand, 98% of the typical FDT blob (to make up a >> statistic) is static. The intent of u-boot FDT support is to >> externally (via the dtc) generate a blob with the 98% already filled >> in and have u-boot configure the 2% that is board-specific or user >> selected. >> >> The blob can be baked into u-boot, stored in flash separately from >> u-boot, or loaded as part of the kernel (baked into the kernel image >> in ROM, tftped separately from the kernel, tftped as part of the >> kernel image). >> >> We are in the tool business, how to use the tool is up to the user. ;-) >> >>> If the plans aren't for u-boot to have the ability to generate a device >>> tree would it be reasonable to create one and embed it in the u-boot >>> binary somehow? (so that another unique binary wouldn't have to be >>> loaded into another separate flash partition) >>> >>> Thanks, >>> Zach >> >> That option is already there as a multi-image boot image, one part of >> the image being a FDT blob. > I've seen a little info on using mkimage to add an initrd, but nothing > specifically with fdt (or dtb). I've seen no info on 'baking it into > u-boot' that you mentioned above... Is there any documentation on how > to do either of these? > > Thanks, > Zach I haven't tried to make a multi-image linux/FDT blob/RAM disk an may have misspoke about it being an option. What I was recalling is something Timur did which was using mkimage to wrap a standalone blob. Baking in - explained above, use dtc to generate assembly and link it in with u-boot. It may make sense in places, but I would think hard about if it made sense before doing it. gvb