From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Fri, 21 Sep 2012 13:33:15 -0500 Subject: [U-Boot] [PATCH v4 10/11] Add u-boot-pad.bin target to the Makefile In-Reply-To: <20120921054348.E7801203200@gemini.denx.de> (from wd@denx.de on Fri Sep 21 00:43:48 2012) Message-ID: <1348252395.19917.6@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 09/21/2012 12:43:48 AM, Wolfgang Denk wrote: > Dear Tom, > > In message > <5FBF8E85CA34454794F0F7ECBA79798F379F6FD992@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. -Scott