ATMEL Custodians == /dev/null ??

Hello all,

it seems that Atmel is not willing to provide manpower for custodians.

I have spend considerable extra time to split my work towards the u-boot port of our new boards into separate patches for the AT91 SoCs.

I have sent them to the list some weeks ago only to see that exactly NOTHING happens to move them towards mainstream.

Unless something happens soon in that regard I will in the future refrain from investing extra hours to create patches for Atmel hardware.

With Best Regards,
Reinhard

i think the linux/open source team there saw some shrinkage, and/or the higher ups thought a change in direction away from working with the community/upstream was the way to go (and to simply maintain an internal fork perpetually). i'm of course just speculating based on their drop off in submissions in general across open source projects and have no direct knowledge of anything.

from the developers pov, they probably dont have much choice. when the economy shrinks and your boss says that is no longer your job, then it's a hard choice. do the right thing or continue to eat ;).

if the maintainers are effectively dead, then i'd suggest someone (i.e. Wolfgang) hand the custodian role over to someone willing to do the work. employment by the company who owns the processor in question only goes so far. vastly more important are the people doing the actual work and in this case, it seems like that person might be you vs anyone with @atmel.com in their e- mail address.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100729/2f9cd3c0/attachment.pgp

Dear Mike Frysinger,

Full ACK.

Full ACK again.

Reinhard, do you volunteer? For AVR32? Or also for AT91?

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Houston, Tranquillity Base here.  The Eagle has landed.
                                                    -- Neil Armstrong

Hello Wolfgang, hello Mike,

that would be a possibility. However I was more thinking in the way, that since there are practically no other contributors right now that Wolfgang would take my patches directly to mainstream unless someone protests them in due time.

Apparently no one is testing them on other AT91 boards (are there any except for Atmel's EKs?); no one critisizes any coding issues :). Naturally those patches work on the AT91SAM9XE-EK (which I use as a substitute as long as our own hardware is not available - mid-August now). After that, I can still test on both.

Then I consider AVR32 a dead architecture for LinuX based systems, since all LinuX-able Variants (AP700x) are "not recommended for new design".

And I am still fighting with GIT in terms of producing Patches and reworking Patches, if, for example I later find an even "nicer" solution or continued testing shows up problems. Of course I read the man pages, read several articles about git, but they usually fail to explain the idea and inner working of a command. Sometimes commands have (for me) unexpected effects which are hard to undo.

As a custodian I sure would need more help and advice on how to handle certain situations. I would (for start) have to rely on advice from Wolfgang or someone else.

And as a custodian for AT91 I would mostly collect my own patches, <sarcasm> review them, apply them after 2 weeks of nobody commenting on them </sarcasm> and once in a while ask Wolfgang to pull them to mainstream?

Of course, hopefully more people would volunteer to work on that architecture there are still lots of places where coding style can be improved, not to mention the vast number of AT91 drivers using #define registers access instead of structures. Also when I tried to cleanup the multi-wrapped defines for controller adresses I noticed that this issue spans the whole AT91 files.

If, after considering my comments above, you still think you really need a custodian for AT91, I am game for it.

With Best Regards,
Reinhard

PS: from messages in Atmel forums I notice that many users use some branched-off old versions of u-boot and (almost naturally) have issues with that. -------------- next part --------------
A non-text attachment was scrubbed...
Name: reinhard_meyer.vcf
Type: text/x-vcard
Size: 370 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100805/8967afaf/attachment.vcf

Dear Reinhard Meyer,

Am 05.08.2010 11:14, schrieb Reinhard Meyer:

[snip]

[snip]

Yes, AVR32 seems to be a dead architecture but I do think mainline U-Boot support for it has its right to exist.

We have two devices using the AP7000. We do think about a major U-Boot update for at least one of these devices. With latest patches from Haavard the avr32 architecture is usable again and we may switch from 2008.10 to 2010.06.

On the other hand there are a lot of evaluation kits still available. I think they are used at least by hobbyists.
The main statement is to not loose off avr32 support in near future no matter what way atmel decides for his products. But therefore it is necessary to get avr32 working in next release. I know 2010.09 is closed but it would be great to get the "simple paging" patch into 2010.09. Nevertheless 2010.12 should be doable for the paging stuff and maybe atmel_usart too.

[snip]

I have an at91rm9200 based eval kit at home and plan to do some effort to get this board mainline (but since january I work on arm-linux toolchain for my mac ...). Therefore I can do testing for some at91 drivers in near future.

We plan to use some at91sam based cpu's for further products. Therefore I could do testing and/or reviews at work too (maybe end of this year).

If we do switch to 2010.06 I plan to do some work on atmel_usart which I think is a shared driver between avr32 and at91.

regards

Andreas Bie?mann

I was not meaning to remove support, just pointing out that a custodian might not be necessary (anymore). Since it is unlikely the many patches pop up... Patches for common drivers for AVR32 and AT91 will be mainlined the AT91 way, and maybe testing them always on AVR32 should not be required.

I had the ATNGW100 working fine with 2010.06, the patches from June 4th onwards still linger around.

I think the RM9200 is quite different from the bunch of the SAM9 ones.

That would help, of course.

Yes, and because of that its needs testing on both architectures. What I don't like in the current AVR32 and AT91 drivers is the several times and in different .h files wrapping of the peripherals' hardware address into new defines.

Reinhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reinhard_meyer.vcf
Type: text/x-vcard
Size: 370 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100805/5f4f725f/attachment.vcf

Hi Reinhard,

Le 05/08/2010 11:14, Reinhard Meyer a ?crit :

I sent patches to update our cpuat91 board 3 times, so you are not the only one trying to get patches merged for AT9 :-).

