[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT
On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:
#define CFG_ENV_ADDR (CFG_MONITOR_BASE - 0x1000) #define CFG_ENV_SIZE 0x2000
This means that the environment is stored 0x1000 bytes before the start of u-boot.bin. Doesn't that mean that if the environment is larger than 0x1000 bytes, that it will overwrite the beginning of u-boot.bin whenever someone does a saveenv?
Doesn't anyone have an answer to this question?
Timur Tabi wrote:
On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:
#define CFG_ENV_ADDR (CFG_MONITOR_BASE - 0x1000) #define CFG_ENV_SIZE 0x2000
This means that the environment is stored 0x1000 bytes before the start of u-boot.bin. Doesn't that mean that if the environment is larger than 0x1000 bytes, that it will overwrite the beginning of u-boot.bin whenever someone does a saveenv?
Timur Tabi wrote:
Doesn't anyone have an answer to this question?
Timur Tabi wrote:
On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:
#define CFG_ENV_ADDR (CFG_MONITOR_BASE - 0x1000) #define CFG_ENV_SIZE 0x2000
This means that the environment is stored 0x1000 bytes before the start of u-boot.bin. Doesn't that mean that if the environment is larger than 0x1000 bytes, that it will overwrite the beginning of u-boot.bin whenever someone does a saveenv?
Looks like it to me. Looks like somebody increased the size without fixing the address offset to match.
Looks to me like it would be better defined: #define CFG_ENV_SIZE 0x2000 #define CFG_ENV_ADDR (CFG_MONITOR_BASE - CFG_ENV_SIZE)
The saving grace here is probably: * For a RAMBOOT image, there isn't any incentive to save lots of stuff in the env since it (generally) disappears on a reboot and definitely disappears on a power cycle.
* On the PowerPC, at least, the first 12K of u-boot.bin is the HRCW and vectors which aren't used by a RAMBOOT image so overwriting them is a non-fatal error.
* 4K is fairly large for an env, so people probably don't run into the problem.
Best regards, gvb
In message 46535865.6060400@smiths-aerospace.com you wrote:
Looks to me like it would be better defined: #define CFG_ENV_SIZE 0x2000 #define CFG_ENV_ADDR (CFG_MONITOR_BASE - CFG_ENV_SIZE)
No, this is broken as CFG_ENV_SIZE may be (and often actually is) smaller than CFG_ENV_SECT_SIZE
The saving grace here is probably:
- For a RAMBOOT image, there isn't any incentive to save lots of stuff
in the env since it (generally) disappears on a reboot and definitely disappears on a power cycle.
One could argue that a correctly configured ramboot version would access the original copy of the environment in flash. But such discussion is void, as ramboot itself it not supported officially.
- On the PowerPC, at least, the first 12K of u-boot.bin is the HRCW and
vectors which aren't used by a RAMBOOT image so overwriting them is a non-fatal error.
Wrong. You may have timer and other interrupts, so overwriting the exception vectors is a Bad Thing (TM).
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 46535865.6060400@smiths-aerospace.com you wrote:
Looks to me like it would be better defined: #define CFG_ENV_SIZE 0x2000 #define CFG_ENV_ADDR (CFG_MONITOR_BASE - CFG_ENV_SIZE)
No, this is broken as CFG_ENV_SIZE may be (and often actually is) smaller than CFG_ENV_SECT_SIZE
Why would that matter? Does the environment need to be located on a sector boundary?
One could argue that a correctly configured ramboot version would access the original copy of the environment in flash. But such discussion is void, as ramboot itself it not supported officially.
My understanding of ramboot is that its sole purpose is to boot U-Boot when flash isn't working at all, so any ramboot-enabled U-Boot would never access anything on flash.
In message 46535B7B.2090903@freescale.com you wrote:
Looks to me like it would be better defined: #define CFG_ENV_SIZE 0x2000 #define CFG_ENV_ADDR (CFG_MONITOR_BASE - CFG_ENV_SIZE)
No, this is broken as CFG_ENV_SIZE may be (and often actually is) smaller than CFG_ENV_SECT_SIZE
Why would that matter? Does the environment need to be located on a sector boundary?
Look at the code.
One could argue that a correctly configured ramboot version would access the original copy of the environment in flash. But such discussion is void, as ramboot itself it not supported officially.
My understanding of ramboot is that its sole purpose is to boot U-Boot when flash isn't working at all, so any ramboot-enabled U-Boot would never access anything on flash.
Other people had other ideas.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 46535B7B.2090903@freescale.com you wrote:
Looks to me like it would be better defined: #define CFG_ENV_SIZE 0x2000 #define CFG_ENV_ADDR (CFG_MONITOR_BASE - CFG_ENV_SIZE)
No, this is broken as CFG_ENV_SIZE may be (and often actually is) smaller than CFG_ENV_SECT_SIZE
Why would that matter? Does the environment need to be located on a sector boundary?
Look at the code.
Which code? The environment isn't even located in flash, so what difference does it make if it's not on a sector boundary? There aren't even any sectors!
My understanding of ramboot is that its sole purpose is to boot U-Boot when flash isn't working at all, so any ramboot-enabled U-Boot would never access anything on flash.
Other people had other ideas.
I don't recall reading any. Can you tell what you're talking about?
Wolfgang Denk wrote:
In message 46535865.6060400@smiths-aerospace.com you wrote:
Looks to me like it would be better defined: #define CFG_ENV_SIZE 0x2000 #define CFG_ENV_ADDR (CFG_MONITOR_BASE - CFG_ENV_SIZE)
No, this is broken as CFG_ENV_SIZE may be (and often actually is) smaller than CFG_ENV_SECT_SIZE
In the case of RAMBOOT where the env is stored in RAM, the flash sector size is immaterial. "But such discussion is void, as ramboot itself it not supported officially."
The saving grace here is probably:
- For a RAMBOOT image, there isn't any incentive to save lots of stuff
in the env since it (generally) disappears on a reboot and definitely disappears on a power cycle.
One could argue that a correctly configured ramboot version would access the original copy of the environment in flash. But such discussion is void, as ramboot itself it not supported officially.
Yup, but arguing minutia keeps geeks entertained. ;-)
- On the PowerPC, at least, the first 12K of u-boot.bin is the HRCW and
vectors which aren't used by a RAMBOOT image so overwriting them is a non-fatal error.
Wrong. You may have timer and other interrupts, so overwriting the exception vectors is a Bad Thing (TM).
Beg to differ (granted, I was pretty loose in my description above). If the env is being stored _before_ u-boot.bin, it means u-boot.bin is not being stored at location 0x00000000 thus _those_ vectors cannot be the ones actively being used by the processor. They are the _source_ of the active vectors (copied to location 0 on relocation) but that is before they are *hypothetically* corrupted by the user creating 4K++ of env and then saving the env.
Obviously, the RAMBOOT u-boot.bin image cannot have more than 4K (+/-) of env variables built in or Very Bad Things would have happened during the link and/or execution. "But such discussion is void, as ramboot itself it not supported officially."
Best regards,
Wolfgang Denk
Best regards, gvb
On 5/22/07, Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
Timur Tabi wrote:
Doesn't anyone have an answer to this question?
That's easy: It's broken. I sort of thought it was too obvious to bother with a response.
The saving grace here is probably:
- For a RAMBOOT image, there isn't any incentive to save lots of stuff
in the env since it (generally) disappears on a reboot and definitely disappears on a power cycle.
I suspect what happened is that no one uses RAMBOOT, so no one noticed when it broke.
- On the PowerPC, at least, the first 12K of u-boot.bin is the HRCW and
vectors which aren't used by a RAMBOOT image so overwriting them is a non-fatal error.
Woah, there. On *some* PowerPC, the first 12k are HRCW. On 85xx this is not the case. The low 256 bytes are for the version string and some empty space. Then we have _start. The exception vectors (as Wolfgang noted) are all in that space. So it's not a problem as long as you never hit a Decrementer exception...
suffice it to say, I would accept any patch which fixed this. But left to my own devices, I don't anticipate fixing this anytime soon.
- 4K is fairly large for an env, so people probably don't run into the
problem.
Best regards, gvb
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Andy Fleming wrote:
On 5/22/07, Jerry Van Baren gerald.vanbaren@smiths-aerospace.com wrote:
Timur Tabi wrote:
Doesn't anyone have an answer to this question?
That's easy: It's broken. I sort of thought it was too obvious to bother with a response.
When something is obviously broken and yet prevalent, it makes me think I might be missing something. In this case, it appears I'm not.
suffice it to say, I would accept any patch which fixed this. But left to my own devices, I don't anticipate fixing this anytime soon.
It's on my to-do list.
In message 46535F2D.80805@freescale.com you wrote:
When something is obviously broken and yet prevalent, it makes me think I might be missing something. In this case, it appears I'm not.
Prevalent? 16 out of 354 configurations, and all of the same breed?
That's a pretty isolated phenomenon tome.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote:
In message 46535F2D.80805@freescale.com you wrote:
When something is obviously broken and yet prevalent, it makes me think I might be missing something. In this case, it appears I'm not.
Prevalent? 16 out of 354 configurations, and all of the same breed?
It's prevalent among Freescale 8xxx-based boards, which is good enough for me. Since I'm not familiar with the other architectures, I can only use quirks in the 8xxx code as a basis for anything. And that's why I post questions like this to the mailing list, so that I can see if anyone with more experience can shed some light. Unfortunately, I occasionally get flamed for it.
In message 46535464.6090206@freescale.com you wrote:
Doesn't anyone have an answer to this question?
Maybe nobody cares? It's an officially unsupported feature anyway.
Timur Tabi wrote:
On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:
Let's put this straight: it is not "a lot of boards", it's just 16 boards - less than 5%:
MPC8313ERDB MPC8360EMDS MPC8641HPCN TQM834x MPC832XEMDS MPC8540ADS PM854 sbc8349 MPC8349EMDS MPC8540EVAL PM856 sbc8560 MPC8349ITX MPC8560ADS SBC8540 stxgp3
If you look closer, you can see that it's only 83xx, 85xx and 86xx systems. Guess where most of the responsible board maintainers are sitting? And who the responsible custodians are?
#define CFG_ENV_ADDR (CFG_MONITOR_BASE - 0x1000) #define CFG_ENV_SIZE 0x2000
Of course this is broken and should always be written as
#define CFG_ENV_ADDR (CFG_MONITOR_BASE-CFG_ENV_SECT_SIZE)
instead.
This means that the environment is stored 0x1000 bytes before the start of u-boot.bin. Doesn't that mean that if the environment is larger than 0x1000 bytes, that it will overwrite the beginning of u-boot.bin whenever someone does a saveenv?
I suggest you raise the issue with the board maintainers and/or custodians. Maybe you simply remove all this broken ramboot support.
Best regards,
Wolfgang Denk
On 5/22/07, Wolfgang Denk wd@denx.de wrote:
In message 46535464.6090206@freescale.com you wrote:
Doesn't anyone have an answer to this question?
Maybe nobody cares? It's an officially unsupported feature anyway.
I suspect that's why we've not heard any complaints
Timur Tabi wrote:
On a lot of boards, if CFG_RAMBOOT is defined, the following code is compiled:
Let's put this straight: it is not "a lot of boards", it's just 16 boards - less than 5%:
MPC8313ERDB MPC8360EMDS MPC8641HPCN TQM834x MPC832XEMDS MPC8540ADS PM854 sbc8349 MPC8349EMDS MPC8540EVAL PM856 sbc8560 MPC8349ITX MPC8560ADS SBC8540 stxgp3
If you look closer, you can see that it's only 83xx, 85xx and 86xx systems. Guess where most of the responsible board maintainers are sitting? And who the responsible custodians are?
Yeah, we let this slip in to the first 85xx board (It was useful for bring-up, when we didn't have working Flash support). And it's fairly straightforward to see that the config files have just been copied from the original MPC8540ADS, and modified.
Anyone who wants to eliminate the RAMBOOT stuff has *my* blessing. It's just way down my priority list for actually doing.
I suggest you raise the issue with the board maintainers and/or custodians. Maybe you simply remove all this broken ramboot support.
Works for me. Who's got a patch. ;)
Andy
On Tue, May 22, 2007 at 11:00:57PM +0200, Wolfgang Denk wrote:
I suggest you raise the issue with the board maintainers and/or custodians. Maybe you simply remove all this broken ramboot support.
Shall I read it a general rule? i.e. remove support for at91rm9200dk Atmel's reference design broken since 04 Apr 2005?
Best regards, ladis
On Tue, May 22, 2007 at 11:00:57PM +0200, Wolfgang Denk wrote:
I suggest you raise the issue with the board maintainers and/or custodians. Maybe you simply remove all this broken ramboot support.
Shall I read it a general rule? i.e. remove support for at91rm9200dk Atmel's reference design broken since 04 Apr 2005?
Best regards, ladis
Things are broken, because Wolfgang refuses patches fixing problems on AT91 on principle. Removing support will cause more work for people because the existing patches to make things work will have to be modified...
What is the point of sabotaging others peoples efforts???
Best Regards Ulf Samuelsson
On Wed, May 23, 2007 at 12:48:20PM +0200, Ulf Samuelsson wrote:
Things are broken, because Wolfgang refuses patches fixing problems on AT91 on principle. Removing support will cause more work for people because the existing patches to make things work will have to be modified...
Wolfgang is waiting for custodian to comment on patch. So far nothing happened. Please note that I'm the last one who wants to see support of this board removed. Also I'm all for applying patches you send to the mailing list (that serie 1,2,3,4,6,7,10,24) except for 24.noflash which seems a bit hackish (and yes I run into the very same problem this patch is trying to solve recently). If there is anything I can do to help them to get applied, just let me know.
What is the point of sabotaging others peoples efforts???
Removing non working code makes whole codebase cleaner. Sabotage is leaving non working code in repository without any will to at least consider applying patches... Anyway, who is responsible for AT91 code?
Best regards, ladis
On Wed, May 23, 2007 at 12:48:20PM +0200, Ulf Samuelsson wrote:
Things are broken, because Wolfgang refuses patches fixing problems on AT91 on principle. Removing support will cause more work for people because the existing patches to make things work will have to be modified...
Wolfgang is waiting for custodian to comment on patch. So far nothing happened. Please note that I'm the last one who wants to see support of this board removed. Also I'm all for applying patches you send to the mailing list (that serie 1,2,3,4,6,7,10,24) except for 24.noflash which seems a bit hackish (and yes I run into the very same problem this patch is trying to solve recently). If there is anything I can do to help them to get applied, just let me know.
What is the point of sabotaging others peoples efforts???
Removing non working code makes whole codebase cleaner. Sabotage is leaving non working code in repository without any will to at least consider applying patches... Anyway, who is responsible for AT91 code?
I think the AT91 group submitted the at91rm9200dk support. All following patches has been rejected. They are fed up with lack of response, has decided not to waste time time on this until the attitude is changed.
I tried to resubmit, but since Grant and Wolfgang has come to the conclusion that sometimes memory is not memory I see no possibility to overcome difference.
The correct approach is to fix the support, and I believe Grant started the debate by saying that he wanted to fix it. I have not seen any result of this.
Best regards, ladis
Best Regards Ulf Samuelsson
In message 007301c79d3a$37b63320$f22ab10a@atmel.com you wrote:
I tried to resubmit, but since Grant and Wolfgang has come to the conclusion that sometimes memory is not memory I see no possibility to overcome difference.
Memory is always memory. Serially attached devices are NOT memory.
But IIRC this is only one part of your patches. There are other parts that have not been disputed.
The correct approach is to fix the support, and I believe Grant started the debate by saying that he wanted to fix it. I have not seen any result of this.
Maybe you could just submit the other parts of your fixes in the meantime?
Best regards,
Wolfgang Denk
In message 007301c79d3a$37b63320$f22ab10a@atmel.com you wrote:
I tried to resubmit, but since Grant and Wolfgang has come to the conclusion that sometimes memory is not memory I see no possibility to overcome difference.
Memory is always memory. Serially attached devices are NOT memory.
That is _your_ definition of memory, others like "Webster Dictionary" say:
"Memory: a device (as a chip) or a component of a device in which information especially for a computer can be inserted and stored and from which it may be extracted when wanted; especially : RAM"
You add an extra requirement that memory must be randomly addressable over a parallel bus. This view is uncompatible with Websters dictionary which does not pose such restrictions. Furthermore, everyone designing flash memories, believe that serial flash memories are memories.
You have made your decision here, and I have to accept that, but you are then trying to get *me* to make the changes you want, and I really have no incentive to do that and will leave that to others.
But IIRC this is only one part of your patches. There are other parts that have not been disputed.
The correct approach is to fix the support, and I believe Grant started the debate by saying that he wanted to fix it. I have not seen any result of this.
Maybe you could just submit the other parts of your fixes in the meantime?
I have submitted one, and will submit more if that gets accepted,
The remainder are basically "board/<board>/*" files and "cpu/arm926ejs/at91sam926x/*" files. None of these patches will result in anything useful for U-boot since the dataflash support will be broken and no board will work without dataflash. - ALL boards will be broken.
Since "dangling" patches are not wanted, why would any patch get accepted.
Best regards,
Wolfgang Denk
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29GSM +46 (706) 22 44 57
Technical support when I am not available: AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com AVR32 Applications Group mailto:avr32@atmel.com http://www.avrfreaks.net/; http://avr32linux.org/ http://www.at91.com/ ; ftp://at91dist:distrib@81.80.104.162/
On Wed, May 23, 2007 at 06:19:21PM +0200, Ulf Samuelsson wrote:
In message 007301c79d3a$37b63320$f22ab10a@atmel.com you wrote:
I tried to resubmit, but since Grant and Wolfgang has come to the conclusion that sometimes memory is not memory I see no possibility to overcome difference.
Memory is always memory. Serially attached devices are NOT memory.
That is _your_ definition of memory, others like "Webster Dictionary" say:
"Memory: a device (as a chip) or a component of a device in which information especially for a computer can be inserted and stored and from which it may be extracted when wanted; especially : RAM"
You add an extra requirement that memory must be randomly addressable over a parallel bus. This view is uncompatible with Websters dictionary which does not pose such restrictions. Furthermore, everyone designing flash memories, believe that serial flash memories are memories.
That belive has nothing to do with software interface design. While you pretend serial flash memory is somehow mapped into procesor address space, others have different ideas. "Webster Dictionary" uses largest common denominator so its definition applies to hard discs as well. Do we pretend hard disc content is mapped over IDE or SCSI bus into CPU address space?
You have made your decision here, and I have to accept that, but you are then trying to get *me* to make the changes you want, and I really have no incentive to do that and will leave that to others.
Then I'm voluntering to do that work. There is one issue left. The interface. I remember few almost endless debates about this topic, but no conclusion.
Lets dive into archives.
In this thread most of possible solutions were developed. Without conclusion. Subject: Atmel DataFlash hooks. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/25983
And this is another very interesting thread: Subject: [PATCH] DataFlash for AT91RM9200DK board http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/9175 It contains quite interesting part which is worth to repeat there (by Wolfgang Denk, 2003-06-04)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In our case, we use it to store and boot an image of linux(the dataflash contains the linux zImage and the ramdisk). This dataflash can be used also for a filesystem.
In this case I think we should offer an interface which looks\ to the user like mmeory.
Instead of providing separate commands to read and write from such "memory" I think we should integrate this into the existing code.
For example, writing to "normal" flash memory is an implicit operation to the "cp" (copy) command when it detects that the target address is in flash memory.
The same should be done for dataflash.
OK, with "normal" flash memory we don't have to special-case read accesses like used by "md" or "bootm" commands - where in case of dataflash such handling will be necessary.
But especially if you boot Linux from dataflash it seems more logical to me to use "bootm" directly instead of using "dataflash read" + "bootm" in separate steps.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
That makes clear reasons behind Ulf's statement and also shows that not all decisions are good ones.
If anyone feels need to fix u-boot's dataflash support, then please either lets continue in more than 16 weeks old debate in 'Atmel DataFlash hooks' thread or spawn new one.
Best regards, ladis
Dear Ladislav,
in message 20070524121048.GA6516@michl.2n.cz you wrote:
And this is another very interesting thread: Subject: [PATCH] DataFlash for AT91RM9200DK board http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/9175 It contains quite interesting part which is worth to repeat there (by Wolfgang Denk, 2003-06-04)
I don't have words to express how much I repent these words.
When I wrote this, I had no idea what DataFlash is and that it actually uses a serial interface. It would be lame if I tried to come up ith the "little time" excuse, because it does not help to undo the damage done then.
In our case, we use it to store and boot an image of linux(the dataflash contains the linux zImage and the ramdisk). This dataflash can be used also for a filesystem.
In this case I think we should offer an interface which looks\ to the user like mmeory.
This was a major misapprehension, and I formally apologize to everybody who suffered or still suffers from the consequences.
That makes clear reasons behind Ulf's statement and also shows that not all decisions are good ones.
Right. This was definitely a bad one.
If anyone feels need to fix u-boot's dataflash support, then please either lets continue in more than 16 weeks old debate in 'Atmel DataFlash hooks' thread or spawn new one.
DataFlash is much more similar to NAND flash than it is to NOR flash or RAM.
IMHO a pretty good summary of the last state of the previous thread can be found here:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/26147
In short:
* the cmd_mem hooks should be removed and replaced by a new interface * the new interface will probably be similar to the NAND interface * both the process for the migration and the new command format need to be discussed * there is no intention to remove functionality, nor to sabotage anybody, but there is pending cleanup that needs to get done sooner or later
During the transition perion, it is IMHO not a good idea to add more code to the old interface because this will just increase the amount of cleanup work that will be needed later; instead, efforts should be put in helping to define, implement and test the new interface.
Thanks.
Wolfgang Denk
On Thu, May 24, 2007 at 03:03:39PM +0200, Wolfgang Denk wrote:
IMHO a pretty good summary of the last state of the previous thread can be found here:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/26147
In short:
- the cmd_mem hooks should be removed and replaced by a new interface
- the new interface will probably be similar to the NAND interface
Perhaps it would make sense build it on top of SPI interface. This way one could read registers of other SPI peripherals (MMC cards etc). I'm not sure how useful it can be. Anyway, implementing that for dataflash seems pretty straightforward, so I'll code it.
- both the process for the migration and the new command format need to be discussed
- there is no intention to remove functionality, nor to sabotage anybody, but there is pending cleanup that needs to get done sooner or later
It would be good to get at45.c patch merged first. It will make maintaining changes much easier.
Best regards, ladis
Memory is always memory. Serially attached devices are NOT memory.
That is _your_ definition of memory, others like "Webster Dictionary" say:
"Memory: a device (as a chip) or a component of a device in which information especially for a computer can be inserted and stored and from which it may be extracted when wanted; especially : RAM"
You add an extra requirement that memory must be randomly addressable over a parallel bus. This view is uncompatible with Websters dictionary which does not pose such restrictions. Furthermore, everyone designing flash memories, believe that serial flash memories are memories.
That belive has nothing to do with software interface design. While you pretend serial flash memory is somehow mapped into procesor address space, others have different ideas. "Webster Dictionary" uses largest common denominator so its definition applies to hard discs as well. Do we pretend hard disc content is mapped over IDE or SCSI bus into CPU address space?
Not in U-boot but in very efficient databases, the virtual memory is used to directly map to hard disks since this is much more efficient than file access. This is one of the main reasons to move to 64 bit virtual addressing
my primary concern is ease of use, and I am pretty sure that any new interface will result in more typing than the old interface.
Just the thought of having to type "spi write" or "dataflash write"
instead of
"cp.b"
sends shudder down my spine...
If people agreed that we change the memory interface from "cp.b" to
"memory write"
then I would have more sympathy for the change.
Any interface to dataflash would need the following operations:
* move from sdram to dataflash (with optional checksum write & byte granularity) * move from dataflash to sdram (with optional checksum check & byte granularity) * compare dataflash to sdram * list dataflash contents * fill dataflash * modify dataflash (with byte granularity) * erase dataflash (byte and partition) * enable/disable write protection of dataflash partition * print dataflash chip info
I see no reason to compare two dataflash areas and to compare two dataflash areas.
It should be possible to stored the environment in dataflash
The partitioning of the flash needs to take into account that the dataflash pages are not 2^n, they are 2^n + some small amount. The 256 page sectors should also be taken into account. The current partitioning is totally screwed for a linux-2.6 kernel. It would be good to be able to change the partition information dynamically so you can grow/shrink the linux-kernel size.
Possibly the pagesize should be migrated into the environment
[snip]
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
Technical support when I am not available: AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com AVR32 Applications Group mailto:avr32@atmel.com http://www.avrfreaks.net/; http://avr32linux.org/ http://www.at91.com/ ; ftp://at91dist:distrib@81.80.104.162/
In message 01f401c79e40$5e938450$0302a8c0@atmel.com you wrote:
Any interface to dataflash would need the following operations:
Good. We're back on a technical level and can discuss potential implementations.
Let me try to reformulate yur suggestions a bit, trying tomap these into my idea of a possible interface (just as base for future discussion):
- move from sdram to dataflash (with optional checksum write & byte
granularity)
* Copy from memory to dataflash
I see no reason why we should restrict the source of the copy to RAM. Also, we should use the term "copy" as "move" to me includes the operation of removing/erasing the source of the data.
What exactly do you mean by "checksum write"? The currently used "cp.b" interface doesn't do anything like this either, or does it?
- move from dataflash to sdram (with optional checksum check & byte
granularity)
* Copy from dataflash to memory.
Same remars as above.
- compare dataflash to sdram
* That would be a two step procedure, like currently used for other storage devices:
- Copy from dataflash to memory - compare two memory areas
No new command needed.
- list dataflash contents
What exactly do you mean here? Do you have any such function currently?
- fill dataflash
* That would be a two step procedure: - fill memory area (RAM) - copy from memory to dataflash
No new command needed.
- modify dataflash (with byte granularity)
* That would be a three step procedure:
- Copy from dataflash to memory - modify memory - copy from memory to dataflash
No new command needed.
- erase dataflash (byte and partition)
OK.
- enable/disable write protection of dataflash partition
OK.
- print dataflash chip info
OK.
I see no reason to compare two dataflash areas and to compare two dataflash areas.
Neither do I, as it boild down to the elementary functions listed above: copy to memory and compare in memory.
It should be possible to stored the environment in dataflash
Agreed.
It would be good to be able to change the partition information dynamically so you can grow/shrink the linux-kernel size.
The mtdparts command should support dataflash devices, too.
Possibly the pagesize should be migrated into the environment
What do you mean by that?
Best regards,
Wolfgang Denk
In message 01f401c79e40$5e938450$0302a8c0@atmel.com you wrote:
Any interface to dataflash would need the following operations:
Good. We're back on a technical level and can discuss potential implementations.
Let me try to reformulate yur suggestions a bit, trying tomap these into my idea of a possible interface (just as base for future discussion):
- move from sdram to dataflash (with optional checksum write & byte
granularity)
- Copy from memory to dataflash
I see no reason why we should restrict the source of the copy to RAM. Also, we should use the term "copy" as "move" to me includes the operation of removing/erasing the source of the data.
What exactly do you mean by "checksum write"? The currently used "cp.b" interface doesn't do anything like this either, or does it?
No but a way to common error is that the kernel is too large to fit into its allocated area and when the file system is written it overwwrites the end of the kernel. In my branch, I can set an environment variable crccheck=1 and if set, any cp.b to dataflash will add a checksum at the end. Any cp.b from dataflash will again compute the checksum and compare vs the checksum at the end.
Saves me a lot of confusing linux boot errors.
- move from dataflash to sdram (with optional checksum check & byte
granularity)
- Copy from dataflash to memory.
Same remars as above.
- compare dataflash to sdram
- That would be a two step procedure, like currently used for other
storage devices:
- Copy from dataflash to memory
- compare two memory areas
If I wanted to wear down my fingers by typing a lot of things, I would have choosen a career as a COBOL programmer.
Your suggestion has the unwanted side effect that you destroy the SDRAM in the process, and you have to keep in mind where you put intermediate copies.
Since dataflash sectors are 256 kB, and you should avoid putting linux/rootfs in the same sector as u-boot, code size is of much less importance than ease of use.
It is very important to reduce typing to a minimum.
Having to do 2-3 commands to do what can be done by one command and complicating the user experience in the process, is simply not acceptable.
No new command needed.
- list dataflash contents
What exactly do you mean here? Do you have any such function currently?
yes
- fill dataflash
- That would be a two step procedure:
- fill memory area (RAM)
- copy from memory to dataflash
No new command needed.
See above, ease of use, is much more important than code size.
- modify dataflash (with byte granularity)
- That would be a three step procedure:
- Copy from dataflash to memory
- modify memory
- copy from memory to dataflash
No new command needed.
- erase dataflash (byte and partition)
OK.
- enable/disable write protection of dataflash partition
OK.
- print dataflash chip info
OK.
I see no reason to compare two dataflash areas and to compare two dataflash areas.
Neither do I, as it boild down to the elementary functions listed above: copy to memory and compare in memory.
It should be possible to stored the environment in dataflash
Agreed.
It would be good to be able to change the partition information dynamically so you can grow/shrink the linux-kernel size.
The mtdparts command should support dataflash devices, too.
Possibly the pagesize should be migrated into the environment
What do you mean by that?
The pagesize of the dataflash varies between 264,528,1056 bytes depending on chip. It might be of interest to know this in a script.
Best regards,
It should be possible to remove any code accessing parallel flash, so the memory commands only access SDRAM. Many boards do not have any parallel flash, and this code will just bloat the binary.
Wolfgang Denk
--
Best Regards Ulf Samuelsson
In message 030501c79e4e$862cf740$0302a8c0@atmel.com you wrote:
What exactly do you mean by "checksum write"? The currently used "cp.b" interface doesn't do anything like this either, or does it?
No but a way to common error is that the kernel is too large to fit into its allocated area and when the file system is written it overwwrites the end of the kernel. In my branch, I can set an environment variable crccheck=1 and if set, any cp.b to dataflash will add a checksum at the end. Any cp.b from dataflash will again compute the checksum and compare vs the checksum at the end.
Why would that be needed? The U-Boot image itself is protected by a CRC32 checksum (by two, actually), so any such corruption will be detected automatically whenever you try to boot such an image.
Saves me a lot of confusing linux boot errors.
Of course checksums are very useful - but we already have them?
- That would be a two step procedure, like currently used for other
storage devices:
- Copy from dataflash to memory
- compare two memory areas
If I wanted to wear down my fingers by typing a lot of things, I would have choosen a career as a COBOL programmer.
U-Boot follows good old Unix philosophy here: prvode small and simple tools that implemnt just one task, but this reliably and efficiently, and provide ways to combine these tools easily to bigger things. Of course it is trivial to combine these steps into one "command" for the user.
Your suggestion has the unwanted side effect that you destroy the SDRAM in the process, and you have to keep in mind where you put intermediate copies.
Well, the same is stru for your current implementation, which also needs some buffers in RAM. The only difference is size and locatioon of the buffers. U-Boot usually remembers the "last used" image address, you normally you don't need to remember much. If in doubt, use variables.
Since dataflash sectors are 256 kB, and you should avoid putting linux/rootfs in the same sector as u-boot, code size is of much less importance than ease of use.
Primarily it's not a question of code size, but of interfaces.
It is very important to reduce typing to a minimum.
This is not one of my primary targets. It's not even very high on my list.
- list dataflash contents
What exactly do you mean here? Do you have any such function currently?
yes
What exactly does it do?
It should be possible to remove any code accessing parallel flash, so the memory commands only access SDRAM.
Agreed.
Many boards do not have any parallel flash, and this code will just bloat the binary.
"Many" is probably not correct if you look at the total of nearly 400 board configurations in the public U-Boot tree. But I agree that support for NOR flash should be configurable like other features, too.
Best regards,
Wolfgang Denk
Hi Ulf,
On Thursday 24 May 2007, Ulf Samuelsson wrote:
- compare dataflash to sdram
- That would be a two step procedure, like currently used for other
storage devices:
- Copy from dataflash to memory
- compare two memory areas
If I wanted to wear down my fingers by typing a lot of things, I would have choosen a career as a COBOL programmer.
We also have board with NAND FLASH only and the number of those boards will grow in the near future. The NAND command interface of course need a little more typing, but I always configure a few environment variables to update the images in the NAND FLASH. Something like:
=> setenv nload 'tftp 200000 board/u-boot.bin' => setenv nupdate 'nand erase 0 40000;nand write 200000 0 40000' => setenv nupd 'run nload nupdate'
A simple "run nupd" will update the image for me then. Not much typing involved.
BTW: I do the same with "normal" NOR FLASH images too, so it always boils down to some env variable commands. And if you have defined those variables in the default env variables, then all "users" can access them right away.
But I understand that your main concern is the *change* of the dataflash user interface. Yes, this is a problem and we can't really solve it. But a README and some env variables might make this change easier for the "users".
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de =====================================================================
Hi (and thanks for starting this discussion again),
On Fri, May 25, 2007 at 07:37:53AM +0200, Stefan Roese wrote:
We also have board with NAND FLASH only and the number of those boards will grow in the near future. The NAND command interface of course need a little more typing, but I always configure a few environment variables to update the images in the NAND FLASH. Something like:
=> setenv nload 'tftp 200000 board/u-boot.bin' => setenv nupdate 'nand erase 0 40000;nand write 200000 0 40000' => setenv nupd 'run nload nupdate'
Yes, yes :-) Here I agree with Wolfgand and Stefan. U-Boot should provide commands which reflect principle of device without any abstraction. Knowing principle means usually less bad surprises coming out from some hidden abstraction implementation details. That's good for power users.
Then we can use scripts in enviroment variables to save typing. This also gives wider range of commands built from 'primitives' Wolfgang described earlier. And typing 'printenv nupdate' gives a clue what this command actually does.
And for my grandfather it is possible to hide command line completely: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/27992
A simple "run nupd" will update the image for me then. Not much typing involved.
BTW: I do the same with "normal" NOR FLASH images too, so it always boils down to some env variable commands. And if you have defined those variables in the default env variables, then all "users" can access them right away.
If we implement mtdparts command on dataflash, user can even do: nand erase kernel0 nand write 0x10400000 kernel0 $filesize
This way you can copy to partition by its symbolic name (you do not need to remember offset) and this command also doesn't allow you to copy more than partition size. Partitioning is then done at one place respecting sector size and other constrains and it is also passed to kernel.
Best regards, ladis
On Wed, May 23, 2007 at 12:48:20PM +0200, Ulf Samuelsson wrote:
Things are broken, because Wolfgang refuses patches fixing problems on AT91 on principle. Removing support will cause more work for people because the existing patches to make things work will have to be modified...
Wolfgang is waiting for custodian to comment on patch. So far nothing happened. Please note that I'm the last one who wants to see support of this board removed. Also I'm all for applying patches you send to the mailing list (that serie 1,2,3,4,6,7,10,24) except for 24.noflash which seems a bit hackish (and yes I run into the very same problem this patch is trying to solve recently). If there is anything I can do to help them to get applied, just let me know.
What is the point of sabotaging others peoples efforts???
Removing non working code makes whole codebase cleaner. Sabotage is leaving non working code in repository without any will to at least consider applying patches... Anyway, who is responsible for AT91 code?
Best regards, ladis
Instead of wasting your time with the mainstream u-boot for the AT91, you could try out my patched u-boot-1.2.0-atmel at ftp://at91supp:support@81.80.104.162/ -> AT91 Third Party -> Linux_Host -> Source
I have a working dataflash support for most Atmel chips there (board = at91rm9200df). It also gets automatically built by the "buildroot" at the same location.
If you have any suggestions/patches, then I would be happy to add that.
Best Regards Ulf Samuelsson
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
On Wed, May 23, 2007 at 02:59:11PM +0200, Ulf Samuelsson wrote:
Instead of wasting your time with the mainstream u-boot for the AT91, you could try out my patched u-boot-1.2.0-atmel at ftp://at91supp:support@81.80.104.162/ -> AT91 Third Party -> Linux_Host -> Source
To be honest, mainstream u-boot works pretty well for me. I'm even using it on board without NOR flash (only serial and NAND) :-) It is just not as nice and featurefull as it could be.
I have a working dataflash support for most Atmel chips there (board = at91rm9200df). It also gets automatically built by the "buildroot" at the same location.
I'm prefering PTXdist which is building toolchain, rootfs and u-boot as well and is not uClibc centric...
If you have any suggestions/patches, then I would be happy to add that.
I'll look at your patches and try to split them to smaller chunks... Lets see if that's posible.
Best regards, ladis
On Wed, May 23, 2007 at 02:59:11PM +0200, Ulf Samuelsson wrote:
Instead of wasting your time with the mainstream u-boot for the AT91, you could try out my patched u-boot-1.2.0-atmel at ftp://at91supp:support@81.80.104.162/ -> AT91 Third Party -> Linux_Host -> Source
To be honest, mainstream u-boot works pretty well for me. I'm even using it on board without NOR flash (only serial and NAND) :-) It is just not as nice and featurefull as it could be.
I have a working dataflash support for most Atmel chips there (board = at91rm9200df). It also gets automatically built by the "buildroot" at the same location.
I'm prefering PTXdist which is building toolchain, rootfs and u-boot as well and is not uClibc centric...
Is that part of mainstream PTXdist, or do you apply your own patches?
My buildroot will build: at91-bootstrap, u.boot, linux, rootfs and scripts for u-boot tying things together, but is of course uClibc centric.
If you have any suggestions/patches, then I would be happy to add that.
I'll look at your patches and try to split them to smaller chunks... Lets see if that's posible.
In the ftp location, there is only a tarball.
I write a small utility which splits the diff into patches which will handle each file. Unfortunately, the way U-boot is structured, you will get files (like $(TOPDIR)/Makefile) which contains the result of many patches. I would prefer a structure where a Makefile fragment for the board is inside the board/<board> directory and the Makefile includes "board/*/*.mk". Much easier to add boards this way without beeing intrusive.
Best regards, ladis
Best Regards Ulf Samuelsson
On Wed, May 23, 2007 at 06:05:31PM +0200, Ulf Samuelsson wrote:
Is that part of mainstream PTXdist, or do you apply your own patches?
I'm applying my own patches directly to PTXdist's svn ;-)
My buildroot will build: at91-bootstrap, u.boot, linux, rootfs and scripts for u-boot tying things together, but is of course uClibc centric.
PTXdist does the same for me. Also builds toolchain. Those two projects does basicaly the same, but PTXdist design seems better for me. And because it is matter of personal preferences and of topic here, you are welcome to continue debate or ask questions on PTXdist mailing list. http://www.pengutronix.de/software/ptxdist/index_en.html
If you have any suggestions/patches, then I would be happy to add that.
I'll look at your patches and try to split them to smaller chunks... Lets see if that's posible.
In the ftp location, there is only a tarball.
I write a small utility which splits the diff into patches which will handle each file. Unfortunately, the way U-boot is structured, you will get files (like $(TOPDIR)/Makefile) which contains the result of many patches.
I did my best to check patches you sent to mailing list, tried to address suggestions (if any) and sent again to custodians. Lets see what happens. In case things move on I will continue stealing code from your ftp, verify on boards I have here and try to push in.
I would prefer a structure where a Makefile fragment for the board is inside the board/<board> directory and the Makefile includes "board/*/*.mk". Much easier to add boards this way without beeing intrusive.
That seems reasonable. But that rule would have to be more complex to support for example board/atmel/atstk1000/
Best regards, ladis
I did my best to check patches you sent to mailing list, tried to address suggestions (if any) and sent again to custodians. Lets see what happens. In case things move on I will continue stealing code from your ftp, verify on boards I have here and try to push in.
You are welcome.
I would prefer a structure where a Makefile fragment for the board is inside the board/<board> directory and the Makefile includes "board/*/*.mk". Much easier to add boards this way without beeing intrusive.
That seems reasonable. But that rule would have to be more complex to support for example board/atmel/atstk1000/
Obviously if Atmel had control over the board/atmel directory the board/atmel/atmel.mk fragment would include board/atmel/*/*.mk
Best Regards Ulf Samuelsson
PTXdist does the same for me. Also builds toolchain. Those two projects does basicaly the same, but PTXdist design seems better for me. And because it is matter of personal preferences and of topic here, you are welcome to continue debate or ask questions on PTXdist mailing list. http://www.pengutronix.de/software/ptxdist/index_en.html
Digging into OpenEmbedded at the moment, so I think I'll wait...
Best Regards Ulf Samuelsson
In message 002601c79d29$4da6de70$3125b10a@atmel.com you wrote:
Things are broken, because Wolfgang refuses patches fixing problems on AT91 on principle.
Nonsense.
Fix the known issues with your patches, submit these and get them accepted by the ARM custodian. If they don't break general U-Boot design criteria I will then just pull from the ARM repo.
But please fix the issues.
Removing support will cause more work for people because the existing patches to make things work will have to be modified...
What is the point of sabotaging others peoples efforts???
Instead of overwehemlimng everybody with a series of monster patches that change change U-Boot inside out you could try submitting small, isolated patches that fix the real problems step by step. If your patches are orthogonal, you could get at lest 90% of your stuff merged without any discussion, and then we could focus oin the remaining difficult parts.
Just because others don't agree with you does not mean the sabotage you. Robert Schwebel and others tried to explain this to you before.
If you cannot advance with brute force, try using diplomacy instead. Just insulting others is definitely not helpful.
Best regards,
Wolfgang Denk
In message 002601c79d29$4da6de70$3125b10a@atmel.com you wrote:
Things are broken, because Wolfgang refuses patches fixing problems on AT91 on principle.
Nonsense.
Let me rephrase this in a less sloppy manner.
Things are broken, because Wolfgang refuses [some critical] patches fixing problems on AT91 on principle. - Dataflash should not be treated as random access memory.
Fix the known issues with your patches, submit these and get them accepted by the ARM custodian. If they don't break general U-Boot design criteria I will then just pull from the ARM repo.
But please fix the issues.
I am not going to develop new user interface for the dataflash because I do not agree that it is neccessary to change the user interface and will leave the work to those that believe it is neccessary.
Until they do, it is not really meaningful to submit any of the other patches because without working dataflash/run from SDRAM support, no recent AT91 board will work.
Still, I have submitted a patch and will not submit anything more until I know if it is rejected or accepted. I know from Peter that it is in the queue and understand that since this is a new process for him, I will not put too much pressure.
Removing support will cause more work for people because the existing patches to make things work will have to be modified...
What is the point of sabotaging others peoples efforts???
Instead of overwehemlimng everybody with a series of monster patches that change change U-Boot inside out you could try submitting small, isolated patches that fix the real problems step by step. If your patches are orthogonal, you could get at lest 90% of your stuff merged without any discussion, and then we could focus oin the remaining difficult parts.
I did submit a patch which basically split a file, into two parts and moved them to different locations. This rendered about 50 emails and requests for total rewrites...
Just because others don't agree with you does not mean the sabotage you. Robert Schwebel and others tried to explain this to you before.
Disagreement with me is not sabotage, but I consider removing "board/at91rm9200dk" just because it does not work, sabotage. It forces additional work on me, and I fail to see any advantage.
If you cannot advance with brute force, try using diplomacy instead. Just insulting others is definitely not helpful.
At the moment I do not see how I can get patches accepted. Hope to be surprised...
Best regards,
Wolfgang Denk
--
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
Technical support when I am not available: AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com AVR32 Applications Group mailto:avr32@atmel.com http://www.avrfreaks.net/; http://avr32linux.org/ http://www.at91.com/ ; ftp://at91dist:distrib@81.80.104.162/
In message 006201c79d56$86d17250$17031b0a@atmel.com you wrote:
Things are broken, because Wolfgang refuses [some critical] patches fixing problems on
I don't refuse fixes, but we should not make things worse.
AT91 on principle. - Dataflash should not be treated as random access memory.
We have an agreement here. Dataflash is a serial device, no memory, and thus it should not be treated as random access memory.
Still, I have submitted a patch and will not submit anything more until I know if it is rejected or accepted.
You will never know if something you don't submit would get accepted or not.
Disagreement with me is not sabotage, but I consider removing "board/at91rm9200dk" just because it does not work, sabotage.
Nobody ever suggested this. Please read more carefully before insulting people with causeless accusations.
If you cannot advance with brute force, try using diplomacy instead. Just insulting others is definitely not helpful.
At the moment I do not see how I can get patches accepted. Hope to be surprised...
I just tried to show you a way (once again).
Best regards,
Wolfgang Denk
On Wed, May 23, 2007 at 05:44:53PM +0200, Ulf Samuelsson wrote:
In message 002601c79d29$4da6de70$3125b10a@atmel.com you wrote: Just because others don't agree with you does not mean the sabotage you. Robert Schwebel and others tried to explain this to you before.
Disagreement with me is not sabotage, but I consider removing "board/at91rm9200dk" just because it does not work, sabotage. It forces additional work on me, and I fail to see any advantage.
I proposed removing board/at91rm9200dk just because noone was able to review patch I sent. Here is reference: http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/27997 Date: Tue, 24 Apr 2007 12:37:12 +0200 Subject: [PATCH] Fix U-Boot base address depending on CONFIG_SKIP_LOWLEVEL_INIT
I have strong feeling (based on zero interest I received), that noone is interested in this board and therefore it is safe to remove support for it. Got my point?
Best regards, ladis
On Thu, May 24, 2007 at 11:14:13AM +0200, Ladislav Michl wrote:
On Wed, May 23, 2007 at 05:44:53PM +0200, Ulf Samuelsson wrote:
Disagreement with me is not sabotage, but I consider removing "board/at91rm9200dk" just because it does not work, sabotage. It forces additional work on me, and I fail to see any advantage.
I proposed removing board/at91rm9200dk just because noone was able to review patch I sent. Here is reference: http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/27997 Date: Tue, 24 Apr 2007 12:37:12 +0200 Subject: [PATCH] Fix U-Boot base address depending on CONFIG_SKIP_LOWLEVEL_INIT
I have strong feeling (based on zero interest I received), that noone is interested in this board and therefore it is safe to remove support for it. Got my point?
Hmm, probably not... Ulf, please read that patch I sent link to and give your ACK or NAK. I hope it will help to Peter (or Wolfgang) to decide if they want to apply it.
Thanks, ladis
participants (7)
-
Andy Fleming -
Jerry Van Baren -
Ladislav Michl -
Stefan Roese -
Timur Tabi -
Ulf Samuelsson -
Wolfgang Denk