On 1/26/07, Wolfgang Denk wd@denx.de wrote:

In message 528646bc0701261111i6f0dcb0i96f81259b3a4311d@mail.gmail.com you wrote:

...

My vote is to treat DataFlash like a block device, and make sure that it supports byte-wide access.

Treat DataFlash like a block device? That sounds wrong to me.

Perhaps using the term block device is too loaded. DataFlash is not the same as memory mapped storage, but it's not the same as a CF card or an IDE disk (in that it's not broken up into sectors). However, being non-memmapped makes it more similar to those devices than it is to memmapped flash.

OTOH, the argument could be made that memory mapped flash isn't the same either because while memmapped flash can be read from directly, writing requires extra twiddling. I'd be mad to suggest that memmapped flash should be removed from the memory manipulation commands.

Flash devices aren't too bad because all of them use the same flash_write and addr2info hooks. Right after them, however, there is an mmc hook which does essentially the exact same thing. DataFlash falls into the same category. (What kicked off this whole topic is that I'm working on the md command which only has the DataFlash hook, not the MMC or Flash hooks (and a flash hook wouldn't even make sense for 'md').

Does anyone see any reason why these hooks couldn't be merged into a single addr2info type call? If the flash_info_t was modified to include read/write function pointers and a private data pointer (move a bunch of the parameters into a private data structure). Boards can provide a table including the various flash and non-memmapped devices that are available. A single hook would be enough to get the entry for a particular address.

If I took this approach; it could be implemented in a staged approach, starting with memmapped flash, and then merging in mmc and dataflash support once the architecture is show to work. It still leaves the issue that it pretends mmc and dataflash devices are memory mapped which I really don't like, but with a standard set of hooks, it may be possible to just pass the raw string into addr2info instead of an integer address, and collect all the parsing code in one place (ie. use a "dev:addr" format as previously suggested)

I understand your concerns about the #ifdef mess, but this suggestion does not sound tempting either.

That particular approach happens to be/was my preference, but it is certainly not the only approach.

Cheers, g.

On 1/26/07, Wolfgang Denk wd@denx.de wrote:

Omitting the Dataflash stuff is simple at the moment, so please make sure that your new code does not grow for boards that don't use Dataflash at all.

ok. I'll hack something preliminary together and see what it ends up looking like space wise.

...

If I took this approach; it could be implemented in a staged approach, starting with memmapped flash, and then merging in mmc and dataflash support once the architecture is show to work. It still leaves the

Where would you stop? If you go this path, why not add CF and USB and IDE as well? I'm not convinced that would be a good thing to do.

CF/USB/SCSI/IDE already have an abstraction layer; hence the original idea of merging the other non-memory mapped devices into it. But your right; which devices does it make sense to merge into a single interface? I don't know, needs more thought.

g.

hi there

after modifing some codes(forget what's the codes:() arm-elf-gcc also get malloc failure,I have to think about my program has something wrong

actually malloc have got failure in the lib_arm/board.c:

a malloc will trigger *sbrk twice(why?) test code in start_armboot() ... void *testptr; testptr=malloc(10); ...

in the void *sbrk (ptrdiff_t increment) { ulong old = mem_malloc_brk; ulong new = old + increment;

if ((new < mem_malloc_start) || (new > mem_malloc_end)) { return (NULL); } mem_malloc_brk = new;

return ((void *) old); }

I print out the debug information:

1st trigger:

increment: a2e2e4e?(so big?) old: c6dfc00 new: 169c2a4e mem_malloc_start: c6dfc00 mem_malloc_end: c700000

2nd:

increment: 1b2 old: c6dfc00 new: c6dfdb2 mem_malloc_start: c6dfc00 mem_malloc_end: c700000

seems the 2nd is ok but testptr still =0

***************** in the cpu/s3c44b0/start.S I create stack like that:

stack_setup:

ldr r0,=0xc700000 /* upper 128 KiB: relocated uboot */ sub r0, r0, #CFG_MALLOC_LEN /* malloc area 1024+128*1024 =1227204bytes */ sub r0, r0, #CFG_GBL_DATA_SIZE /* bdinfo 128 */ sub sp, r0, #12 /* leave 3 words for abort-stack */

i think it should be ok ******************

regards, rui

________________________________

From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] Sent: Saturday, January 27, 2007 12:11 PM To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] Arm-linux-gcc malloc get failure while arm-elf-gcc ok

hi there

I wonder if I am the first one to get this problem

In common\lists.c

Handle NewHandle (unsigned int numBytes) { void *memPtr; HandleRecord *hanPtr;

memPtr = calloc (numBytes, 1); hanPtr = (HandleRecord *) calloc (sizeof (HandleRecord), 1);

Debug("memPtr:%d hanPtr:%d\n",memPtr ,hanPtr ); //arm-linux-gcc get 0 for both of the Ptr while arm-elf-gcc can malloc successfully

if (hanPtr && (memPtr || numBytes == 0)) { hanPtr->ptr = memPtr; hanPtr->size = numBytes; return (Handle) hanPtr; } else { free (memPtr); free (hanPtr); return NULL; }

}

Arm-elf-gcc is 3.4.0 Arm-linux-gcc is 3.3.2 (heard there are most problems in this version??)

Regards Zhou rui

In message 45BB54FB.2040904@schweigstill.de you wrote:

When we are thinking about a new Dataflash abstraction layer we should also keep in mind that some new Dataflash components (AT45DBxxxD series) contain features like the security register and sector locking which also should be supported by the API. Other memory technologies, especially SD/MMC, also provide such special features.

... and to me this sounds is if it would fit better in the set of flash related commands (protect etc.) than any other existing interface.

Best regards,

Wolfgang Denk

Andreas Schweigstill wrote:

Hello!

Wolfgang Denk schrieb:

...

... and to me this sounds is if it would fit better in the set of flash related commands (protect etc.) than any other existing interface.

The flash related commands could work on an extension of the block device layer. IDE/ATA drives also seem to have a means for provision of drive geometry data to the file system driver or application (e.g. fdisk under DOS/Windows/Linux). (Yes, I am just joking... :-) )

There is something what I really don't like about U-Boot's current Dataflash implementation: after copying data to Dataflash using the "cp.b" command the source data has been corrupted; it has been swapped with the old contents of the Dataflash. The reason for this behaviour can be found in the AT91F_SpiWrite() function (at45.c) which programs the PDC to use the SPI transmit buffer address also as receive address. Has anybody found out if it is possible to ignore the read data?