If needed, I also can help you for AT91 (I have board using :
at91rm9200, at91sam9260 and at91sam9g20).

Eric

rebasing in my own branch tends to be how i manage my own changes. this allows you to merge commits into one, change the order of things, edit changes in he middle of a tree, or drop commits. but this is obviously for your own branches only and not for public branches other people are working off of.

i can probably answer most of your git related questions ... not sure if Wolfgang prefers them to be answered off list ...

go for it
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100805/90ff1f99/attachment.pgp

Dear Mike Frysinger,

I recommend to use comon sense - most stuff can go over the list, so everybody can benefit from it. If you feel it's a generic topic, you are also welcome to add thjis to the wiki, and post a link here. If you have lenghty examples that are really uninteresting for anybody else you can run it off list.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Celestial navigation is based on the premise that the  Earth  is  the
center  of  the  universe.  The  premise is wrong, but the navigation
works. An incorrect model can be a useful tool.   - Kelvin Throop III

Hi Wolfgang, Mike,

considering that both AVR32 and AT91 share most of the peripheral hardware building blocks, and therefore share the drivers, it seems to make sense to have an atmel custodian tree instead of avr32 and at91. Each change to a shared
driver must (at least with MAKEALL) be checked for both architectures and adding it to both trees would make life unnecessary complicated...

Best Regards,
Reinhard

yes, but the cores are going to be radically different. so i imagine you'd be fine with the peripheral drivers, but not the avr32 core. it's your time though of course.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100806/1cb5b623/attachment.pgp

Dear Mike,

So what areas do we have?
1. AVR32 core - avr32 custodian
2. ARMxxx core - ARM custodian
3. AT91 core specifics and drivers - at91 custodian
4. Atmel peripheral hardware drivers - avr32 AND at91 custodians

Area 1. there will be not much new development for AVR32-AP700x, since Atmel declared the AP700x NRFD. None of the UC3 Variants will be likely to use u-boot. Only one of them allows significant external ROM and RAM. Picking up the few commits for AVR32 core, should not be much work.

Area 3. I see nothing specific right now for the ARM core itself. In arch/.../at91
are some "drivers" that manage at91 specific stuff like peripheral inits, clock, (now my at91sam9xe-specific eflash driver), led(!), reset, timer. Nothing really
ARM core related. It might even be discussed whether some of the files even belong in this directory...

Area 4. any commit in this area would need both custodians' work before it can go mainline. Wolfgang pulling from both trees might sometimes give him extra work because of conflicts.
Or we postulate that common driver work goes through the at91 custodian only.

And yes, taking care of AVR32 as well looks like extra work at first, but it seems
to me that the extra work involved for Area 4 is not less if there are two trees.

Reinhard

picking up random commits from a mailing list isnt exactly the same as being familiar with a core architecture and knowing whether the changes in question are even correct. any patch monkey can save an e-mail and run git am on it. a real custodian should understand what's going on.

it isnt that hard to talk to each other on a public mailing list. as for conflicts, Wolfgang is good about telling someone they need to redo their changes because of conflicts. so if he pulled at91 and then pulled avr32 and hit a conflict, the avr32 custodian gets to resolve it.

but again, i have no interest in either arch, so what people do with them doesnt really matter to me. i'm just providing general advice.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100806/09a245a6/attachment.pgp

Dear Mike Frysinger,

You were right, _if_ we had active at91 and avr32 custodians. Unfortunaltey, we have none for avr32 and a non-responsive one for at91. So if we find a volunteer who handles it both in one tree that can be only an improvement. And if it should turn out later that two separate repos would be better, well, then we split them again.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Have you lived in this village all your life?"        "No, not yet."

Dear Reinhard Meyer,

I'm fine with that.

You take this, then? :-)

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"...one of the main causes of the fall of the Roman Empire was  that,
lacking  zero,  they had no way to indicate successful termination of
their C programs."                                     - Robert Firth

Dear Reinhard Meyer,

