[U-Boot] U-Boot Graphics Library?
Hi,
We are currently using a very rudimentary graphics features attached to U-Boot. It can only display bitmap images. We use this in Chromium to composite a display for the various screens we need to display in U-Boot. Unfortunately the graphics screens get quite large when using multiple languages since they are pre-rendered.
Is there any interest in a simply graphics library in U-Boot, that can display things on the screen? We already have bitmap support, but could perhaps add outline font support (e.g. freetype) as well. This might allow display of simple boot menus or booting information. A board could create a structure containing a list of things to display (text, bitmaps) and pass it to the graphics library for rendering using existing functions and the new font support.
If we do this, rather than re-invent the wheel, does anyone have any suggestions on a very small and simple existing library that we could bring in to do this?
Regards, Simon
Dear Simon Glass,
In message CAPnjgZ12psS6sOnsuMU-VrrXWxS04Zb+grqqGUKNw2DTzBupag@mail.gmail.com you wrote:
We are currently using a very rudimentary graphics features attached to U-Boot. It can only display bitmap images. We use this in Chromium to composite a display for the various screens we need to display in U-Boot. Unfortunately the graphics screens get quite large when using multiple languages since they are pre-rendered.
Is there any interest in a simply graphics library in U-Boot, that can display things on the screen? We already have bitmap support, but could perhaps add outline font support (e.g. freetype) as well. This might allow display of simple boot menus or booting information. A board could create a structure containing a list of things to display (text, bitmaps) and pass it to the graphics library for rendering using existing functions and the new font support.
This sounds like a nice feature. Initially. Then I start wondering if this really belongs into a boot loader. Instead of doing fancy graphics stuff, we should IMO rather focus on booting the OS of your choice really fast, and let this do the fancy GUIs. Or?
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Wed, Jan 16, 2013 at 11:46 AM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ12psS6sOnsuMU-VrrXWxS04Zb+grqqGUKNw2DTzBupag@mail.gmail.com you wrote:
We are currently using a very rudimentary graphics features attached to U-Boot. It can only display bitmap images. We use this in Chromium to composite a display for the various screens we need to display in U-Boot. Unfortunately the graphics screens get quite large when using multiple languages since they are pre-rendered.
Is there any interest in a simply graphics library in U-Boot, that can display things on the screen? We already have bitmap support, but could perhaps add outline font support (e.g. freetype) as well. This might allow display of simple boot menus or booting information. A board could create a structure containing a list of things to display (text, bitmaps) and pass it to the graphics library for rendering using existing functions and the new font support.
This sounds like a nice feature. Initially. Then I start wondering if this really belongs into a boot loader. Instead of doing fancy graphics stuff, we should IMO rather focus on booting the OS of your choice really fast, and let this do the fancy GUIs. Or?
The problem is that a major purpose of the GUIs is to allow installing an OS from a USB stick/SD card, since the OS may have become corrupted and unbootable. We have looked at keeping around a separate OS image for this (e.g. in an available disk partition), but so far that hasn't proved practical since that itself can be fairly easily overwritten and we then have a doorstop.
The less fancy, the better, but consumers have certain expectations that force us to make some efforts...there is already a single font in U-Boot, but it's not good enough for multi-language pretty displays unfortunately.
Regards, Simon
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de "Go to Heaven for the climate, Hell for the company." - Mark Twain
Dear Simon Glass,
In message CAPnjgZ3rNhvL98JEOPV=90u-Wr3iEqs8QgqYaz=bOohRFRJeEA@mail.gmail.com you wrote:
The problem is that a major purpose of the GUIs is to allow installing an OS from a USB stick/SD card, since the OS may have become corrupted and unbootable. We have looked at keeping around a separate OS image for this (e.g. in an available disk partition), but so far that hasn't proved practical since that itself can be fairly easily overwritten and we then have a doorstop.
The less fancy, the better, but consumers have certain expectations that force us to make some efforts...there is already a single font in U-Boot, but it's not good enough for multi-language pretty displays unfortunately.
Why don't you load and start a small recovery system from the USB stick then? I don't see why you need a GUI to do that. This could be mostly made automatic.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Wed, Jan 16, 2013 at 2:40 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ3rNhvL98JEOPV=90u-Wr3iEqs8QgqYaz=bOohRFRJeEA@mail.gmail.com you wrote:
The problem is that a major purpose of the GUIs is to allow installing an OS from a USB stick/SD card, since the OS may have become corrupted and unbootable. We have looked at keeping around a separate OS image for this (e.g. in an available disk partition), but so far that hasn't proved practical since that itself can be fairly easily overwritten and we then have a doorstop.
The less fancy, the better, but consumers have certain expectations that force us to make some efforts...there is already a single font in U-Boot, but it's not good enough for multi-language pretty displays unfortunately.
Why don't you load and start a small recovery system from the USB stick then? I don't see why you need a GUI to do that. This could be mostly made automatic.
That's exactly what we do, yes!
But the user has to be told that there is a problem, and be able to select their language so they can understand the instructions. The USB image needs to be downloaded, and the stick inserted. Also we require that the stick be inserted while we are watching, since this shows that the user is actually present, and it is not a remote attacker causing recovery. All of this means instructions are needed, hence the bitmaps and text.
Regards, Simon
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Brain: an apparatus with which we think we think. - Ambrose Bierce
On 16.01.2013 23:54, Simon Glass wrote:
Hi Wolfgang,
On Wed, Jan 16, 2013 at 2:40 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ3rNhvL98JEOPV=90u-Wr3iEqs8QgqYaz=bOohRFRJeEA@mail.gmail.com you wrote:
The problem is that a major purpose of the GUIs is to allow installing an OS from a USB stick/SD card, since the OS may have become corrupted and unbootable. We have looked at keeping around a separate OS image for this (e.g. in an available disk partition), but so far that hasn't proved practical since that itself can be fairly easily overwritten and we then have a doorstop.
The less fancy, the better, but consumers have certain expectations that force us to make some efforts...there is already a single font in U-Boot, but it's not good enough for multi-language pretty displays unfortunately.
Why don't you load and start a small recovery system from the USB stick then? I don't see why you need a GUI to do that. This could be mostly made automatic.
That's exactly what we do, yes!
But the user has to be told that there is a problem, and be able to select their language so they can understand the instructions. The USB image needs to be downloaded, and the stick inserted. Also we require that the stick be inserted while we are watching, since this shows that the user is actually present, and it is not a remote attacker causing recovery. All of this means instructions are needed, hence the bitmaps and text.
Yes, we were thinking about the same use case: An U-Boot based device where U-Boot is responsible for the whole system update, including the OS. The user has to insert an USB stick or SD card containing the files to be updated. Then U-Boot has to copy these files to the NOR, NAND or whatever the system boots from. The only user interface is a display, no serial console. On the display something like "Please insert the USB stick", "Update in progress, please wait", "Update successfully finished", "Update error xx" has to be shown, then.
Best regards
Dirk
I thik the GUI is not be included in "U-boot", if you want a gui you can coding a software boot and load by UBOOT.
right?
boot done.
update done .
reboot to uboot and normal bring up your OS.
uboot is uboot .
It's not GUI-boot.
2013/1/16 Dirk Behme dirk.behme@de.bosch.com
he user has to insert an USB stick or SD card containing the files to be updated. Then U-Boot has to copy these files to the NOR, NAND or whatever the system boots from. The only user interface is a display, no serial console. On the display something like "Please inser
Dear Dirk,
In message 50F7A2D7.90405@de.bosch.com you wrote:
Yes, we were thinking about the same use case: An U-Boot based device where U-Boot is responsible for the whole system update, including the OS. The user has to insert an USB stick or SD card containing the files to be updated. Then U-Boot has to copy these files to the NOR, NAND or whatever the system boots from. The only user interface is a display, no serial console. On the display something like "Please insert the USB stick", "Update in progress, please wait", "Update successfully finished", "Update error xx" has to be shown, then.
This has been done before, and probably many times. The last time I did that for a customer I ended up with a 7.5 kB / 111 lines shell script. OK, I did not have to support a multi-language interface, and it was all text based, but it included pretty good error handling and all the logic even to test for a specific dongle to be installed to enable the update. [And yes, it revealed a number of hush bugs, too. :-( ]
I do not relly see why we need a graphics library with all bells and whistles up to and including support for TTF here...
If you need a fancy GUI, please use an OS.
Best regards,
Wolfgang Denk
Dear Simon,
In message CAPnjgZ0vjatrA5X_SuQC4j8-0HC=FOGcj9sSk_zqyCet6iMJhQ@mail.gmail.com you wrote:
Why don't you load and start a small recovery system from the USB stick then? I don't see why you need a GUI to do that. This could be mostly made automatic.
That's exactly what we do, yes!
But the user has to be told that there is a problem, and be able to select their language so they can understand the instructions. The USB image needs to be downloaded, and the stick inserted. Also we require
Why has all this to be implemented in U-Boot? My PC BIOS will not tell me which files I have to download to install, say, a BIOS update.
Even if you need this, you can probably implement a simple menu to select the language, and then load a single page (bmp image) with the rest of the needed information.
that the stick be inserted while we are watching, since this shows that the user is actually present, and it is not a remote attacker causing recovery. All of this means instructions are needed, hence the bitmaps and text.
Well, you can always come up with a set of requirements and mark these as mandatory and not negotiable. This is the marketroid's approach. As an engineer, we should ask ourself if these requirements make sense, or if there are other ways to satisfy the (probably reasonable) wishes of the users.
I think what you request here is technically possible, but it exceeds the limits of what should be done in a boot loader. I am pretty much convinced that you can get the same results with more features and functionality and less efforts when booting into a small recovery configuration under Linux instead.
Best regards,
Wolfgang Denk
On 16/01/2013 22:46, Simon Glass wrote:
Hi Wolfgang,
Hi Simon,
This sounds like a nice feature. Initially. Then I start wondering if this really belongs into a boot loader. Instead of doing fancy graphics stuff, we should IMO rather focus on booting the OS of your choice really fast, and let this do the fancy GUIs. Or?
The problem is that a major purpose of the GUIs is to allow installing an OS from a USB stick/SD card, since the OS may have become corrupted and unbootable. We have looked at keeping around a separate OS image for this (e.g. in an available disk partition), but so far that hasn't proved practical since that itself can be fairly easily overwritten and we then have a doorstop.
Well, if a separate OS image can be overwritten, U-Boot image can be overwritten too, and then the board does not boot at all.
I provided for a customer a solution with a separate OS and a small rootfs as initramfs, and even if it is theoretically possible to destroy this image, it has the same probability that U-Boot has to disappear. It still seems to me a good solution, with the drawback to use much more resorces (Flash) that a U-Boot solution can use. Anyway, with the current size of NAND flash, even this drawback is not very important in many projects.
Maybe more as a GUI-guided recovery, the customer needs a way to rescue the system when everything goes wrong. Providing a booting SD or USB card, that can complete restore the system, seems to be a good way, or at least it was in my case.
Implementing it in U-Boot seems to me overkilling, but is only my 2 cents ;-).
Best regards, Stefano
Hi,
On Fri, Jan 18, 2013 at 1:18 AM, Stefano Babic sbabic@denx.de wrote:
On 16/01/2013 22:46, Simon Glass wrote:
Hi Wolfgang,
Hi Simon,
This sounds like a nice feature. Initially. Then I start wondering if this really belongs into a boot loader. Instead of doing fancy graphics stuff, we should IMO rather focus on booting the OS of your choice really fast, and let this do the fancy GUIs. Or?
The problem is that a major purpose of the GUIs is to allow installing an OS from a USB stick/SD card, since the OS may have become corrupted and unbootable. We have looked at keeping around a separate OS image for this (e.g. in an available disk partition), but so far that hasn't proved practical since that itself can be fairly easily overwritten and we then have a doorstop.
Well, if a separate OS image can be overwritten, U-Boot image can be overwritten too, and then the board does not boot at all.
If U-Boot is kept in read-only memory (only written during manufacture) then it cannot be overwritten. This is the approach we are taking at present. However the size of this memory is very limited (4MB) and not enough for a kernel/graphics. So far we are not using NAND flash for this since we cannot write-protect it. If we could expand that memory somewhat then I agree we could use a read-only OS image for this and I would not have started this discussion.
I provided for a customer a solution with a separate OS and a small rootfs as initramfs, and even if it is theoretically possible to destroy this image, it has the same probability that U-Boot has to disappear. It still seems to me a good solution, with the drawback to use much more resorces (Flash) that a U-Boot solution can use. Anyway, with the current size of NAND flash, even this drawback is not very important in many projects.
Maybe more as a GUI-guided recovery, the customer needs a way to rescue the system when everything goes wrong. Providing a booting SD or USB card, that can complete restore the system, seems to be a good way, or at least it was in my case.
Yes, this is what we do, but we unfortunately do need a GUI for this - language selection and instructions on what to do.
Implementing it in U-Boot seems to me overkilling, but is only my 2 cents ;-).
Yes it is quite a lot of effort. Partly it is due to the security requirements - we have read-only firmware and (upgradable) read-write firmware in case there is a bug we need to patch in read-only firmware. This adds to the image size. We have a recovery mode which must run from read-only firmware, and guides the user through the process (bearing in mind the user is probably not a techie!). Also, in 'developer' mode we print a nice large warning screen on boot to make sure the user intends to be in this mode.
This is quite a different experience from a PC BIOS upgrade - all upgrades need to be seamless and automatic. We can't have it say 'Missing Operating System' and refuse to boot, no matter what happens. Yes these sorts of things have been done in various ways, but above all it needs to be secure and self-explanatory.
As I said at the start, so far we are using rendered images in every language, but it is not very efficient. I am trying to find a way to improve on this.
Regards, Simon
Best regards, Stefano
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de =====================================================================
Am 16.01.2013 20:46, schrieb Wolfgang Denk:
Dear Simon Glass,
In message CAPnjgZ12psS6sOnsuMU-VrrXWxS04Zb+grqqGUKNw2DTzBupag@mail.gmail.com you wrote:
We are currently using a very rudimentary graphics features attached to U-Boot. It can only display bitmap images. We use this in Chromium to composite a display for the various screens we need to display in U-Boot. Unfortunately the graphics screens get quite large when using multiple languages since they are pre-rendered.
Is there any interest in a simply graphics library in U-Boot, that can display things on the screen? We already have bitmap support, but could perhaps add outline font support (e.g. freetype) as well. This might allow display of simple boot menus or booting information. A board could create a structure containing a list of things to display (text, bitmaps) and pass it to the graphics library for rendering using existing functions and the new font support.
This sounds like a nice feature. Initially. Then I start wondering if this really belongs into a boot loader. Instead of doing fancy graphics stuff, we should IMO rather focus on booting the OS of your choice really fast, and let this do the fancy GUIs. Or?
Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;)
And I think too that all this can be handled by adding a kernel (e.g. with integrated minimal initramfs) to u-boot. At least that is how I have handled such in the past.
Regards,
Alexander
Am 18.01.2013 01:50, schrieb Alexander Holler:
(...)
Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;)
(...)
I've just wondered what happened to the cc-list of that mail I sent.
I've send it with
CC: Simon Glass sjg@chromium.org, U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
and received it just with
Cc: U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
Looks like mailman is confused.
Regards,
Alexander
On 01/17/2013 07:22:57 PM, Alexander Holler wrote:
Am 18.01.2013 01:50, schrieb Alexander Holler:
(...)
Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;)
(...)
I've just wondered what happened to the cc-list of that mail I sent.
I've send it with
CC: Simon Glass sjg@chromium.org, U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
and received it just with
Cc: U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
Looks like mailman is confused.
Yes, this is a very old known bug in mailman: https://bugs.launchpad.net/mailman/+bug/266161
-Scott
Am 18.01.2013 04:17, schrieb Scott Wood:
On 01/17/2013 07:22:57 PM, Alexander Holler wrote:
Am 18.01.2013 01:50, schrieb Alexander Holler:
(...)
Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;)
(...)
I've just wondered what happened to the cc-list of that mail I sent.
I've send it with
CC: Simon Glass sjg@chromium.org, U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
and received it just with
Cc: U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
Looks like mailman is confused.
Yes, this is a very old known bug in mailman: https://bugs.launchpad.net/mailman/+bug/266161
Thanks for the pointer.
I've now disabled that "avoid duplicates" option as the bug suggests. Good to know that such seems to be needed for mailman lists.
Regards,
Alexander
Am 18.01.2013 17:32, schrieb Alexander Holler:
Am 18.01.2013 04:17, schrieb Scott Wood:
On 01/17/2013 07:22:57 PM, Alexander Holler wrote:
Am 18.01.2013 01:50, schrieb Alexander Holler:
(...)
Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;)
(...)
I've just wondered what happened to the cc-list of that mail I sent.
I've send it with
CC: Simon Glass sjg@chromium.org, U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
and received it just with
Cc: U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
Looks like mailman is confused.
Yes, this is a very old known bug in mailman: https://bugs.launchpad.net/mailman/+bug/266161
Thanks for the pointer.
I've now disabled that "avoid duplicates" option as the bug suggests. Good to know that such seems to be needed for mailman lists.
I've just checked my last post, and it happened again. So disabling that knob (avoid duplicates) in the (my) preferences doesn't help.
Looking at those two mails, I think mailman just deletes every CC in the list which is before the address of the mailing list itself.
so
CC: a, u-boot@lists.denx.de, b
becomes
CC: u-boot@lists.denx.de, b
Regards,
Alexander
On 01/20/2013 08:53:05 PM, Alexander Holler wrote:
Am 18.01.2013 17:32, schrieb Alexander Holler:
Am 18.01.2013 04:17, schrieb Scott Wood:
On 01/17/2013 07:22:57 PM, Alexander Holler wrote:
Am 18.01.2013 01:50, schrieb Alexander Holler:
(...)
Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;)
(...)
I've just wondered what happened to the cc-list of that mail I sent.
I've send it with
CC: Simon Glass sjg@chromium.org, U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
and received it just with
Cc: U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
Looks like mailman is confused.
Yes, this is a very old known bug in mailman: https://bugs.launchpad.net/mailman/+bug/266161
Thanks for the pointer.
I've now disabled that "avoid duplicates" option as the bug suggests. Good to know that such seems to be needed for mailman lists.
I've just checked my last post, and it happened again.
What do you mean by "it"? Your address got dropped from CC, or Simon's?
So disabling that knob (avoid duplicates) in the (my) preferences doesn't help.
It's the preferences of the person who's being dropped from the CC list that matter (supposedly).
Looking at those two mails, I think mailman just deletes every CC in the list which is before the address of the mailing list itself.
I'm pretty sure I've seen droppage that wasn't consistent with that rule (e.g. the list was in To:).
-Scott
Am 21.01.2013 19:19, schrieb Scott Wood:
On 01/20/2013 08:53:05 PM, Alexander Holler wrote:
Am 18.01.2013 17:32, schrieb Alexander Holler:
Am 18.01.2013 04:17, schrieb Scott Wood:
On 01/17/2013 07:22:57 PM, Alexander Holler wrote:
Am 18.01.2013 01:50, schrieb Alexander Holler:
(...)
Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;)
(...)
I've just wondered what happened to the cc-list of that mail I sent.
I've send it with
CC: Simon Glass sjg@chromium.org, U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
and received it just with
Cc: U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jeroen@myspectrum.nl
Looks like mailman is confused.
Yes, this is a very old known bug in mailman: https://bugs.launchpad.net/mailman/+bug/266161
Thanks for the pointer.
I've now disabled that "avoid duplicates" option as the bug suggests. Good to know that such seems to be needed for mailman lists.
I've just checked my last post, and it happened again.
What do you mean by "it"? Your address got dropped from CC, or Simon's?
This time it was Steve Strobel. Simon was in to.
So disabling that knob (avoid duplicates) in the (my) preferences doesn't help.
It's the preferences of the person who's being dropped from the CC list that matter (supposedly).
Ah, thats the (broken) logic. Mailman drops such people from every CC, not just from mails it sends directly to them. Not what I would have expected as it breaks cc-lists in threads totally.
Looking at those two mails, I think mailman just deletes every CC in the list which is before the address of the mailing list itself.
I'm pretty sure I've seen droppage that wasn't consistent with that rule (e.g. the list was in To:).
Regards,
Alexander
Alexander Holler wrote:
And I think too that all this can be handled by adding a kernel (e.g. with integrated minimal initramfs) to u-boot. At least that is how I have handled such in the past.
I agree that graphics (apart from a logo) should be handled outside U-boot proper - my own rationale for this being "how essential is this for the primary operation of a bootloader, which is to set the system up for execution of the main payload as quickly as possible ?"
The bootloader can still manage to provide quick feedback on which kind of boot it is performing, normal or upgrade, for instance by loading a different logo for each case; any message such as "please wait for upgrade start" can always be designed into the upgrade case logo on a comfy workstation -- preferably with Gimp or Inkscape. :)
Regards,
Alexander
Amicalement,
Hi Simon,
On 17 January 2013 04:17, Simon Glass sjg@chromium.org wrote:
If we do this, rather than re-invent the wheel, does anyone have any suggestions on a very small and simple existing library that we could bring in to do this?
If what you want is a small graphics/font system then I'd recommend the work stb libraries from http://nothings.org. He's got an image loader that comes in at around 40k of x86 binary, which supports PNG, JPEG, GIF etc... and a .ttf render of around 2,000 lines of code (not sure of the compiled size). They're all public domain licensed, well maintained, and have no external dependencies. They're not the fastest, but they are the smallest that I've seen.
Whether it's a good idea to load such additional features into U-Boot or not, I don't really know.
Regards, Andre
Hi Andre,
On Wed, Jan 16, 2013 at 2:42 PM, Andre Renaud andre@bluewatersys.com wrote:
Hi Simon,
On 17 January 2013 04:17, Simon Glass sjg@chromium.org wrote:
If we do this, rather than re-invent the wheel, does anyone have any suggestions on a very small and simple existing library that we could bring in to do this?
If what you want is a small graphics/font system then I'd recommend the work stb libraries from http://nothings.org. He's got an image loader that comes in at around 40k of x86 binary, which supports PNG, JPEG, GIF etc... and a .ttf render of around 2,000 lines of code (not sure of the compiled size). They're all public domain licensed, well maintained, and have no external dependencies. They're not the fastest, but they are the smallest that I've seen.
Whether it's a good idea to load such additional features into U-Boot or not, I don't really know.
Thanks for that Andre - I will take a look!
Regards, Simon
Regards, Andre
participants (9)
-
Albert ARIBAUD -
Alexander Holler -
Andre Renaud -
Dirk Behme -
James W. -
Scott Wood -
Simon Glass -
Stefano Babic -
Wolfgang Denk