* [U-Boot] U-Boot Graphics Library? @ 2013-01-16 15:17 Simon Glass 2013-01-16 19:46 ` Wolfgang Denk 2013-01-16 22:42 ` Andre Renaud 0 siblings, 2 replies; 24+ messages in thread From: Simon Glass @ 2013-01-16 15:17 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-16 15:17 [U-Boot] U-Boot Graphics Library? Simon Glass @ 2013-01-16 19:46 ` Wolfgang Denk 2013-01-16 21:46 ` Simon Glass 2013-01-18 0:50 ` Alexander Holler 2013-01-16 22:42 ` Andre Renaud 1 sibling, 2 replies; 24+ messages in thread From: Wolfgang Denk @ 2013-01-16 19:46 UTC (permalink / raw) To: u-boot 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 -- 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 at denx.de "Go to Heaven for the climate, Hell for the company." - Mark Twain ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-16 19:46 ` Wolfgang Denk @ 2013-01-16 21:46 ` Simon Glass 2013-01-16 22:40 ` Wolfgang Denk 2013-01-18 9:18 ` Stefano Babic 2013-01-18 0:50 ` Alexander Holler 1 sibling, 2 replies; 24+ messages in thread From: Simon Glass @ 2013-01-16 21:46 UTC (permalink / raw) To: u-boot 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 at denx.de > "Go to Heaven for the climate, Hell for the company." - Mark Twain ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-16 21:46 ` Simon Glass @ 2013-01-16 22:40 ` Wolfgang Denk 2013-01-16 22:54 ` Simon Glass 2013-01-18 9:18 ` Stefano Babic 1 sibling, 1 reply; 24+ messages in thread From: Wolfgang Denk @ 2013-01-16 22:40 UTC (permalink / raw) To: u-boot 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 -- 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 at denx.de Brain: an apparatus with which we think we think. - Ambrose Bierce ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-16 22:40 ` Wolfgang Denk @ 2013-01-16 22:54 ` Simon Glass 2013-01-17 7:05 ` Dirk Behme 2013-01-17 12:48 ` Wolfgang Denk 0 siblings, 2 replies; 24+ messages in thread From: Simon Glass @ 2013-01-16 22:54 UTC (permalink / raw) To: u-boot 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 at denx.de > Brain: an apparatus with which we think we think. - Ambrose Bierce ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-16 22:54 ` Simon Glass @ 2013-01-17 7:05 ` Dirk Behme 2013-01-17 7:53 ` James W. 2013-01-17 12:56 ` Wolfgang Denk 2013-01-17 12:48 ` Wolfgang Denk 1 sibling, 2 replies; 24+ messages in thread From: Dirk Behme @ 2013-01-17 7:05 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-17 7:05 ` Dirk Behme @ 2013-01-17 7:53 ` James W. 2013-01-17 12:56 ` Wolfgang Denk 1 sibling, 0 replies; 24+ messages in thread From: James W. @ 2013-01-17 7:53 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-17 7:05 ` Dirk Behme 2013-01-17 7:53 ` James W. @ 2013-01-17 12:56 ` Wolfgang Denk 1 sibling, 0 replies; 24+ messages in thread From: Wolfgang Denk @ 2013-01-17 12:56 UTC (permalink / raw) To: u-boot 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 -- 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 at denx.de "Life, loathe it or ignore it, you can't like it." - Marvin the paranoid android ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-16 22:54 ` Simon Glass 2013-01-17 7:05 ` Dirk Behme @ 2013-01-17 12:48 ` Wolfgang Denk 1 sibling, 0 replies; 24+ messages in thread From: Wolfgang Denk @ 2013-01-17 12:48 UTC (permalink / raw) To: u-boot 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 -- 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 at denx.de Never worry about theory as long as the machinery does what it's supposed to do. - R. A. Heinlein ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-16 21:46 ` Simon Glass 2013-01-16 22:40 ` Wolfgang Denk @ 2013-01-18 9:18 ` Stefano Babic 2013-01-18 13:23 ` Simon Glass 1 sibling, 1 reply; 24+ messages in thread From: Stefano Babic @ 2013-01-18 9:18 UTC (permalink / raw) To: u-boot 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 -- ===================================================================== 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 at denx.de ===================================================================== ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-18 9:18 ` Stefano Babic @ 2013-01-18 13:23 ` Simon Glass [not found] ` <CAGrmWbzMM33kvQjvDEn66e_XO+GrV+UYb9uVxqUv0iHAnKm3Vg@mail.gmail.com> 0 siblings, 1 reply; 24+ messages in thread From: Simon Glass @ 2013-01-18 13:23 UTC (permalink / raw) To: u-boot 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 at denx.de > ===================================================================== ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <CAGrmWbzMM33kvQjvDEn66e_XO+GrV+UYb9uVxqUv0iHAnKm3Vg@mail.gmail.com>]
* [U-Boot] U-Boot Graphics Library? [not found] ` <CAGrmWbzMM33kvQjvDEn66e_XO+GrV+UYb9uVxqUv0iHAnKm3Vg@mail.gmail.com> @ 2013-01-18 20:57 ` Simon Glass 2013-01-21 1:29 ` Alexander Holler 0 siblings, 1 reply; 24+ messages in thread From: Simon Glass @ 2013-01-18 20:57 UTC (permalink / raw) To: u-boot Hi, On Fri, Jan 18, 2013 at 7:47 AM, Steve Strobel <steve.strobel@link-comm.com> wrote: > Maybe the USB flash drive used for recovery could contain not only the image > to be written to flash, but also a bootable OS image used to provide > on-screen messages during the recovery process. You would still need the > read-only code to provide enough of a UI to boot from the USB flash drive, > but the rest of the messages could be generated by that OS. Yes that's exactly what we do...and yes we still need the read-only code to provide a minimal GUI to get things started. That was the subject of this thread. The recovery mode GUI is provided by a Linux user space tool, but we need to get there first... Regards, Simon > > Steve > > > -- > Steve Strobel > Link Communications, Inc. > 1035 Cerise Rd > Billings, MT 59101-7378 > (406) 245-5002 ext 102 > (406) 245-4889 (fax) > WWW: http://www.link-comm.com > MailTo:steve.strobel at link-comm.com ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-18 20:57 ` Simon Glass @ 2013-01-21 1:29 ` Alexander Holler 2013-01-22 11:29 ` Alexander Holler 0 siblings, 1 reply; 24+ messages in thread From: Alexander Holler @ 2013-01-21 1:29 UTC (permalink / raw) To: u-boot Am 18.01.2013 21:57, schrieb Simon Glass: > Hi, > > On Fri, Jan 18, 2013 at 7:47 AM, Steve Strobel > <steve.strobel@link-comm.com> wrote: >> Maybe the USB flash drive used for recovery could contain not only the image >> to be written to flash, but also a bootable OS image used to provide >> on-screen messages during the recovery process. You would still need the >> read-only code to provide enough of a UI to boot from the USB flash drive, >> but the rest of the messages could be generated by that OS. > > Yes that's exactly what we do...and yes we still need the read-only > code to provide a minimal GUI to get things started. That was the > subject of this thread. The recovery mode GUI is provided by a Linux > user space tool, but we need to get there first... Hmm, maybe the kernel people are more open to such an idea. It would just be an additional module/driver and would offer other possible use case too, much more than if such a library would be added to U-Boot. A minimal kernel is doable with less than 2MB and that Graphics Library could be implemented as module (statically linked) which uses the framebuffer, so no userspace would be necessary at all. Regards, Alexander ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-21 1:29 ` Alexander Holler @ 2013-01-22 11:29 ` Alexander Holler 0 siblings, 0 replies; 24+ messages in thread From: Alexander Holler @ 2013-01-22 11:29 UTC (permalink / raw) To: u-boot Am 21.01.2013 02:29, schrieb Alexander Holler: > Am 18.01.2013 21:57, schrieb Simon Glass: >> Hi, >> >> On Fri, Jan 18, 2013 at 7:47 AM, Steve Strobel >> <steve.strobel@link-comm.com> wrote: >>> Maybe the USB flash drive used for recovery could contain not only the image >>> to be written to flash, but also a bootable OS image used to provide >>> on-screen messages during the recovery process. You would still need the >>> read-only code to provide enough of a UI to boot from the USB flash drive, >>> but the rest of the messages could be generated by that OS. >> >> Yes that's exactly what we do...and yes we still need the read-only >> code to provide a minimal GUI to get things started. That was the >> subject of this thread. The recovery mode GUI is provided by a Linux >> user space tool, but we need to get there first... > > Hmm, maybe the kernel people are more open to such an idea. It would > just be an additional module/driver and would offer other possible use > case too, much more than if such a library would be added to U-Boot. > > A minimal kernel is doable with less than 2MB and that Graphics Library > could be implemented as module (statically linked) which uses the > framebuffer, so no userspace would be necessary at all. Combined e.g. with lua to use some syscalls for loading files, that could be imho useful for many other task. E.g. to get rid of bootloaders on UEFI systems or to replace initrd's at all (lua in kernel instead of a shell in userspace). Ok, thats stuff which likely would provoke heated discussions, but at least I would like such. ;) But something like lua isn't really needed for the above problem. Hardcoding the few steps (e.g. font and picture loading) necessary to lead users to insert an usb-stick is imho a pragmatic solution too. The kernel devs most likely wouldn't want that (because it's not a generic solution), but thats live. Regards, Alexander ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-16 19:46 ` Wolfgang Denk 2013-01-16 21:46 ` Simon Glass @ 2013-01-18 0:50 ` Alexander Holler 2013-01-18 1:22 ` [U-Boot] cc-list modified? Alexander Holler 2013-01-18 8:49 ` [U-Boot] U-Boot Graphics Library? Albert ARIBAUD 1 sibling, 2 replies; 24+ messages in thread From: Alexander Holler @ 2013-01-18 0:50 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] cc-list modified? 2013-01-18 0:50 ` Alexander Holler @ 2013-01-18 1:22 ` Alexander Holler 2013-01-18 3:17 ` Scott Wood 2013-01-18 8:49 ` [U-Boot] U-Boot Graphics Library? Albert ARIBAUD 1 sibling, 1 reply; 24+ messages in thread From: Alexander Holler @ 2013-01-18 1:22 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] cc-list modified? 2013-01-18 1:22 ` [U-Boot] cc-list modified? Alexander Holler @ 2013-01-18 3:17 ` Scott Wood 2013-01-18 16:32 ` Alexander Holler 0 siblings, 1 reply; 24+ messages in thread From: Scott Wood @ 2013-01-18 3:17 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] cc-list modified? 2013-01-18 3:17 ` Scott Wood @ 2013-01-18 16:32 ` Alexander Holler 2013-01-21 2:53 ` Alexander Holler 0 siblings, 1 reply; 24+ messages in thread From: Alexander Holler @ 2013-01-18 16:32 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] cc-list modified? 2013-01-18 16:32 ` Alexander Holler @ 2013-01-21 2:53 ` Alexander Holler 2013-01-21 18:19 ` Scott Wood 0 siblings, 1 reply; 24+ messages in thread From: Alexander Holler @ 2013-01-21 2:53 UTC (permalink / raw) To: u-boot 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 at lists.denx.de, b becomes CC: u-boot at lists.denx.de, b Regards, Alexander ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] cc-list modified? 2013-01-21 2:53 ` Alexander Holler @ 2013-01-21 18:19 ` Scott Wood 2013-01-21 18:32 ` Alexander Holler 0 siblings, 1 reply; 24+ messages in thread From: Scott Wood @ 2013-01-21 18:19 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] cc-list modified? 2013-01-21 18:19 ` Scott Wood @ 2013-01-21 18:32 ` Alexander Holler 0 siblings, 0 replies; 24+ messages in thread From: Alexander Holler @ 2013-01-21 18:32 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-18 0:50 ` Alexander Holler 2013-01-18 1:22 ` [U-Boot] cc-list modified? Alexander Holler @ 2013-01-18 8:49 ` Albert ARIBAUD 1 sibling, 0 replies; 24+ messages in thread From: Albert ARIBAUD @ 2013-01-18 8:49 UTC (permalink / raw) To: u-boot 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, -- Albert. ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-16 15:17 [U-Boot] U-Boot Graphics Library? Simon Glass 2013-01-16 19:46 ` Wolfgang Denk @ 2013-01-16 22:42 ` Andre Renaud 2013-01-16 22:57 ` Simon Glass 1 sibling, 1 reply; 24+ messages in thread From: Andre Renaud @ 2013-01-16 22:42 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* [U-Boot] U-Boot Graphics Library? 2013-01-16 22:42 ` Andre Renaud @ 2013-01-16 22:57 ` Simon Glass 0 siblings, 0 replies; 24+ messages in thread From: Simon Glass @ 2013-01-16 22:57 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2013-01-22 11:29 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-01-16 15:17 [U-Boot] U-Boot Graphics Library? Simon Glass 2013-01-16 19:46 ` Wolfgang Denk 2013-01-16 21:46 ` Simon Glass 2013-01-16 22:40 ` Wolfgang Denk 2013-01-16 22:54 ` Simon Glass 2013-01-17 7:05 ` Dirk Behme 2013-01-17 7:53 ` James W. 2013-01-17 12:56 ` Wolfgang Denk 2013-01-17 12:48 ` Wolfgang Denk 2013-01-18 9:18 ` Stefano Babic 2013-01-18 13:23 ` Simon Glass [not found] ` <CAGrmWbzMM33kvQjvDEn66e_XO+GrV+UYb9uVxqUv0iHAnKm3Vg@mail.gmail.com> 2013-01-18 20:57 ` Simon Glass 2013-01-21 1:29 ` Alexander Holler 2013-01-22 11:29 ` Alexander Holler 2013-01-18 0:50 ` Alexander Holler 2013-01-18 1:22 ` [U-Boot] cc-list modified? Alexander Holler 2013-01-18 3:17 ` Scott Wood 2013-01-18 16:32 ` Alexander Holler 2013-01-21 2:53 ` Alexander Holler 2013-01-21 18:19 ` Scott Wood 2013-01-21 18:32 ` Alexander Holler 2013-01-18 8:49 ` [U-Boot] U-Boot Graphics Library? Albert ARIBAUD 2013-01-16 22:42 ` Andre Renaud 2013-01-16 22:57 ` Simon Glass
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.