From: Simon Glass <sjg@chromium.org> The reason for providing a U-Boot library will not be obvious to many. Add a comment about this. Signed-off-by: Simon Glass <sjg@chromium.org> --- doc/develop/ulib.rst | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/doc/develop/ulib.rst b/doc/develop/ulib.rst index 56e4e437dbf..e6ee5aa98c9 100644 --- a/doc/develop/ulib.rst +++ b/doc/develop/ulib.rst @@ -10,6 +10,44 @@ build that functionality directly into a U-Boot image. Please read `License Implications`_ below. +Motivation +---------- + +U-Boot contains a vast arrange of functionality. It supports standard boot, +native execution (sandbox) for development and testing, filesystems, networking, +all sorts of boot protocols, drivers and support for about 1300 boards, a full +command line interface, a configuration editor / graphical menu, good Linux +compatibility for porting drivers, a powerful but efficient driver model which +uses Linux devicetree and many other features. The code base is fairly modern, +albeit with some dark spaces. Unusually for firmware, U-Boot provides a vast +array of tests. It can boot EFI apps or as an EFI app. It supports most relevant +architectures and modern SoCs. + +But of course time marches on and innovation must continue. U-Boot will clearly +be part of the picture in the future, but what is next? + +Ulib is an attempt to make U-Boot's functionality more easily available to other +projects, so they can build on it improve it or even replace parts of it. Ulib +aims to open up the capabilities of U-Boot to new use cases. + +Ulib also provides the ability to write the main program in another language. +For now C and Rust are supported, but Python should also be possible, albeit +with a significant amount of work. + +Few can predict where boot firmware will be in 10 years. The author of this file +rashly believes that we may have moved on from U-Boot, EFI and many other things +considered essential today. Perhaps firmware will be written in Rust or Zig or +Carbon or some other new language. Our AI overlords may be capable of writing +firmware based on a specification, if we can feed them enough electricity. Or it +could be that the complexity of SoCs grows at such a rate that we just carry on +as we are, content to just be able to make something boot. + +Ulib aims to provide a bridge from the best (more or less) of what we have today +to whatever it is that will replace it. Ulib is not an end itself, just a +platform for further innovation in booting, to new languages, new boot protocols +and new development methods. + + Building the Libraries ---------------------- -- 2.43.0