If you find that annoying, you can always generate a patch which allocates a 1056 byte buffer and use that as the receive buffer for all transfers.

With best regards Andreas Scheigstill

Best Regards, Ulf Samuelsson ulf@atmel.com GSM: +46 (706) 22 44 57 Tel: +46 (8) 441 54 22 Fax: +46 (8) 441 54 29 Mail: Box 2033 174 02 Sundbyberg Visit: Kavallerivägen 24 174 58 Sundbyberg' Sweden

Hello!

Wolfgang Denk schrieb:

...

There is something what I really don't like about U-Boot's current Dataflash implementation: after copying data to Dataflash using the "cp.b" command the source data has been corrupted; it has been swapped with the old contents of the Dataflash. The reason for this behaviour

Arghhh.. That is indeed a bug, then.

Oh, since lots of people here are using U-Boot on AT91RM9200 I thought that such behaviour was a feature. The really big problems occur when using imxtract command because the multi-file image will be corrupted. Also verifying the Dataflash contents becomes quite difficult when the source has been overwritten.

So I suggest that the AT91F_SpiWrite() function has to be modified, e.g. with a new parameter which determines if the source has to be overwritten. How many applications have been written which depend on the strange cp.b behaviour? Should there be an environment variable? Hmmm.... bad idea.

With best regards Andreas Schweigstill

On 1/26/07, Wolfgang Denk wd@denx.de wrote:

In message 528646bc0701261111i6f0dcb0i96f81259b3a4311d@mail.gmail.com you wrote:

...

My vote is to treat DataFlash like a block device, and make sure that it supports byte-wide access.

Treat DataFlash like a block device? That sounds wrong to me.

I've been thinking about this some more, and I'm not sure I agree.

Just for the moment; forget the term 'block device' and forget about the current implementation of u-boot. How significant are the difference between the following devices? mmc, CF, IDE HD, SCSI HD, DataFlash, memmapped flash, NAND flash, i2c eeprom, USB storage. Here's my short list: - different block sizes; DataFlash can be written byte at a time; while other devices have minimum write sizes. Some devices need blocks to be specifically erased before rewriting. - memmapped flash can be be read directly on the memory bus; but writing requires a special routine - Large variation of size, from a few kbytes up to thousands of gigabytes. - Some devices are typically partitioned for convenience - speed differences - large number of

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.

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. Notes: - assume device can only be opened once. ie. it's a bug to call open() twice - this could be used by commands like mm, md, bootm, etc. I'm not trying to design a full control interface (protect, erase, etc). - 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. - should be suitable for partition access too - read/write commands are expected to transparently handle block boundaries. ie. if one byte is written to the middle of a block; the write hook should read the block, modify the byte, and keep it buffered until it either a read/write/seek() moves to another sector, or close() is called. - and yes, I'm just using the each device as a file perspective. It's a well established abstraction, so why not here too?

I think this is a reasonable approach to provide a common interface without making device specific side cases too complex to deal with. Adding new device support to all commands becomes pretty trivial this way.

Thoughts? Feel free to tell me if I'm flying too high in the stratosphere on this one. g.

In message 45BC0099.3070706@comcast.net you wrote:

understand this command. This way, it is possible to read/write from any "device" to system ram. A driver to treat system ram as a device could also be compiled into u-boot.

It certainly could. BUt IMHO it does not ake sense to require a driver to access RAM (!) when a "*pointer" is all that's needed. We're talking aboth the difference between a single machine instruction versus calls to several complex functions here!

Please let's keep the code as small, and as simple, as possible.

If the user wants to maintain the ability to operate with memory commands on bus-addressed memory of any kind, it is simple to initialize the mmapped address table appropriately.

Folks, please, do me a favour: before you continue, go and read the U-Boot code and make a list what needs to be done on all the different boards even before we have a working C environment.

Be aware, that your rewrite (1) will have to support all these features, too, (2) must not (significantly) increase the memory footprint for existing configurations which don't need any features added, and (2) will have to run in such a restricted environment, where you probably cannot even allocate a 512 byte buffer for I/O.

I don't want to stop you, but please keep the environment in mind where your code has to fit in.

dynamically. If the user does not want this type of support, it can be completely omitted from the u-boot build and all memory type commands will be executed using the CPU ram read/write routines and addresses.

??? I don;t see how this would be possible if I understand hwta GRand and you have in mind. At least not without adding yet another #ifdef maze.

I think this approach gives everybody what they want. In cases where "normal" ram and device access to a few devices is all that is desired, u-boot would probably be slightly smaller than it is now. If mmapped support is included, it might be very

I can't see how you would get the standard configuration (just RAM and NOR flash support) smaller with such a change?

Comments welcome. I don't think this is really a big change from the current system, it is just a formalization of what has always been desired.

Umm... "always been desired" - by whom? :-)

You probably remember our old discussion about ENV_IS_EMBEDDED from a year or so ago - do you? This is another similar area. The current code is not flexible and ugly, but all the configuration and code selection is done at compile time, which means we have a minimal memory footprint.

U-Boot is a boot loader. Keep is small and simple.

Best regards,

Wolfgang Denk

In message 45BD21D7.20203@comcast.net you wrote:

...

I can't see how you would get the standard configuration (just RAM and NOR flash support) smaller with such a change?

There are presently quite a few #ifdefs involved in cmd_mem.c and cmd_load.c to take different memory types into consideration. These would mostly go away. That is why I think a ram + flash configuration

OK, so the *source* code may become smaller indeed. But I'd expect the memory footprint on the target system to grow instead, or you lose functionality.

configuration. Naturally, you loose the ability to dump flash data with md, compare to flash data with cmp, copy flash data with cp.b, load data directly to flash with loadb, etc. so it is not free, just a bit smaller.

Arghhh... Indeed, that's not free. I guess for such a price there are other, more efficient ways to reduce the code size.

...

...

current system, it is just a formalization of what has always been desired.

Umm... "always been desired" - by whom? :-)

Well, as I understood it, at least partially by you. :-) The ability to use memory oriented commands on memory other than simple ram seems to be

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

considered a plus by many u-boot community members. However, this does

Read what you wrote: "use memory oriented commands on memory". That's exactly what I really expect to be able to do, indeed.

Why should I not be allowed to "md" or "crc" or "cmp" RAM and flash contents?

add some complexity and size to the associated memory manipulation commands. As the object being addressed differs more and more from

Not really. Normally only writing may need special handling.

I can't say if Dataflash really fits into this szenario; I never used this feature myself.

