On 1/28/07, Wolfgang Denk wd@denx.de wrote:
In message 528646bc0701271419l8069e56nb06bb328cf85b8b7@mail.gmail.com you wrote:
- large number of
of ???
heh; brain fart... please ignore. :)
The technology varies wildly, but they are all storage devices which store of an ordered sequence of bytes. In every device, the address of a single item of data can be boiled down to a single integer.
...assuming your "integer" type has enough bits to address any byte.
yes.
Take a look at the following interface. For *most* commands; how well does this is this api encapsulate those differences for common commands? Assume that device specific commands still exist for things that don't fit well into the model. ie. block erase and protect commands.
open(device) # Prepare for read/write operation seek(distance, abs_flag) # Relative or absolute seek read(buffer, count) write(buffer, count) close() # Operation finished; sync any pending buffers back to disk.
Please keep in mind that this is a boot loader, not an OS. One im- portant point is, and always has been, to keep the memory footprint small. I often sacrificed beautiful code for an uglier, but much smaller implementation. And I guess I will (have to) do this again.
May bootloaders use this type of interface. OpenFirmware is a good example. RedBoot is another. CFE does too. I think it is a good and well established abstraction regardless of whether it is an OS or a bootloader.
Notes:
- assume device can only be opened once. ie. it's a bug to call open() twice
Why?
Mostly to keep the use cases simple; but maybe I'm optimizing too early. I was thinking in terms of not needing to dynamically allocate temporary buffers.
- this could be used by commands like mm, md, bootm, etc. I'm not
trying to design a full control interface (protect, erase, etc).
Why not? I'm not willing to see such functions dropped.
Neither am I.
I'm not trying to design a one size fits all interface for all extra device features. The specific problem I want to tackle is to provide a single hook point for attaching read/write commands to non-memmapped devices. I'm comfortable with keeping the existing device specific commands for protect/erase/etc, (at least for now).
I'm going to do a trial implementation of that stuff discussed so far so I can post patches for review. At that point I'll be looking for feedback to decide if this is a direction worth pursuing further. If so, then I'll take a look at the protect/erase/etc features
- common commands would typically call open(), seek(),
read/write(), read/write(), ..., close() before returning to user. ie. device would *not* be left open after command completes.
Sounds like a lot of code to implement (code size) and run (execution times).
I don't think it will be; but I'll should just stop arguing here and implement it. It's the only way to actually know.
It's a well established abstraction, so why not here too?
Well, just to name one of the potential issues: U-Boot is designed to make porting to new hardware as eassy as possible. So we want to have serial console output as soon as possible. That means that very, very early in the boot process you will have to read the environment to read environment variables like "baudrate" and some others. In this stage, we usually don't have a regular stack, we have no BSS, and we have no writable data segment. In other words, we don't have a regular C environment, only a very primitve subset. But *all* your new code would have to be able to run in this environment. Or we would need duplicate implementations which is even worse than what we have today.
I'm not looking at rewriting all the device back end drivers. I'm only looking at the attachment to common commands. I have no intention to rip and replace the existing code for early access.
I can't read your altimeter from here, but it seems you did take off (i. e. lose ground ;-)
:-P
Cheers, g.