[U-Boot] U-Boot Graphics Library?

[Simon Glass]

Hi,

On Fri, Jan 18, 2013 at 1:18 AM, Stefano Babic <sbabic at 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
> =====================================================================