simple ram, more and more people seem to accept "new" commands to read and write these objects, and to forgo the advantages/features of the memory commands. This becomes especially true when the size of the object to be read/written exceeds the size of the CPU address space.

Do you have an example where this happens in U-Boot context?

What my goal in this proposed design is to allow users to choose at compile time what features are desired for the u-boot memory commands a) without an ifdef maze and b) without needing to inject new code into cmd_mem.c and cmd_load.c for every different memory technology that will use memory access type commands. If somebody wants to use the memory commands on a serial EEPROM, this can be made to work if desired, or not

I feel that would be not natural. And EEPROM (like on a I2C bus) does not have any natural adresses in the CPU's address space. Same for IDE or USB devices. These are storage devices on some form of I/O bus, but certainly NOT memory.

made to work if not considered necessary, without changing cmd_mem.c. How possible/good this goal is remains to be seen, I agree. The current

IMHO we should provide a user inteface which is powerful, yet easy to use - this requires it must be intuitive to the end user. For most f them, (NOR) flash *is* memory, while and IDE or USB disk and even an EEPROM is not.

I completely agree with small and simple, and making feature choices at compile time. I think these attributes can be preserved, or perhaps

Ther eis another thing that is important to me: U-Boot on different systems, boards and architectures shall always behave as similar as possible. Having the "cmp" command (if configured into U-Boot) work on flash memory on one system and failing to do so on another one seems unacceptable to me.

Best regards,

Wolfgang Denk

In message 528646bc0701281850n4b4fa2b1x7022b4daf9bfe89a@mail.gmail.com you wrote:

This is the exact category that MMC and DataFlash devices are in (both accessed via SPI). Yet they are both accessible by commands in cmd_mem.c.

I have never used DataFlash nor MMC. Maybe the interface was really badly chosen. From the description I got from the implementor when the Dataflash patches went in it sounded OK to me.

...

IMHO we should provide a user inteface which is powerful, yet easy to

use - this requires it must be intuitive to the end user. For most f

...

them, (NOR) flash *is* memory, while and IDE or USB disk and even an EEPROM is not.

Right; so what do we do with MMC and DataFlash?

So far I hear only discussion from developers.

Are there any users of Dataflah and MCC here? What is your opinion about the current user interface, abd about the suggested changes?

Best regards,

Wolfgang Denk

I'm not sure if I understand. U-boot pretends mmc and DataFlash are memory mapped? That sounds completely insane, especially for MMC. What happens if you insert an 8GB SD card on a 32-bit host?

There is nothing to stop U-Boot memory commands from implementing a 64 bit virtual address space. (The day that you have an 8GB Dataflash, Champagne corks will fly.Largest one today is 8 MB)

I haven't actually used DataFlash on any avr32 boards yet, but I have written an MMC driver for it and I didn't even know it could be accessed as a memory-mapped device. In fact, I can't even understand why anyone would want that --

The reason to memory map is that then it is easy to do memory commands like copy, compare etc, which you do want to do on dataflash, even though it is not fully implemented in the current mainstream. I have implemented additional functions, because they are really needed. I wrote them because it is such a pain to copy to RAM before you can compare, and I definitely do not like to have to start doing that again.

It is perfectly possible to memory map the dataflash without having a lot of ifdefs, by letting the memory commands call a driver. I believe this is the way forward.

It is easier for a user to learn a single command set to handle flash regardless of type.

MMC/SD/USB Memories have the advantage of beeing able to be read/written by the host, and this advantage makes it more natural to use a real file system.

the main usage of an MMC or SD card is to put a filesystem (usually FAT, but you can use pretty much anything) on it and use it for storage.

I guess DataFlash makes slightly more sense to access this way, but I still think the interface is totally unintuitive.

So, even though I'm technically more of a developer than a user, consider this a vote in favour of ripping the stuff out. Unless of course lots of users depend on stuff working this way. I highly doubt it since it doesn't even work properly (yes, the MMC stuff too; the mmc2info function on pxa is a total hack which only works for 32MB cards.)

Håvard

---

Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

On 1/29/07, Ulf Samuelsson ulf@atmel.com wrote:

...

I'm not sure if I understand. U-boot pretends mmc and DataFlash are memory mapped? That sounds completely insane, especially for MMC. What happens if you insert an 8GB SD card on a 32-bit host?

There is nothing to stop U-Boot memory commands from implementing a 64 bit virtual address space.

Except that for most (all?) CPUs supported by u-boot, the virtual address space _isn't_ 64 bit.

(The day that you have an 8GB Dataflash, Champagne corks will fly.Largest one today is 8 MB)

Yeah, that's why I said it makes slightly more sense to do this with DataFlash than with MMC. But I'm guessing that whoever implemented the memory mapped MMC thing didn't expect MMC cards to reach 8 GB any time soon either.

...

I haven't actually used DataFlash on any avr32 boards yet, but I have written an MMC driver for it and I didn't even know it could be accessed as a memory-mapped device. In fact, I can't even understand why anyone would want that --

The reason to memory map is that then it is easy to do memory commands like copy, compare etc, which you do want to do on dataflash, even though it is not fully implemented in the current mainstream. I have implemented additional functions, because they are really needed. I wrote them because it is such a pain to copy to RAM before you can compare, and I definitely do not like to have to start doing that again.

I agree that the functionality is needed. I just disagree with the interface.

It is perfectly possible to memory map the dataflash without having a lot of ifdefs, by letting the memory commands call a driver. I believe this is the way forward.

It is easier for a user to learn a single command set to handle flash regardless of type.

How do you teach the user that the DataFlash is mapped at some obscure address that has absolutely nothing to do with reality? What address is it mapped at anyway? I can't find any information about this in the README...

Extending the memory commands to take a prefix specifying which address space you're talking about would make a lot more sense, though. Then it might make sense to use 64-bit offsets too since we're not really talking about the CPU's address space anymore, although it could be difficult to support offsets of different size with a single command.

Maybe it would be better to create a different set of commands for manipulating any kind of raw storage (including flash) and let the memory commands deal with memory.

MMC/SD/USB Memories have the advantage of beeing able to be read/written by the host, and this advantage makes it more natural to use a real file system.

Exactly. It's just absurd to pretend removable storage devices reside in physical memory.

Haavard

On 1/30/07, Wolfgang Denk wd@denx.de wrote:

In message 1defaf580701291628s572e1092re30ea906140e2a30@mail.gmail.com you wrote:

...

Maybe it would be better to create a different set of commands for manipulating any kind of raw storage (including flash) and let the memory commands deal with memory.

