[U-Boot] [PATCH] Add 'sf update' command to do smart SPI flash update

Mike Frysinger vapier at gentoo.org
Fri Aug 19 20:57:47 CEST 2011


On Friday, August 19, 2011 14:25:46 Simon Glass wrote:
> On Fri, Aug 19, 2011 at 12:19 PM, Mike Frysinger wrote:
> > On Friday, August 19, 2011 14:07:16 Simon Glass wrote:
> >> On Fri, Aug 19, 2011 at 9:14 AM, Mike Frysinger wrote:
> >> > On Friday, August 19, 2011 09:47:04 Simon Glass wrote:
> >> >> +static int spi_flash_update(struct spi_flash *flash, u32 offset,
> >> >> +             size_t len, const char *buf)
> >> >> +{
> >> >> +     const char *oper;
> >> > 
> >> > i wonder if there'd be any code size difference if we had:
> >> >        static const char * const opers[] = {
> >> >                "malloc",
> >> >                "read",
> >> >                ...
> >> >        };
> >> >        const char *oper;
> >> >        ...
> >> >                oper = 0;
> >> >        ...
> >> >                ++oper;
> >> >        ...
> >> >                ++oper;
> >> >        ...
> >> >        printf("...%s...", ..., opers[oper]);
> >> > 
> >> > i hope it'd be slightly smaller as you would be loading up a small int
> >> > in the for loop and not an entire pointer ...
> >> 
> >> It's exactly the same code/data size on ARM, but perhaps smaller on a
> >> different architecture. I like that approach anyway so will change it.
> > 
> > i know on Blackfin at least, doing something like:
> >        i = 0;
> > will expand into a 16bit insn:
> >        R0 = 0;
> > and the follow up:
> >        ++i;
> > will be another 16bit insn:
> >        R0 += 1;
> > 
> > while something like:
> >        void *foo = "foo";
> > will expand into two 32bit insns:
> >        P0.L = _some_label_for_string;
> >        P0.H = _some_label_for_string;
> > and since there will be no known relationship between the diff strings at
> > the C -> asm stage (since string placement is done by the linker), each
> > string load will be a sep pointer load.
> > 
> > i imagine that the normal ARM insn set sucks at this kind of code
> > density, but i'd think their reworks (like thumb and friends) would be
> > much better.
> 
> Well it's just a literal pool access on ARM, so a single instruction
> on both ARM and Thumb. Not sure how else the compiler would do it...

i'm not as well versed in ARM lingo as you to understand what "literal pool 
access" means ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20110819/b671abf9/attachment.pgp 


More information about the U-Boot mailing list