[U-Boot] U-Boot Graphics Library?

[U-Boot] U-Boot Graphics Library?

[Simon Glass]

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

[U-Boot] U-Boot Graphics Library?

[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?

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

[U-Boot] U-Boot Graphics Library?

[Simon Glass]

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

[U-Boot] U-Boot Graphics Library?

[Wolfgang Denk]

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

[U-Boot] U-Boot Graphics Library?

[Andre Renaud]

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

[U-Boot] U-Boot Graphics Library?

[Simon Glass]

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

[U-Boot] U-Boot Graphics Library?

[Simon Glass]

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

[U-Boot] U-Boot Graphics Library?

[Dirk Behme]

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

[U-Boot] U-Boot Graphics Library?

[James W.]

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

[U-Boot] U-Boot Graphics Library?

[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

-- 
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

[U-Boot] U-Boot Graphics Library?

[Wolfgang Denk]

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

[U-Boot] U-Boot Graphics Library?

[Alexander Holler]

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

[U-Boot] cc-list modified?

[Alexander Holler]

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

[U-Boot] cc-list modified?

[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

-Scott

[U-Boot] U-Boot Graphics Library?

[Albert ARIBAUD]

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.

[U-Boot] U-Boot Graphics Library?

[Stefano Babic]

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
=====================================================================

[U-Boot] U-Boot Graphics Library?

[Simon Glass]

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
> =====================================================================

[U-Boot] cc-list modified?

[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.

Regards,

Alexander

[U-Boot] U-Boot Graphics Library?

[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...

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

[U-Boot] U-Boot Graphics Library?

[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.

Regards,

Alexander

[U-Boot] cc-list modified?

[Alexander Holler]

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

[U-Boot] cc-list modified?

[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?

> 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

[U-Boot] cc-list modified?

[Alexander Holler]

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

[U-Boot] U-Boot Graphics Library?

[Alexander Holler]

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