Exclude flash here, and we already have such an interface: "<bus> read ..." and "<bus> write", for example "eeprom read" or "ide read" or "usb read" or ...

Ah, how come there's no "mmc read" and "mmc write"?

Btw, flash isn't entirely excluded as nand flash seems to use the same interface.

...

Exactly. It's just absurd to pretend removable storage devices reside in physical memory.

Not per se. We could want to support removable memory modules (hot swap RAM - now that would be fun :-)

Yeah, of course. I really meant storage devices that aren't actually behaving like physical memory.

Haavard

Haavard Skinnemoen skrev:

On 1/29/07, Ulf Samuelsson ulf@atmel.com wrote:

...

...

I'm not sure if I understand. U-boot pretends mmc and DataFlash are memory mapped? That sounds completely insane, especially for MMC. What happens if you insert an 8GB SD card on a 32-bit host?

There is nothing to stop U-Boot memory commands from implementing a 64 bit virtual address space.

Except that for most (all?) CPUs supported by u-boot, the virtual address space _isn't_ 64 bit.

...

(The day that you have an 8GB Dataflash, Champagne corks will fly.Largest one today is 8 MB)

Yeah, that's why I said it makes slightly more sense to do this with DataFlash than with MMC. But I'm guessing that whoever implemented the memory mapped MMC thing didn't expect MMC cards to reach 8 GB any time soon either.

...

...

I haven't actually used DataFlash on any avr32 boards yet, but I have written an MMC driver for it and I didn't even know it could be accessed as a memory-mapped device. In fact, I can't even understand why anyone would want that --

The reason to memory map is that then it is easy to do memory commands like copy, compare etc, which you do want to do on dataflash, even though it is not fully implemented in the current mainstream. I have implemented additional functions, because they are really needed. I wrote them because it is such a pain to copy to RAM before you can compare, and I definitely do not like to have to start doing that again.

I agree that the functionality is needed. I just disagree with the interface.

...

It is perfectly possible to memory map the dataflash without having a lot of ifdefs, by letting the memory commands call a driver. I believe this is the way forward.

It is easier for a user to learn a single command set to handle flash regardless of type.

How do you teach the user that the DataFlash is mapped at some obscure address that has absolutely nothing to do with reality? What address is it mapped at anyway? I can't find any information about this in the README...

I have not seen a single customer complain about the fact that a serial flash is memory mapped. The customers are informed about the memory map of the board in the board documentation. If the interface is changed, then this board documentation will have to change.

Alternatively the board documentation will have to document two different command sets for handling dataflash, depending on which version of u-boot is on the board. I am convinced that this is going to cause all sorts of confusion at the customers.

This simple point is key to why I think that the interface to the dataflash should remain as it is.

If the internal implementation changes to something more maintainable I do not have a problem with that, as long as it is tested. I do have a problem with the approach: "let's change the interface, and leave the debugging to someone who cares about whether it works or not".

I know that Atmel's AT91 department does not want to spend any time on U-Boot right now so who will test the fixes for dataflash?

Extending the memory commands to take a prefix specifying which address space you're talking about would make a lot more sense, though.

If you only see dataflash as an extra storage device then you might have a point, in my world it is quite often the only device and I do not see any need to have any prefix.

Computers are good at computation and humans does not like typing. I am sure that noone wants to have a prefix for accessing their normal parallell flash memory and I think anyone that do not want to have such a prefix, should have respect for those that do not want to have a prefix for accessing their only (serial) flash.

On the memory map: I think this is up to the implementor. In AT91 U-Boot AT45/dataflash drivers you have the following mapping : * chip select 0 maps to 0xC000_0000 * chip select 1 maps to 0xD000_0000

Then it might make sense to use 64-bit offsets too since we're not really talking about the CPU's address space anymore, although it could be difficult to support offsets of different size with a single command.

Maybe it would be better to create a different set of commands for manipulating any kind of raw storage (including flash) and let the memory commands deal with memory.

...

MMC/SD/USB Memories have the advantage of beeing able to be read/written by the host, and this advantage makes it more natural to use a real file system.

Exactly. It's just absurd to pretend removable storage devices reside in physical memory.

Haavard

---

Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

Hi Mr. Denk, You are up late this Sunday night. Probably you will not see this until Monday morning!

Wolfgang Denk wrote:

In message 45BD21D7.20203@comcast.net you wrote:

...

...

I can't see how you would get the standard configuration (just RAM and NOR flash support) smaller with such a change?

There are presently quite a few #ifdefs involved in cmd_mem.c and cmd_load.c to take different memory types into consideration. These would mostly go away. That is why I think a ram + flash configuration

OK, so the *source* code may become smaller indeed. But I'd expect the memory footprint on the target system to grow instead, or you lose functionality.

You lose functionality as outlined below. The memory footprint is smaller though. Not that that is a big advantage anyway, I just wanted to assert it didn't get larger.

...

configuration. Naturally, you loose the ability to dump flash data with md, compare to flash data with cmp, copy flash data with cp.b, load data directly to flash with loadb, etc. so it is not free, just a bit smaller.

Arghhh... Indeed, that's not free. I guess for such a price there are other, more efficient ways to reduce the code size.

Probably. However the fact it gets no larger could be important.

...

...

...

current system, it is just a formalization of what has always been desired.

Umm... "always been desired" - by whom? :-)

Well, as I understood it, at least partially by you. :-) The ability to use memory oriented commands on memory other than simple ram seems to be

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

...

considered a plus by many u-boot community members. However, this does

Read what you wrote: "use memory oriented commands on memory". That's exactly what I really expect to be able to do, indeed.

Why should I not be allowed to "md" or "crc" or "cmp" RAM and flash contents?

You should. However, in the current u-boot, if you try these commands with Dataflash addresses, crc takes the crc of some random data, you get an error message saying it is not supported for cmp, and it works correctly for md (because there is explicit code to support it compiled in if Dataflash is present). There is also a device MMC which is included in some builds. As near as I can tell, it does not work in any of the read operations, there is no code built-in for it as a special case.

...

add some complexity and size to the associated memory manipulation commands. As the object being addressed differs more and more from

Not really. Normally only writing may need special handling.

True enough. Yet the only memory write command that explicitly works on flash memory is cp. mw does not check for a flash address, so what it does depends on the protect state of the chip and how the flash works. Some flash lets you change a single byte, others require various erase operations and so on. The rule here may be know what you are doing before you try to modify flash one byte at a time, but it is an asymmetry. I won't even hazard a guess at what loopw will do, but I am sure its not a good idea on flash. The MMC case is also not provided for at all.

