[U-Boot-Users] AT91 NAND om AT91SAM9260EK

Ulf Samuelsson ulf at atmel.com
Mon Feb 12 01:26:48 CET 2007


> Dear Ulf,
>
> in message <00f201c74e25$71fdbf80$01c4af0a at Glamdring> you wrote:
>>
>> A contributor has no business changing  a board file
>> if he cannot reasonably verify that this will not break a board.
>
> You are right in principle, but live is not always black and white.
>
>> > I cannot help this, and we will definitely not wait to see an ACK for
>> > each and every board that is listed in the U-Boot tree.
>>
>> No, but as mentioned above, different parts of U-Boot should require
>> the submitter to focus on different subsets of boards.
>
> It ain't that easy. Take for example this stupid ". = .;" addition to
> the linker scripts that was needed  to  make  some  versions  of  the
> toolchain  happy  -  of course I add this to ALL boards without being
> able to test even half of them.

I think that is something which I could live with.
(This can be verified by building the board using MAKEALL)
Going in and writing a new UART driver and replacing the old one is not
something I could live with if they do not test this.

>
> And as mentioned before: if I have a global change  to  make,  and  I
> cannot   get  response  from  board  /  architecture  maintainers  in
> reasonable time, that change will be made globally, even if it breaks
> their boards. It's IMHO better to have a board  clearly  broken  than
> having all boards in N different patch states.

Global changes needs to go ahead, but I already point that out.

>
>> The proposed dataflash patches in our other heated discussion
>> for instance should only be accepted once proven that it actually
>> works with dataflash memory chips.
>> The proposer seemed to be happy if the stuff compiled...
>> Since that mainly affects Atmel boards, he should make
>> sure to get Atmel boards or sign up testers for it,
>> and have it tested before even thinking about submit patches.
>
> I disagree with you. You cannot expect any maintainer or custodian or
> other person volunteering to contribute to U-Boot code (or any  other
> free  software  project)  to "get Atmel boards or sign up testers for
> it". There are board maintainers,  and  it  is  their  task  to  help
> testing  things. And yes, this includes that they will sometimes have
> to help sorting out problems created by other people. That's  how  it
> has  been,  and  will remain, even if Atmel was shipping test systems
> for free.

I expect anyone that significantly modifies anything to ensure that
the submitted patch is tested on *something*.
I expect that the fact that things compiles is not considered a measure of 
success
for significant code changes.

>From this follows that anything which is specific to an Atmel target
and not used anywhere else cannot be tested on anything but an Atmel target.
Your changes above does not change code.

>
> Or do you intend to get a cmc_pu2 board or sign up testers for it  to
> check your patches? No, it will be me who has to run the tests, right?


No, I know that this is a weak point of the argument, and that
is why I would like to avoid changing significantly the contents of the 
patch.

The only change I see I do, is the bugfix in form of a type cast.
The current at45.c only exercises the internal resources
of the at91rm9200, so this fix should be enough to exercise
on any at9rm9200 board. There are board specific things
like which chip select to use etc, but all these parts are part
of other files, and not part of at45.c.

I really just change where the code is located in the source tree.
I have tested building cmc_pu2 to ensure that is not a problem.
Have also tested the patch so that non-Atmel arm targets and non-Arm targets
can build (Power PC target).

>
>> 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.

>
> Best regards,
>
> Wolfgang Denk
>


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 





More information about the U-Boot mailing list