[DNX#2006033142000972] [U-Boot-Users] SPI support in U-boot

DENX Support System support at denx.de
Fri Mar 31 23:50:40 CEST 2006


Hello list,

inside the automatic U-Boot patch tracking system a new ticket
[DNX#2006033142000972] was created:

<snip>
> Hello Wolfgang,
> 
> Wolfgang Denk wrote:
> 
> >Good catch!
> >  
> >
> >>Is that OK? I also noticed the same mechanism being used in the 
> >>FPGA-related code.
> >>    
> >>
> >
> >I think your interpretation is correct.
> >  
> >
> And? :)
> 
> OK, so here are the questions:
> 
>    1. Should the code be left like that (i.e. some parts are executing
>       from FLASH instead of RAM) because it "just works for me" or it is
>       not acceptable to code like that?
>    2. What is the right way to do that: to use an uninitialized variable
>       and initialize it from board_misc_init_r with something like
> 
>                    myfuncptr = &myfunc + bd->reloc_off
> 
>       or to have initialized variable myfuncptr = myfunc and simply do
>       myfuncptr += bd->reloc_off in board_misc_init_r?
>    3. Ironically enough, I noticed that fpga_init() is declared like 
>       extern void fpga_init( ulong reloc_off ), but all the
>       implementations use void fpga_init(void)!
>    4. Wouldn't it make sense to add a small section to README,
>       explaining how to use function pointer tables in U-boot (not sure
>       how much sense it makes to begin with).
> 
> >It would be nice to preserve the currnt behaviour, so a patch  should
> >try  to  implement the required changes for all boiards. Testing will
> >have to be performed by the respective board maintainers, of course.
> >  
> >
> This seems to be difficult, since the current interface only allows you 
> to assert/de-assert a particular chipselect, but not to query which one 
> is currently active (so that "sspi" command could restore what was 
> before it. I guess, I can do three things:
> 
>    1. Extend sspi command, so that if there is only 1 arg, chip_select,
>       it will simply assert it and do nothing else
>    2. Hope, that people who use "eeprom" command don't really care about
>       "sspi" so far, otherwise it would be working!
>    3. Document the changes.
> 
> Thanks,
> Vladimir
</snip>

Your U-Boot support team




More information about the U-Boot mailing list