I can't say if Dataflash really fits into this szenario; I never used this feature myself.

It does not, and probably is an example of why this is an issue to some of us. Dataflash requires a routine to read the data as well as to write it. Most of the memory read routines work fine on any memory technology that has a one-to-one bus address to data technology. Dataflash does not fit this model and therefore doesn't work in many read operations. In some cases you get an error, because it is explicitly handled in the code, in some cases you get a bogus result and no error. As near as I can determine, the MMC also requires a routine to read data. When copying from MMC to ram, the mmc_read routine is used. In no other cases is it used. Since I think the MMC is a read-write interface through a fifo buffer, based on looking at mmc.c, I assume it does not work in any cases except cp from ram to mmc and from ram to mmc. mmc to flash for instance would write trash to flash as near as I can tell. Also you can't cmp it or md it correctly.

...

simple ram, more and more people seem to accept "new" commands to read and write these objects, and to forgo the advantages/features of the memory commands. This becomes especially true when the size of the object to be read/written exceeds the size of the CPU address space.

Do you have an example where this happens in U-Boot context?

Yes, some of them you give later, like an IDE disk. It would be impossible to memory map large IDE disks all at once, so nobody even considers it as an option. You could perhaps consider a serial Flash to be memory-mapped if that model was desired. I had thought that that might have been desired at one time, but I think that notion is obsolete.

...

What my goal in this proposed design is to allow users to choose at compile time what features are desired for the u-boot memory commands a) without an ifdef maze and b) without needing to inject new code into cmd_mem.c and cmd_load.c for every different memory technology that will use memory access type commands. If somebody wants to use the memory commands on a serial EEPROM, this can be made to work if desired, or not

I feel that would be not natural. And EEPROM (like on a I2C bus) does not have any natural adresses in the CPU's address space. Same for IDE or USB devices. These are storage devices on some form of I/O bus, but certainly NOT memory.

Agreed. But these same arguments apply to Dataflash. Also, there are eeproms that are not serial and can reside on the CPU memory bus. The read-type memory commands would work fine on them, but there would be no way to write to them. I imagine it could be done by hacking into the flash interface, since it is after all similar. The chips read like ram but write more like flash. However, this is somewhat confusing if the parallel eeprom interface would be in the flash module. I guess this can be worried about later if necessary. If it can be decided that the only devices that will be supported by the memory commands in cmd_mem.c are those devices that can be read directly as ram without a read routine, I think that would help clarify the intent of the commands.

...

made to work if not considered necessary, without changing cmd_mem.c. How possible/good this goal is remains to be seen, I agree. The current

IMHO we should provide a user inteface which is powerful, yet easy to use - this requires it must be intuitive to the end user. For most f them, (NOR) flash *is* memory, while and IDE or USB disk and even an EEPROM is not.

I am not sure I concur with the idea users consider NOR flash as "memory" . NOR flash has always required the user to be aware of the protect on/protect off requirements, as well as erase requirements. In fact, the user even needs to know what sectors to protect/unprotect in some cases. The only "memory" write commands that actually do work on NOR flash are cp and loadX. However, I do agree that u-boot users by now expect cp and loadX to work on NOR flash. In fact, I think it is expected to work on any bus-addressed flash type. I can see why removing that support would not work well for existing boards. On the other hand, I do not think it less logical to require a write to flash to consist of a command different from cp, since in order for it to actually work, the user must have done all the right preparation.

...

I completely agree with small and simple, and making feature choices at compile time. I think these attributes can be preserved, or perhaps

Ther eis another thing that is important to me: U-Boot on different systems, boards and architectures shall always behave as similar as possible. Having the "cmp" command (if configured into U-Boot) work on flash memory on one system and failing to do so on another one seems unacceptable to me.

Me too, especially since, if we remove the Dataflash case and MMC case, support for commands like cmp crc, md etc. is absolutely transparent. It takes no code at all. The only issue arises with cp/loadX. If we all agree there is no desire to interface anything that requires a routine to read data from it to the memory commands, then I have no desire to go there either. Presently, we have loadX commands that will work with "flash" by calling flash_write. cp also explicity contains code to work with flash by calling flash_write. Dataflash and MMC devices work in cp by calling mmc_write, mmc_read, write_dataflash, and read_dataflash. These two devices work poorly/not at all in most other memory command cases, but if nobody sees this as a problem, then I don't either. Presently, if there is more than one type of parallel flash in the system, it must be dealt with inside the flash_write routine. Maybe this has never been a problem. It is also true that you can't write across flash memory type boundaries, you get an error, so this is probably fine/expected.

So the summary of all this, from my point of view, is that if we do not expect to add a bunch of new devices to the cmd_mem.c and loadX interfaces, and if we are ok with the present performance of MMC devices and Dataflash devices in the current interface (I don't care since I don't use them), I see no reason to change the current code. I would suggest removing support for MMC and Dataflash devices from the cmd_mem.c file, since these devices seem more like serial FLASH/USB device etc., and moving support to a new file, but I am sure current users wouldn't like that, so they probably must stay where they are. It would be a shame if we intend to add a bunch of cases to the current stuff in cmd_mem.c to not generalize the interface to allow adding such devices without needing to modify cmd_mem.c in the common code, but if we don't expect to make such additions, then I see no need for such a change. I had thought that there was interest in interfacing non-bus devices to the memory commands, along the lines of the Dataflash interface, but with all cases working "properly". I personally have no such interest. If nobody else does, I see no reason for changes in how cmd_mem.c interfaces to "memory". The only change I have any interest in is adding a conditional compile allowing the removal of flash support from the cp/loadX commands without removing support for parallel flash from the board. I prefer FLASH WRITE x y z to cp x y z when dealing with flash, but that's just me. Naturally, all the other commands would still work the same, such as cmp, etc. This is probably because most of the systems I am now working with use serial flash which requires a different command anyway, so I just expect it.

Thanks for bearing with me on this, and I hope the research will be of some benefit!

Best Regards, Bill Campbell

Best regards,

Wolfgang Denk

In message 006c01c74378$2945df50$01c4af0a@atmel.com you wrote:

If you want to store environment in EEPROM (which Wolfgang does not like) then I think you need to memory map it with the current U-Boot.

No, not at all. U-Boot will read the EEPROM through the appropriate I2C / SPI / ... driver calls.

[ And my dislike for EEPROm comes from the facts that (1) I've seen data loss / corruption on I2C EEPROMS too often (see doc/I2C_Edge_Conditions), and that it's so slow which slows down booting too much. ]

