Dear Scott Wood, > On 09/21/2012 12:43:48 AM, Wolfgang Denk wrote: > > Dear Tom, > > > > In message > > <5fbf8e85ca34454794f0f7ecba79798f379f6fd...@hqmail04.nvidia.com> you > > > > wrote: > > > If you flash u-boot-dtb-tegra.bin, you'll get a fully functioning > > > U-Boot. There's an intermediate file (u-boot-dtb.bin) that I assume > > > is u-boot.bin+dtb - I'm not sure why it's left around - Allen could > > > comment here. > > > > I _dislike_ the idea of having image names which include architecture > > or even board parts. I would really like to have generic names, that > > can be used in a consistent way across platforms, architectures and > > boards. > > > > > So in my eyes, all you really need is u-boot-dtb-tegra.bin - an > > > unwieldy name, to be sure, but it seems to satisfy your request for > > > > a > > > > > Soc identifier in the name. I voted for just having u-boot.bin be > > > > the > > > > Please reconsider. I definitely do NOT want to have SoC names or that > > in any such images! > > > > > > IIRC, the original idea was to provide image names (common for all > > architectures, SoCs, boards) that only depend on where you install > > U-Boot to. in this way, we would have: > > > > - u-boot.bin for the generic case (say, for installation into NOR > > > > flash, no SPL or similar needed). > > > > - u-boot-nand.bin > > > > for installation in NAND (with all needed headers, > > padding etc. included) > > > > - u-boot-onenand.bin > > > > for installation in OneNAND > > > > - u-boot.sd for installation on a SDCard > > > > [actually we have an inconsistency in names here; this > > should have been "u-boot-sd.bin" or maybe even better > > "u-boot-sdcard.bin"] > > > > etc. > > > > It is very important to me that we do NOT include any architectures, > > SoCs, or board specifc parts in the names because this will cause > > major PITA for all kind of automatic test suites etc. > > The awkwardness with naming based on nand/onenand/sd is that we no > longer have build infrastructure that is specific to the type of boot > device -- and IIRC with some of the newer SPL targets, the same image > works on multiple types of boot device. > > Having u-boot.bin be the final output regardless of internal > implementation details such as spl would avoid that problem, and be > even nicer to automated testing than the nand/onenand/sd names.
On the other hand, I use u-boot.bin and expect it to always be the raw linked binary of u-boot . > -Scott Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot