[U-Boot-Users] AT91 NAND om AT91SAM9260EK

[Ulf Samuelsson]

> On 2/12/07, Ulf Samuelsson <ulf at atmel.com> wrote:
>> > On 2/12/07, Ulf Samuelsson <ulf at atmel.com> wrote:
>> >> >> It really does not make sense to test his patches only
>> >> >> on boards which does not use the dataflash.
>> >> >
>> >> > If that's all he has, then he has no other choice.
>> >>
>> >> He has always the choice of realizing that he maybe should
>> >> leave this possible improvement to someone capable of testing it
>> >> and concentrate on stuff which he can test.
>> >
>> > Yeah, that's a nice attitude. "Go away, we don't want your patches."
>> > Without even looking at them?
>>
>> I dont want patches that stops U-boot from functioning, that is correct.
>> If someone creates a patch which will improve functionality,
>> tries it out on a reasonable number of targets and then it
>> later turns out that there are some problems in corner cases,
>> I will not call for a public hanging.
> 
> I do agree with this -- all changes should be tested by _someone_.
> However, I don't think we should categorically reject all patches that
> haven't been tested by the author. If someone sees something which
> looks wrong, or an opportunity for optimization, not having the board
> in question shouldn't stop him from submitting a patch IMO. The board
> maintainer (or cpu/arch/subsystem maintainer, depending on the code in
> question) may test it himself, or send it to someone else for testing.
> 
> I disagree with your requirement that the author and the tester
> _always_ has to be the same person. Having done thorough testing,
> benchmarking, etc. and providing lots of nice numbers will of course
> increase the chances of acceptance, but none of it is an absolute
> requirement IMO.
> 

I do not require that the author and the tester is the same person,
If someone wants to fix something, it is perfectly OK
that someone else tests the patch.

What I have seen of the dataflash interface discussion, there is no plan
to test the dataflash, the goal was to get rid of the dataflash
from the memory commands, write something which
appeared to replace the dataflash command, ensure it compiled
and submit that.
And since the current interface is undesirable, those patches
would get a fast acceptance

This plan  leaves dataflash users to sort out the mess and with the current
time to get patches approved, at91 support would be broken for 
a long time.



Best Regards
Ulf Samuelsson                ulf at 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:
AT89 C51 Applications Group: mailto:micro.hotline at nto.atmel.com
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
FPSLIC Application Group: mailto:fpslic at atmel.com
Best AVR  link: www.avrfreaks.net