...

If it can be decided that the only devices that will be supported by the memory commands in cmd_mem.c are those devices that can be read directly as ram without a read routine, I think that would help clarify the intent of the commands.

No it can't. Any modifications to the dataflash needs to allow for things that work today, and also what needs to be implemented, like memory compare, crc etc.

Ummm... I guess you don't have *my* support any longer on this.

...

cp/loadX. If we all agree there is no desire to interface anything that requires a routine to read data from it to the memory commands

That will never reach an agreement.

Then we will have to come up with a decision even without a complete agreement of all involved parties.

Best regards,

Wolfgang Denk

Wolfgang Denk wrote:

In message 45BD6755.3000100@comcast.net you wrote:

<snip>

...

True enough. Yet the only memory write command that explicitly works on flash memory is cp. mw does not check for a flash address, so what it does depends on the protect state of the chip and how the flash works.

Note that this is intentionally. This is what you use to test flash access commands on the low level. I would consider it broken it this were different.

I understand your point. Similar conditions apply to memory-mapped control and status registers. However, there is still an asymmetry between mw and cp. mw feeds the data directly to the chip, no matter what kind of chip/address is used (which is useful). cp "cooks" the data sent to flash chips so that it will actually write into the chips. (Granted it is cooked very rare, but still it is cooked) This is also desired behavior, but not the same behavior.

<snip>

...

...

...

memory commands. This becomes especially true when the size of the object to be read/written exceeds the size of the CPU address space.

Do you have an example where this happens in U-Boot context?

Yes, some of them you give later, like an IDE disk. It would be

That's not what we discussed. You wrote: "size of the object to be read/written" - the size of such objects is probably always smaller than the storage capacity of the external devices. And I doubt that you will ever be able to write (as an atomical operation) any object that is bigger than the CPU's address space.

We agree here, I just was not very precise. The trick is that if you allow mapping an IDE disk as memory, you could copy from one part of the disk to another part of the disk an an object that is LARGER than the CPU memory space. (There would be nothing requiring the first or second operand of the cp command must be on the CPU memory bus) We also both agree we don't want to do this as part of the cmd_mem.c interface!

...

...

I feel that would be not natural. And EEPROM (like on a I2C bus) does not have any natural adresses in the CPU's address space. Same for IDE or USB devices. These are storage devices on some form of I/O bus, but certainly NOT memory.

Agreed. But these same arguments apply to Dataflash. Also, there are eeproms that are not serial and can reside on the CPU memory bus. The

If they do, it is natural to be able to access these using standard commands like "md". That must be a supported option.

All read commands would work fine. Write operations could be another story. If we define (as I think you do) mw to be a "raw" write to the address space, it would also work, subject to any timing requirements of the device, which is the users problem anyway. cp is another story.

...

read-type memory commands would work fine on them, but there would be no way to write to them. I imagine it could be done by hacking into the

I'm not sure I understand. What sort of devices do you have in mind specifically? We've had FRAM on some boards which was just read / write without problems.

You undoubtedly had FRAM like the FM20L08 that has "NoDelay" writes. However, even these chips do have a software protect/unprotect sequence that requires some "flash-like" commands to use. Some EEPROM chips (for instance the M28LV16) have a (3 ms) page/byte maximum write cycle, which requires a write routine to poll the chip for done on a write when a page boundary is crossed or at the end of any write operation.

...

If it can be decided that the only devices that will be supported by the memory commands in cmd_mem.c are those devices that can be read directly as ram without a read routine, I think that would help clarify the intent of the commands.

Yes, that's what I have in mind.

Good. I think this position greatly clarifies things, at least from my point of view.

<snip>

...

...

IMHO we should provide a user inteface which is powerful, yet easy to use - this requires it must be intuitive to the end user. For most f them, (NOR) flash *is* memory, while and IDE or USB disk and even an EEPROM is not.

I am not sure I concur with the idea users consider NOR flash as "memory" . NOR flash has always required the user to be aware of the protect on/protect off requirements, as well as erase requirements. In

But it's still memory - "flash memory" is a very commnonly used term, so for me there is not the slightest doubt about this.

I understand you point of view. However, the very common use of "flash memory" is also often directed at flash memory that has an spi or other type of interface, which is not the type of flash memory you have in mind! It is also worthy of mention that PPCBUG does have a PFLASH command, so it is not a universal idea that NOR flash is simply memory. It is however a perfectly good point of view, and the one that u-boot follows!

...

fact, the user even needs to know what sectors to protect/unprotect in some cases. The only "memory" write commands that actually do work on NOR flash are cp and loadX. However, I do agree that u-boot users by now

No. Also mw works fine - exactly as it should.

Ack.

<snip>

...

On the other hand, I do not think it less logical to require a write to flash to consist of a command different from cp, since in order for it to actually work, the user must have done all the right preparation.

Call it historical reasons, then ;-)

I like this better :-)

...

Presently, if there is more than one type of parallel flash in the system, it must be dealt with inside the flash_write routine. Maybe this has never been a problem. It is also true that you can't write across flash memory type boundaries, you get an error, so this is probably fine/expected.

No - if flash regions are mapped contiguously, a "cp" should be able to cross device boundaries transparently.

Actually, what I said above is wrong. The flash_write code DOES allow crossing flash type boundaries. What is not allowed in the flash_write routine is starting in flash and ending in non-flash. This throws an error. Starting in flash, intervening ram, ending in flash would not work properly. Holes in the memory map between flash regions also would not work properly. This may be defined as an error, but you don't get an error message in these cases as near as I can tell. Rather, the code seems to do something untoward in the next flash bank. It would be trivial to detect and throw an error for these cases, but the current code does not. Also, there are several places in the current code where it is assumed that if the initial destination address is in ram, the entire operation is in ram. This can be false if ram and flash are contiguously mapped. IMNSHO this condition should either work or be an error that is detected.

There is also a semantic question regarding the meaning of the size part of the cp.X command when the destination operand is flash. If the destination operand is in flash, the size of the operand for both the source and destination addresses is not enforced. The size of access is enforced if the destination is ram. This may be a bit of a nit, but I bring it up for completeness. cp.l commands that look like they for sure should generate an alignment exception will not do so if the destination is flash.

<snip>

...

change. I had thought that there was interest in interfacing non-bus devices to the memory commands, along the lines of the Dataflash

Not on my side...

Ack. Not mine either!

Best Regards, Bill Campbell

Best regards,

