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