From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Wed, 12 Mar 2014 11:46:11 +0100 Subject: [U-Boot] [PATCH 01/12] kbuild, mxs: use short logs for MXS images In-Reply-To: <20140312191929.6F55.AA925319@jp.panasonic.com> References: <1394503522-17744-2-git-send-email-yamada.m@jp.panasonic.com> <201403111252.11191.marex@denx.de> <20140312191929.6F55.AA925319@jp.panasonic.com> Message-ID: <201403121146.11172.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Wednesday, March 12, 2014 at 11:19:30 AM, Masahiro Yamada wrote: > Hello Marek, > > > > Cc: Marek Vasut > > > Cc: Fabio Estevam > > > Cc: Otavio Salvador > > > Cc: Lauri Hintsala > > > > You can drop Lauri from CC , I think this address is dead. > > It looks like Cc to Lauri is not bouncing so far. Strange, I remember the apx4 maintainer didn't work for B/G anymore. > > b5d5feab4a6974fe00272d3a3408300d8c8a473d u-boot.bin > > > > Given that u-boot.bin and spl/u-boot-spl.bin are packed into u-boot.sb , > > this is why you always see a different u-boot.sb . > > For other boot images, binary compare matched except a few bytes > difference which comes from time stamp. > > But, when I compared u-boot.sb > I had much more diffs than I expect for the difference of timestamp. > > I still cannot understand what is different from the others. Ah, right. The u-boot.sb is also encrypted with aes-128-cbc with zero key. The bootrom on mx23/mx28 has the encryption enabled by default (and it can be fused off), with the default key being all zeroes. That's why you see so many differences. > Anyway, that's good to know it worked on run test. > > > > I wish someone could do run test this patch. > > > > The patch is good, I have just a minor rant below, otherwise add my: > > > > Acked-by: Marek Vasut > > It's really appreciated. Thanks! No, thank _you_ for putting so much effort into this :) > > > -$(OBJTREE)/mxsimage.cfg: > > > $(SRCTREE)/$(CPUDIR)/$(SOC)/mxsimage.$(MKIMAGE_TARGET-y).cfg - sed > > > "s at OBJTREE@$(OBJTREE)@g" $^ > $@ > > > +quiet_cmd_mkimage_mxs = UIMAGE $@ > > > > Why don't we use 'MKIMAGE' here to be consistent ? Or 'MXSIMAGE' if we > > want to differentiate ? > > Good point. > MXSIMAGE is no good because the short log must be within 7 characters. > MKIMAGE is OK. > > Why UIMAGE? > > All explanation I can give is > just the mimic of scripts/Makefile.build which originates > from Linux Kernel. > > Around line 340, > > quiet_cmd_uimage = UIMAGE $(UIMAGE_OUT) > cmd_uimage = $(CONFIG_SHELL) $(MKIMAGE) -A $(UIMAGE_ARCH) -O linux \ > > > Anyway I do not persist on "UIMAGE". > If requested (or you can post a patch), it's OK to rename it, > althogh naming must be consistent throughout the code. Yes, I see. We shall eventually rename it to mkimage throughout the code. How shall we proceed? I see we have three options: - Post V2 of this patch - Fix the rest of the files which have this 'UIMAGE' in them and then post V2 - Postpone the fix and then do it globally I would be in favor of the second option. Best regards, Marek Vasut