Wolfgang Denk

Wolfgang Denk wrote: <snip>

...

...

No - if flash regions are mapped contiguously, a "cp" should be able to cross device boundaries transparently.

Actually, what I said above is wrong. The flash_write code DOES allow crossing flash type boundaries. What is not allowed in the flash_write routine is starting in flash and ending in non-flash. This throws an error. Starting in flash, intervening ram, ending in flash would not work properly. Holes in the memory map between flash regions also would

Actually, I am still wrong. The flash code allows crossing flash chip boundaries of the same type. It does not support crossing flash type boundaries of different types unless the write_buff routine chosen for the target board does some additional de-multiplexing. Thus, if you use common/cfi_flash.c, all your flash needs to be cfi flash. Many of the flash routines in the board/ directory do support more than one type of flash. I just wanted to state this correctly.

You are right. But anybody who is crazy enough to come up with such a memory map should fix his design before complaining that U-Boot does not support all possible pathologic cases.

OK, that makes sense.

...

not work properly. This may be defined as an error, but you don't get an error message in these cases as near as I can tell. Rather, the code

There are many other misconfigurations that result in non-working systems without useful error message (in most cases because the code crashes long before it can send any messages at all).

OK, but there are also cases where you DO get an error. I assume it depends mostly on the cost of detecting the error and how important/probable the error condition may be.

...

seems to do something untoward in the next flash bank. It would be trivial to detect and throw an error for these cases, but the current code does not. Also, there are several places in the current code where

As mentioned before: I tend to consider this as a design error which is not worth the code for runtime error checking.

OK. I'm not sure I totally agree, as I think the parameters could easily be checked in addr2info in a manner that should not increase the footprint much if at all. I will submit a patch and see what you think. On the other hand you are quite right that nothing prevents the user from copying from non-existent memory to non-existent memory, so other address errors are no different.

...

it is assumed that if the initial destination address is in ram, the entire operation is in ram. This can be false if ram and flash are contiguously mapped. IMNSHO this condition should either work or be an error that is detected.

If you look close enough, you can find many problematic situations - eception vectors, malloc arena, stack, U-Boot code, data and BSS etc. are not protected in RAM - you can easily overwrite any of these without any protection.

You can do a lot more mess when meddeling with PCI memory.

U-Boot does not attampt to prevent all possible kind of user errors. It was designed to be small, powerful, and easy to port.

Here is one of my favorite quotes which fully applies to U-Boot, too:

"UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn

Agreed and understood.

...

There is also a semantic question regarding the meaning of the size part of the cp.X command when the destination operand is flash. If the destination operand is in flash, the size of the operand for both the source and destination addresses is not enforced. The size of access is enforced if the destination is ram. This may be a bit of a nit, but I

Sorry, I cannot parse this. Please explain.

...

bring it up for completeness. cp.l commands that look like they for sure should generate an alignment exception will not do so if the destination is flash.

Why should they?

Well, my thought on this is that UNIX (and u-boot) also follows the Principle of Least Surprise, namely that like cases tend to work alike. If I type cp.l 0x3 0x10 0x1 on a system that enforces longword (4 byte words) to be aligned, it will throw an exception and not work. I would therefore also expect cp.l 0x3 <some flash address> 0x1 to also throw an exception and not work for the same reason, yet it does not do so. It is executed as cp.b 0x3 <some flash address> 0x1, which is not what I asked for. Like I said, this is a nit and probably not important. I expect few people use cp.l to copy into flash anyway. It was just a difference between flash and ram that I noticed.

Best Regards, Bill Campbell

Best regards,

Wolfgang Denk

If it can be decided that the only devices that will be supported by the memory commands in cmd_mem.c are those devices that can be read directly as ram without a read routine, I think that would help clarify the intent of the commands.

Why limit to "read". Why not say that any memory which can be read or *written* without a driver will be supported by the cmd_mem.c ?

In message 45BE95C6.8090809@comcast.net you wrote:

There are at least two very good reasons why adding the "written" constraint is not practical: First, as he has stated several times in this thread, Mr. Denk believes that users regard NOR flash as just like ram and therefore expect ram commands to work on it. This point of view

I *never* said that. I said we consider it as *memory*, and expect *memory* commands to work on it. Note the difference.

I also expect memory commands to work on PCI windows, for example.

certainly has merit, and while we may not all totally agree with it, it is, and must be, Mr. Denk's u-boot. He is the final determining person on what will be accepted.

No, it's not my U-Boot, it's *our* baby.

Best regards,

Wolfgang Denk

On 1/29/07, Wolfgang Denk wd@denx.de wrote:

In message 45BD6755.3000100@comcast.net you wrote:

...

On the other hand, I do not think it less logical to require a write to flash to consist of a command different from cp, since in order for it to actually work, the user must have done all the right preparation.

Call it historical reasons, then ;-)

...

takes no code at all. The only issue arises with cp/loadX. If we all agree there is no desire to interface anything that requires a routine to read data from it to the memory commands, then I have no desire to go there either. Presently, we have loadX commands that will work with

I do agree. Grant?

Yes, I agree.

[I really have to stop myself from writing "You can take this for Granted" :-) ]

:-P

In message 007201c7455f$aebb2b20$01c4af0a@atmel.com you wrote:

But we dont all agree, I only see a bunch of non-data flash users that agree that dataflash users do not need to do memory commands.

How many dataflash *users* have voiced their opinion here?

Memory commands are used to handle flash and DRAM.

... and other memory ranges that are mapped into the address sapce of the processor.

Please explain to me why the users should care about that you do not like the internal implementation?

Where are those users?

A perfectly good implementation would let the memory commands (after translation of environment variables) send the parameters to a validation routine for each supported memory.

I disagree here. You are talking about storage devices, not memory. Can we agree that "memory" shall be considered something which is directly addressable in the processors address space? So ROM, RAM and NOR flash are memory, but NAND flash, data flash, an EEPROM with I2C interface, USB, IDE, etc. are *not* memory? Once we have such an agreement, then you will understand what the memory commands shall support (memory), and what not (storage devices).

I am sorry that I did not catch this when dataflash support was added initially, or when MMC support was added. My fault.

The validation routine would return an accept or reject. If accepted, then for you would call a probe routine for any memorty read, which would return a pointer to a valid block of memory containint minimum n valid bytes.

And how do you explain to a user, that the "cp" or "md" command can read valid data from some magic address, while accessing the same addresses in a JTAG debugger does not work at all?

Sorry, this *is* conceptually broken. I agree that this needs to be cleaned up.

