public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 0/2] api: extend accessible set of block device attributes
Date: Mon, 24 Oct 2011 11:32:44 +0200	[thread overview]
Message-ID: <m2r522ohtv.fsf@ohwell.denx.de> (raw)
In-Reply-To: <CANJuy2LDoPtHC_37=rkR3pvHmPFJvUnsM+==YxgaDpVoo5sT1A@mail.gmail.com> (Che-liang Chiou's message of "Mon, 24 Oct 2011 11:36:50 +0800")

Hi Che-liang,

> I am working on an open source secure bootloader based on U-Boot.
> Mostly I wrote boot logic (by boot logic I mean prompting user and
> listing available devices sort of things). If you see U-Boot as a
> platform, you can think of my project as an application running on top
> of U-Boot, except that my application is statically linked with
> U-Boot.

Usually the (old or new) API is used to separate the application from
the GPLed U-Boot codebase to allow for proprietary applications.  If you
plan to link your application statically to U-Boot anyway, then I think
that using the (external) API is not a good way to move forward.

> The boot logic is running on ARM and x86. Through the project I have
> learned that certain APIs would be helpful, such as enumerating all
> available block device and drawing bitmaps on screen regardless of
> which driver (video or LCD) you are using.

Yes, I think what you actually are looking for is a proper device model
in U-Boot.  Actually we are in dire need for something like this in the
whole of U-Boots codebase and we talk about it for a very long time (see
for example [1]).  This would ease progress in multiple
areas, where currently we hack around this.  See for example the
SERIAL_MULTI code base or NET_MULTI.  Both are isolated solutions for
the same problem.  As you note, video and block devices will also
profit - USB will be another instance.

> It was probably a misleading finding when I searched the code base: I
> saw only the external apps API implemented an API for enumerating
> available block device. So I thought improving the external apps API
> was the right place to go.
>
> Alternatively (if not go the external apps API), we could have like
> common/cmd_enum_block_dev.c that does what I am planning to do, and I
> am happy to do this. What do you think?

I think we should aim at a pretty generic device interface.  Currently I
would think that this also needs to fit into the "configure U-Boot
through the device tree" topic.  The one will profit from the other.

As far as I know, Marek (on CC) is working towards this device tree
model also.  Coordinating the efforts will be a good thing.

Thanks!
  Detlev

-- 
Perfecting oneself is as much unlearning as it is learning. 
                                        -- Edsger Dijkstra 
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

      reply	other threads:[~2011-10-24  9:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-21  6:31 [U-Boot] [PATCH 0/2] api: extend accessible set of block device attributes Che-Liang Chiou
2011-10-21  6:31 ` [U-Boot] [PATCH 1/2] Flatten and solidify block_dev_desc layout Che-Liang Chiou
2011-10-21 19:09   ` Wolfgang Denk
2011-10-24  3:36     ` Che-liang Chiou
2011-10-24 10:49       ` Detlev Zundel
2011-10-21  6:31 ` [U-Boot] [PATCH 2/2] api: storage: Share attributes with block_dev_desc Che-Liang Chiou
2012-01-08  7:26   ` Mike Frysinger
2011-10-21  7:03 ` [U-Boot] [PATCH 1/2] Flatten and solidify block_dev_desc layout Che-Liang Chiou
2011-10-21 16:06 ` [U-Boot] [PATCH 0/2] api: extend accessible set of block device attributes Detlev Zundel
2011-10-24  3:36   ` Che-liang Chiou
2011-10-24  9:32     ` Detlev Zundel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2r522ohtv.fsf@ohwell.denx.de \
    --to=dzu@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox