From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Thu, 18 Oct 2007 18:43:37 -0400 Subject: [U-Boot-Users] FDT intentions in u-boot In-Reply-To: <20071019000813.21adb815@siona> References: <1192605168.3174.17.camel@p60635-ste.ids.de> <5CBE65F7D9232C47861CB09B0954861C87BD52@MAIL.infinitychannel.local> <471623F4.7000809@ge.com> <4717657E.1090606@ripcode.com> <4717B418.40904@ge.com> <20071019000813.21adb815@siona> Message-ID: <4717E199.6020807@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Haavard Skinnemoen wrote: > On Thu, 18 Oct 2007 15:29:28 -0400 > Jerry Van Baren wrote: > >> 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. > > Why not just generate a binary file (possibly compressed) and suck it > into an assembly file using .incbin? Yet Another Way to do the same thing. Dtc produces a binary blob or human readable assembly, might as well output assembly and skip the .incbin, but to each their own. Compressing probably isn't profitable, a blob is a few K uncompressed. On the other hand, u-boot knows how to uncompress, so anything is possible... >> 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. > > Yes, having a mutable device tree probably makes more sense for a > development board. But embedding it in the u-boot binary could save > some space in the "production" image. Is it possible to support both? Yes. Ultimately u-boot (mboot/linux) takes the address of the blob. You can store it anywhere you want, as long as it has an address. If it doesn't have an address (e.g. i2c eeprom, NAND flash), you simply need to copy it somewhere addressable (RAM) first. U-boot knows how to cp too. :-) > I don't know all that much about FDT, so I could be way off. I would > like to try it out with avr32 at some point though, after all the > basics are in place. > > H?vard You have the concepts OK. FDT is pretty cool stuff, much better than shared "bd" structures. gvb