Best regards,

Wolfgang Denk

On 1/31/07, Ulf Samuelsson ulf@atmel.com wrote:

ons 2007-01-31 klockan 22:55 +0100 skrev Wolfgang Denk: There is a very big difference in "cleaning" something up and removing most of the functionality,because You dont use it, and find it irritating to see it in the code.

I have no intention of removing the functionality. However, I do not believe that it belongs in the memory access commands. There should be an appropriate command set for doing read/write/compare against devices which does not pretend that it is mapped onto memory

Nor have I any intention of pushing patches to remove the DataFlash hooks right now. I will make wait until an appropriate replacement has been accepted and tested before posting patches to remove the cmd_mem hooks.

As for the prefix option; I do agree that it can be implemented that way, but I think that a separate command set for device access is a better UI (for many of the reasons discussed in this thread). Since Wolfgang is also of this opinion, I'm going to go ahead and start drafting a command set.

What remains to be discussed is the process of depreciating the cmd_mem hooks to minimize the end user impact. ie. Format of replacement commands, How long will the transition period be, how will the changes be documented, what order do patches get applied, etc.

Cheers, g.

Wolfgang Denk wrote:

...

Then please continue to explain why, when you are doing exactly the same manouvers, but use a serial flash, you do not need the commands.

Because these devices are not directly addressable in the processors address space, i. e. they are not memory.

Everything is fine as long as the "md" command in U-Boot and the "md" command at my BDI2000's telnet prompt show the same results for the same address ranges. When this is NOT the case, something is broken. Here, it is the U-Boot implementation.

I guess I am OK with either implementation.

I think just because BDI is not capable of handling any address space besides the processor address space should not mean we should so restrictive of command line of U-Boot. I think address space tags that I proposed yesterday could remove the confusion of what address the command is referring to and it is easy to explain that a BDI could only access untagged address space directly and everything else are indirectly accessible memory. This would also enable us to use paged memory mapped to a small window in processor address space seamlessly.

Anyway, I think either approach is valid and usable. There are pros and cons with either scheme.

I think it might be easier to educate the user with one set of commands as opposed to user having to decide which one of several <dev> read/write commands should be applicable.

...

The concept to map an address is not at all hard to explain. Even so, I have never had the question in over 100 projects.

For me this is a very important issue: when U-Boto and a hardware debugger start behaving differently, I consider this a serious problem. U-Boot is a boot loader, and as such mostly a hardware debug tool.

I see your point. However, with a hardware debugger you are not currently able to mmc data directly and so you could not be able to access mmc:0x00112233 either because "mmc:0x00112233" is not an address that would be valid for BDI. So, I see no difference. It is really mostly a matter of style rather than function.

Having the capability of u-boot memory commands to access different address spaces is a convenience feature. When such feature is not available the read/write commands will bring a chunk to ram and it will be processed using memory commands again so first one would allow the two operations combined but not a huge gain or loss either way.

Having said all that, I will concluded that either way is OK for me as long as we maintain consistent architecture.

Tolunay

On 1/27/07, J. William Campbell jwilliamcampbell@comcast.net wrote:

Grant Likely wrote:

...

On 1/26/07, Wolfgang Denk wd@denx.de wrote: Thoughts? Feel free to tell me if I'm flying too high in the stratosphere on this one. g.

I think Grant has a good point. The discussion about abstractions used to read/write devices and memory is really a discussion about a memory hierarchy. If we treat it this way, it is possible to optionally give everybody what they want while still allowing a "minimal" u-boot configuration for people who do not desire a particular feature of the "storage hierarchy". Suppose we have an abstraction that treats CF, IDE HD, DataFlash, memmapped flash etc. as a device. We also have a set of commands that read/write to these devices. There will be a protect command that does nothing on devices that do not understand this command.

Yes, a device driver exports a table of ops and it is free to omit any operations it does not support.

BTW, for this iteration, I'm only looking at device read/write. I plan to leave the protect/erase/etc commands alone (use existing commands)

This way, it is possible to read/write from any "device" to system ram.

yes

A driver to treat system ram as a device could also be compiled into u-boot.

Hmmm, I think that goes too far. Memory mapped ram is always available and doesn't need any special operations to access it. I don't see any value in wrapping it with a device driver.

As Grant discussed in an earlier part of this thread, we can also modify the current memory commands such that there is a table of what I will call "mmapped address". If the mmapped support is enabled, all memory commands will pass through a routine that splits them up into sub-commands that operate on addresses in single parts of the mmapped address table for both source and destination.

Yes. I'm not fond of this behavior, but it can be easily implemented. I don't like the idea of pretending non memmapped devices have real bus addresses. I would prefer a namespace which defines the device you want to talk to. For example:

Instead of: "cp 200000 cf004000 200" (copy from 0x200 bytes from mem address 200000 to address 0x4000 on MMC card) I'd prefer: "cp 200000 mmc0:4000"

But, I don't want to debate this issue just yet. For the time being, I'll stick with using virtual memmapping (status quo for MMC and DataFlash).

This would include breaking the commands into "sector-sized" operations based on an entry for the sector size in the table. Non-sectored devices can use all 1s for the sector size. The memory commands now would consist of a seek/read from one "device" followed by seek and read or write from another device. If necessary, buffering would be provided by two dedicated buffers in the memory command subsystem.

Yes, mostly, as long as regular memcpy is used wherever possible. For copy operations, I see four possible cases: 1. memory to memory 2. memory to device 3. device to memory 4. device to device

1. is trivial; it's just memcpy. 2 & 3 are mostly trivial; a call to the device read/write hook can operate directly on memory 3. this is not trivial (but not hard either). It requires the copy routine to buffer all data to be transfered, and also to reconcile between differing block sizes. I'm tempted to say this is either not supported; or is an optional feature.

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.

In message 009101c7437a$0d0ee6e0$01c4af0a@atmel.com you wrote:

I dont see why you should need to call any "open" routine since the dataflash is active before u-boot has even started and does not need any initialization sequence.

You load U-boot from the dataflash to the SDRAM so any initialization needed by the dataflash is already done before the first U-boot instruction is executed..

This may, or may not, be the case. We've been discussing this before. For me, booting from dataflash is not a default mode operation for U-Boot.

Best regards,

Wolfgang Denk

In message 528646bc0701281833i5d595d83ua436f75c8b29e76@mail.gmail.com you wrote:

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.

Does that mean you suggest to have to different sets of accesor functions, one for early boot and another one for later?

Best regards,

Wolfgang Denk