On 22:23 Fri 13 Apr , Sascha Hauer wrote: > On Fri, Apr 13, 2012 at 03:37:04PM +0000, ANDY KENNEDY wrote: > > I first saw Barebox about a year ago, did a little poking around and > > realized that this seems like the way to go for booting an embedded > > system. I am, however, meeting opposition to implementing Barebox in > > our current system. I need some help on questions I cannot answer. If > > you could, please take the time to answer the following few issues. > > > > 1) I have a concern that barebox is not mainstream enough yet. > > Well by using it you could make it a bit more mainstream ;) > > > > > 2) I have a feeling we will always be porting everyone's bsp (that > > already has a working u-boot) to barebox. > > I'd say that usually barebox better abstracts from the hardware, so > different boards usually feel much more the same. With U-Boot the usage > often differs across different boards. Having a common environment > becomes a real advantage when you have many different boards. > > > 3) I also don't really see the real advantage over standard u-boot > > (what's the 'killer' application?). > > For me the basic killing feature is that barebox has filesystem support > which means that you can mount filesystems and only have one > 'ls' (cp, rm,..) command to access all files and devices. U-Boot instead > has a set of these commands for each filesystem and device: > > fatload <interface> <dev[:part]> <addr> <filename> [bytes] > nand read - addr off|partition size > mmc read addr blk# cnt > eeprom read devaddr addr off cnt > > All these commands have a different syntax and are non obvious to use. > Also note that the target of all the commands above is a chunk of plain > SDRAM. This means that in case of a system update you always have to > copy the update image first from the device to SDRAM and then from SDRAM > to the target device. To do this you have to know where SDRAM is (varies > across different boards) and also the size of the update image is > limited by the amount of free SDRAM you have. With barebox all this goes > down to for example cp /mnt/usb0-fat/rootimage /dev/nor0.root. > > There are other things aswell: > > - barebox has a sane configuration system (U-Boot is configured using > several thousand CFG_* defines) > - barebox can always start itself as a second stage loader (with U-Boot > you have to compile a special ramboot image which then again can't > start first stage) > - barebox can start zImages, raw Linux images, uImages, all using the > same command (U-Boot is limited to uImages) you forget Android Image > - barebox has command line options, U-Boot only supports positional > arguments > - barebox has a driver model which means that you can register devices > which automatically find the correct driver. > - you can put your environment into files as opposed to 'executable > environment variables' in U-Boot we have full feature bootp support with a dhcp client supporting vondor id client id client uuid user class and very esay to extend we have menu support that you can write in c or shell we have shell support with shell script (file) U-Boot use var to store the shell which is quite hard to customised and make it nearly imposssible to foactorize. On barebox we have a defaultenv that you just need to cusmoize in your board without having to touch it. (this simplify to adding of platform quite a lot). We have DFU support, srial of USB device that you can select at the runtime (take a look on the Atmel reference baord or the Calao) We have pull support that allow you to have recurent task evenif we do not support IRQ (impossible in u-boot) And if you need modules support to extend barebox feature at the run time And framebufer support (derived from the kernel) I'm sure I forget some feature but barebox is design to easly share the code with the kernel and to simplify the life of the developper and the end customer And I implement complex boot sequence easly in barebox where in U-Boot evenif I known perfecly I get hard time. Best Regards, J. _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
