From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlev Zundel Date: Mon, 24 Oct 2011 11:32:44 +0200 Subject: [U-Boot] [PATCH 0/2] api: extend accessible set of block device attributes In-Reply-To: (Che-liang Chiou's message of "Mon, 24 Oct 2011 11:36:50 +0800") References: <1319178708-10881-1-git-send-email-clchiou@chromium.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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