Hi Prafulla, hi Rabeeh,
from your point of view this is surely right.
Sadly, I don't know what the intention of the marvell.git u-boot is.
If you only want to support the sheevaplug than you're right. There is no need for any enhancements.
But for a hardware develpers purposes there is maybe something different.
I'm developing highly customized boards for industrial customers for a few years now (formerly based on TI DaVinci and Netsilicon ARM9 CPUs)
and there was always the need to bring up some hardware before you start the kernel. The alternative was to do the initialisation in early kernel init code
which isn't much fun for me and gives some other problems
So GPIO and legacy serial protocols like I2C and SPI are very helpful!
This gives you the change to do all the setup on board level by using well defined interfaces and no need to hack somewhere deep inside u-boot.
Which makes it more easy to keep your u-boot up to date with upstream.
So if Marvell plans to support industrial customers too it would be a good idea to also support some legacy protocols inside u-boot - as many other archs
The main purpose of u-boot is surely to boot the kernel but sometimes it is also essential to bring up some hardware (like PLLs for example) before you boot
What do you think about that?
I think, bootloader should be limited to it's objective , i.e. boot the kernel and rfs from supported media SF, NANDF (additional MMC, or USB), any specific h/w usage should be ported on OS level, otherwise boot loader may be equally fat AS kernel :-)
Mostly this is the approach with the u-boot development.
At this moment it U-boot Kirkwood support enables SF,NANDF and network interface, USB will be anther useful interface in the pipeline,
Apart from this I don't think other things are really needed in u-boot.
Prafulla . .