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

[Simon Glass]

Hi Mike,

On Fri, Aug 19, 2011 at 12:19 PM, Mike Frysinger <vapier at gentoo.org> 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...

>
> do we leverage thumb at all in ARM u-boot ?  or am i crazy/stupid for thinking
> this could possibly be a good thing ?
> -mike
>

No we don't. IMO if available we should use Thumb 2 instead of ARM
most of the time - it is a lot smaller and runs about the same speed.

Regards,
Simon