On Sun, Apr 19, 2009 at 04:59:41PM -0500, Kumar Gala wrote:
On Apr 19, 2009, at 2:48 PM, Robert Schwebel wrote:
On Sat, Apr 18, 2009 at 08:54:41PM +0200, Wolfgang Denk wrote:
u-boot-v2 is an interesting approach in several aspects, but since it was made publicly visible nearly two years ago it did not collect much of a community around it.
Right; part of the reason is it was always something we used to solve our problems, and we didn't do much marketing around it. Nevertheless, it *does* solve our problems very well, and each time we have to work with v1 again it's weaknesses show up again and again.
What's the summary of features that v2 has that v1 doesnt?
- Kconfig support - Linux Build support - Clean device registration and driver matching, so there can always be multiple instances of a device - filesystem support. U-Boot starts by mounting a ramfs on /, populating a devfs under /dev and load the environemt to /env. Use the normal commands like cd, ls, rm, cat,... - mount: there is no mmc_ls and mmc_load and stuff like that. Just mount your device and use ls - The environment is not limited to a variable store, instead it's a ramfs which can store variables, scripts, splashimages or whatever - module support - One image for all storage types. Well, the hardware has to support it, but on i.MX27 the same image can start from RAM, Nor Flash and NAND Flash. - USB Network support - A network phy device layer, so phys are handled in a generic way. Their registers can be showed with md -s /dev/phy0 (and of course changed with mw) - A much simpler clock implementation (Linux clocksource). So basically what an architecture needs to do is to specify the timer resolution and provide a read_timer function which returns the raw timer value. - getopt support, so there is no need for positional arguments - A simple editor to edit scripts - readline usable on the command line to allow for interactive scripts - a sandbox port to run U-Boot on the host including tap ethernet - different bugs to hunt for
Sascha