I have no chance to test anything, so rather leave responsibility with someone who actually can do at least some testing, and who has an understanding of the architecture.

No problem.

Right. And please don't forget the testing :-)

If you are willing to take that responsibility, please send me (off list) your SSH public key so I can give you write permission to the custodian repository. And thanks in advance.

I'd be happy to have working support for them in mainline.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The rule on staying alive as a program manager is to give 'em a  num-
ber or give 'em a date, but never give 'em both at once.

Wolfgang Denk wrote:
Dear Wolfgang,

Sure there are different levels of testing possible.

1. If the patch is simple enough reasoning might be sufficient.
2. If its a new driver, it has to be proven to work (reliably) on at least one board (other
boards cannot break since they won't use it), and it should be reasonably obvious that the new
code is not board specific, or (if REALLY unavoidable) that board specific parts are at least
obvious by using #if defined(CONFIG_<board>)
3. If its a rework, it should be shown working on at least one board in each architecture (if it
is a shared source)
4. If nobody but the submitter is able/willing to test the patch, what do we do then?
n. of course all must survive the MAKEALL test.

I'll collect Q&A in a text file, maybe one can make a FAQ out of it later.

That's implicit on my own patches. They are either of type 2. or type 3. as above ;)

Yes. And the first Qs:
Q: how do I get a key pair, and where do I find it?
A: I'll figure that out tomorrow, I think my system has generated one during install...
Q: it should be save when everyone knows the public part, why not on the list?
A: its not necessary...

It is actually working in the mainline, I compiled ATNGW100 and AT91SAM9XE-EK
out of mainline and both worked out of the box (apart from that AVR32 CFI issue).

I should put our new board's support files as patches out soon, even if they are not final, to
give others a glimpse how to add the new features to their boards. That raises the next few Qs:
Q: who resolves conflicts in very common files like MAINTAINERS, boards.cfg etc, they
are bound to have merge conflicts when you pull?
Q: boards.cfg does not appear to be completely sorted, its not even sorted by ARCH.
And using the vi command does sort the header of that file, too....

Best regards,

Reinhard

use ssh-keygen to create one in ~/.ssh/. send Wolfgang the .pub file. configure your ~/.ssh/config to use that key when connecting to the denx servers.

it probably only generated a host key pair for sshd and you dont want to go mixing those

right, no one cares :P
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100807/34812983/attachment.pgp

Dear Reinhard Meyer,

Might. But things might go wrong. Turn around - Murphy is standing right behind you.

Adding a bad driver can break ALL boards. You just have to mess up the Makefile.

CONFIG_<board> should always be avoided and replaced by an appropriate CONFIG_<feature>.

That's what happens often, and turns out to be unreliable often, too.

If nobody complains, it goes in.

If that's the only problems, and if your code is based on reasonably current versions, I will fix these.

The file is mostly sorted, as described in the comment.

Not if you place the cursor (i. e. the '.') on the first non-comment line.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Every solution breeds new problems.

I would love to work with Reinhard and others to test and integrate stuff for AVR32 NGW100 board. My target is to get current 2010.06 with patches really working on this board. Currently, I see two problems:

1) One cannot save the environment due to wrong flash address stuff (recent patch from Haavard Skinnemoen should fix that)
2) With a completely erased flash, at least 2008.10 and 2010.06 detect the flash to be 3.2Gig or 4Gig and crash. 1.3.3 is fine.

When the U-Boot environment settings block was not erased, they boot fine but cannot erase nor write flash.

I'm going to test the solution for 1) and I'm still investigating 2).

Then, I'll push that version with the required patches to OpenWRT to replace the ancient 1.3.3 with LZMA patches that is used now. After that, I'll wait until (2010.06&patches) lands in a new release and push that to OpenWRT as well.

Bas.

explicitly cc-ing the atmel guys just so there's no surprise when at91/avr32 have been handled over to someone else without their explicit ACK ... -mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100807/a9e29901/attachment.pgp

So...what exactly are you Cc'ing us on?

Haavard

read the thread
-mike

That sort of brings us back to my original question, doesn't it?

<reads the archives>

Ok, so there are complaints about the non-responsiveness of some of Atmel's custodians and a wish for someone to take over. Fine by me, I guess, since I've already indicated I'm probably not the right person for the job anymore. I can't speak for the AT91 team, however.

But it does seem kind of rude to just hand everything off without Cc'ing any of the maintainers in question. Perhaps they would respond more quickly if people actually send e-mail to them?

Btw, I'm not ranting at you, Mike. Thanks for letting me know about the discussion, although I would have preferred a bit more context...

For the record, the thread seems to be this one, but I seem to be unable to find the start of it...

http://lists.denx.de/pipermail/u-boot/2010-August/074769.html

Haavard

i think the supposition might have been that active maintainers watch the lists. or it was an accidental oversight from the start.

