Hi Che-liang,
I am working on an open source secure bootloader based on U-Boot. Mostly I wrote boot logic (by boot logic I mean prompting user and listing available devices sort of things). If you see U-Boot as a platform, you can think of my project as an application running on top of U-Boot, except that my application is statically linked with U-Boot.
Usually the (old or new) API is used to separate the application from the GPLed U-Boot codebase to allow for proprietary applications. If you plan to link your application statically to U-Boot anyway, then I think that using the (external) API is not a good way to move forward.
The boot logic is running on ARM and x86. Through the project I have learned that certain APIs would be helpful, such as enumerating all available block device and drawing bitmaps on screen regardless of which driver (video or LCD) you are using.
Yes, I think what you actually are looking for is a proper device model in U-Boot. Actually we are in dire need for something like this in the whole of U-Boots codebase and we talk about it for a very long time (see for example [1]). This would ease progress in multiple areas, where currently we hack around this. See for example the SERIAL_MULTI code base or NET_MULTI. Both are isolated solutions for the same problem. As you note, video and block devices will also profit - USB will be another instance.
It was probably a misleading finding when I searched the code base: I saw only the external apps API implemented an API for enumerating available block device. So I thought improving the external apps API was the right place to go.
Alternatively (if not go the external apps API), we could have like common/cmd_enum_block_dev.c that does what I am planning to do, and I am happy to do this. What do you think?
I think we should aim at a pretty generic device interface. Currently I would think that this also needs to fit into the "configure U-Boot through the device tree" topic. The one will profit from the other.
As far as I know, Marek (on CC) is working towards this device tree model also. Coordinating the efforts will be a good thing.
Thanks! Detlev