Re: [U-Boot-Users] Atmel DataFlash hooks.
On 1/26/07, Ulf Samuelsson ulfs@dof.se wrote:
Grant Likely wrote:
On 1/26/07, Ulf Samuelsson ulfs@dof.se wrote:
Are you prepared to make the fixes so that all Atmel development kits are supported by your patches. This means taking the atmnel patches from the Atmel ftp site and test them thoroughly on the appropriate boards.
No. If the board port is not in mainline, then it is the responsibility of the port maintainer to keep it synced.
Now with the new approach to introducing patches, I think the SAM9 patches should be sent in soon and you will have a significant number of boards that will break if you screw up.
Just because I write the patches doesn't mean they get accepted. They need to be acked by someone who has tested them first. I'm offering to take on the workload of writing the patches, but I cannot take on the testing. A number of the changes that I'm making right now (not just DataFlash) affect every single board, but I cannot test them all. Best I can do is make sure it works on the handful of boards I do have, post the patches for others to test, and only request inclusion in mainline when nobody reports problems with them.
For the stuff that *is* in mainline, I will of course make sure that the patches compile, but I cannot test them. I do not have the hardware to do so, nor will I spend the time to test boards that I have absolutely no involvement with.
That sound like a great idea, introduce significant modifications without testing...
The mods I'm interested in are the architectural changes which I can and will test. The DataFlash changes are collateral damage. The alternative for me is to break dataflash support without even attempting to providing a solution.
I think you should spend time on modifying things you *can* test.
Then how does *anybody* attempt to fix common code? Nobody can test all platforms.
Cheers, g.
Now with the new approach to introducing patches, I think the SAM9 patches should be sent in soon and you will have a significant number of boards that will break if you screw up.
Just because I write the patches doesn't mean they get accepted. They need to be acked by someone who has tested them first. I'm offering to take on the workload of writing the patches, but I cannot take on the testing. A number of the changes that I'm making right now (not just DataFlash) affect every single board, but I cannot test them all. Best I can do is make sure it works on the handful of boards I do have, post the patches for others to test, and only request inclusion in mainline when nobody reports problems with them.
I beleive a more proper approach is that If you cannot test the patches yourself, then you need to wait until someone confirms that the patch is actually working.
If noone tests the patch, that is an indication that noone is interested.
For the stuff that *is* in mainline, I will of course make sure that the patches compile, but I cannot test them. I do not have the hardware to do so, nor will I spend the time to test boards that I have absolutely no involvement with.
That sound like a great idea, introduce significant modifications without testing...
The mods I'm interested in are the architectural changes which I can and will test. The DataFlash changes are collateral damage. The alternative for me is to break dataflash support without even attempting to providing a solution.
I think you should spend time on modifying things you *can* test.
Then how does *anybody* attempt to fix common code? Nobody can test all platforms.
No, but you started off by saying you specifically are focusing on dataflash, and then you need to test on the primary target for the dataflash which is the AT91 series.
Cheers, g.
Best Regards, Ulf Samuelsson
On 1/26/07, Ulf Samuelsson ulfs@atmel.com wrote:
Now with the new approach to introducing patches, I think the SAM9 patches should be sent in soon and you will have a significant number of boards that will break if you screw up.
Just because I write the patches doesn't mean they get accepted. They need to be acked by someone who has tested them first. I'm offering to take on the workload of writing the patches, but I cannot take on the testing. A number of the changes that I'm making right now (not just DataFlash) affect every single board, but I cannot test them all. Best I can do is make sure it works on the handful of boards I do have, post the patches for others to test, and only request inclusion in mainline when nobody reports problems with them.
I beleive a more proper approach is that If you cannot test the patches yourself, then you need to wait until someone confirms that the patch is actually working.
If noone tests the patch, that is an indication that noone is interested.
Fair enough. I'm still going to push for change though. :)
For the stuff that *is* in mainline, I will of course make sure that the patches compile, but I cannot test them. I do not have the hardware to do so, nor will I spend the time to test boards that I have absolutely no involvement with.
That sound like a great idea, introduce significant modifications without testing...
The mods I'm interested in are the architectural changes which I can and will test. The DataFlash changes are collateral damage. The alternative for me is to break dataflash support without even attempting to providing a solution.
I think you should spend time on modifying things you *can* test.
Then how does *anybody* attempt to fix common code? Nobody can test all platforms.
No, but you started off by saying you specifically are focusing on dataflash, and then you need to test on the primary target for the dataflash which is the AT91 series.
Then I apologies and ask for forgiveness. I want to see some of the crazy side cases removed from the generic routines (and replaced with generic hooks where appropriate). I should have couched it more in those terms when I first brought it up.
Plus, looking deeper there are similar issues with MMC and flash writing which can probably be cleaned up at the same time (as discussed in a previous email)
Cheers, g.
Then how does *anybody* attempt to fix common code? Nobody can test all platforms.
No, but you started off by saying you specifically are focusing on dataflash, and then you need to test on the primary target for the dataflash which is the AT91 series.
Then I apologies and ask for forgiveness. I want to see some of the crazy side cases removed from the generic routines (and replaced with generic hooks where appropriate).
Why? Have you done any cost benefit analysis to the rest of the community? What will the world gain by such a change?
I should have couched it more in those terms when I first brought it up.
From my point of view, dataflash is the main case, and
everything else is a side case. I do not see any benefit in changing the MMI for dataflash. I rather see changes which will make dataflash more similar in use to std parallell flash. In my u-boot I can compare dataflash to SDRAM etc.
Plus, looking deeper there are similar issues with MMC and flash writing which can probably be cleaned up at the same time (as discussed in a previous email)
Cheers, g.
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
On 1/26/07, Ulf Samuelsson ulfs@atmel.com wrote:
No, but you started off by saying you specifically are focusing on dataflash, and then you need to test on the primary target for the dataflash which is the AT91 series.
Then I apologies and ask for forgiveness. I want to see some of the crazy side cases removed from the generic routines (and replaced with generic hooks where appropriate).
Why? Have you done any cost benefit analysis to the rest of the community? What will the world gain by such a change?
Simpler code, easier to maintain code, easier to add new storage devices, easier to have boards with multiple different storage technologies, smaller u-boot binaries.
Let me flip the question around: Do you like the current implementation where each storage technology (MMC, memmapped flash, and DataFlash; see my reply to Wolfgang) has it's own set of hooks in each memory access command?
How about this: 1. start with *not* changing the mmi and u-boot continues to pretend that DataFlash and MMC devices are memmapped. I may not like it, but I understand your position on this. 2. add a common interface for non-RAM and non-memorymapped devices that provides a single interface for commands like cp, md, bootm, etc to find out if an address is 'special' and what routines it should call to access them. 3. First migrate memmapped flash devices to the new interface to prove it is workable. 4. Second migrate over either MMC or DataFlash devices; based on who is able to provide test support (this does *not* touch the low level code. It introduces a shim between the commands and the device routines) 5. Migrate the remaining hooks. At this point, all the command functions should only have a single hook for access non-memmapped, non-RAM devices. All commands should now work on all devices. ie. md command can access MMC devices, something it cannot do now.
Of course there is design work that needs to be done, but in this stages approach, the first patch will show how the common interface is designed.
I should have couched it more in those terms when I first brought it up.
From my point of view, dataflash is the main case, and
everything else is a side case.
I only see it as a side case due to the way it is implemented. Now that I've looked deeper into the other commands, the same argument goes for MMC devices. If the implementation changes to use a common interface for these similar devices then it's not a side case any longer in my mind.
I do not see any benefit in changing the MMI for dataflash. I rather see changes which will make dataflash more similar in use to std parallell flash. In my u-boot I can compare dataflash to SDRAM etc.
Fair enough
Cheers, g.
Grant Likely wrote:
On 1/26/07, Ulf Samuelsson ulfs@atmel.com wrote:
No, but you started off by saying you specifically are focusing on dataflash, and then you need to test on the primary target for the dataflash which is the AT91 series.
Then I apologies and ask for forgiveness. I want to see some of the crazy side cases removed from the generic routines (and replaced with generic hooks where appropriate).
Why? Have you done any cost benefit analysis to the rest of the community? What will the world gain by such a change?
Simpler code, easier to maintain code, easier to add new storage devices, easier to have boards with multiple different storage technologies, smaller u-boot binaries.
Let me flip the question around: Do you like the current implementation where each storage technology (MMC, memmapped flash, and DataFlash; see my reply to Wolfgang) has it's own set of hooks in each memory access command?
How about this:
- start with *not* changing the mmi and u-boot continues to pretend
that DataFlash and MMC devices are memmapped. I may not like it, but I understand your position on this. 2. add a common interface for non-RAM and non-memorymapped devices that provides a single interface for commands like cp, md, bootm, etc to find out if an address is 'special' and what routines it should call to access them. 3. First migrate memmapped flash devices to the new interface to prove it is workable. 4. Second migrate over either MMC or DataFlash devices; based on who is able to provide test support (this does *not* touch the low level code. It introduces a shim between the commands and the device routines) 5. Migrate the remaining hooks. At this point, all the command functions should only have a single hook for access non-memmapped, non-RAM devices. All commands should now work on all devices. ie. md command can access MMC devices, something it cannot do now.
Of course there is design work that needs to be done, but in this stages approach, the first patch will show how the common interface is designed.
Now you are getting there... This is a workable approach.
I should have couched it more in those terms when I first brought it up.
From my point of view, dataflash is the main case, and
everything else is a side case.
I only see it as a side case due to the way it is implemented. Now that I've looked deeper into the other commands, the same argument goes for MMC devices. If the implementation changes to use a common interface for these similar devices then it's not a side case any longer in my mind.
I do not see any benefit in changing the MMI for dataflash. I rather see changes which will make dataflash more similar in use to std parallell flash. In my u-boot I can compare dataflash to SDRAM etc.
Fair enough
Cheers, g.
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
Hi Ulf,
On Saturday 27 January 2007 00:01, Ulf Samuelsson wrote:
Then I apologies and ask for forgiveness. I want to see some of the crazy side cases removed from the generic routines (and replaced with generic hooks where appropriate).
Why? Have you done any cost benefit analysis to the rest of the community? What will the world gain by such a change?
More readable and less error-prone code.
I should have couched it more in those terms when I first brought it up.
From my point of view, dataflash is the main case, and
everything else is a side case. I do not see any benefit in changing the MMI for dataflash. I rather see changes which will make dataflash more similar in use to std parallell flash. In my u-boot I can compare dataflash to SDRAM etc.
You can do this with NAND flash too. You just have to copy it to SDRAM before comparing.
Best regards, Stefan
-----Original Message----- From: glikely@gmail.com [mailto:glikely@gmail.com] On Behalf Of Grant Likely Sent: 26 January 2007 20:27 To: Ulf Samuelsson Cc: uboot; Peter Menzebach; Peter Pearse Subject: Re: [U-Boot-Users] Atmel DataFlash hooks.
For the stuff that *is* in mainline, I will of course
make sure that
the patches compile, but I cannot test them. I do not have the hardware to do so, nor will I spend the time to test
boards that I
have absolutely no involvement with.
I propose that part of each gatekeepers checking for a (non-trivial) patch is to request & collate testing of the patch to ensure it works on TBD % of the affected boards.
The patch would not be offered to the main tree until such testing has been done
Peter
On Monday 29 January 2007 14:44, Peter.Pearse wrote:
I propose that part of each gatekeepers checking for a (non-trivial) patch is to request & collate testing of the patch to ensure it works on TBD % of the affected boards.
Yes. This should definitely be the gatekeepers/custodians responsibility, to check if these patches have been tested successfully (and _not_ Wolfgangs).
The patch would not be offered to the main tree until such testing has been done
ACK.
Best regards, Stefan
In message 200701291547.44180.sr@denx.de you wrote:
Yes. This should definitely be the gatekeepers/custodians responsibility, to check if these patches have been tested successfully (and _not_ Wolfgangs).
This is one of the idea behind the custodians: it is expected that they have access to at least some of the related hardware.
For example, I don't even have access to a system with Dataflash on it, so how should I test it?
Best regards,
Wolfgang Denk
participants (5)
-
Grant Likely -
Peter.Pearse -
Stefan Roese -
Ulf Samuelsson -
Wolfgang Denk