i'm not terribly inclined to summarize a topic i'm not vested in when i'd too have to review the archives in order to do so. nothing personal of course.

pipermail blows at threading across months. you'd think they'd fix something so extremely basic ...

at any rate, gmane shows it nicely:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/81812
-mike

Dear Haavard Skinnemoen,

Rude? send e-mail to them?

It's not that I'm going to hand off (note that nothing has happened yet) anything from any active custodian.

First, I have poked them a number of times, both on and off list.

Second, they are subscribed to this list, and supposed to read the traffic. Especially if addresses directly in the Subject they should notice that, right?

Third, there have been patches posted that clearly fall in their domain, and there is zero response: no comment, no activity in the custodian directory, no pull request, nothing.

Finally, I have to admit that I have been a bit sceptic right from the beginning to assign custodianship to someone who has no track record as developer in the community. But obviously Atmel would be in the best positition to provide decent support for their chips. At least that was my hope.

I am seriously sick with the current situation. We have a number of AT91 and AVR32 related patches sitting there with nobody taking care of them. No life signs of any custodian or anybody else from Atmel.

But then there are people available who are actively working with these chips, who post fixes and other patches, and who even volunteer to take the burden of maintaining the tree.

Guess what I'll do? Continue to wait that some vendor wakes up?

Just have a look at the "References:" headers, and look up the first one in gmane - just append the message ID to http://mid.gmane.org/

==> http://mid.gmane.org/4C50E124.2000807 at emk-elektronik.de

==> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/81812

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Software suppliers are trying to make their  software  packages  more
``user-friendly''.  .  .  .  Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover.                                               - Bill Gates

I mean rude _not_ to send e-mail to them.

It's not that I necessarily oppose such a hand-off either.

I haven't received any such pokes from you in a long time.

I used to be subscribed to a whole bunch of lists, but after hitting around 70,000 unread e-mail, I decided to unsubscribe from most of them, including u-boot and LKML.

Of course, this is also the main reason why I wanted to resign as a custodian; I felt I hadn't been able to do a proper job for some time. But this makes it especially odd that I wasn't Cc'd on the discussion about custodianship.

If I wasn't Cc'd, that would explain it. Of course, it's always best if maintainers follow all relevant mailing lists, but sometimes it's just not an option, not if you're working on several other projects besides u-boot.

Atmel should definitely be in a good position for that, at least in theory. But the reality is that people need to do other things too, and it's difficult to justify spending a lot of time on the boot loader when there are more customer-focused tasks at hand.

And then there's the whole cost/benefit thing. I've been arguing quite enthusiastically for the benefits of getting things upstream earlier, but I've lately started to realize that maybe we're not really getting all that much in return for the work we've been putting in. Especially when we're forced to implement a bloody VM subsystem just to fix a regression someone else introduced.

Again, not Cc'ing the relevant maintainers might be an explanation, though I'm not saying I'm sure it's the _right_ explanation.

Sure, if someone outside Atmel wants to take over the AVR32 tree, I'm all for it. I would really appreciate to be Cc'd on the discussion, however. And I can be available to help whoever takes over the custodianship if there's anything avr32-specific they can't figure out.

Again, I'm not speaking for the AT91 team.

Not commenting on this beyond what I said above.

Thanks, I'll have a look at those. Please forgive me for following the link on your mailserver ;-)

Haavard

Dear Haavard Skinnemoen,

I'm not talking about you here. You have clearly indicated that you resign as custodian, which I have accepted. So why should I poke you?

A custodian who is not subscried on the mailing list? How is this supposed to work? I have to admit that I never expected somebody would come up with such a concept.

It has never been a requirement to Cc: the custodian. It is up to the custodian to pick up the work that falls into hiw bailiwick, including for example global changes that happen to affect his architecture / subsystem. Of course this requires that you are subscribed. And that you actually *read* the list, at leats to the extend that you recognize certain buzzwords in the Subject: lines, like the name of the architure you feel responsible for.

Your idea of working as a maintainer is very much different from mine, and from the actual requirements for the job.

mailman has certain restrictions and limitations, but I'm not an expert in that field. If you know better solutions, then suggestions are welcome.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To be a winner, all you need to give is all you have.

I didn't resign _that_ long ago.

It actually works on Linux, where people know that they need to Cc the maintainer to get his attention. So you can actually maintain a dozen drivers across half a dozen subsystems without getting completely bogged down with e-mail. If you just drop a patch into the LKML firehose, it will most likely be ignored unless akpm picks it up and pokes the relevant maintainer.

In other words, being a u-boot custodian takes a lot more work than being a Linux maintainer. Combine this with what I said before about it being difficult to justify spending a lot of time keeping the bootloader limping along, and it's not good news if you want more vendor involvement.

That seems to be the case, yes.

Haavard