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