On 09/17/12 10:32, Scott Wood wrote: > On 09/17/2012 11:51:52 AM, Tom Rini wrote: >> On 09/17/12 09:27, Scott Wood wrote: >> > On 09/17/2012 04:24:34 AM, José Miguel Gonçalves wrote: >> [snip] >> >> If no one else has anything against, I will change the name of the new >> >> target to u-boot-pad.bin >> > >> > What exactly is u-boot-pad.bin supposed to be? I hope that's not being >> > proposed as the final output file the user sees. >> > >> > With old nand_spl we had u-boot-nand.bin for the final concatenated >> > binary, but that's not appropriate for a generic spl. I think it would >> > be better for the user to see "u-boot.bin" as the actual image to >> put on >> > the boot device, regardless of implementation details like spl, if >> > there's no requirement of a specific file format. The second stage >> > could become "u-boot-main.bin" or similar on builds where spl is used. >> >> We need some name that means "U-Boot SPL with U-Boot tacked on at the >> end". This can optionally be padded to a defined size to make writing >> to hardware easier. We also have the problem that "u-boot.bin" already >> means something so it needs to be clear. > > u-boot.bin has traditionally (except for nand_spl and derivatives) meant > the final image ready to put into flash, after any platform-specific > layout issues are taken care of (e.g. on mpc83xx it will have a reset > control word embedded, on mpc85xx it will be padded to 512K with a reset > vector at the end, etc.). That we did the tweaking in the linker script > rather than after linking seems like an inconsequential implementation > detail.
Right, but it's also just objcopy (with OBJCFLAGS) -O binary of, and this is the biggie to me, just U-Boot. >> I further fear that even if we >> made an "out" directory if we put u-boot.bin in there and it's not the >> same as the objcopy -O binary u-boot u-boot.bin as before we've violated >> the rule of least surprise and the end user problems from people that >> read "the" document (that happened to be out of date) will be our >> problem. > > In this case I think you can't meet one user's expectations without > violating another's. I think it's more important to make it clear to > the user what file they're supposed to put into flash. Users of > platforms that are currently supported by nand_spl would probably like > to continue seeing u-boot-nand.bin -- it's a tradeoff of historical > stability versus current consistency. Right. So I'm saying we need to set new expectations for everyone and some human helper symlinks to help. A new top-level out or images or something, with symlinks inside. >> In short, at least a few people have said something along the lines of >> "We need generic output nameo $mediums and targets" but there's two hard >> problems, one of which is that every SoC _needs_ things tweaked just so >> (no header? no boot!), sometimes wants things tweaked further (pad the >> final image out to be easier to write to $medium) and sometimes needs >> multiple files (the whole of 'SPL' will be read so it must fit into >> $SMALL_MEMORY). The other is naming. > > A simple concatenation of a padded SPL plus the main U-Boot was good > enough for all the nand_spl boards AFAIK, so it's not quite every SoC > that needs something special here. For those that do require a special > format (or multiple files) with a file extension that is familiar to > people working with that platform, using that extension makes sense. > "pad" does not, and a proliferation of SoC-specific suffixes isn't much > better. I think we're running into PowerPC vs ARM "fun". We've got 7 or so different "whack the image for this SoC for this medium" type things already. -- Tom _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot