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

[Simon Glass]

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

:-) It's just a pool of literals, basically in this case a list of
string pointers, placed close to the PC address so that you can easily
access them with a PC-relative load. It's not an ARM think though -
lots of CPUs use them. The alternative is to encode the full address
in the instruction, so I suppose it's this:

ldr r0, fred    (which turns into ldr r0, [pc, #offset of fred])

fred:
   DCD 0x12345678


instead of:

mov r0, #0x12345678

Regards,
Simon